From report at bugs.python.org  Tue Jan  1 02:35:45 2019
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 01 Jan 2019 07:35:45 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
Message-ID: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

The typing docs for List includes a note to use generic collection types, but lists AbstractSet and Mapping which aren't generally replacements for a List. It would be better to remove those types from the List note and add corresponding ones to Dict and Set which are currently lacking it.

Additionally, some examples in the typing docs are in violation of the above stated preference, using Lists and Dicts as parameters.

----------
assignee: docs at python
components: Documentation
messages: 332842
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Improve typing docs wrt abstract/concrete collection types
type: enhancement

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

From report at bugs.python.org  Tue Jan  1 02:37:37 2019
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 01 Jan 2019 07:37:37 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546328257.95.0.332244291324.issue35631@roundup.psfhosted.org>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
keywords: +patch
pull_requests: +10774
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan  1 02:37:42 2019
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 01 Jan 2019 07:37:42 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546328262.89.0.161788888569.issue35631@roundup.psfhosted.org>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
keywords: +patch, patch
pull_requests: +10774, 10775
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan  1 02:37:47 2019
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 01 Jan 2019 07:37:47 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546328267.95.0.272864785187.issue35631@roundup.psfhosted.org>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
keywords: +patch, patch, patch
pull_requests: +10774, 10775, 10776
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan  1 02:58:02 2019
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Tue, 01 Jan 2019 07:58:02 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546329482.43.0.676426916.issue35631@roundup.psfhosted.org>


Ville Skytt? <ville.skytta at iki.fi> added the comment:

(s/generic collection types/abstract collection types/ in the initial message)

----------

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

From report at bugs.python.org  Tue Jan  1 03:28:25 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Tue, 01 Jan 2019 08:28:25 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1546331305.89.0.615373266777.issue35431@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

Thanks @mark.dickinson. As @rhettinger suggested, I'll write a basic function that uses division and works in O(k) for now. It's holiday season but hopefully @kellerfuchs will respond by then, and in the meantime I'll write more tests other than pascal's identity and corner cases.

----------

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

From report at bugs.python.org  Tue Jan  1 03:58:06 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 01 Jan 2019 08:58:06 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546333086.44.0.743078292607.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
Removed message: https://bugs.python.org/msg332828

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

From report at bugs.python.org  Tue Jan  1 03:58:41 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 01 Jan 2019 08:58:41 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546333121.23.0.958574497795.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
Removed message: https://bugs.python.org/msg332827

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

From report at bugs.python.org  Tue Jan  1 03:59:22 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 01 Jan 2019 08:59:22 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546333162.84.0.195665001683.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


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

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

From report at bugs.python.org  Tue Jan  1 13:02:52 2019
From: report at bugs.python.org (thautwarm)
Date: Tue, 01 Jan 2019 18:02:52 +0000
Subject: [issue35632] support unparse for Suite ast
Message-ID: <1546365770.39.0.971588675244.issue35632@roundup.psfhosted.org>


New submission from thautwarm <yaoxiansamma at gmail.com>:

Although `Suite` is not an actual AST used in CPython, it's quite useful when performing some code analysis. 

`Suite` is a sequence of statements which could be used to represent a block whose context inherits from outside block's.

Also, the document said it's useful in Jython.

I wonder if we could support `unparse` for Suite through making a tiny modification to

https://github.com/python/cpython/blob/master/Tools/parser/unparse.py

def _Suite(self, tree):
      for stmt in tree.body:
         self.dispatch(stmt)

----------
components: Demos and Tools
messages: 332845
nosy: thautwarm
priority: normal
severity: normal
status: open
title: support unparse for Suite ast
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Jan  1 13:09:10 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 01 Jan 2019 18:09:10 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
Message-ID: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>


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

test_eintr fails on AIX since fcntl functions were modified
In issue35189 the fnctl() module was modified so that the EINTR interruption should be retried automatically.

On AIX the test for flock() passes, but the test for lockf() fails:

 ======================================================================
> ERROR: test_lockf (__main__.FNTLEINTRTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/data/prj/python/git/python3-3.8/Lib/test/eintrdata/eintr_tester.py", line 522, in test_lockf
>     self._lock(fcntl.lockf, "lockf")
>   File "/data/prj/python/git/python3-3.8/Lib/test/eintrdata/eintr_tester.py", line 507, in _lock
>     lock_func(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
> PermissionError: [Errno 13] Permission denied
>

Researching...

----------
components: IO, Tests
messages: 332846
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_eintr fails on AIX since fcntl functions were modified
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Jan  1 18:59:32 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Tue, 01 Jan 2019 23:59:32 +0000
Subject: [issue35621] asyncio.create_subprocess_exec() only works with main
 event loop
In-Reply-To: <1546210778.19.0.43686311162.issue35621@roundup.psfhosted.org>
Message-ID: <1546387172.7.0.442538095783.issue35621@roundup.psfhosted.org>


Change by Stefan Seefeld <stefan at seefeld.name>:


----------
nosy: +stefan

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

From report at bugs.python.org  Tue Jan  1 19:12:54 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 02 Jan 2019 00:12:54 +0000
Subject: [issue35527] Make fields selectively immutable in dataclasses
In-Reply-To: <1545167633.41.0.788709270274.issue35527@psf.upfronthosting.co.za>
Message-ID: <1546387974.33.0.310266178925.issue35527@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi @rhettinger, this is similar to #33474.

I started working on an implementation of this.

With the implementation you propose, if a field has both init=True and frozen=True, it may be set after the creation of the instance:

        @dataclass
        class Person:
            ssn: int = field(init=False, frozen=True)
            name: str

        p = Person(name='foo')
        p.name = 'bar'
        p.ssn = 1234

Wouldn't this conflict with the purpose of safe hashing?

I think it would need __setattr__ to be:

      def __setattr__(self, attr, value):
            if attr in {'ssn', 'birth_city'}:
                 raise TypeError(
                     f'{attr!r} is not settable after initialization')
            return super(cls, self).__setattr__(self, name, attr)

wouldn't it?

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Tue Jan  1 19:41:14 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 02 Jan 2019 00:41:14 +0000
Subject: [issue35577] side_effect mocked method lose reference to instance
In-Reply-To: <1545664740.73.0.712150888896.issue35577@roundup.psfhosted.org>
Message-ID: <1546389674.0.0.241829722582.issue35577@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Is there a problem with:

from unittest import mock

class SomeClass:
    def do_something(self, x):
        pass

def some_function(x):
    obj = SomeClass()
    y = obj.do_something(x)
    return y

def do_something_side_effect(self, x):
    print(self)
    return x

def test_some_function():
    with mock.patch.object(SomeClass, "do_something", do_something_side_effect):
        assert some_function(1)

?

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Tue Jan  1 20:04:35 2019
From: report at bugs.python.org (iceboy)
Date: Wed, 02 Jan 2019 01:04:35 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
Message-ID: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>


New submission from iceboy <spam at iceboy.org>:

Using the multidict package on pypi to illustrate the problem.

Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import multidict
>>> d = multidict.CIMultiDict([('a', 1), ('a', 2)])
>>> def foo(**kwargs): pass
... 
>>> foo(**d)
>>> foo(**{}, **d)

Python 3.6.7 (default, Oct 21 2018, 08:08:16) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import multidict
>>> d = multidict.CIMultiDict([('a', 1), ('a', 2)])
>>> def foo(**kwargs): pass
... 
>>> foo(**d)
>>> foo(**{}, **d)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() got multiple values for keyword argument 'a'

(1) foo(**d)
(2) foo(**{}, **d)

(1) works fine in both versions but (2) only works in Python 3.5 but raises TypeError in Python 3.6. This should be a regression. We should either make both expressions work or raises error.

----------
messages: 332849
nosy: iceboy
priority: normal
severity: normal
status: open
title: kwargs regression when there are multiple entries with the same key
versions: Python 3.6

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

From report at bugs.python.org  Tue Jan  1 20:22:00 2019
From: report at bugs.python.org (beruhan)
Date: Wed, 02 Jan 2019 01:22:00 +0000
Subject: [issue35608] python3 multiprocessing queue deadlock when use thread
 and process at same time
In-Reply-To: <1546052022.11.0.920360901938.issue35608@roundup.psfhosted.org>
Message-ID: <1546392120.85.0.896500642294.issue35608@roundup.psfhosted.org>


beruhan <baiwenping00 at gmail.com> added the comment:

I also tested on windows 10,it worked normally.But when I run it under ubuntu16.04,It will blocked.my python version is 3.6.5

----------

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

From report at bugs.python.org  Tue Jan  1 20:57:46 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jan 2019 01:57:46 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394266.71.0.601260250807.issue35630@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 7e3fb40b923cb09ecc67816d3191197868593737 by Benjamin Peterson (Suriyaa ???) in branch 'master':
closes bpo-35630: Use code tag for 'python3' in 'README.rst' (GH-11394)
https://github.com/python/cpython/commit/7e3fb40b923cb09ecc67816d3191197868593737


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jan  1 20:58:15 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 01:58:15 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394295.09.0.272319398966.issue35630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10777

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

From report at bugs.python.org  Tue Jan  1 20:58:19 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 01:58:19 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394299.21.0.761977858824.issue35630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10777, 10778

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

From report at bugs.python.org  Tue Jan  1 20:58:23 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 01:58:23 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394303.42.0.965407659216.issue35630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10778, 10779

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

From report at bugs.python.org  Tue Jan  1 20:58:27 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 01:58:27 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394307.69.0.405313062472.issue35630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10779, 10780

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

From report at bugs.python.org  Tue Jan  1 20:58:31 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 01:58:31 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394311.71.0.662861546159.issue35630@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10779, 10780, 10781

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

From report at bugs.python.org  Tue Jan  1 21:01:58 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jan 2019 02:01:58 +0000
Subject: [issue35623] Segfault in test_bigmem.ListTest.test_sort
In-Reply-To: <1546218988.78.0.27697670498.issue35623@roundup.psfhosted.org>
Message-ID: <1546394518.74.0.638889878533.issue35623@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset f8b534477a2a51d85ea1663530f685f805f2b247 by Benjamin Peterson (sth) in branch 'master':
closes bpo-35623: Fix integer overflow when sorting large lists (GH-11380)
https://github.com/python/cpython/commit/f8b534477a2a51d85ea1663530f685f805f2b247


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jan  1 21:02:07 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jan 2019 02:02:07 +0000
Subject: [issue35623] Segfault in test_bigmem.ListTest.test_sort
In-Reply-To: <1546218988.78.0.27697670498.issue35623@roundup.psfhosted.org>
Message-ID: <1546394518.74.0.638889878533.issue35623@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset f8b534477a2a51d85ea1663530f685f805f2b247 by Benjamin Peterson (sth) in branch 'master':
closes bpo-35623: Fix integer overflow when sorting large lists (GH-11380)
https://github.com/python/cpython/commit/f8b534477a2a51d85ea1663530f685f805f2b247


----------
nosy: +benjamin.peterson
pull_requests: +10782
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jan  1 21:03:57 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 02:03:57 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394637.18.0.06042759702.issue35630@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 513fab2c67365e1693216dd59e4df0a5f6bfeb26 by Miss Islington (bot) in branch '3.7':
closes bpo-35630: Use code tag for 'python3' in 'README.rst' (GH-11394)
https://github.com/python/cpython/commit/513fab2c67365e1693216dd59e4df0a5f6bfeb26


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jan  1 21:04:27 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jan 2019 02:04:27 +0000
Subject: [issue35630] Missing code tag for "python3" in README.rst
In-Reply-To: <1546289591.73.0.0479486789763.issue35630@roundup.psfhosted.org>
Message-ID: <1546394667.77.0.575410208678.issue35630@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset de66b8d498e47ed9d70607ac9b9f72468241da77 by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
closes bpo-35630: Use code tag for 'python3' in 'README.rst' (GH-11400)
https://github.com/python/cpython/commit/de66b8d498e47ed9d70607ac9b9f72468241da77


----------

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

From report at bugs.python.org  Tue Jan  1 21:07:22 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Wed, 02 Jan 2019 02:07:22 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
Message-ID: <1546394840.15.0.0864584726941.issue35635@roundup.psfhosted.org>


New submission from Stefan Seefeld <stefan at seefeld.name>:

This is an addendum to issue35621:

To be able to call `asyncio.create_subprocess_exec()` from another thread, A separate event loop needs to be created. To make the child watcher aware of this new loop, I have to call `asyncio.get_child_watcher().attach_loop(loop)`. However, in the current implementation this call needs to be made by the main thread (or else the `signal` module will complain as handlers may only be registered in the main thread).

So, to work around the above limitations, the following workflow needs to be used:

1) create a new loop in the main thread
2) attach it to the child watcher
3) spawn a worker thread
4) set the previously created event loop as default loop

After that, I can run `asyncio.create_subprocess_exec()` in the worker thread. However, I suppose the worker thread will be the only thread able to call that function, given the child watcher's limitation to a single loop.

Am I missing something ? Given the complexity of this, I would expect this to be better documented in the sections explaining how `asyncio.subprocess` and `threading` interact.

----------
components: asyncio
messages: 332855
nosy: asvetlov, stefan, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.create_subprocess_exec() only works in main thread
type: behavior

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

From report at bugs.python.org  Tue Jan  1 21:25:25 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 02:25:25 +0000
Subject: [issue35623] Segfault in test_bigmem.ListTest.test_sort
In-Reply-To: <1546218988.78.0.27697670498.issue35623@roundup.psfhosted.org>
Message-ID: <1546395925.36.0.0131818811507.issue35623@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a5955b0895aa011b0beff1ceb6539b2ff8888425 by Miss Islington (bot) in branch '3.7':
closes bpo-35623: Fix integer overflow when sorting large lists (GH-11380)
https://github.com/python/cpython/commit/a5955b0895aa011b0beff1ceb6539b2ff8888425


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jan  2 02:20:58 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 07:20:58 +0000
Subject: [issue35636] remove redundant code in unicode_hash(PyObject *self)
Message-ID: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

Please see the PR

----------
messages: 332857
nosy: Ma Lin
priority: normal
severity: normal
status: open
title: remove redundant code in unicode_hash(PyObject *self)

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

From report at bugs.python.org  Wed Jan  2 02:25:06 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 07:25:06 +0000
Subject: [issue35636] remove redundant code in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546413906.02.0.614003848024.issue35636@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch
pull_requests: +10783
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 02:25:10 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 07:25:10 +0000
Subject: [issue35636] remove redundant code in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546413910.23.0.521058955932.issue35636@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch, patch
pull_requests: +10783, 10784
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 02:25:14 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 07:25:14 +0000
Subject: [issue35636] remove redundant code in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546413914.07.0.698829775357.issue35636@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10783, 10784, 10785
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 02:30:20 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 07:30:20 +0000
Subject: [issue35636] remove redundant code in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546414220.59.0.774050692506.issue35636@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Every non-empty str will be checked twice at present.

----------
components: +Interpreter Core
type:  -> enhancement
versions: +Python 3.8

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

From report at bugs.python.org  Wed Jan  2 02:49:36 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 07:49:36 +0000
Subject: [issue35636] remove redundant code in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546415376.59.0.556011503143.issue35636@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


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

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

From report at bugs.python.org  Wed Jan  2 03:03:07 2019
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 02 Jan 2019 08:03:07 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546416187.23.0.59837942307.issue35634@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

This change in difference is caused by https://github.com/python/cpython/commit/e036ef8fa29f27d57fe9f8cef8d931d4122d8223

The old code checked for duplicate arguments by essentially running `set().intersection(d)` and since `set().intersection(['a', 'a'])` is the empty set, it doesn't register as a duplicated argument. The newer code iterates over the keys in order to merge the dictionaries.

Note however that 3.5 is now is in security only mode: https://devguide.python.org/#branchstatus so its unlikely this behavior will be back-ported.

----------
nosy: +ammar2
type:  -> behavior

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

From report at bugs.python.org  Wed Jan  2 05:07:28 2019
From: report at bugs.python.org (iceboy)
Date: Wed, 02 Jan 2019 10:07:28 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546423648.57.0.947462843553.issue35634@roundup.psfhosted.org>


iceboy <spam at iceboy.org> added the comment:

I feel like we should not check the argument and allow overriding. If the argument checking is desired, can we also check when there is only a single kwargs? Currently `foo(**d)` still works in Python 3.6 with duplicated keys.

----------

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

From report at bugs.python.org  Wed Jan  2 06:08:15 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 11:08:15 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546427295.52.0.074457945455.issue35636@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

This redundant exists since Python 3.4 or earlier.

----------
title: remove redundant code in unicode_hash(PyObject *self) -> remove redundant check in unicode_hash(PyObject *self)
type: enhancement -> performance
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jan  2 06:14:26 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Wed, 02 Jan 2019 11:14:26 +0000
Subject: [issue35637] Factorial should be able to evaluate float arguments
Message-ID: <1546427665.46.0.211230468351.issue35637@roundup.psfhosted.org>


New submission from Yash Aggarwal <aggarwal.yash2011 at gmail.com>:

Factorial as of now accepts only integers or integral floats. 
I want to suggest extending the definition of float to accept all positive real numbers to be more consistent with general definition of factorial that uses gamma function.

What I am proposing is:
1. for integer value, the function should work as it does and return integer result.

2. for float input, both integer and non-integer valued, the returned value should be a floating point number.

3. the input domain should be extended to all real numbers except negative integers.

Such generalized function would feel more mathematically consistent.

----------
components: Library (Lib)
messages: 332862
nosy: FR4NKESTI3N
priority: normal
severity: normal
status: open
title: Factorial should be able to evaluate float arguments
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Jan  2 06:23:21 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Wed, 02 Jan 2019 11:23:21 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546428201.04.0.861075134239.issue35545@roundup.psfhosted.org>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
pull_requests: +10786

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

From report at bugs.python.org  Wed Jan  2 06:23:30 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Wed, 02 Jan 2019 11:23:30 +0000
Subject: [issue33678] selector_events.BaseSelectorEventLoop.sock_connect
 should preserve socket type
In-Reply-To: <1527587007.35.0.682650639539.issue33678@psf.upfronthosting.co.za>
Message-ID: <1546428210.15.0.270351154554.issue33678@roundup.psfhosted.org>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
pull_requests: +10790
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 06:23:30 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Wed, 02 Jan 2019 11:23:30 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546428210.13.0.82063497266.issue35545@roundup.psfhosted.org>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
pull_requests: +10786, 10787

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

From report at bugs.python.org  Wed Jan  2 06:23:40 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Wed, 02 Jan 2019 11:23:40 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546428220.03.0.993362140458.issue35545@roundup.psfhosted.org>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
pull_requests: +10786, 10787, 10788

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

From report at bugs.python.org  Wed Jan  2 06:23:43 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Wed, 02 Jan 2019 11:23:43 +0000
Subject: [issue33678] selector_events.BaseSelectorEventLoop.sock_connect
 should preserve socket type
In-Reply-To: <1527587007.35.0.682650639539.issue33678@psf.upfronthosting.co.za>
Message-ID: <1546428223.02.0.756849123362.issue33678@roundup.psfhosted.org>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
pull_requests: +10790, 10791
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 06:23:49 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Wed, 02 Jan 2019 11:23:49 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546428229.83.0.297310033722.issue35545@roundup.psfhosted.org>


Change by twisteroid ambassador <twisteroid.ambassador at gmail.com>:


----------
pull_requests: +10786, 10787, 10788, 10789

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

From report at bugs.python.org  Wed Jan  2 06:25:03 2019
From: report at bugs.python.org (steelman)
Date: Wed, 02 Jan 2019 11:25:03 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
Message-ID: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>


New submission from steelman <steelman at post.pl>:

It is currently impossible to format floating point numbers with an arbitrary number of decimal digits AND the decimal point matching locale settings. For example no current format allows to display numbers ranging from 1 to 1000 with exactly two decimal digits.

----------
components: Library (Lib)
messages: 332863
nosy: steelman
priority: normal
severity: normal
status: open
title: Introduce fixed point locale awear format type for floating point numbers
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/issue35638>
_______________________________________

From report at bugs.python.org  Wed Jan  2 06:25:50 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 02 Jan 2019 11:25:50 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546428350.63.0.273511797998.issue35636@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Unlikely to get changed in Py3.4/5 anymore, since this is not even a bug fix. I wouldn't even fight for backporting, although 3.7 seems ok for it.

I agree that this code duplication is worth removing. I don't consider hashing the empty string important enough for leaving it in, especially because the net performance effect can at most be zero, if not negative, for the normal case of non-empty strings.

----------
nosy: +scoder
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jan  2 06:32:47 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 11:32:47 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546428767.57.0.667718405675.issue35636@roundup.psfhosted.org>


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


----------
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Jan  2 06:33:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 11:33:03 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546428783.91.0.988153405157.issue35636@roundup.psfhosted.org>


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


----------
pull_requests:  -10784

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

From report at bugs.python.org  Wed Jan  2 06:33:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 11:33:15 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546428795.86.0.107092427434.issue35636@roundup.psfhosted.org>


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


----------
pull_requests:  -10785

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

From report at bugs.python.org  Wed Jan  2 07:03:45 2019
From: report at bugs.python.org (Erdem Uney)
Date: Wed, 02 Jan 2019 12:03:45 +0000
Subject: [issue35639] Lowecasing Unicode Characters
Message-ID: <1546430623.48.0.462352175173.issue35639@roundup.psfhosted.org>


New submission from Erdem Uney <erdemuney at gmail.com>:

assert '???L?'.lower() == '?i?li'

Lowercasing the capital ? (with a dot on - \u0130) adds a unicode character \u0307 after i and if there is a following character it adds that dot (\u0307) over that character. The behavior is different in Python 2.7.10 where it adds the dot on top of 'i'.

Accord to Unicode Specifications character \u0130 should be converted to character \u0069.

----------
messages: 332865
nosy: kingofsevens
priority: normal
severity: normal
status: open
title: Lowecasing Unicode Characters
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan  2 07:16:10 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 12:16:10 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546431370.75.0.517188596447.issue35636@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a1d14253066f7dd60cfb465c6511fa565f312b42 by Serhiy Storchaka (animalize) in branch 'master':
bpo-35636: Remove redundant check in unicode_hash(). (GH-11402)
https://github.com/python/cpython/commit/a1d14253066f7dd60cfb465c6511fa565f312b42


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

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

From report at bugs.python.org  Wed Jan  2 07:22:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 12:22:09 +0000
Subject: [issue35588] Speed up mod/divmod/floordiv for Fraction type
In-Reply-To: <1545817172.57.0.712150888896.issue35588@roundup.psfhosted.org>
Message-ID: <1546431729.03.0.674577685752.issue35588@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3a374e0c5abe805667b71ffaaa7614781101ff4c by Serhiy Storchaka (Stefan Behnel) in branch 'master':
bpo-35588: Speed up mod, divmod and floordiv operations for Fraction type (#11322)
https://github.com/python/cpython/commit/3a374e0c5abe805667b71ffaaa7614781101ff4c


----------

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

From report at bugs.python.org  Wed Jan  2 07:42:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 12:42:03 +0000
Subject: [issue35588] Speed up mod/divmod/floordiv for Fraction type
In-Reply-To: <1545817172.57.0.712150888896.issue35588@roundup.psfhosted.org>
Message-ID: <1546432923.74.0.443736668034.issue35588@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Stefan!

I am sorry for an awful commit message. I edited it, but due to some bug on GitHub the edited commit message was ignored after pressing the "Try merge" button. I heart this is not the first time of ignoring the edited commit message.

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

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

From report at bugs.python.org  Wed Jan  2 07:43:20 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jan 2019 12:43:20 +0000
Subject: [issue35637] Factorial should be able to evaluate float arguments
In-Reply-To: <1546427665.46.0.211230468351.issue35637@roundup.psfhosted.org>
Message-ID: <1546433000.01.0.140555825314.issue35637@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See related discussion in issue #33083.

Are you aware that `math.gamma` and `math.lgamma` exist? These already provide the ability to compute the "factorial" of a non-integral input.

I'd be opposed to extending math.factorial to accept non-integral floats.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Jan  2 07:45:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 12:45:13 +0000
Subject: [issue35637] Factorial should be able to evaluate float arguments
In-Reply-To: <1546427665.46.0.211230468351.issue35637@roundup.psfhosted.org>
Message-ID: <1546433113.16.0.594578611882.issue35637@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with Mark.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jan  2 07:48:35 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 12:48:35 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546433315.96.0.528357435302.issue35545@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi!, 

I was reading the PR.  Just a little comment. I am not sure about have a difference for IPv4 and IPv6, in the sense of use a tuple for IPv4 and separate parameters for IPv6

Regards

----------
nosy: +eamanu

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

From report at bugs.python.org  Wed Jan  2 07:49:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 12:49:28 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546433368.39.0.779407459178.issue35603@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 830ddc74c495ac1a5c03172a31006074967571a3 by Serhiy Storchaka in branch 'master':
Revert "bpo-35603: Escape table header of make_table output that can cause potential XSS. (GH-11341)" (GH-11356)
https://github.com/python/cpython/commit/830ddc74c495ac1a5c03172a31006074967571a3


----------

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

From report at bugs.python.org  Wed Jan  2 07:52:04 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Jan 2019 12:52:04 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546433524.76.0.987535150342.issue35603@roundup.psfhosted.org>


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


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
versions: +Python 2.7 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan  2 07:53:42 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 12:53:42 +0000
Subject: [issue35640] Allow passing PathLike arguments to
 SimpleHTTPRequestHandler
Message-ID: <1546433621.79.0.480952807407.issue35640@roundup.psfhosted.org>


New submission from Emmanuel Arias <emmanuelarias30 at gmail.com>:

Hi, 

A PR was opened https://github.com/python/cpython/pull/11398. This PR seems interest in the sense that this allow passing a pathlike arguments to SimpleHTTPRequestHandler. 

Regards

----------
components: Library (Lib)
messages: 332873
nosy: eamanu
priority: normal
pull_requests: 10792
severity: normal
status: open
title: Allow passing PathLike arguments to SimpleHTTPRequestHandler
type: enhancement

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

From report at bugs.python.org  Wed Jan  2 08:05:44 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 02 Jan 2019 13:05:44 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546434344.78.0.10371616106.issue35634@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I prepared a patch to make the check when there is only one dict, it may be the less surprising change.

BTW, I got lost when looking for the root cause  of this change because grepping for the error message did not work as it has line breaks:

-                            PyErr_Format(PyExc_TypeError,
-                                    "%.200s%.200s got multiple "
-                                    "values for keyword argument '%U'",
-                                    PyEval_GetFuncName(func),
-                                    PyEval_GetFuncDesc(func),
-                                    key);

Can we add a note like https://www.kernel.org/doc/html/v4.12/process/coding-style.html#breaking-long-lines-and-strings to the PEP7?

> However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them.

It would help in such situations.

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Wed Jan  2 08:28:52 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 02 Jan 2019 13:28:52 +0000
Subject: [issue35639] Lowecasing Unicode Characters
In-Reply-To: <1546430623.48.0.462352175173.issue35639@roundup.psfhosted.org>
Message-ID: <1546435732.04.0.305276474204.issue35639@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

please read this discussion
https://bugs.python.org/issue17252

behavior in Python 3.2- is correct for Turkish users.
behavior in Python 3.3+ is correct for non-Turkish users.

----------
nosy: +Ma Lin

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

From report at bugs.python.org  Wed Jan  2 08:32:30 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Jan 2019 13:32:30 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546435950.68.0.278659312785.issue35638@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Since this is a new feature, it can only be added to 3.8. Adjusting versions accordingly.

I suggest that if we add this at all, it only be added to __format__, not to %-formatting.

Any suggestions on a specification for this?

----------
components: +Interpreter Core -Library (Lib)
nosy: +eric.smith
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/issue35638>
_______________________________________

From report at bugs.python.org  Wed Jan  2 09:01:08 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 02 Jan 2019 14:01:08 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546437668.12.0.989450476218.issue35631@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

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

From report at bugs.python.org  Wed Jan  2 09:14:03 2019
From: report at bugs.python.org (steelman)
Date: Wed, 02 Jan 2019 14:14:03 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546438443.74.0.255978899611.issue35638@roundup.psfhosted.org>


steelman <steelman at post.pl> added the comment:

I've got the patch. I will push it to github as soon as I can (some technical issues).

----------

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

From report at bugs.python.org  Wed Jan  2 09:15:58 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Jan 2019 14:15:58 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546438558.6.0.721555537541.issue35638@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Before a patch is created, we should discuss the behavior that will be implemented and agree on it. What is your suggestion?

----------

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

From report at bugs.python.org  Wed Jan  2 09:16:58 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Jan 2019 14:16:58 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546438618.31.0.734632633644.issue35638@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Of course, feel free to create a PR. But the correct place to discuss any new behavior is on the issue tracker, or maybe on python-ideas, not in a PR.

----------

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

From report at bugs.python.org  Wed Jan  2 09:19:28 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Wed, 02 Jan 2019 14:19:28 +0000
Subject: [issue35640] Allow passing PathLike arguments to
 SimpleHTTPRequestHandler
In-Reply-To: <1546433621.79.0.480952807407.issue35640@roundup.psfhosted.org>
Message-ID: <1546438768.31.0.372128709193.issue35640@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
nosy: +maggyero, mdk, xtreak
versions: +Python 3.7

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

From report at bugs.python.org  Wed Jan  2 10:31:00 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 15:31:00 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546443060.08.0.379370012981.issue35638@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +10793
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 10:31:05 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 15:31:05 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546443065.26.0.731244688789.issue35638@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +10793, 10794
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 10:31:09 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 15:31:09 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546443069.38.0.58648586817.issue35638@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +10793, 10794, 10796
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 10:31:14 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 15:31:14 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546443074.11.0.267390971277.issue35638@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10793, 10794, 10795, 10796
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 10:33:09 2019
From: report at bugs.python.org (steelman)
Date: Wed, 02 Jan 2019 15:33:09 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546443189.31.0.0402009643719.issue35638@roundup.psfhosted.org>


steelman <steelman at post.pl> added the comment:

I have created a new format "m" that is for "n", what "f" is for "g". The patch for string.rst says

   +---------+----------------------------------------------------------+
   | ``'m'`` | Number. This is the same as ``'f'``, except that it uses |
   |         | the current locale setting to insert the appropriate     |
   |         | number separator characters.                             |
   +---------+----------------------------------------------------------+

My patch only applies to floats not integers.

----------

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

From report at bugs.python.org  Wed Jan  2 10:50:36 2019
From: report at bugs.python.org (Dan Snider)
Date: Wed, 02 Jan 2019 15:50:36 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1546444236.8.0.953099181482.issue35196@roundup.psfhosted.org>


Dan Snider <mr.assume.away at gmail.com> added the comment:

Not 100% sure if it's appropriate to post this here... so sorry if not. 

So anyway, the _MAX_COLS and _MAX_LINE constants used for `get_argspec` seem like they were intended to limit the generated text tips to at most 5 rows, 85 characters wide, which makes sense, but isn't what happens at all.

Easy to just post an example of how the call signature isn't limited in any meaningful way, which can easily lead to a call tip millions of character long that obviously cannot be rendered and can maybe cause crashes:

# freshly started repl session
>>> if 1:
        from idlelib.calltips import get_argspec
        G = globals()
        @get_argspec
        def func(x, d=G): pass
        print('len of func signature:', len(func))
        print(f'len(repr(globals())): {len(repr(G)):_} ({len(G)} globals)')

len of func signature: 564
len(repr(globals())): 899 (10 globals)
>>> from numpy import *
>>> if 1:
        from idlelib.calltips import get_argspec
        G = globals()
        @get_argspec
        def func(x, d=G): pass
        print('len of func signature:', len(func))
        print(f'len(repr(globals())): {len(repr(G)):_} ({len(G)} globals)')
...
len of func signature: 45524
len(repr(globals())): 92_488 (604 globals)

----------
nosy: +bup

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

From report at bugs.python.org  Wed Jan  2 11:43:40 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 16:43:40 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
Message-ID: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>


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

IDLE usually wraps call-tips to 85 characters.  However, for functions without a doc-string, this formatting is skipped.  This is an issue for functions with long signatures, e.g. due to having many arguments or due to having default values with long repr-s.

This appears to be caused by line 170 in Lib/idlelib/calltip.py being indented once too much. (see: https://github.com/python/cpython/blob/87e59ac11ee074b0dc1bc864c74fac0660b27f6e/Lib/idlelib/calltip.py)

Thanks to Dan Snider for the original report in msg332881 on issue #35196.


Example:

>>> def foo(s='a'*100):
	pass

>>> print(get_argspec(foo))
(s='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa')

>>> def bar(s='a'*100):
	"""doc-string"""
	pass

>>> print(get_argspec(bar))
(s='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaa')
doc-string

----------
messages: 332882
nosy: bup, taleinat
priority: normal
severity: normal
status: open
title: IDLE: calltips not properly formatted for functions without doc-strings

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

From report at bugs.python.org  Wed Jan  2 11:44:09 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 16:44:09 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546447449.07.0.618998316103.issue35641@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
assignee:  -> taleinat
components: +IDLE
nosy: +terry.reedy
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Jan  2 11:46:36 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 16:46:36 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1546447596.57.0.815059535151.issue35196@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Hi Dan,

Your report is unrelated to this Squeezer-related issue, but thanks for reporting it! I've created a new issue for what you've reported, see #35641.

----------

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

From report at bugs.python.org  Wed Jan  2 11:47:04 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 16:47:04 +0000
Subject: [issue35609] Improve of abc.py docstring
In-Reply-To: <1546052751.93.0.333388893142.issue35609@roundup.psfhosted.org>
Message-ID: <1546447624.54.0.978597804864.issue35609@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi Serhiy, 

A little question. Is there a planned version to remove the deprecated?

----------

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

From report at bugs.python.org  Wed Jan  2 12:42:51 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jan 2019 17:42:51 +0000
Subject: [issue35638] Introduce fixed point locale awear format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546450971.52.0.592685378803.issue35638@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Wed Jan  2 12:43:28 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 17:43:28 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546451008.88.0.440368901317.issue35641@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

I'm marking this as easy.

Whoever works on this should make sure to add a new test case for this bug.

----------
assignee: taleinat -> 
keywords: +easy

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

From report at bugs.python.org  Wed Jan  2 13:03:19 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 18:03:19 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546452199.53.0.364257622233.issue35641@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi Tal Einat!

I would like to take this issue to be my first contribution :-)

Thanks!

----------
nosy: +eamanu

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

From report at bugs.python.org  Wed Jan  2 13:05:52 2019
From: report at bugs.python.org (Gregory Szorc)
Date: Wed, 02 Jan 2019 18:05:52 +0000
Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and
 _asyncio.vcxproj
Message-ID: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org>


New submission from Gregory Szorc <gregory.szorc at gmail.com>:

The _asynciomodule.c source file is compiled as part of both pythoncore.vcxproj (providing pythonXY.dll) and _asyncio.vcxproj (providing _asyncio.pyd).

PC\config.c doesn't reference PyInit__asyncio. I'm inclined to believe that _asynciomodule.c being built as part of pythoncore.vcxproj is a mistake.

If all goes according to plan, I will contribute my first CPython patch with a fix shortly...

----------
components: Build
messages: 332887
nosy: Gregory.Szorc
priority: normal
severity: normal
status: open
title: _asynciomodule.c compiled in both pythoncore.vcxproj and _asyncio.vcxproj
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/issue35642>
_______________________________________

From report at bugs.python.org  Wed Jan  2 13:08:08 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 18:08:08 +0000
Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and
 _asyncio.vcxproj
In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org>
Message-ID: <1546452488.15.0.46967913097.issue35642@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +10797
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 13:08:12 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 18:08:12 +0000
Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and
 _asyncio.vcxproj
In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org>
Message-ID: <1546452492.02.0.860365888154.issue35642@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +10797, 10798
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 13:08:14 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 18:08:14 +0000
Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and
 _asyncio.vcxproj
In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org>
Message-ID: <1546452494.99.0.799987889973.issue35642@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +10797, 10798, 10800
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 13:08:17 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Jan 2019 18:08:17 +0000
Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and
 _asyncio.vcxproj
In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org>
Message-ID: <1546452497.16.0.112123645929.issue35642@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10797, 10798, 10799, 10800
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:01:49 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Wed, 02 Jan 2019 19:01:49 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
Message-ID: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>


New submission from Micka?l Schoentgen <contact at tiger-222.fr>:

This warning is emitted on Modules/_sha3/cleanup.py, line 11:

    SyntaxWarning: invalid escape sequence \
      CPP2 = re.compile("\ //(.*)")

----------
components: Extension Modules
messages: 332888
nosy: Tiger-222
priority: normal
severity: normal
status: open
title: SyntaxWarning: invalid escape sequence in Modules/_sha3/cleanup.py
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Jan  2 14:07:35 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Wed, 02 Jan 2019 19:07:35 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546456055.61.0.499047205612.issue35643@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
keywords: +patch
pull_requests: +10801
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:07:38 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Wed, 02 Jan 2019 19:07:38 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546456058.69.0.822048466036.issue35643@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
keywords: +patch, patch
pull_requests: +10801, 10802
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:27:02 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Jan 2019 19:27:02 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457222.4.0.230743117987.issue35643@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d466c43e55cd32af84e353f0e9a48b09b7534f61 by Benjamin Peterson (Micka?l Schoentgen) in branch 'master':
closes bpo-35643: Fix a SyntaxWarning: invalid escape sequence in Modules/_sha3/cleanup.py (GH-11411)
https://github.com/python/cpython/commit/d466c43e55cd32af84e353f0e9a48b09b7534f61


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jan  2 14:27:14 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:27:14 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457234.8.0.519618670346.issue35643@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10803

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

From report at bugs.python.org  Wed Jan  2 14:27:20 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:27:20 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457240.62.0.0201842636124.issue35643@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10803, 10804

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

From report at bugs.python.org  Wed Jan  2 14:27:26 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:27:26 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457246.48.0.259588553846.issue35643@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10803, 10804, 10805

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

From report at bugs.python.org  Wed Jan  2 14:27:32 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:27:32 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457252.36.0.902350486261.issue35643@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10803, 10804, 10805, 10806

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

From report at bugs.python.org  Wed Jan  2 14:27:36 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:27:36 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457256.61.0.184574737979.issue35643@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10804, 10805, 10806, 10808

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

From report at bugs.python.org  Wed Jan  2 14:27:41 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:27:41 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546457261.45.0.237703986379.issue35643@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10804, 10805, 10806, 10807, 10808

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

From report at bugs.python.org  Wed Jan  2 14:31:08 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Wed, 02 Jan 2019 19:31:08 +0000
Subject: [issue35434] Wrong bpo linked in What's New in 3.8
In-Reply-To: <1544157988.47.0.788709270274.issue35434@psf.upfronthosting.co.za>
Message-ID: <1546457468.04.0.888620959249.issue35434@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests: +10809

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

From report at bugs.python.org  Wed Jan  2 14:31:17 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Wed, 02 Jan 2019 19:31:17 +0000
Subject: [issue35434] Wrong bpo linked in What's New in 3.8
In-Reply-To: <1544157988.47.0.788709270274.issue35434@psf.upfronthosting.co.za>
Message-ID: <1546457477.87.0.44604511499.issue35434@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests: +10809, 10810

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

From report at bugs.python.org  Wed Jan  2 14:31:23 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Wed, 02 Jan 2019 19:31:23 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1546457483.91.0.856467150854.issue35431@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests: +10812

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

From report at bugs.python.org  Wed Jan  2 14:31:26 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Wed, 02 Jan 2019 19:31:26 +0000
Subject: [issue35434] Wrong bpo linked in What's New in 3.8
In-Reply-To: <1544157988.47.0.788709270274.issue35434@psf.upfronthosting.co.za>
Message-ID: <1546457486.85.0.070201104718.issue35434@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests: +10809, 10810, 10811

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

From report at bugs.python.org  Wed Jan  2 14:32:34 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Jan 2019 19:32:34 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546457554.39.0.849795311233.issue35638@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I haven't looked at this closely yet, but you'll need to at least:
- add tests that the locale-aware formatting is happening
- support decimal
- make sure it works with complex (which it probably does, but needs a test)

And, I think we'll need to run this through python-ideas first. One thing I expect to come up there: why f and not g?

Again, I haven't looked through the code yet, or really even given any thought to determining if this is a sound idea.

----------
title: Introduce fixed point locale awear format type for floating point numbers -> Introduce fixed point locale aware format type for floating point numbers

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

From report at bugs.python.org  Wed Jan  2 14:40:22 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Wed, 02 Jan 2019 19:40:22 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546458022.68.0.330698701805.issue35643@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
resolution: fixed -> 
status: closed -> open
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Jan  2 14:41:14 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Wed, 02 Jan 2019 19:41:14 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546458074.58.0.522470387876.issue35643@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


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

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

From report at bugs.python.org  Wed Jan  2 14:43:12 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 19:43:12 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458192.22.0.919183692987.issue35641@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch
pull_requests: +10813
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:43:18 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 19:43:18 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458198.53.0.777850474347.issue35641@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10813, 10814
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:43:25 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 19:43:25 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458205.62.0.804173542843.issue35641@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10813, 10814, 10815
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:43:33 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 02 Jan 2019 19:43:33 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458213.53.0.202098515536.issue35641@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10813, 10814, 10815, 10816
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Jan  2 14:46:51 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 19:46:51 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458411.39.0.513597824849.issue35641@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10814

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

From report at bugs.python.org  Wed Jan  2 14:47:01 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 19:47:01 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458421.21.0.562127792467.issue35641@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10814, 10815

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

From report at bugs.python.org  Wed Jan  2 14:47:11 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 19:47:11 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546458431.03.0.567576261926.issue35641@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10814, 10815, 10816

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

From report at bugs.python.org  Wed Jan  2 14:59:00 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 19:59:00 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546459140.95.0.611501919433.issue35643@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6d04bc9a2eb02efdb49f14f2c9664fe687f9a170 by Miss Islington (bot) in branch '3.7':
closes bpo-35643: Fix a SyntaxWarning: invalid escape sequence in Modules/_sha3/cleanup.py (GH-11411)
https://github.com/python/cpython/commit/6d04bc9a2eb02efdb49f14f2c9664fe687f9a170


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jan  2 15:30:13 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Wed, 02 Jan 2019 20:30:13 +0000
Subject: [issue35644] venv doesn't do what it claims to do (apears not to work
 at all?)
Message-ID: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>


New submission from Ray Donnelly <rdonnelly at anaconda.com>:

Happy New Year!

I'm not sure if this is a misunderstanding on my part, a docs bug or a code bug.

At https://docs.python.org/3/library/venv.html we see:

"The solution for this problem is to create a virtual environment, a self-contained directory tree that contains a Python installation for a particular version of Python, plus a number of additional packages"

and

"This will create the tutorial-env directory if it doesn?t exist, and also create directories inside it containing a copy of the Python interpreter, the standard library, and various supporting files."

However, when testing with https://www.python.org/ftp/python/3.7.2/python-3.7.2-amd64.exe I see no Python interpreter (nor DLL) in my venv directory:

```
python.exe -m venv %TEMP%\venv
%TEMP%\venv\Scripts\activate.bat
dir %TEMP%\venv
```

gives:

```
 Directory of C:\Users\RDONNE~1\AppData\Local\Temp\venv

02/01/2019  19:38    <DIR>          .
02/01/2019  19:38    <DIR>          ..
02/01/2019  19:38    <DIR>          Include
02/01/2019  19:38    <DIR>          Lib
02/01/2019  19:38               121 pyvenv.cfg
02/01/2019  19:38    <DIR>          Scripts
               1 File(s)            121 bytes
               5 Dir(s)  912,281,780,224 bytes free
```

pyvenv.cfg contains:

```
home = C:\Users\rdonnelly\AppData\Local\Programs\Python\Python37
include-system-site-packages = false
version = 3.7.2
```

Further to this, after activating, I do not see the `venv` directory in `sys.path`:

```
python -c "import sys; print(sys.path)"
['',
 'C:\\Users\\rdonnelly\\AppData\\Local\\Programs\\Python\\Python37\\python37.zip',
 'C:\\Users\\rdonnelly\\AppData\\Local\\Programs\\Python\\Python37\\DLLs',
 'C:\\Users\\rdonnelly\\AppData\\Local\\Programs\\Python\\Python37\\lib',
 'C:\\Users\\rdonnelly\\AppData\\Local\\Programs\\Python\\Python37',
 'C:\\Users\\rdonnelly\\AppData\\Local\\Programs\\Python\\Python37\\lib\\site-packages']
```

>From past experience, the old `virtualenv` project would copy the interpreter and DLL across.

Any help here would be appreciated!

----------
components: Windows
messages: 332892
nosy: Ray Donnelly, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: venv doesn't do what it claims to do (apears not to work at all?)
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Jan  2 15:34:43 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 20:34:43 +0000
Subject: [issue35500] Align expected and actual calls on
 mock.assert_called_with error message
In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za>
Message-ID: <1546461283.83.0.485763220903.issue35500@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Perhaps "expected" and "observed" or "detected"?

----------
nosy: +taleinat

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

From report at bugs.python.org  Wed Jan  2 15:37:59 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Wed, 02 Jan 2019 20:37:59 +0000
Subject: [issue35644] venv doesn't do what it claims to do (apears not to work
 at all?)
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546461479.4.0.0911579775004.issue35644@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

I found the executable is in the `Scripts` directory, closing. The real issue I'm facing is on Anaconda Distribution's build of Python 3 which I'm updating to 3.7.2.

Closing,

Cheers!

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

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

From report at bugs.python.org  Wed Jan  2 15:53:23 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 20:53:23 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546462403.17.0.299808517586.issue35525@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10554

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

From report at bugs.python.org  Wed Jan  2 15:53:27 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 20:53:27 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546462407.41.0.784439372555.issue35525@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10554, 10555

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

From report at bugs.python.org  Wed Jan  2 16:04:51 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Wed, 02 Jan 2019 21:04:51 +0000
Subject: [issue35644] venv doesn't do what it claims to do (apears not to work
 at all?)
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546463091.99.0.434782798264.issue35644@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

Bit of an update to this, I'm re-opening it as there appears to be a regression from Python 3.7.1 to 3.7.2 for the case when there is no venvlauncher.exe present (i.e. when there are no python{w,}.exes in Lib\venv\scripts\nt). The old code of copying `sys.executable` is no longer run (on Windows only).

Currently Anaconda Distribution's venv is done this way. Should we change it to use the same method as official CPython Windows releases?

Here is a diff I think we need to apply for now, if you feel it is reasonable to make a PR then I'm happy to do so.

```
$ diff -urN Lib/venv/__init__.py.orig Lib/venv/__init__.py
--- Lib/venv/__init__.py.orig   2019-01-02 20:56:45.015131800 +0000
+++ Lib/venv/__init__.py        2019-01-02 20:56:55.330130800 +0000
@@ -188,9 +188,9 @@
         binpath = context.bin_path
         path = context.env_exe
         copier = self.symlink_or_copy
+        copier(context.executable, path)
         dirname = context.python_dir
         if os.name != 'nt':
-            copier(context.executable, path)
             if not os.path.islink(path):
                 os.chmod(path, 0o755)
             for suffix in ('python', 'python3'):
```

----------
status: closed -> open

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

From report at bugs.python.org  Wed Jan  2 16:05:27 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 21:05:27 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463127.55.0.774496670225.issue35525@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset e9a044ec16989bd4b39763c0588c17200a925350 by Tal Einat (Harmandeep Singh) in branch 'master':
bpo-35525: Correct the argument name for NNTP.starttls() (GH-11310)
https://github.com/python/cpython/commit/e9a044ec16989bd4b39763c0588c17200a925350


----------
nosy: +taleinat

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

From report at bugs.python.org  Wed Jan  2 16:05:44 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:05:44 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463144.31.0.614261959891.issue35525@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10817

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

From report at bugs.python.org  Wed Jan  2 16:05:49 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:05:49 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463149.62.0.425199772581.issue35525@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10817, 10818

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

From report at bugs.python.org  Wed Jan  2 16:05:53 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:05:53 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463153.71.0.559437152971.issue35525@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10818, 10820

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

From report at bugs.python.org  Wed Jan  2 16:05:57 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:05:57 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463157.77.0.946112492213.issue35525@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10817, 10818, 10819, 10820

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

From report at bugs.python.org  Wed Jan  2 16:06:03 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:06:03 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463163.64.0.443416181938.issue35525@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10819, 10820, 10822

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

From report at bugs.python.org  Wed Jan  2 16:06:11 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:06:11 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463171.61.0.238286303523.issue35525@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10819, 10820, 10821, 10822

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

From report at bugs.python.org  Wed Jan  2 16:09:22 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 21:09:22 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463362.72.0.944557905757.issue35525@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10818

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

From report at bugs.python.org  Wed Jan  2 16:09:27 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 21:09:27 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463367.74.0.102946631227.issue35525@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10818, 10819

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

From report at bugs.python.org  Wed Jan  2 16:09:31 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 21:09:31 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463371.97.0.0128822855955.issue35525@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10818, 10819, 10822

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

From report at bugs.python.org  Wed Jan  2 16:09:37 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 02 Jan 2019 21:09:37 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463377.2.0.112034570319.issue35525@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10818, 10819, 10821, 10822

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

From report at bugs.python.org  Wed Jan  2 16:10:31 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Wed, 02 Jan 2019 21:10:31 +0000
Subject: [issue35644] venv doesn't do what it claims to do (apears not to work
 at all?)
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546463431.96.0.0539767306519.issue35644@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

The commit that my patch modifies is: https://github.com/python/cpython/commit/1c3de541e64f75046b20cdd27bada1557e550bcd

Cheers.

----------

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

From report at bugs.python.org  Wed Jan  2 16:11:02 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Jan 2019 21:11:02 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1546463462.68.0.10962674341.issue35525@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d7cb2034bbaa26170cdc66eb54626e3ce1b8678a by Miss Islington (bot) in branch '3.7':
bpo-35525: Correct the argument name for NNTP.starttls() (GH-11310)
https://github.com/python/cpython/commit/d7cb2034bbaa26170cdc66eb54626e3ce1b8678a


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jan  2 16:26:11 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Wed, 02 Jan 2019 21:26:11 +0000
Subject: [issue35644] venv doesn't work on Windows when no venvlauncher
 executable present
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546464371.41.0.400795402295.issue35644@roundup.psfhosted.org>


Change by Ray Donnelly <rdonnelly at anaconda.com>:


----------
title: venv doesn't do what it claims to do (apears not to work at all?) -> venv doesn't work on Windows when no venvlauncher executable present

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

From report at bugs.python.org  Wed Jan  2 16:29:58 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Jan 2019 21:29:58 +0000
Subject: [issue35589] BaseSelectorEventLoop.sock_sendall() performance
 regression: extra copy of data
In-Reply-To: <1545818673.36.0.712150888896.issue35589@roundup.psfhosted.org>
Message-ID: <1546464598.4.0.785366921704.issue35589@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +10823
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 16:30:05 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Jan 2019 21:30:05 +0000
Subject: [issue35589] BaseSelectorEventLoop.sock_sendall() performance
 regression: extra copy of data
In-Reply-To: <1545818673.36.0.712150888896.issue35589@roundup.psfhosted.org>
Message-ID: <1546464605.5.0.188688406805.issue35589@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10823, 10824
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 16:30:12 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Jan 2019 21:30:12 +0000
Subject: [issue35589] BaseSelectorEventLoop.sock_sendall() performance
 regression: extra copy of data
In-Reply-To: <1545818673.36.0.712150888896.issue35589@roundup.psfhosted.org>
Message-ID: <1546464612.26.0.139066161678.issue35589@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10823, 10824, 10825
stage:  -> patch review

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

From report at bugs.python.org  Wed Jan  2 18:36:59 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 02 Jan 2019 23:36:59 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546472219.79.0.754141845148.issue35629@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I believe that this is similar to https://bugs.python.org/issue35378 on which @pablogsal is working.

You were right, the issue steems from a refcount bug. Until the resolution you can avoid the issue by explictly keeping a reference on the pool:

>>> import multiprocessing
>>> d = multiprocessing.Pool(4)
>>> tuple(d.imap(print, (1, 2, 3)))
1
2
3
(None, None, None)
>>>

----------

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

From report at bugs.python.org  Wed Jan  2 18:37:38 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 02 Jan 2019 23:37:38 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546472258.12.0.624377998803.issue35629@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +pablogsal

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

From report at bugs.python.org  Wed Jan  2 18:43:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Jan 2019 23:43:08 +0000
Subject: [issue35500] Align expected and actual calls on
 mock.assert_called_with error message
In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za>
Message-ID: <1546472588.25.0.745371202895.issue35500@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Expected" and "Observed" seem good.  I like "Received" slightly better, but would not argue with PR author.  It depends on whether one anthropomorphizes the assert function (or test machinery) as saying 'I expected to see' or 'I expected to get'.

----------
stage:  -> test needed
versions: +Python 3.8

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

From report at bugs.python.org  Wed Jan  2 19:11:51 2019
From: report at bugs.python.org (Grant Jenks)
Date: Thu, 03 Jan 2019 00:11:51 +0000
Subject: [issue34055] IDLE: erroneous 'smart' indents in shell
In-Reply-To: <1530817533.77.0.56676864532.issue34055@psf.upfronthosting.co.za>
Message-ID: <1546474311.26.0.0755739452816.issue34055@roundup.psfhosted.org>


Grant Jenks <grant.jenks at gmail.com> added the comment:

This issue was closed but I still see the problem in 3.7.2. Here's a snippet with line numbers from IDLE:

01 Python 3.7.2 (default, Dec 30 2018, 08:59:00) 
02 [Clang 9.1.0 (clang-902.0.39.2)] on darwin
03 Type "help", "copyright", "credits" or "license()" for more information.
04 >>> 1 + 2
05 3
06 >>> print('Hello')
07 Hello
08 >>> d = {1: 'uno', 2: 'dos', 3: 'tres}
09 	 
10 SyntaxError: EOL while scanning string literal
11 >>> 1 + 2
12 	 
13 3
14 >>> 

Notice that IDLE is inserting an extra blank line at (12) above.

And here's a snippet with line numbers from the Python shell:

01 Python 3.7.2 (default, Dec 30 2018, 08:59:00) 
02 [Clang 9.1.0 (clang-902.0.39.2)] on darwin
03 Type "help", "copyright", "credits" or "license" for more information.
04 >>> 1 + 2
05 3
06 >>> print('Hello')
07 Hello
08 >>> d = {1: 'uno', 2: 'dos', 3: 'tres}
09   File "<stdin>", line 1
10     d = {1: 'uno', 2: 'dos', 3: 'tres}
11                                      ^
12 SyntaxError: EOL while scanning string literal
13 >>> 1 + 2
14 3
15 >>> 

Between lines (13) and (14) there is no extra blank line.

I'm sorry if my initial post was unclear. But the extra blank line is the bug I'm describing. I don't think there should be an extra blank line between (11) and (13) in the IDLE shell. This blank line persists for every input, even after restarts.

I'm on macOS.

I would be interested in debugging the issue locally but I ran into a couple issues trying to do so. When I check out the CPython sources and build the python.exe executable, I get this error when trying to execute IDLE:

$ ./python.exe -m pdb -m idlelib.idle
> /Users/grantj/repos/cpython/Lib/idlelib/idle.py(1)<module>()
-> import os.path
(Pdb) c
Traceback (most recent call last):
  File "/Users/grantj/repos/cpython/Lib/pdb.py", line 1695, in main
    pdb._runmodule(mainpyfile)
  File "/Users/grantj/repos/cpython/Lib/pdb.py", line 1540, in _runmodule
    self.run(code)
  File "/Users/grantj/repos/cpython/Lib/bdb.py", line 585, in run
    exec(cmd, globals, locals)
  File "/Users/grantj/repos/cpython/Lib/idlelib/idle.py", line 1, in <module>
    import os.path
  File "/Users/grantj/repos/cpython/Lib/idlelib/pyshell.py", line 1507, in main
    macosx.setupApp(root, flist)
  File "/Users/grantj/repos/cpython/Lib/idlelib/macosx.py", line 280, in setupApp
    overrideRootMenu(root, flist)
  File "/Users/grantj/repos/cpython/Lib/idlelib/macosx.py", line 181, in overrideRootMenu
    del mainmenu.menudefs[-2][1][0]
IndexError: list assignment index out of range

If I comment out line 181 in /Users/grantj/repos/cpython/Lib/idlelib/macosx.py then I can get IDLE to start. But it will later crash trying to display the first tooltip:

$ ./python.exe -m pdb -m idlelib.idle
> /Users/grantj/repos/cpython/Lib/idlelib/idle.py(1)<module>()
-> import os.path
(Pdb) c
2019-01-02 15:52:57.582 python.exe[23803:6374992] *** Assertion failure in -[_NSCGSWindow setFrame:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1561.60.100/CGS.subproj/NSCGSWindow.m:1002
2019-01-02 15:52:57.588 python.exe[23803:6374992] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: CGRectContainsRect(CGRectMake((CGFloat)INT_MIN, (CGFloat)INT_MIN, (CGFloat)INT_MAX - (CGFloat)INT_MIN, (CGFloat)INT_MAX - (CGFloat)INT_MIN), frame)'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff48fa923b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x00007fff7023ac76 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff48faefd2 +[NSException raise:format:arguments:] + 98
	3   Foundation                          0x00007fff4b0d9150 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 193
	4   AppKit                              0x00007fff465d6f50 -[_NSCGSWindow setFrame:] + 475
	5   AppKit                              0x00007fff4668eb07 _NSCreateWindowWithOpaqueShape2 + 248
	6   AppKit                              0x00007fff4668d763 -[NSWindow _commonAwake] + 1057
	7   AppKit                              0x00007fff46d9bbe7 -[NSWindow(NSWindow_Carbon) windowRefWithCompositedAttribute:andFrameworkScaledAttribute:] + 139
	8   Tk                                  0x00000001061f9ad5 XMapWindow + 239
	9   Tk                                  0x0000000106166dbf Tk_MapWindow + 89
	10  Tk                                  0x000000010616fcc5 MapFrame + 62
	11  Tcl                                 0x00000001060c05cd TclServiceIdle + 76
	12  Tcl                                 0x00000001060a4a96 Tcl_DoOneEvent + 329
	13  Tk                                  0x0000000106145f7d Tk_UpdateObjCmd + 172
	14  Tcl                                 0x000000010603ed6f TclEvalObjvInternal + 773
	15  Tcl                                 0x000000010603ff42 Tcl_EvalObjv + 66
	16  _tkinter.cpython-37dm-darwin.so     0x000000010601a865 Tkapp_Call + 901
	17  python.exe                          0x0000000104e27d14 _PyMethodDef_RawFastCallKeywords + 1476
	18  python.exe                          0x0000000104e34394 _PyMethodDescr_FastCallKeywords + 388
	19  python.exe                          0x0000000104ff89cf call_function + 1535
	20  python.exe                          0x0000000104ff0f15 _PyEval_EvalFrameDefault + 82021
	21  python.exe                          0x0000000104fdcea7 PyEval_EvalFrameEx + 87
	22  python.exe                          0x0000000104e26a29 function_code_fastcall + 377
	23  python.exe                          0x0000000104e25dbc _PyFunction_FastCallKeywords + 668
	24  python.exe                          0x0000000104ff8b5a call_function + 1930
	25  python.exe                          0x0000000104ff0f15 _PyEval_EvalFrameDefault + 82021
	26  python.exe                          0x0000000104fdcea7 PyEval_EvalFrameEx + 87

This was the case for both the master (e9a044ec16) and the 3.7 (d7cb2034bb) branch. Is there something extra I need to configure for a working build on macOSX?

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

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

From report at bugs.python.org  Wed Jan  2 21:59:16 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 02:59:16 +0000
Subject: [issue34055] IDLE: erroneous 'smart' indents in shell
In-Reply-To: <1530817533.77.0.56676864532.issue34055@psf.upfronthosting.co.za>
Message-ID: <1546484356.12.0.719534810752.issue34055@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On my Macbook with Mohave with installed python.org 3.7.2, compiled against tk 8.6.8, the startup header is
Python 3.7.2 (v3.7.2.9a3ffc0492, Dec 24 ...) [Clang 6.0 .. on Darwin].

Your header is quite different (repository?, tk version?) but the version is the exact same: '3.7.2'.  This should mean that it is a compilation of released 3.7.2 and does not have any post-3.7.2 patches, such as the fix here.  If it did, the version should be '3.7.2+', as it is for my 3.7 compiled today.

Since the problem resulting from a missing closers was fixed on Windows and Ubuntu by the post 3.7.2 patch, I will presume it is fixed on Mac also until presented with clear evidence otherwise.

Tal, does Grant's problem with compiling on Mac look familiar to you?

----------
nosy: +taleinat
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Jan  2 22:01:02 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 03:01:02 +0000
Subject: [issue34055] IDLE: erroneous 'smart' indents in shell
In-Reply-To: <1530817533.77.0.56676864532.issue34055@psf.upfronthosting.co.za>
Message-ID: <1546484462.07.0.738463630135.issue34055@roundup.psfhosted.org>


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


----------
pull_requests:  -10543

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

From report at bugs.python.org  Wed Jan  2 22:02:03 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 03:02:03 +0000
Subject: [issue34055] IDLE: erroneous 'smart' indents in shell
In-Reply-To: <1530817533.77.0.56676864532.issue34055@psf.upfronthosting.co.za>
Message-ID: <1546484523.63.0.394781732437.issue34055@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PR 11307 was moved to #35610.

----------

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

From report at bugs.python.org  Wed Jan  2 22:04:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 03:04:10 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546484650.21.0.102321964441.issue33987@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset aff0adabf3ace62073076f4ce875ff568f2d3180 by Terry Jan Reedy in branch 'master':
bpo-33987: IDLE - use ttk Frame for ttk widgets (GH-11395)
https://github.com/python/cpython/commit/aff0adabf3ace62073076f4ce875ff568f2d3180


----------

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

From report at bugs.python.org  Wed Jan  2 22:04:24 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 03:04:24 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546484664.3.0.993550043107.issue33987@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10826
stage: test needed -> patch review

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

From report at bugs.python.org  Wed Jan  2 22:04:29 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 03:04:29 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546484669.5.0.0115496429652.issue33987@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10826, 10827
stage: test needed -> patch review

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

From report at bugs.python.org  Wed Jan  2 22:04:34 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 03:04:34 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546484674.85.0.303374261821.issue33987@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10826, 10827, 10828
stage: test needed -> patch review

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

From report at bugs.python.org  Wed Jan  2 22:15:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 03:15:47 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546485347.17.0.478178170762.issue33987@roundup.psfhosted.org>


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


----------
pull_requests:  -10828

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

From report at bugs.python.org  Wed Jan  2 22:16:05 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 03:16:05 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546485365.14.0.240192463629.issue33987@roundup.psfhosted.org>


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


----------
pull_requests:  -10827

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

From report at bugs.python.org  Wed Jan  2 22:22:14 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 03:22:14 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546485734.55.0.228500927221.issue33987@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b364caa39999658e843151602356e527851d6c68 by Miss Islington (bot) in branch '3.7':
bpo-33987: IDLE - use ttk Frame for ttk widgets (GH-11395)
https://github.com/python/cpython/commit/b364caa39999658e843151602356e527851d6c68


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jan  2 22:28:24 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 03 Jan 2019 03:28:24 +0000
Subject: [issue35609] Improve of abc.py docstring
In-Reply-To: <1546052751.93.0.333388893142.issue35609@roundup.psfhosted.org>
Message-ID: <1546486104.45.0.94303416306.issue35609@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

No plan for removal.  See https://bugs.python.org/issue28886#msg282582

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Wed Jan  2 23:57:42 2019
From: report at bugs.python.org (Siva)
Date: Thu, 03 Jan 2019 04:57:42 +0000
Subject: [issue35645] Alarm usage
Message-ID: <1546491460.13.0.00460604445854.issue35645@roundup.psfhosted.org>


New submission from Siva <shivsidhi at gmail.com>:

'\a' in a command line gives  '\x07' in response.Tried '\a' in a calci programe but response gives me enter a valid data and a small box but o alarm. Do we have any ways to rectify the same. if so please let me know.

print('enter a value from the below list\n')
a = input('enter a value + , - ')

if a!= '+' and a!= '-' :
    print ('enter a valid data \a')
elif a == '+':
    b = eval(input('enter first value'))
    c=eval(input('enter 2nd value'))
    add = b+c
    print (b,'+',c,'=',add)
elif a== '-':
    b = eval(input('enter first value'))
    c=eval(input('enter 2nd value'))
    sub=b-c
    print (b,'-',c,'=',sub)

----------
components: Regular Expressions
messages: 332907
nosy: ezio.melotti, mrabarnett, shivsidhi
priority: normal
severity: normal
status: open
title: Alarm usage
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Jan  3 00:10:25 2019
From: report at bugs.python.org (Ma Lin)
Date: Thu, 03 Jan 2019 05:10:25 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546492225.48.0.442300634443.issue35636@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Thanks for review.

Don't know why bytes and str generates the same hash value for ASCII sequence.
>>> hash('abc') == hash(b'abc')
True

This may brings some hash collisions, does it affect performance slightly?

----------

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

From report at bugs.python.org  Thu Jan  3 00:59:25 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 05:59:25 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546495165.72.0.153717750601.issue33987@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jan  3 02:02:11 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Jan 2019 07:02:11 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546498931.07.0.744110572563.issue35636@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> why bytes and str generates the same hash value for ASCII sequence

Probably mostly for historical Py2 reasons. These days, both are somewhat unlikely to appear in the same dict. But still, I'd advise against changing the hash function without a very good reason. You never know how much code relies on it in one way or another.

----------

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

From report at bugs.python.org  Thu Jan  3 02:13:32 2019
From: report at bugs.python.org (Ma Lin)
Date: Thu, 03 Jan 2019 07:13:32 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546499612.02.0.284006942788.issue35636@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

> I'd advise against changing the hash function without a very good reason. You never know how much code relies on it in one way or another.

ok, maybe this can be changed in Python 4.0

----------

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

From report at bugs.python.org  Thu Jan  3 02:20:48 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 03 Jan 2019 07:20:48 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546500048.79.0.996342025371.issue35636@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

> maybe this can be changed in Python 4.0

Well, if you find a *very* good reason for changing it, as I said. Py4 won't be special in that regard, I suppose.

----------

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

From report at bugs.python.org  Thu Jan  3 02:21:42 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 03 Jan 2019 07:21:42 +0000
Subject: [issue35645] Alarm usage
In-Reply-To: <1546491460.13.0.00460604445854.issue35645@roundup.psfhosted.org>
Message-ID: <1546500102.6.0.774763741631.issue35645@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This bug report is incoherent. This has nothing to do with alarms or regular expressions, and I don't know what your code is supposed to do or what results you are expecting. What's "a calci programe"?

You ask: 

"Do we have any ways to rectify the same. if so please let me know."

First of all, rectify *what*? I don't understand what problem you think you are having. And secondly, this is for reporting bugs in the Python interpreter and libraries, not for asking for help with bugs in your own code.

I'm going to close this bug report now. If you believe it is actually a bug in the interpreter, then please explain what behaviour you expect and show the exact behaviour you get, including any traceback. COPY AND PASTE the code and any errors, don't summarise them or retype them from memory.

If you want help with your own code, I suggest:

https://old.reddit.com/r/learnpython/

https://mail.python.org/mailman/listinfo/tutor

https://mail.python.org/mailman/listinfo/python-list

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

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

From report at bugs.python.org  Thu Jan  3 02:24:15 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 03 Jan 2019 07:24:15 +0000
Subject: [issue35645] Alarm usage
In-Reply-To: <1546491460.13.0.00460604445854.issue35645@roundup.psfhosted.org>
Message-ID: <1546500255.88.0.567958133813.issue35645@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


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

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

From report at bugs.python.org  Thu Jan  3 02:26:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Jan 2019 07:26:26 +0000
Subject: [issue35644] venv doesn't work on Windows when no venvlauncher
 executable present
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546500386.22.0.760911518214.issue35644@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

That patch will break the case where the launcher *is* present, which is why it was changed. If you're sure the launcher won't be present under Scripts/nt, then that patch is okay. You'll probably need to add code to also copy python37.dll and vcruntime140.dll, since those are needed by the regular python.exe but not the launcher.

However, why not use the launcher? All it does is find pyvenv.cfg, read its home variable and launches the python.exe it finds there. If you copy your build of venvlauncher over (or even our build) it will do the same thing.

That said, I'm a little concerned about the sys.path in your first post. I assumed nobody had hit problems since there haven't been any complaints (I've been using the Store version exclusively since 3.7.2 was released), but there seems to be something wrong there. Perhaps it was due to your build?

----------

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

From report at bugs.python.org  Thu Jan  3 02:29:13 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Jan 2019 07:29:13 +0000
Subject: [issue35644] venv doesn't work on Windows when no venvlauncher
 executable present
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546500553.76.0.23547066424.issue35644@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The installed venv seems to be okay, so I'm going to assume it's something about your own build.

Now I realise I haven't ever tried virtualenv against 3.6 or later... no idea what state that's in.

----------

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

From report at bugs.python.org  Thu Jan  3 02:37:44 2019
From: report at bugs.python.org (Deepak Joshi)
Date: Thu, 03 Jan 2019 07:37:44 +0000
Subject: [issue35646] Subprocess.Popen('python -v', stdout=PIPE, stderr=PIPE, 
 Shell=True) gives output in stderr
Message-ID: <1546501063.03.0.591969937784.issue35646@roundup.psfhosted.org>


New submission from Deepak Joshi <deepakjoshishri at gmail.com>:

Subprocess.Popen('python -v',stdout=PIPE,stderr=PIPE,Shell=True)

Prduces output in stderr instead of stdout.

For others: pip --version or git --version output is in stdout and is expected.

----------
components: Windows, ctypes
messages: 332915
nosy: Deepak Joshi, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Subprocess.Popen('python -v',stdout=PIPE,stderr=PIPE,Shell=True) gives output in stderr
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan  3 02:45:46 2019
From: report at bugs.python.org (Ma Lin)
Date: Thu, 03 Jan 2019 07:45:46 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546501546.41.0.166685177512.issue35636@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

One scene is caching regular expresses, b'[a-z]', '[a-z]' may exist in the same dict. Any way, it's trivial on the whole.

----------

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

From report at bugs.python.org  Thu Jan  3 02:48:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Jan 2019 07:48:08 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546501688.98.0.194655784706.issue35641@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ab54b9a130c88f708077c2ef6c4963b632c132b3 by Terry Jan Reedy (Emmanuel Arias) in branch 'master':
bpo-35641: IDLE - format calltip properly when no docstring (GH-11415)
https://github.com/python/cpython/commit/ab54b9a130c88f708077c2ef6c4963b632c132b3


----------

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

From report at bugs.python.org  Thu Jan  3 02:48:22 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 07:48:22 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546501702.56.0.778416158151.issue35641@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10829

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

From report at bugs.python.org  Thu Jan  3 02:48:29 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 07:48:29 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546501709.65.0.940048221887.issue35641@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10829, 10830

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

From report at bugs.python.org  Thu Jan  3 02:48:37 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 07:48:37 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546501717.66.0.0556820260863.issue35641@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10829, 10830, 10831

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

From report at bugs.python.org  Thu Jan  3 02:59:30 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 Jan 2019 07:59:30 +0000
Subject: [issue35646] python -v writes to stderr
In-Reply-To: <1546501063.03.0.591969937784.issue35646@roundup.psfhosted.org>
Message-ID: <1546502370.65.0.610469736138.issue35646@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

-v writes to stderr, so this is the expected behavior. Although maybe this could be better documented.

See issue 18338, where this was briefly discussed and a change was rejected.

Maybe you're looking for -V (uppercase) or --version, which do write to stdout, at least in 3.x. I'm not sure where they write in 2.7, but it's much too late to change 2.7's behavior.

I'm going to close this. If you find some of our documentation that says -v writes to stdout, then we can reopen this.

This is not a Windows specific error, so I'm modifying the nosy list.

----------
components: +Interpreter Core -Windows, ctypes
nosy: +eric.smith -paul.moore, steve.dower, tim.golden, zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Subprocess.Popen('python -v',stdout=PIPE,stderr=PIPE,Shell=True) gives output in stderr -> python -v writes to stderr

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

From report at bugs.python.org  Thu Jan  3 02:59:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 03 Jan 2019 07:59:58 +0000
Subject: [issue35647] Cookie path check returns incorrect results
Message-ID: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I came across the issue during https://bugs.python.org/issue35121#msg332583 . I think this can be dealt as a separate issue not blocking the original report. I am classifying it as security but can be reclassified as a bug fix given the section on weak confidentiality in RFC 6265. I have a fix implemented at https://github.com/tirkarthi/cpython/tree/bpo35121-cookie-path.

Report : 

I have come across another behavior change between path checks while using the cookie jar implementation available in Python. This is related to incorrect cookie validation but with respect to path. I observed the following difference : 

1. Make a request to "/" that sets a cookie with "path=/any"
2. Make a request to "/any" and the set cookie is passed since the path matches
3. Make a request to "/anybad" and cookie with "path=/any" is also passed too.

On using golang stdlib implementation of cookiejar the cookie "path=/any" is not passed when a request to "/anybad" is made. So I checked with RFC 6265 where the path match check is defined in section-5.1.4 . RFC 6265 also obsoletes RFC 2965 upon which cookiejar is based I hope since original implementation of cookiejar is from 2004 and RFC 6265 was standardized later. So I think it's good to enforce RFC 6265 since RFC 2965 is obsolete at least in Python 3.8 unless this is considered as a security issue. I think this is a security issue. The current implementation can potentially cause cookies to be sent to incorrect paths in the same domain that share the same prefix. This is a behavior change with more strict checks but I could see no tests failing with RFC 6265 implementation too.

RFC 2965 also gives a loose definition of path-match without mentioning about / check in the paths based on which Python implementation is based as a simple prefix match.

> For two strings that represent paths, P1 and P2, P1 path-matches P2
> if P2 is a prefix of P1 (including the case where P1 and P2 string-
> compare equal).  Thus, the string /tec/waldo path-matches /tec.

RFC 6265 path-match definition : https://tools.ietf.org/html/rfc6265#section-5.1.4

   A request-path path-matches a given cookie-path if at least one of
   the following conditions holds:

   o  The cookie-path and the request-path are identical.

   o  The cookie-path is a prefix of the request-path, and the last
      character of the cookie-path is %x2F ("/").

   o  The cookie-path is a prefix of the request-path, and the first
      character of the request-path that is not included in the cookie-
      path is a %x2F ("/") character.

The current implementation in cookiejar is as below : 

def path_return_ok(self, path, request):
    _debug("- checking cookie path=%s", path)
    req_path = request_path(request)
    if not req_path.startswith(path):
        _debug("  %s does not path-match %s", req_path, path)
        return False
    return True

Translating the RFC 6265 steps (a literal translation of go implementation) would have something like below and no tests fail on master. So the python implementation goes in line with the RFC not passing cookies of "path=/any" to /anybody

def path_return_ok(self, path, request):
    req_path = request_path(request)
    if req_path == path:
        return True
    elif req_path.startswith(path) and ((path.endswith("/") or req_path[len(path)] == "/")):
        return True
        
    return False


The golang implementation is as below which is a literal translation of RFC 6265 steps at https://github.com/golang/go/blob/50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26/src/net/http/cookiejar/jar.go#L130

// pathMatch implements "path-match" according to RFC 6265 section 5.1.4.
func (e *entry) pathMatch(requestPath string) bool {
	if requestPath == e.Path {
		return true
	}
	if strings.HasPrefix(requestPath, e.Path) {
		if e.Path[len(e.Path)-1] == '/' {
			return true // The "/any/" matches "/any/path" case.
		} else if requestPath[len(e.Path)] == '/' {
			return true // The "/any" matches "/any/path" case.
		}
	}
	return false
}


RFC 6265 on weak confidentiality (https://tools.ietf.org/html/rfc6265#section-8.5)

   Cookies do not always provide isolation by path.  Although the
   network-level protocol does not send cookies stored for one path to
   another, some user agents expose cookies via non-HTTP APIs, such as
   HTML's document.cookie API.  Because some of these user agents (e.g.,
   web browsers) do not isolate resources received from different paths,
   a resource retrieved from one path might be able to access cookies
   stored for another path.

----------
components: Library (Lib)
messages: 332919
nosy: martin.panter, ned.deily, orsenthil, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: Cookie path check returns incorrect results
type: security
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Jan  3 03:01:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 03 Jan 2019 08:01:23 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1546502483.75.0.59324134979.issue35121@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have opened issue35647 for path related checks as a separate report.

----------

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

From report at bugs.python.org  Thu Jan  3 03:10:39 2019
From: report at bugs.python.org (Deepak Joshi)
Date: Thu, 03 Jan 2019 08:10:39 +0000
Subject: [issue35646] python -v writes to stderr
In-Reply-To: <1546502370.65.0.610469736138.issue35646@roundup.psfhosted.org>
Message-ID: <CAL-2UH3FTzST_Vw4+dJjp=J1iDBs=QALz7Hoc+AZAaZCDe0P2A@mail.gmail.com>


Deepak Joshi <deepakjoshishri at gmail.com> added the comment:

Hello,

-V and --version both write to stderr not stdout.

On Thu, 3 Jan 2019, 1:29 pm Eric V. Smith <report at bugs.python.org wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> -v writes to stderr, so this is the expected behavior. Although maybe this
> could be better documented.
>
> See issue 18338, where this was briefly discussed and a change was
> rejected.
>
> Maybe you're looking for -V (uppercase) or --version, which do write to
> stdout, at least in 3.x. I'm not sure where they write in 2.7, but it's
> much too late to change 2.7's behavior.
>
> I'm going to close this. If you find some of our documentation that says
> -v writes to stdout, then we can reopen this.
>
> This is not a Windows specific error, so I'm modifying the nosy list.
>
> ----------
> components: +Interpreter Core -Windows, ctypes
> nosy: +eric.smith -paul.moore, steve.dower, tim.golden, zach.ware
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
> title: Subprocess.Popen('python -v',stdout=PIPE,stderr=PIPE,Shell=True)
> gives output in stderr -> python -v writes to stderr
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35646>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Jan  3 03:58:35 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 Jan 2019 08:58:35 +0000
Subject: [issue35646] python -v writes to stderr
In-Reply-To: <1546501063.03.0.591969937784.issue35646@roundup.psfhosted.org>
Message-ID: <1546505915.15.0.635218154485.issue35646@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

That's just the way it is with 2.7.

----------

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

From report at bugs.python.org  Thu Jan  3 04:06:13 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 09:06:13 +0000
Subject: [issue35648] Add use_srcentry parameter to shutil.copytree()
Message-ID: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org>


New submission from flokX <accounts at fkcore.de>:

Currently it is decided if to use the srcentry in the copy_function by checking if the copy_function is copy() or copy2(). This will fail if the copy_function is a modified copy() or copy2() function. To control if the copy_function gets a srcentry or srcname parameter, added the use_srcentry parameter.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 332923
nosy: docs at python, flokX
priority: normal
severity: normal
status: open
title: Add use_srcentry parameter to shutil.copytree()
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Jan  3 04:07:41 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 09:07:41 +0000
Subject: [issue35648] Add use_srcentry parameter to shutil.copytree()
In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org>
Message-ID: <1546506461.61.0.696231457283.issue35648@roundup.psfhosted.org>


Change by flokX <accounts at fkcore.de>:


----------
keywords: +patch
pull_requests: +10832
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 04:07:46 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 09:07:46 +0000
Subject: [issue35648] Add use_srcentry parameter to shutil.copytree()
In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org>
Message-ID: <1546506466.77.0.617616141236.issue35648@roundup.psfhosted.org>


Change by flokX <accounts at fkcore.de>:


----------
keywords: +patch, patch
pull_requests: +10832, 10833
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 04:07:52 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 09:07:52 +0000
Subject: [issue35648] Add use_srcentry parameter to shutil.copytree()
In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org>
Message-ID: <1546506472.61.0.18838738399.issue35648@roundup.psfhosted.org>


Change by flokX <accounts at fkcore.de>:


----------
keywords: +patch, patch, patch
pull_requests: +10832, 10833, 10835
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 04:07:58 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 09:07:58 +0000
Subject: [issue35648] Add use_srcentry parameter to shutil.copytree()
In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org>
Message-ID: <1546506478.32.0.748637508938.issue35648@roundup.psfhosted.org>


Change by flokX <accounts at fkcore.de>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10832, 10833, 10834, 10835
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 04:21:30 2019
From: report at bugs.python.org (Deepak Joshi)
Date: Thu, 03 Jan 2019 09:21:30 +0000
Subject: [issue35646] python -v writes to stderr
In-Reply-To: <1546505915.15.0.635218154485.issue35646@roundup.psfhosted.org>
Message-ID: <CAL-2UH1KG0o2Rve0MTgBBfJpziuDrBawnRn==hhGdO2xLTSRWQ@mail.gmail.com>


Deepak Joshi <deepakjoshishri at gmail.com> added the comment:

Thank you for the reply Eric.
Thought the behaviour is pretty wierd and opened the issue.

On Thu, 3 Jan 2019, 2:28 pm Eric V. Smith <report at bugs.python.org wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> That's just the way it is with 2.7.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35646>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Jan  3 04:44:49 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 09:44:49 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546508689.32.0.793734621172.issue35641@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3c83cb7eed4f0e8b9f1cbf39263a2053a2483cb0 by Miss Islington (bot) in branch '3.7':
bpo-35641: IDLE - format calltip properly when no docstring (GH-11415)
https://github.com/python/cpython/commit/3c83cb7eed4f0e8b9f1cbf39263a2053a2483cb0


----------
nosy: +miss-islington

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

From report at bugs.python.org  Thu Jan  3 04:51:02 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 03 Jan 2019 09:51:02 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546509062.49.0.473800083965.issue35641@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10831

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

From report at bugs.python.org  Thu Jan  3 04:51:11 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 03 Jan 2019 09:51:11 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546509071.58.0.380052515476.issue35641@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10830, 10831

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

From report at bugs.python.org  Thu Jan  3 04:52:56 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 03 Jan 2019 09:52:56 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1546509176.23.0.216196005872.issue35641@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks for the report, Dan!

Thanks for the fix, Emmanuel!

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

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

From report at bugs.python.org  Thu Jan  3 05:51:22 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Thu, 03 Jan 2019 10:51:22 +0000
Subject: [issue35434] Wrong bpo linked in What's New in 3.8
In-Reply-To: <1544157988.47.0.788709270274.issue35434@psf.upfronthosting.co.za>
Message-ID: <1546512682.21.0.884534019134.issue35434@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests:  -10809

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

From report at bugs.python.org  Thu Jan  3 05:51:37 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Thu, 03 Jan 2019 10:51:37 +0000
Subject: [issue35434] Wrong bpo linked in What's New in 3.8
In-Reply-To: <1544157988.47.0.788709270274.issue35434@psf.upfronthosting.co.za>
Message-ID: <1546512697.18.0.561969829831.issue35434@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests:  -10810

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

From report at bugs.python.org  Thu Jan  3 05:51:56 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Thu, 03 Jan 2019 10:51:56 +0000
Subject: [issue35434] Wrong bpo linked in What's New in 3.8
In-Reply-To: <1544157988.47.0.788709270274.issue35434@psf.upfronthosting.co.za>
Message-ID: <1546512716.71.0.321073102654.issue35434@roundup.psfhosted.org>


Change by Yash Aggarwal <aggarwal.yash2011 at gmail.com>:


----------
pull_requests:  -10811

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

From report at bugs.python.org  Thu Jan  3 06:17:16 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Thu, 03 Jan 2019 11:17:16 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546514236.43.0.682249633942.issue31450@roundup.psfhosted.org>


Change by Harmandeep Singh <harmandeep3091 at gmail.com>:


----------
keywords: +patch
pull_requests: +10836
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 06:17:22 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Thu, 03 Jan 2019 11:17:22 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546514242.61.0.53890084935.issue31450@roundup.psfhosted.org>


Change by Harmandeep Singh <harmandeep3091 at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10836, 10837
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 06:17:32 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Thu, 03 Jan 2019 11:17:32 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546514252.54.0.369628876346.issue31450@roundup.psfhosted.org>


Change by Harmandeep Singh <harmandeep3091 at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10836, 10837, 10838
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 06:17:39 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Thu, 03 Jan 2019 11:17:39 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546514259.68.0.699976548437.issue31450@roundup.psfhosted.org>


Change by Harmandeep Singh <harmandeep3091 at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10836, 10837, 10838, 10839
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 07:57:14 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 03 Jan 2019 12:57:14 +0000
Subject: [issue35645] Alarm usage
In-Reply-To: <1546491460.13.0.00460604445854.issue35645@roundup.psfhosted.org>
Message-ID: <1546520234.55.0.153787178224.issue35645@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

@Steven: The complaint is that the BEL character ('\a') doesn't result in a beep when printed.

@Siva: These days, you shouldn't be relying on '\a' because it's not always supported. If you want to make a beep, do so with the appropriate function call. Ask Google!

----------

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

From report at bugs.python.org  Thu Jan  3 08:59:32 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Stelmach?=)
Date: Thu, 03 Jan 2019 13:59:32 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546523972.63.0.911190214528.issue35638@roundup.psfhosted.org>


?ukasz Stelmach <steelman at post.pl> added the comment:

> I haven't looked at this closely yet, but you'll need to at least:
> - add tests that the locale-aware formatting is happening

Done.

> - support decimal
> - make sure it works with complex

Good points. Done. Please note, that there is an inconsistency between float/complex/int/_pydecimal(!) and decimal. The former provide only 'n' format type and the latter provides 'n' and 'N'. So I implemented 'm' and 'M' for decimal and 'm' for _pydecimal.

> (which it probably does, but needs a test)

There are no tests for 'n'. Should I create for both 'm' and 'n'?

> And, I think we'll need to run this through python-ideas first. One thing I expect to come up there: why f and not g?

Because 'g' has been already covered with 'n'.

----------

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

From report at bugs.python.org  Thu Jan  3 09:29:18 2019
From: report at bugs.python.org (keeely)
Date: Thu, 03 Jan 2019 14:29:18 +0000
Subject: [issue35218] decompressing and then re-compressing zipfiles with
 Python 3 zipfile loses flag_bits
In-Reply-To: <1542033501.3.0.788709270274.issue35218@psf.upfronthosting.co.za>
Message-ID: <1546525758.83.0.871688527843.issue35218@roundup.psfhosted.org>


keeely <smh at sophos.com> added the comment:

Please note:  I'm unable to fill in your contributor agreement form, so please consider the patch an illustrative example.  In any case, the fix is pretty-much a one-liner, so shouldn't be a big deal to 're-write'.

I'm disappointed that this has been largely overlooked since I raised it.  It's a clear regression in Python3 and represents a show-stopper for people wanting to switch from 2->3.  I would imagine you *want* people to migrate to 3, so I'm baffled by the response or lack thereof.  Sure, I know everyone is busy but this is pretty basic stuff.

----------

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

From report at bugs.python.org  Thu Jan  3 09:59:17 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 03 Jan 2019 14:59:17 +0000
Subject: [issue35218] decompressing and then re-compressing zipfiles with
 Python 3 zipfile loses flag_bits
In-Reply-To: <1542033501.3.0.788709270274.issue35218@psf.upfronthosting.co.za>
Message-ID: <1546527557.75.0.429186169354.issue35218@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan  3 10:11:18 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jan 2019 15:11:18 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546528278.82.0.770919797856.issue35638@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I think there's another open GitHub issue for this, and yes, probably
it should be discussed on python-ideas, too.

My main concern with 'm' for libmpdec is that I'd like to reserve it
for LC_MONETARY. There was one OS X issue that would have been solved
by adding LC_MONETARY support.

On the other hand perhaps '$' would also be possible for monetary.


So it appears that there might be some bikeshedding about the names
or whether the feature is needed at all.

----------
nosy: +skrah

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

From report at bugs.python.org  Thu Jan  3 10:16:28 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 03 Jan 2019 15:16:28 +0000
Subject: [issue35639] Lowecasing Unicode Characters
In-Reply-To: <1546430623.48.0.462352175173.issue35639@roundup.psfhosted.org>
Message-ID: <1546528588.38.0.869227972105.issue35639@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


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

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

From report at bugs.python.org  Thu Jan  3 10:25:40 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Stelmach?=)
Date: Thu, 03 Jan 2019 15:25:40 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546529140.7.0.12819532061.issue35638@roundup.psfhosted.org>


?ukasz Stelmach <steelman at post.pl> added the comment:

As much as I am open to any suggestions for naming and such (although I think 'm' together with 'n' are a good supplement for 'f' and 'g'), I really would like to introduce a method to format numbers with fixed number of decimal digits (it looks good in tables) and with separators from locale.

----------

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

From report at bugs.python.org  Thu Jan  3 10:29:24 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Jan 2019 15:29:24 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546529364.21.0.551881037183.issue35638@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

For reference, the (one of the?) other GitHub issue(s) is here:

https://github.com/python/cpython/pull/8612


It actually proposes to use LC_MONETARY.

----------

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

From report at bugs.python.org  Thu Jan  3 10:38:05 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Thu, 03 Jan 2019 15:38:05 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1546529885.05.0.34369771305.issue35431@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

I have written the function in the latest patch to work only for positive n. Although the definition of combination or nChoosek makes no sense for negative n, negative binomial distribution exists and so binomial coefficient is defined for negative value of n. So my question is should the function be expanded to calculate for negative n or is the function expected to work only in combination sense?

----------

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

From report at bugs.python.org  Thu Jan  3 11:41:50 2019
From: report at bugs.python.org (skorpeo)
Date: Thu, 03 Jan 2019 16:41:50 +0000
Subject: [issue35649] http.client doesn't close.  Infinite loop
Message-ID: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>


New submission from skorpeo <skorpeo11 at gmail.com>:

when testing example from https://docs.python.org/3/library/http.client.html.  Specifically the chunked example, i.e. while not r1.closed.  Results in infinite loop.  

I believe this is because line 398 function def _close_conn(self), should call self.close().

----------
messages: 332934
nosy: skorpeo
priority: normal
severity: normal
status: open
title: http.client doesn't close.  Infinite loop
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Jan  3 11:45:41 2019
From: report at bugs.python.org (skorpeo)
Date: Thu, 03 Jan 2019 16:45:41 +0000
Subject: [issue35649] http.client doesn't close.  Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546533941.48.0.936783481765.issue35649@roundup.psfhosted.org>


Change by skorpeo <skorpeo11 at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Thu Jan  3 11:53:57 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 03 Jan 2019 16:53:57 +0000
Subject: [issue35650] cygwin treats X and X.exe as the same file
Message-ID: <1546534436.45.0.760844199857.issue35650@roundup.psfhosted.org>


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

>>> with open('f.exe', 'w') as f:
...     f.write('hi')
...
>>> with open('f') as f:
...     print(f.read())
...
hi


`os.path.exists(...)` and others treat them as the same file as well.  It seems the only reliable way to write both files is:

1. write to f.exe
2. write to f.bak
3. move f.bak to f (`os.rename`)

----------
components: Windows
messages: 332935
nosy: Anthony Sottile, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: cygwin treats X and X.exe as the same file
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Jan  3 12:04:54 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:04:54 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546535094.51.0.656750210094.issue35633@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

After reading the PEP I realized it is much simpler. The test is for interrupts that occur at a low-level - and not for permission issues. The test is failing because there is a permission issue, not a missed interrupt issue. Modifying the code to: (see line 510)

  +506                      try:
  +507                          lock_func(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
  +508                          lock_func(f, fcntl.LOCK_UN)
  +509                          time.sleep(0.01)
  +510                      except (BlockingIOError, PermissionError):
  +511                          break
  +512                  # the child locked the file just a moment ago for 'sleep_time' seconds
  +513                  # that means that the lock below will block for 'sleep_time' minus some
  +514                  # potential context switch delay
  +515                  lock_func(f, fcntl.LOCK_EX)
  +516                  dt = time.monotonic() - start_time
  +517                  self.assertGreaterEqual(dt, self.sleep_time)
  +518                  self.stop_alarm()

fixes this.

----------

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

From report at bugs.python.org  Thu Jan  3 12:06:20 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 03 Jan 2019 17:06:20 +0000
Subject: [issue35650] cygwin treats X and X.exe as the same file
In-Reply-To: <1546534436.45.0.760844199857.issue35650@roundup.psfhosted.org>
Message-ID: <1546535180.41.0.92128695793.issue35650@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

ah yes, I should include more version information

IEUser at IE11WIN7 ~
$ python --version
Python 2.7.14

IEUser at IE11WIN7 ~
$ python3 --version --version
Python 3.6.4 (default, Jan  7 2018, 17:45:56)
[GCC 6.4.0]


IEUser at IE11WIN7 ~
$ uname -a
CYGWIN_NT-6.1 IE11WIN7 2.11.2(0.329/5/3) 2018-11-08 14:30 i686 Cygwin

----------

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

From report at bugs.python.org  Thu Jan  3 12:08:10 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 03 Jan 2019 17:08:10 +0000
Subject: [issue35650] cygwin treats X and X.exe as the same file
In-Reply-To: <1546534436.45.0.760844199857.issue35650@roundup.psfhosted.org>
Message-ID: <1546535290.6.0.260242174172.issue35650@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This sounds like a Cygwin issue; what can Python do about it?

>From a Cygwin shell:

$ ls

$ echo "test.exe" >> test.exe

$ echo "test" >> test

$ cat test
test.exe
test

----------

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

From report at bugs.python.org  Thu Jan  3 12:12:32 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 03 Jan 2019 17:12:32 +0000
Subject: [issue35650] cygwin treats X and X.exe as the same file
In-Reply-To: <1546534436.45.0.760844199857.issue35650@roundup.psfhosted.org>
Message-ID: <1546535552.95.0.963441924552.issue35650@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

hmmm probably nothing in that case -- didn't realize this also happened in the cygwin shell.

insanity.

feel free to close!  thanks!

----------

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

From report at bugs.python.org  Thu Jan  3 12:13:19 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 03 Jan 2019 17:13:19 +0000
Subject: [issue35650] cygwin treats X and X.exe as the same file
In-Reply-To: <1546534436.45.0.760844199857.issue35650@roundup.psfhosted.org>
Message-ID: <1546535599.08.0.781259970479.issue35650@roundup.psfhosted.org>


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


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jan  3 12:29:54 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:29:54 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546536594.69.0.677214601902.issue35633@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +10840
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 12:29:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:29:56 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546536596.72.0.964416767455.issue35633@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch, patch
pull_requests: +10840, 10841
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 12:29:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:29:56 +0000
Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted
 by a signal (EINTR)
In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za>
Message-ID: <1546536596.74.0.615814564181.issue35189@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +10842

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

From report at bugs.python.org  Thu Jan  3 12:30:03 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:30:03 +0000
Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted
 by a signal (EINTR)
In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za>
Message-ID: <1546536603.29.0.880707564276.issue35189@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +10842, 10843

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

From report at bugs.python.org  Thu Jan  3 12:30:09 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:30:09 +0000
Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted
 by a signal (EINTR)
In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za>
Message-ID: <1546536609.7.0.428799029084.issue35189@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +10842, 10843, 10845

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

From report at bugs.python.org  Thu Jan  3 12:30:15 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:30:15 +0000
Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted
 by a signal (EINTR)
In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za>
Message-ID: <1546536615.88.0.649329431322.issue35189@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +10842, 10843, 10844, 10845

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

From report at bugs.python.org  Thu Jan  3 12:34:28 2019
From: report at bugs.python.org (Mark Amery)
Date: Thu, 03 Jan 2019 17:34:28 +0000
Subject: [issue35651] PEP 257 (active) references PEP 258 (rejected) as if it
 were active
Message-ID: <1546536866.6.0.633154963858.issue35651@roundup.psfhosted.org>


New submission from Mark Amery <markamery at btinternet.com>:

PEP 257 says:

> Please see PEP 258, "Docutils Design Specification" [2], for a detailed description of attribute and additional docstrings.

But PEP 258 is rejected. It doesn't seem coherent that an active PEP can defer some of its details to a rejected PEP - and indeed it makes me unsure how much of the surrounding commentary in PEP 257 to treat as active. e.g. should I treat the entire concepts of "attribute docstrings" and "additional docstrings" as rejected, given the rejection of PEP 258, or are they still part of the current spec, given that they're referenced in PEP 257 prior to any mention of PEP 258? It's currently completely unclear.

----------
assignee: docs at python
components: Documentation
messages: 332940
nosy: ExplodingCabbage, docs at python
priority: normal
severity: normal
status: open
title: PEP 257 (active) references PEP 258 (rejected) as if it were active
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/issue35651>
_______________________________________

From report at bugs.python.org  Thu Jan  3 12:34:55 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 03 Jan 2019 17:34:55 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546536895.05.0.363256462134.issue35633@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
components:  -IO

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

From report at bugs.python.org  Thu Jan  3 12:45:38 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 03 Jan 2019 17:45:38 +0000
Subject: [issue35651] PEP 257 (active) references PEP 258 (rejected) as if it
 were active
In-Reply-To: <1546536866.6.0.633154963858.issue35651@roundup.psfhosted.org>
Message-ID: <1546537538.27.0.607998340891.issue35651@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Thu Jan  3 13:57:47 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 18:57:47 +0000
Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II
Message-ID: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org>


New submission from flokX <accounts at fkcore.de>:

Currently it is decided if to use the srcentry in the copy_function by checking if the copy_function is copy() or copy2(). This will fail if the copy_function is a modified copy() or copy2() function. To control if the copy_function gets a srcentry or srcname parameter, added the use_srcentry parameter.

Successor of https://bugs.python.org/issue35648

----------
components: Library (Lib)
messages: 332941
nosy: flokX
priority: normal
severity: normal
status: open
title: Add use_srcentry parameter to shutil.copytree() II
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Jan  3 14:04:25 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 19:04:25 +0000
Subject: [issue35652] Add use_srcentry parameter to shutil.copytree() II
In-Reply-To: <1546541865.13.0.115152005965.issue35652@roundup.psfhosted.org>
Message-ID: <1546542265.84.0.923119009639.issue35652@roundup.psfhosted.org>


Change by flokX <accounts at fkcore.de>:


----------
keywords: +patch
pull_requests: +10846
stage:  -> patch review

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

From report at bugs.python.org  Thu Jan  3 14:09:37 2019
From: report at bugs.python.org (flokX)
Date: Thu, 03 Jan 2019 19:09:37 +0000
Subject: [issue35648] Add use_srcentry parameter to shutil.copytree()
In-Reply-To: <1546506372.52.0.724433917377.issue35648@roundup.psfhosted.org>
Message-ID: <1546542577.81.0.421082709215.issue35648@roundup.psfhosted.org>


flokX <accounts at fkcore.de> added the comment:

A new PR is started.
See https://bugs.python.org/issue35652 and https://github.com/python/cpython/pull/11425

----------
nosy:  -docs at python
resolution:  -> later
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jan  3 14:25:06 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Thu, 03 Jan 2019 19:25:06 +0000
Subject: [issue35644] venv doesn't work on Windows when no venvlauncher
 executable present
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546543506.96.0.277565872326.issue35644@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

Thanks Steve, the sys.path value from the first comment can be discarded, it was running the wrong Python!

The 'old' mechanism (which my patch reverts to) does copy all the necessary DLLs already. I released builds with this patch now and venv works fine (tested with pyperformance which uses venv).

However, we are more than happy to switch to the venvlauncher method as not deviating from upstream unnecessarily is always a good thing!

Do you have any pointers about how to build venvlauncher? I'll try to schedule some time for that.

----------

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

From report at bugs.python.org  Thu Jan  3 14:50:48 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 03 Jan 2019 19:50:48 +0000
Subject: [issue35605] backported patch requires new sphinx,
 minimum sphinx version was not bumped
In-Reply-To: <1546016436.32.0.942702382011.issue35605@roundup.psfhosted.org>
Message-ID: <1546545048.43.0.211914451855.issue35605@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I also had to update the patch for sphinx.util.status_iterator which was also introduced in sphinx 1.6

----------

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

From report at bugs.python.org  Thu Jan  3 14:53:58 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Jan 2019 19:53:58 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546545238.65.0.576751769945.issue31450@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 47a2fced84605a32b79aa3ebc543533ad1a976a1 by Gregory P. Smith (Harmandeep Singh) in branch 'master':
bpo-31450: Remove documentation mentioning that subprocess's child_traceback is available with the parent process (GH-11422)
https://github.com/python/cpython/commit/47a2fced84605a32b79aa3ebc543533ad1a976a1


----------

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

From report at bugs.python.org  Thu Jan  3 14:54:15 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 19:54:15 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546545255.17.0.932342067774.issue31450@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10847

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

From report at bugs.python.org  Thu Jan  3 14:54:21 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 19:54:21 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546545261.32.0.00273717841507.issue31450@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10847, 10848

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

From report at bugs.python.org  Thu Jan  3 14:54:27 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 19:54:27 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546545267.43.0.140235159832.issue31450@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10847, 10848, 10849

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

From report at bugs.python.org  Thu Jan  3 15:01:48 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Jan 2019 20:01:48 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546545708.4.0.00537282471441.issue31450@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 47c035f3efa77a439967776b5b6ba11d010ce466 by Miss Islington (bot) in branch '3.7':
bpo-31450: Remove documentation mentioning that subprocess's child_traceback is available with the parent process (GH-11422)
https://github.com/python/cpython/commit/47c035f3efa77a439967776b5b6ba11d010ce466


----------
nosy: +miss-islington

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

From report at bugs.python.org  Thu Jan  3 15:21:41 2019
From: report at bugs.python.org (Martin Panter)
Date: Thu, 03 Jan 2019 20:21:41 +0000
Subject: [issue35649] http.client doesn't close.  Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546546901.23.0.686832241357.issue35649@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

This was changed in Python 3.2+ in Issue 16723. The response object no longer sets the ?closed? attribute when it runs out of data; it is only set when the ?close? method is called. Perhaps the example should be amended so that it checks if ?read? returned an empty string, rather than checking ?closed?.

Another problem with the example is that printing the chunk as a bytes object can trigger BytesWarning. I would add a ?repr? call to avoid that.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, martin.panter

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

From report at bugs.python.org  Thu Jan  3 16:29:12 2019
From: report at bugs.python.org (adiba)
Date: Thu, 03 Jan 2019 21:29:12 +0000
Subject: [issue35653] All regular expression match groups are the empty string
Message-ID: <1546550950.61.0.624475109311.issue35653@roundup.psfhosted.org>


New submission from adiba <adib1234 at hotmail.de>:

This is the regular expression: ^(?:(\d*)(\D*))*$
This is the test string: 42AZ
This is the expectation for the match groups: ('42', 'AZ')
This is the actual return value: ('', '')

https://gist.github.com/adiba/791ba943a1102994d43171dc98aaecd0

----------
components: Regular Expressions
messages: 332948
nosy: adiba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: All regular expression match groups are the empty string
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Jan  3 16:35:43 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 03 Jan 2019 21:35:43 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
Message-ID: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>


New submission from Martijn Pieters <mj at python.org>:

Currently, the sorting HOWTO at https://docs.python.org/3/howto/sorting.html#odd-and-ends contains the text:

> The sort routines are guaranteed to use __lt__() when making comparisons between two objects. So, it is easy to add a standard sort order to a class by defining an __lt__() method

Nowhere else in the Python documentation is this guarantee made, however. That sort currently uses __lt__ only is, in my opinion, an implementation detail.

The above advice also goes against the advice PEP 8 gives:

> When implementing ordering operations with rich comparisons, it is best to implement all six operations (__eq__, __ne__, __lt__, __le__, __gt__, __ge__) rather than relying on other code to only exercise a particular comparison.
>
> To minimize the effort involved, the functools.total_ordering() decorator provides a tool to generate missing comparison methods.

The 'guarantee' seems to have been copied verbatim from the Wiki version of the HOWTO in https://github.com/python/cpython/commit/0fe095e87f727f4a19b6cbfd718d51935a888740, where that part of the Wiki page was added by an anonymous user in revision 44 to the page: https://wiki.python.org/moin/HowTo/Sorting?action=diff&rev1=43&rev2=44

Can this be removed from the HOWTO?

----------
assignee: docs at python
components: Documentation
messages: 332949
nosy: docs at python, mjpieters, rhettinger
priority: normal
severity: normal
status: open
title: Remove 'guarantee' that sorting only relies on __lt__ from sorting howto
versions: Python 3.6

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

From report at bugs.python.org  Thu Jan  3 17:07:33 2019
From: report at bugs.python.org (skorpeo)
Date: Thu, 03 Jan 2019 22:07:33 +0000
Subject: [issue35649] http.client doesn't close. Infinite loop
In-Reply-To: <1546546901.23.0.686832241357.issue35649@roundup.psfhosted.org>
Message-ID: <CAMXrOMPB7Qvqwuw0F619u+F6+ejh=PnpcShPTFyQFxcThaqgXA@mail.gmail.com>


skorpeo <skorpeo11 at gmail.com> added the comment:

Ha, ok that would explain it.  Yes, I think it would indeed be helpful to
update the example, but then again I guess leaving it as is may be a good
way to find out if people are reading the docs.

On Thu, Jan 3, 2019 at 10:21 PM Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter <vadmium+py at gmail.com> added the comment:
>
> This was changed in Python 3.2+ in Issue 16723. The response object no
> longer sets the ?closed? attribute when it runs out of data; it is only set
> when the ?close? method is called. Perhaps the example should be amended so
> that it checks if ?read? returned an empty string, rather than checking
> ?closed?.
>
> Another problem with the example is that printing the chunk as a bytes
> object can trigger BytesWarning. I would add a ?repr? call to avoid that.
>
> ----------
> assignee:  -> docs at python
> components: +Documentation
> nosy: +docs at python, martin.panter
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35649>
> _______________________________________
>

----------
title: http.client doesn't close.  Infinite loop -> http.client doesn't close. Infinite loop

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

From report at bugs.python.org  Thu Jan  3 17:20:37 2019
From: report at bugs.python.org (Tim Peters)
Date: Thu, 03 Jan 2019 22:20:37 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546554037.66.0.953301677455.issue35654@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I don't know that the language needs to define this, but sticking to __lt__ was a wholly deliberate design decision for CPython.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Thu Jan  3 18:15:53 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Jan 2019 23:15:53 +0000
Subject: [issue35644] venv doesn't work on Windows when no venvlauncher
 executable present
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1546557353.01.0.782548790211.issue35644@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It should just build directly from venv[w]launcher.vcxproj, though you'll need to rename venv[w]launcher.exe to python[w].exe (otherwise they'd conflict in the build directory).

----------

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

From report at bugs.python.org  Thu Jan  3 18:55:04 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 03 Jan 2019 23:55:04 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546559704.65.0.511092406024.issue35598@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +10850

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

From report at bugs.python.org  Thu Jan  3 18:55:11 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 03 Jan 2019 23:55:11 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546559711.65.0.263480966694.issue35598@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +10850, 10851

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

From report at bugs.python.org  Thu Jan  3 18:55:19 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 03 Jan 2019 23:55:19 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546559719.33.0.758213518095.issue35598@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +10850, 10851, 10852

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

From report at bugs.python.org  Thu Jan  3 19:02:01 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 00:02:01 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546560121.63.0.0811626448106.issue35598@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Terry,

I just saw your note about waiting to split this into a Window and Frame class, which was after I had already gotten the PR ready.  I've been mostly offline for the past few days, so I had been working on those changes locally with the intent of pushing them once I was back online.  I understand if it's not a priority to review.  My main goal in splitting them was more for readability rather than for being able to add it to a Tabbed window.  As a follow up to this refactor, I had hoped to split the Basic and Advanced frames into their own tabs, mostly to clean up the create_widgets and to organize the supporting functions.

Anyway, PR11427 refactors the main frame from the window.

----------

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

From report at bugs.python.org  Thu Jan  3 19:02:20 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 00:02:20 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546560140.29.0.78037173851.issue35598@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10851

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

From report at bugs.python.org  Thu Jan  3 19:02:33 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 00:02:33 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546560153.48.0.289077161182.issue35598@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10852

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

From report at bugs.python.org  Thu Jan  3 19:39:08 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 04 Jan 2019 00:39:08 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546562348.66.0.479829328187.issue35654@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> That sort currently uses __lt__ only is, in my opinion, an implementation detail.

Its only an implementation detail until the language specification defines it as a guarantee of the language. Then it becomes part of the sorting API.

Personally, I think it is a nice feature that sorting works for objects which define only __lt__, and it sounds like Tim is happy for that to be part of the sort API.

This is documented under list.sort() but not sorted():

https://docs.python.org/3/library/stdtypes.html#list.sort

https://docs.python.org/3/library/functions.html#sorted

Rather than removing it from the HOWTO, I would rather document that fact under sorted() as well.

If you still want to argue that we should not document this as a language guarantee, for the sake of other implementations such as Jython and IronPython, you should raise it on Python-Dev. It would probably help if you had other implementation maintainers state that this was a burden on them.

For what it is worth, it seems that Jython 2.5 supports this feature too.

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

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

From report at bugs.python.org  Thu Jan  3 20:02:14 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 04 Jan 2019 01:02:14 +0000
Subject: [issue35312] lib2to3.pgen2.parse.ParseError is not roundtrip
 pickleable
In-Reply-To: <1543205038.25.0.788709270274.issue35312@psf.upfronthosting.co.za>
Message-ID: <1546563734.99.0.159885058345.issue35312@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

Looks like this was merged and can be marked as resolved -- should this be backported to 3.7?

----------

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

From report at bugs.python.org  Thu Jan  3 20:13:35 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 04 Jan 2019 01:13:35 +0000
Subject: [issue35653] All regular expression match groups are the empty string
In-Reply-To: <1546550950.61.0.624475109311.issue35653@roundup.psfhosted.org>
Message-ID: <1546564415.88.0.465914297935.issue35653@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Look at the spans of the groups:

>>> import re
>>> re.search(r'^(?:(\d*)(\D*))*$', "42AZ").span(1)
(4, 4)
>>> re.search(r'^(?:(\d*)(\D*))*$', "42AZ").span(2)
(4, 4)

They're telling you that the groups are matching twice (because of the outer *). The first time, they match ('42', 'AZ'); the second time, they match ('', '') at the end of the string.

Not a bug.

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

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

From report at bugs.python.org  Thu Jan  3 21:26:15 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 04 Jan 2019 02:26:15 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1546529885.05.0.34369771305.issue35431@roundup.psfhosted.org>
Message-ID: <20190104022609.GP13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> should the function be expanded to calculate for negative 
> n or is the function expected to work only in combination sense?

If this were my design, I would offer both but in separate functions:

def comb(n, k):
    if n < 0: raise ValueError
    return bincoeff(n, k)

def bincoeff(n, k):
    if n < 0:
        return (-1)**k * bincoeff(n+k+1, k)
    else:
        # implementation here...

I believe we agreed earlier that supporting non-integers was not 
necessary.

Are you also providing a perm(n, k) function?

----------

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

From report at bugs.python.org  Thu Jan  3 21:38:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jan 2019 02:38:31 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546569511.17.0.686116615813.issue35654@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I also prefer to leave this as is.  FWIW, heapq and bisect are also deliberately based on __lt__.  The PEP 8 advice (something I wrote) is primarily about making code less fragile and avoiding surprising behavior.

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

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

From report at bugs.python.org  Thu Jan  3 22:33:01 2019
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Jan 2019 03:33:01 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546572781.17.0.681999017076.issue35654@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Steven, thanks for noticing the docs!  I was surprised to hear it wasn't documented, but not surprised enough to check myself ;-)

This decision was suggested by me, and endorsed by Guido, when designing timsort looking ahead to Python 3, where __cmp__ was going to vanish.  The convenience of needing to add only a single method to support a custom sort order is considerable.

Since it's working as designed and dccumented, and I know for certain that code in the wild relises on it, I'm inclined to reject this report.  However, rather than add more words to `sorted()`, I'd suggest removing words from `sorted()`, pointing instead to the `.sort()` docs for all specification of `sorted()`'s sorting behavior.

----------

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

From report at bugs.python.org  Thu Jan  3 23:10:34 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 04 Jan 2019 04:10:34 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <20190104022609.GP13616@ando.pearwood.info>
Message-ID: <20190104041028.GQ13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

>         return (-1)**k * bincoeff(n+k+1, k)

Oops, that's meant to be n+k-1.

----------

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

From report at bugs.python.org  Fri Jan  4 00:31:44 2019
From: report at bugs.python.org (Kevin)
Date: Fri, 04 Jan 2019 05:31:44 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1546579904.79.0.36673673065.issue35198@roundup.psfhosted.org>


Kevin <kadler at us.ibm.com> added the comment:

Just a friendly ping that there's a PR for this bug waiting to be reviewed.

----------
nosy: +kadler

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

From report at bugs.python.org  Fri Jan  4 02:17:52 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Fri, 04 Jan 2019 07:17:52 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546586272.51.0.45642962891.issue35545@roundup.psfhosted.org>


twisteroid ambassador <twisteroid.ambassador at gmail.com> added the comment:

Hi Emmanuel,

Are you referring to my PR 11403? I don't see where IPv6 uses separate parameters.

----------

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

From report at bugs.python.org  Fri Jan  4 03:01:32 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Fri, 04 Jan 2019 08:01:32 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546588892.74.0.559545613315.issue35545@roundup.psfhosted.org>


twisteroid ambassador <twisteroid.ambassador at gmail.com> added the comment:

I just noticed that in the socket module, an AF_INET address tuple is allowed to have an unresolved host name. Quote:

A pair (host, port) is used for the AF_INET address family, where host is a string representing either a hostname in Internet domain notation like 'daring.cwi.nl' or an IPv4 address like '100.50.200.5', and port is an integer.

https://docs.python.org/3/library/socket.html#socket-families

Passing a tuple of (hostname, port) to socket.connect() successfully connects the socket (tested on Windows). Since the C struct sockaddr_in does not support hostnames, socket.connect obviously does resolution at some point, but its implementation is in C, and I haven't looked into it.

BaseSelectorEventLoop.sock_connect() calls socket.connect() directly, therefore it also supports passing in a tuple of (hostname, port). I just tested ProactorEventLoop.sock_connect() on 3.7.1 on Windows, and it does not support hostnames, raising OSError: [WinError 10022] An invalid argument was supplied.

I personally believe it's not a good idea to allow hostnames in address tuples and in sock.connect(). However, the socket module tries pretty hard to basically accept any (host, port) tuple as address tuples, whether host is an IPv4 address, IPv6 address or host name, so that's probably not going to change.

----------

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

From report at bugs.python.org  Fri Jan  4 03:20:32 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Fri, 04 Jan 2019 08:20:32 +0000
Subject: [issue35545] asyncio.base_events.create_connection doesn't handle
 scoped IPv6 addresses
In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za>
Message-ID: <1546590032.08.0.0937578832795.issue35545@roundup.psfhosted.org>


twisteroid ambassador <twisteroid.ambassador at gmail.com> added the comment:

Oh wait, there's also this in asyncio docs for loop.sock_connect:

Changed in version 3.5.2: address no longer needs to be resolved. sock_connect will try to check if the address is already resolved by calling socket.inet_pton(). If not, loop.getaddrinfo() will be used to resolve the address.

https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.sock_connect

So this is where the current bug comes from! My PR 11403 basically undid this change.

My proposal, as is probably obvious, is to undo this change and insist on passing only resolved address tuples to loop.sock_connect(). My argument is that this feature never worked properly: 

* As mentioned in the previous message, this does not work on ProactorEventLoop.
* On SelectorEventLoop, the resolution done by loop.sock_connect() is pretty weak anyways: it only takes the first resolved address, unlike loop.create_connection() that actually tries all the resolved addresses until one of them successfully connects.

Users should use create_connection() or open_connection() if they want to avoid the complexities of address resolution. If they are reaching for low_level APIs like loop.sock_connect(), they should also handle loop.getaddrinfo() themselves.

----------

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

From report at bugs.python.org  Fri Jan  4 05:38:44 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 04 Jan 2019 10:38:44 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546598324.35.0.306140741928.issue35654@roundup.psfhosted.org>


Martijn Pieters <mj at python.org> added the comment:

Well, if this is indeed by design (and I missed the list.sort() reference) then I agree the HOWTO should not be changed!

I'd be happy to change this to asking for more explicit mentions in the docs for sorted, heapq and bisect that using only < (__lt__) is a deliberate choice.

----------

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

From report at bugs.python.org  Fri Jan  4 05:39:28 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 04 Jan 2019 10:39:28 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546598368.17.0.342130703443.issue35654@roundup.psfhosted.org>


Martijn Pieters <mj at python.org> added the comment:

(I have no opinion on this having to be a language feature however)

----------

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

From report at bugs.python.org  Fri Jan  4 06:02:43 2019
From: report at bugs.python.org (Juan)
Date: Fri, 04 Jan 2019 11:02:43 +0000
Subject: [issue35655] documentation have wrong info about fibo module examples
Message-ID: <1546599762.04.0.11226790108.issue35655@roundup.psfhosted.org>


New submission from Juan <juanbaio10 at gmail.com>:

The below sections in modules documentation have wrong information about fibo module:
6. Modules
6.1. More on Modules
6.1.1. Executing modules as scripts
6.3. The dir() Function

The name of module is Fibo not fibo and the attributes are fab,fab2 not fib,fib2.


root at archlinux ~]# python2 --version
Python 2.7.15
[root at archlinux ~]# pip2 --version
pip 18.1 from /usr/lib/python2.7/site-packages/pip (python 2.7)
[root at archlinux ~]# pip2 install fibo
Collecting fibo
  Using cached https://files.pythonhosted.org/packages/24/50/e74bd48bbef1040afb01b107e6cfbc3c1e991be24c10c40a37e335383e54/Fibo-1.0.0.tar.gz
Installing collected packages: fibo
  Running setup.py install for fibo ... done
Successfully installed fibo-1.0.0
[root at archlinux ~]# pip2 list modules |grep -i fibo
Fibo         1.0.0  
[root at archlinux ~]# python2
Python 2.7.15 (default, Jun 27 2018, 13:05:28) 
[GCC 8.1.1 20180531] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import fibo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named fibo
>>> import Fibo
>>> Fibo.fib(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'fib'
>>> Fibo.fib2(10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'fib2'
>>> Fibo.fab(10)
1
1
2
3
5
8
13
21
34
55
>>> Fibo.fab2(10)
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55]
>>> Fibo.__name__
'Fibo'
>>> dir(Fibo)
['Fab', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'fab', 'fab2', 'fab4']

----------
assignee: docs at python
components: Documentation
messages: 332967
nosy: docs at python, eric.araujo, ezio.melotti, juanbaio10, mdk, willingc
priority: normal
severity: normal
status: open
title: documentation have wrong info about fibo module examples
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/issue35655>
_______________________________________

From report at bugs.python.org  Fri Jan  4 06:04:52 2019
From: report at bugs.python.org (Petter S)
Date: Fri, 04 Jan 2019 11:04:52 +0000
Subject: [issue35656] More matchers in unittest.mock
Message-ID: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>


New submission from Petter S <petter.strandmark at gmail.com>:

The ``ANY`` object in ``unittest.mock`` is also pretty useful when verifying dicts in tests:

    self.assertEqual(result, {
        "message": "Hi!",
        "code": 0,
        "id": mock.ANY
    })

Then it does not matter what the (presumably randomly generated) id is. For the same use cases, objects like ``APPROXIMATE`` (for approximate floating-point matching) and ``MATCHES`` (taking a boolean lambda) would be pretty useful, I think.

----------
components: Library (Lib)
messages: 332968
nosy: Petter S
priority: normal
severity: normal
status: open
title: More matchers in unittest.mock
type: enhancement

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

From report at bugs.python.org  Fri Jan  4 06:11:22 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 04 Jan 2019 11:11:22 +0000
Subject: [issue35655] documentation have wrong info about fibo module examples
In-Reply-To: <1546599762.04.0.11226790108.issue35655@roundup.psfhosted.org>
Message-ID: <1546600282.84.0.316992473614.issue35655@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The documentation examples are not based on the 3rd party Fibo Python package. All examples are based on the short script https://docs.python.org/3/tutorial/modules.html?highlight=fibo#modules :

  For instance, use your favorite text editor to create a file
  called fibo.py in the current directory with the following contents

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Jan  4 06:52:48 2019
From: report at bugs.python.org (Huazuo Gao)
Date: Fri, 04 Jan 2019 11:52:48 +0000
Subject: [issue35657] multiprocessing.Process.join() ignores timeout if child
 process use os.exec*()
Message-ID: <1546602767.92.0.99491105947.issue35657@roundup.psfhosted.org>


New submission from Huazuo Gao <gaohuazuo at gmail.com>:

import os
import time
from multiprocessing import Process

p = Process(target=lambda:os.execlp('bash', 'bash', '-c', 'sleep 1.5'))
t0 = time.time()
p.start()
p.join(0.1)
print(time.time() - t0)

---

Python 3.5 - 3.8 take 1.5 sec to finish
Python 2.7 take 0.1 sec to finish

----------
components: Library (Lib)
messages: 332970
nosy: Huazuo Gao
priority: normal
severity: normal
status: open
title: multiprocessing.Process.join() ignores timeout if child process use os.exec*()
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/issue35657>
_______________________________________

From report at bugs.python.org  Fri Jan  4 06:54:42 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 04 Jan 2019 11:54:42 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1546602882.04.0.27976163044.issue35198@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

While the PR probably solves this - there is a 'bug' in pandas (I expect) that prevents me from completing the test - as, I expect LONG before the .cpp source is to be compiled - there is a error because a wrong flag is passed to the compiler (-Wno-unused-function) and the build stops.

Have not had the time to disect pandas so that I can get a .cpp source compiled.

+++++
Successfully installed pip-18.1
root at x066:[/data/prj/python/git/kadler]pip list
/opt/lib/python3.8/site-packages/pip/_vendor/html5lib/_trie/_base.py:3: DeprecationWdeprecated, and in 3.8 it will stop working
  from collections import Mapping
Package    Version
---------- -------
pip        18.1
setuptools 39.0.1
root at x066:[/data/prj/python/git/kadler]pip install numpy
/opt/lib/python3.8/site-packages/pip/_vendor/html5lib/_trie/_base.py:3: DeprecationWdeprecated, and in 3.8 it will stop working
  from collections import Mapping
Collecting numpy
/opt/lib/python3.8/site-packages/pip/_vendor/msgpack/fallback.py:220: PendingDepreca
  warnings.warn(
  Using cached https://files.pythonhosted.org/packages/2d/80/1809de155bad674b494248b
Installing collected packages: numpy
  Running setup.py install for numpy ... done
Successfully installed numpy-1.15.4

...
Installing collected packages: six, python-dateutil, pytz, pandas
...
    copying pandas/io/formats/templates/html.tpl -> build/lib.aix-6.1-3.8-pydebug/pandas/io/formats/templates
    UPDATING build/lib.aix-6.1-3.8-pydebug/pandas/_version.py
    set build/lib.aix-6.1-3.8-pydebug/pandas/_version.py to '0.23.4'
    running build_ext
    building 'pandas._libs.algos' extension
    creating build/temp.aix-6.1-3.8-pydebug
    creating build/temp.aix-6.1-3.8-pydebug/pandas
    creating build/temp.aix-6.1-3.8-pydebug/pandas/_libs
    xlc_r -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -Ipandas/_libs/src/klib -Ipandas/_libs/src -I/opt/lib/python3.8/site-packages/numpy/core/include -I/opt/include/python3.8dm -c pandas/_libs/algos.c -o build/temp.aix-6.1-3.8-pydebug/pandas/_libs/algos.o -Wno-unused-function
    xlc_r: 1501-210 (S) command option Wno-unused-function contains an incorrect subargument
    error: command 'xlc_r' failed with exit status 40

    ----------------------------------------
Command "/opt/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-xnscgehv/pandas/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-0w46p413/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-xnscgehv/pandas/

----------

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

From report at bugs.python.org  Fri Jan  4 06:57:56 2019
From: report at bugs.python.org (Malcolm Smith)
Date: Fri, 04 Jan 2019 11:57:56 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1546603076.38.0.554863082209.issue10948@roundup.psfhosted.org>


Malcolm Smith <malcolm.smith at gmail.com> added the comment:

Please reopen this issue. The distutils2 project has now been abandoned, so that's no longer a justification for taking no action. 

At the very least, the documentation should be fixed to either warn about this surprising behavior, or make it clear that the the dir_util functions are for distutils internal use only.

----------
nosy: +Malcolm Smith
versions: +Python 3.7

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

From report at bugs.python.org  Fri Jan  4 07:17:40 2019
From: report at bugs.python.org (Bart van den Donk)
Date: Fri, 04 Jan 2019 12:17:40 +0000
Subject: [issue35658] Reggie_Linear_Regression_Solution.ipynb devide by 10
 diff with multiply by .1
Message-ID: <1546604258.86.0.0685397461869.issue35658@roundup.psfhosted.org>


New submission from Bart van den Donk <bart.van.den.donk at gmail.com>:

possible_ms1 = [i*.1 for i in range(-100, 101, 1)] #your list comprehension here
print(possible_ms1)
possible_ms2 = [i/10 for i in range(-100, 101, 1)] #your list comprehension here
print(possible_ms2)

Multiply by .1 gives dirty results.
Divide by 10 gives clean results.

----------
components: Demos and Tools, Regular Expressions
messages: 332973
nosy: Bart van den Donk, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Reggie_Linear_Regression_Solution.ipynb devide by 10 diff with multiply by .1
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Jan  4 08:00:08 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 04 Jan 2019 13:00:08 +0000
Subject: [issue35609] Improve of abc.py docstring
In-Reply-To: <1546052751.93.0.333388893142.issue35609@roundup.psfhosted.org>
Message-ID: <1546606808.02.0.499057950841.issue35609@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

> No plan for removal.  See https://bugs.python.org/issue28886#msg282582

Thanks!

----------

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

From report at bugs.python.org  Fri Jan  4 08:01:24 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 04 Jan 2019 13:01:24 +0000
Subject: [issue35658] Reggie_Linear_Regression_Solution.ipynb devide by 10
 diff with multiply by .1
In-Reply-To: <1546604258.86.0.0685397461869.issue35658@roundup.psfhosted.org>
Message-ID: <1546606884.3.0.373335113122.issue35658@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Not a bug. 0.1 is a binary floating point value, please read the FAQs:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

1/10 = 0.1 in decimal cannot be represented *exactly* in binary floating point, so when you type 0.1 as a float, the actual value you get is the closest number you can get using 53 bits for the significant digits, 8 bits for the exponent and 1 bit for the sign (plus or minus). That is approximately 0.1000000000000000056 or so.

Unfortunately you cannot get any closer to 1/10 in binary floating point numbers, for the same reason you cannot get 1/3 exactly in decimal.

See also 

https://stackoverflow.com/questions/8215437/floating-point-accuracy-in-python

https://stackoverflow.com/questions/21895756/why-are-floating-point-numbers-inaccurate

https://stackoverflow.com/questions/1089018/why-cant-decimal-numbers-be-represented-exactly-in-binary?noredirect=1&lq=1

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Jan  4 08:19:22 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 04 Jan 2019 13:19:22 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546607962.67.0.897549184917.issue24928@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

ping Vaibhav :-)

> I would like to make a PR for this.

----------
nosy: +eamanu

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

From report at bugs.python.org  Fri Jan  4 08:31:36 2019
From: report at bugs.python.org (Vaibhav Gupta)
Date: Fri, 04 Jan 2019 13:31:36 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546608696.47.0.557226678792.issue24928@roundup.psfhosted.org>


Vaibhav Gupta <vaibhgupt199 at gmail.com> added the comment:

Hi Emmanuel

Please go ahead and make a PR. :)

----------

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

From report at bugs.python.org  Fri Jan  4 08:52:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 13:52:43 +0000
Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument
 functions
In-Reply-To: <1545749861.65.0.712150888896.issue23867@roundup.psfhosted.org>
Message-ID: <CA+3bQGFUNrydYaPxw807Gt2reQ7L+v69pKG8TKTsChPR-fwUmg@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

Nice optimization! I wanted to implement it, but then I forgot.

----------

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

From report at bugs.python.org  Fri Jan  4 09:14:36 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 04 Jan 2019 14:14:36 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611276.58.0.172731957545.issue35631@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 31ec52a9afedd77e36a3ddc31c4c45664b8ac410 by Ivan Levkivskyi (Ville Skytt?) in branch 'master':
bpo-35631: Improve typing docs wrt abstract/concrete collection types (GH-11396)
https://github.com/python/cpython/commit/31ec52a9afedd77e36a3ddc31c4c45664b8ac410


----------

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

From report at bugs.python.org  Fri Jan  4 09:14:58 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:14:58 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611298.29.0.182207976778.issue35631@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10853

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

From report at bugs.python.org  Fri Jan  4 09:15:05 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:15:05 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611305.11.0.217445490271.issue35631@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10853, 10854

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

From report at bugs.python.org  Fri Jan  4 09:15:11 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:15:11 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611311.02.0.0271725433383.issue35631@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10854, 10856

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

From report at bugs.python.org  Fri Jan  4 09:15:18 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:15:18 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611318.62.0.983371963034.issue35631@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10856, 10857

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

From report at bugs.python.org  Fri Jan  4 09:15:25 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:15:25 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611325.6.0.968084297766.issue35631@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10856, 10857, 10858

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

From report at bugs.python.org  Fri Jan  4 09:15:31 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:15:31 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611331.48.0.354661832449.issue35631@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10853, 10854, 10855, 10856, 10857, 10858

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

From report at bugs.python.org  Fri Jan  4 09:20:21 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Jan 2019 14:20:21 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546611621.73.0.364812516131.issue35631@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 902196d867a34cc154fa9c861c883e69232251c6 by Miss Islington (bot) in branch '3.7':
bpo-35631: Improve typing docs wrt abstract/concrete collection types (GH-11396)
https://github.com/python/cpython/commit/902196d867a34cc154fa9c861c883e69232251c6


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Jan  4 09:26:42 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 04 Jan 2019 14:26:42 +0000
Subject: [issue35631] Improve typing docs wrt abstract/concrete collection
 types
In-Reply-To: <1546328143.85.0.754432945533.issue35631@roundup.psfhosted.org>
Message-ID: <1546612002.46.0.883399873751.issue35631@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I think this can be closed now. Whether to merge doc-fix backport to now security-only 3.6 branch is up to Ned.

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

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

From report at bugs.python.org  Fri Jan  4 09:48:58 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 04 Jan 2019 14:48:58 +0000
Subject: [issue35657] multiprocessing.Process.join() ignores timeout if child
 process use os.exec*()
In-Reply-To: <1546602767.92.0.99491105947.issue35657@roundup.psfhosted.org>
Message-ID: <1546613338.01.0.904985365023.issue35657@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

I don't know what triggered the change, but I strongly suspect this is not a supported use of the multiprocessing module; Process is for worker processes (still running Python), and it has a lot of coordination machinery set up between parent and child (for use by, among other things,  join) that exec severs rather abruptly.

Launching unrelated child processes is what the subprocess module is for.

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

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

From report at bugs.python.org  Fri Jan  4 10:20:15 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 04 Jan 2019 15:20:15 +0000
Subject: [issue35657] multiprocessing.Process.join() ignores timeout if child
 process use os.exec*()
In-Reply-To: <1546602767.92.0.99491105947.issue35657@roundup.psfhosted.org>
Message-ID: <1546615215.09.0.765675752381.issue35657@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Looks like the cause of the change was when os.pipe was changed to create non-inheritable pipes by default; if I monkey-patch multiprocessing.popen_fork.Popen._launch to use os.pipe2(0) instead of os.pipe() to get inheritable descriptors or just clear FD_CLOEXEC in the child with fcntl.fcntl(child_w, fcntl.F_SETFD, 0), the behavior returns to Python 2's behavior.

The problem is caused by the mismatch in lifetimes between the pipe fd and the child process itself; normally the pipe lives as long as the child process (it's never actually touched in the child process at all, so it just dies with the child), but when exec gets involved, the pipe is closed long before the child ends.

The code in Popen.wait that is commented with "This shouldn't block if wait() returned successfully" is probably the issue; wait() first waits on the parent side of the pipe fd, which returns immediately when the child execs and the pipe is closed. The code is assumes the poll on the process itself can be run in blocking (since the process should have ended already) but this assumption is wrong of course.

Possible solutions:

1. No code changes; document that exec in worker processes is unsupported (use subprocess, possibly with a preexec_fn, for this use case).

2. Precede the call to process_obj._bootstrap() in the child with fcntl.fcntl(child_w, fcntl.F_SETFD, 0) to clear the CLOEXEC flag on the child's descriptor, so the file descriptor remains open in the child post-exec. Using os.pipe2(0) instead of os.pipe() in _launch would also work and restore the precise 3.3 and earlier behavior, but it would introduce reintroduce race conditions with parent threads, so it's better to limit the scope to the child process alone, for the child's version of the fd alone.

3. Change multiprocessing.popen_fork.Popen.wait to use os.WNOHANG for all calls with a non-None timeout (not just timeout=0.0), rather than trusting multiprocessing.connection.wait's return value (which only says whether the pipe is closed, not whether the process is closed). Problem is, this would just change the behavior from waiting for the lifetime of the child no matter what to waiting until the exec and then returning immediately, even well before the timeout; it might also introduce race conditions if the fd registers as being closed before the process is fully exited. Point is, this approach would likely require a lot of subtle tweaks to make it work.

I'm in favor of either #1 or #2. #2 feels like a intentionally opening a resource leak on the surface, but I think it's actually fine, since we already signed up for a file descriptor that would live for the life of the process; the fact that it's exec-ed seems sort of irrelevant.

----------
keywords: +3.4regression

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

From report at bugs.python.org  Fri Jan  4 11:08:22 2019
From: report at bugs.python.org (Kevin)
Date: Fri, 04 Jan 2019 16:08:22 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1546618102.94.0.898324410847.issue35198@roundup.psfhosted.org>


Kevin <kadler at us.ibm.com> added the comment:

Ah. We always compile with GCC, so would not have hit that particular problem.

----------

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

From report at bugs.python.org  Fri Jan  4 11:10:57 2019
From: report at bugs.python.org (Ajay Mahato)
Date: Fri, 04 Jan 2019 16:10:57 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1546618257.88.0.960668055513.issue9305@roundup.psfhosted.org>


Ajay Mahato <ajjayymahato at gmail.com> added the comment:

I would like to work on this issue. Please assign this to me.

----------
nosy: +Ajay Mahato

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

From report at bugs.python.org  Fri Jan  4 12:25:03 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 17:25:03 +0000
Subject: [issue19120] shlex.shlex.lineno reports a different number depending
 on the previous token
In-Reply-To: <1380422113.39.0.502795028764.issue19120@psf.upfronthosting.co.za>
Message-ID: <1546622703.07.0.08356638462.issue19120@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

There was a parameter `punctuation_chars` added to the shlex.shlex class with issue 1521950 (implemented for 3.6).  Although the comma is not one of the default punctuation characters (setting the parameter to punctuation_chars=True won't change the behavior), you can use `punctuation_chars=","` to see the results reported in this issue.


>>> second = shlex.shlex('word1 word2,\nword3', punctuation_chars=',')
>>> second.get_token()
'word1'
>>> second.lineno
1
>>> second.get_token()
'word2'
>>> second.lineno
1
>>> second.get_token()
','
>>> second.lineno
2
>>>


Closing this as a duplicate of #1521950.

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> shlex.split() does not tokenize like the shell

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

From report at bugs.python.org  Fri Jan  4 12:39:22 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Fri, 04 Jan 2019 17:39:22 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1546623562.55.0.574633721707.issue35431@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

@steven.daprano 
> Are you also providing a perm(n, k) function?
I didn't know it is also being implemented. Should I start on that too?

My implementation is based on these requirements:

> - Spell it comb(n, k).
> - TypeError if args aren't ints.
> - ValueError if not 0 <= k <= n.

Should the bincoeff function be same with exception of allowing negative n?

----------

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

From report at bugs.python.org  Fri Jan  4 12:56:09 2019
From: report at bugs.python.org (Tim Peters)
Date: Fri, 04 Jan 2019 17:56:09 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1546624569.37.0.765100758058.issue35431@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Please resist pointless feature creep.  The original report was about comb(n, k) for integer n and k with 0 <= k <= n and that's all.  Everyone who commented appeared to agree they'd find that useful.

But nobody has said they'd find generalizing beyond those constraints USEFUL, or that they'd find perm(n, k) USEFUL.  They just pointed out that such things are possible.

Every bit of new API implies eternal maintenance, porting, testing, doc, and conceptual costs.  So please stick to what's (at least nearly) universally agreed to be useful.  Complications can be added later if there turns out to be real demand for them.

----------

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

From report at bugs.python.org  Fri Jan  4 13:37:32 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 04 Jan 2019 18:37:32 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1546618102.94.0.898324410847.issue35198@roundup.psfhosted.org>
Message-ID: <bd3021ef-db99-058f-ed93-a046e77e0c17@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 04/01/2019 17:08, Kevin wrote:
> Kevin <kadler at us.ibm.com> added the comment:
>
> Ah. We always compile with GCC, so would not have hit that particular problem.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35198>
> _______________________________________
>
FYI. I found a 'hack' in ./setup.py to skip adding the argument.
Progressing.

----------

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

From report at bugs.python.org  Fri Jan  4 13:43:29 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Fri, 04 Jan 2019 18:43:29 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1546627409.25.0.879370490993.issue35431@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

@tim.peters
Got it.

----------

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

From report at bugs.python.org  Fri Jan  4 13:52:11 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 18:52:11 +0000
Subject: [issue35168] shlex punctuation_chars inconsistency
In-Reply-To: <1541439134.06.0.788709270274.issue35168@psf.upfronthosting.co.za>
Message-ID: <1546627931.46.0.752459275578.issue35168@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python
stage:  -> needs patch
versions:  -Python 3.6

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

From report at bugs.python.org  Fri Jan  4 14:04:33 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 04 Jan 2019 19:04:33 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1546628673.01.0.517501642701.issue35198@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Further along - however, I never get to the "link" routine.

Again, this is likely a pandas coding issue - currently python is calling xlc_r ..., but when I manually modify it to xlC_r I get the same error.

xlc_r -D_LARGE_FILES -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -Ipandas/_libs -I./pandas/_libs -Ipandas/_libs/src/klib -Ipandas/_libs/src -I/opt/lib/python3.8/site-packages/numpy/core/include -I/opt/include/python3.8dm -c pandas/_libs/window.cpp -o build/temp.aix-6.1-3.8-pydebug/pandas/_libs/window.o
"pandas/_libs/window.cpp", line 9943.23: 1540-0063 (S) The text "(" is unexpected.
"pandas/_libs/window.cpp", line 10030.23: 1540-0063 (S) The text "(" is unexpected.
"pandas/_libs/window.cpp", line 11165.21: 1540-0063 (S) The text "(" is unexpected.
error: command 'xlc_r' failed with exit status 1
root at x066:[/data/prj/aixtools/git/pandas-master]ebug/pandas/_libs/window.o                    <
"pandas/_libs/window.cpp", line 9943.23: 1540-0063 (S) The text "(" is unexpected.
"pandas/_libs/window.cpp", line 10030.23: 1540-0063 (S) The text "(" is unexpected.
"pandas/_libs/window.cpp", line 11165.21: 1540-0063 (S) The text "(" is unexpected.

root at x066:[/data/prj/aixtools/git/pandas-master]xlC_r -D_LARGE_FILES -O -I/opt/include -O2 -qm>
"pandas/_libs/window.cpp", line 9943.23: 1540-0063 (S) The text "(" is unexpected.
"pandas/_libs/window.cpp", line 10030.23: 1540-0063 (S) The text "(" is unexpected.
"pandas/_libs/window.cpp", line 11165.21: 1540-0063 (S) The text "(" is unexpected.

FYI. Will look more tomorrow, but if you have an idea, like the -D_LARGE_FILES fix, I am much obliged.

----------

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

From report at bugs.python.org  Fri Jan  4 14:05:44 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 04 Jan 2019 19:05:44 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1546628744.42.0.696518587105.issue34522@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Jan  4 14:28:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 19:28:19 +0000
Subject: [issue35617] unittest discover does not work with implicit namespaces
In-Reply-To: <1546162337.0.0.646769357962.issue35617@roundup.psfhosted.org>
Message-ID: <1546630099.92.0.284301138698.issue35617@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If this is truly a duplicate, this should be closed and the issue number in the pr title changed to 23882.  Any reviewer should look at both proposed fixes, as they are not the same.  The other patch has what looks like the beginning of a test.

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

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

From report at bugs.python.org  Fri Jan  4 14:31:39 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 19:31:39 +0000
Subject: [issue35625] Comprehension doc doesn't mention buggy class scope
 behavior
In-Reply-To: <1546253280.49.0.920078772343.issue35625@roundup.psfhosted.org>
Message-ID: <1546630299.29.0.105941235635.issue35625@roundup.psfhosted.org>


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


----------
title: documentation of list, set & dict comprehension make no mention of buggy class scope behavior -> Comprehension doc doesn't mention buggy class scope behavior
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  4 14:32:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 19:32:53 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1546630373.0.0.52796856937.issue35627@roundup.psfhosted.org>


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


----------
nosy: +davin, pitrou

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

From report at bugs.python.org  Fri Jan  4 14:34:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 19:34:10 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546630450.9.0.345181624358.issue35629@roundup.psfhosted.org>


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


----------
nosy: +pitrou
versions:  -Python 3.6

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

From report at bugs.python.org  Fri Jan  4 14:42:30 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jan 2019 19:42:30 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1546630950.62.0.328453643407.issue35627@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I couldn't reproduce on Ubuntu either.  I tried the "fork", "forkserver" and "spawn" methods (all with 3.7.2).

Terry, if you are on Windows, can you try the script?  Be sure to enclose the test() call in a "if __name__ == '__main__'" guard.

----------

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

From report at bugs.python.org  Fri Jan  4 14:43:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 19:43:37 +0000
Subject: [issue35624] Shelve sync issues while using Gevent
In-Reply-To: <1546243936.53.0.108056450415.issue35624@roundup.psfhosted.org>
Message-ID: <1546631017.01.0.672871445523.issue35624@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.6 only gets security fixes.  Please verify that there is a problem in 3.8 (or at least 3.7)

Also demonstrate that issue is not with the 3rd party gevent module.  Does gevent includes compiled non-python code?  (I suspect it does, but don't know.)  If so, your script should *not* import that extension.  Or you should close this as '3rd party' and submit a report to the gevent authors, who should be better able to determine where the problem originates.

----------
nosy: +terry.reedy
versions: +Python 3.8 -Python 3.6

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

From report at bugs.python.org  Fri Jan  4 14:44:32 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jan 2019 19:44:32 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546631072.95.0.622389125935.issue35629@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, looks like a duplicate.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> multiprocessing.Pool.imaps iterators do not maintain alive the multiprocessing.Pool objects

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

From report at bugs.python.org  Fri Jan  4 14:47:04 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 19:47:04 +0000
Subject: [issue33896] Document what components make up the filecmp.cmp os.stat
 signature.
In-Reply-To: <1529345931.78.0.56676864532.issue33896@psf.upfronthosting.co.za>
Message-ID: <1546631224.27.0.385047326191.issue33896@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
versions:  -Python 3.6

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

From report at bugs.python.org  Fri Jan  4 14:52:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 19:52:42 +0000
Subject: [issue12991] Python 64-bit build on HP Itanium - Executable built
 successfully but modules failed with HP Compiler
In-Reply-To: <1316173380.25.0.744886006815.issue12991@psf.upfronthosting.co.za>
Message-ID: <1546631562.36.0.707780612859.issue12991@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Closed based on msg323776.

----------
nosy: +cheryl.sabella
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Jan  4 15:00:20 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 04 Jan 2019 20:00:20 +0000
Subject: [issue35381] Heap-allocated posixmodule types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1546632020.3.0.915522174919.issue35381@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Jan  4 15:35:21 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 20:35:21 +0000
Subject: [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1546634121.33.0.335753501144.issue15457@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Issue24400 changed some of the documentation wording around generators.  I don't know if there is still interest in applying the other parts of this patch.

----------
nosy: +cheryl.sabella
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Jan  4 15:39:37 2019
From: report at bugs.python.org (Gabriel Corona)
Date: Fri, 04 Jan 2019 20:39:37 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1546634377.87.0.452922534853.issue18747@roundup.psfhosted.org>


Gabriel Corona <corona.gabriel at gmail.com> added the comment:

Now that the default PRNG of the 'random' package is automatically reseeded at fork, wouldn't it make sense to reseed the OpenSSL seed as well?

(At the same time the OpenSSL wiki states [1] that "The situation has changed greatly, starting with OpenSSL 1.1.1 which completely rewrote RNG. The concerns [of fork unsafety] do not really apply any more".)

[1] https://wiki.openssl.org/index.php/Random_fork-safety

----------
nosy: +Gabriel Corona

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

From report at bugs.python.org  Fri Jan  4 15:43:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Jan 2019 20:43:53 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546634633.39.0.829066669062.issue35643@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Would not be better to just remove a backslash?

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

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

From report at bugs.python.org  Fri Jan  4 15:47:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Jan 2019 20:47:36 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546634856.86.0.196673715825.issue35638@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You can use locale.format_string() for locale aware formatting.

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

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

From report at bugs.python.org  Fri Jan  4 15:51:00 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 20:51:00 +0000
Subject: [issue32660] Solaris should support constants like termios' FIONREAD
In-Reply-To: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>
Message-ID: <1546635060.93.0.37857623174.issue32660@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


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

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

From report at bugs.python.org  Fri Jan  4 16:13:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Jan 2019 21:13:13 +0000
Subject: [issue35616] Change references to '4.0'.
In-Reply-To: <1546145542.58.0.745728606206.issue35616@roundup.psfhosted.org>
Message-ID: <1546636393.01.0.00919448906012.issue35616@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Removing the C API function is a major breaking change. AFAIK there was no precedence since 3.0. It may be that we will name the new version 4.0 after doing this.

In any case, first than remove this API, we need to pass the following steps:

* Implement Py_DEPRECATED on Windows and use it for *all* deprecated functions.
* Get rid of using deprecated API in the core and stdlib. I'm working on this.
* I think it is good idea to implement a custom build without wchar_t cache and deprecated API for testing with third-party code. I'm working on this.

One or two versions after using Py_DEPRECATED for all deprecated functions (but not earlier than EOL of 2.7) we can make them issuing run-time warnings. One or two versions after this we can replace them with stub functions that always fail. I think they can be removed after around 5 years from now. Currently we do not have exact terms. I do not see a problem with using 4.0 as a hypothetical removal term.

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

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

From report at bugs.python.org  Fri Jan  4 16:17:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:17:23 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546636643.44.0.465787511215.issue35634@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Serhiy, nosying you because Ammar identified your commit as relevant.
https://github.com/python/cpython/commit/e036ef8fa29f27d57fe9f8cef8d931d4122d8223
---

3.6 is also security-fix only.

Normally, code bug reports need a minimal, reproducible, initially-failing test case that only uses the stdlib, not 3rd party code.  A test case would have to include a simplified version of a multidict.

The problem here is that a multidict with duplicate keys is not a proper mapping, in spite of having a MutableMapping interface.  (Just curious, what does d['a'] return?). 

The purpose of the package is to meet the needs of HTTP Headers and URL query strings (and other situations) where the 'keys' are value-type tags, not true mapping keys.  Another example would be a bibliography entry that tags each of multiple author names with 'Author:'.  (Aside: A deficiency of git (github) is allowing only 1 author key and only one github username as the value.)

Is an object with duplicate keys legal for **expression in calls?
https://docs.python.org/3/reference/expressions.html#index-48
says that expression must evaluate to a 'mapping'.  The glossary entry
https://docs.python.org/3/glossary.html#term-mapping says
"A container object that supports arbitrary key lookups and implements the methods specified in the Mapping or MutableMapping abstract base classes." followed by unique-key examples.  To me, 'key lookup' implies unique keys.  The Mapping functions include 'keys' and 'items'.  What signature?  To return set-like views, the keys should be unique.

If we take the call to be a bug, is CPython *obligated* to immediately raise an exception?  In other words, must every call with **mapping take the time to check for duplicates because someone might pass a dup-key 'mapping'.

----------
nosy: +serhiy.storchaka, terry.reedy
stage:  -> test needed
versions: +Python 3.7, Python 3.8 -Python 3.6

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

From report at bugs.python.org  Fri Jan  4 16:31:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:31:09 +0000
Subject: [issue35639] Lowecasing Unicode Characters
In-Reply-To: <1546430623.48.0.462352175173.issue35639@roundup.psfhosted.org>
Message-ID: <1546637469.76.0.158111095047.issue35639@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Latin Capital Letter I with Dot Above

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

From report at bugs.python.org  Fri Jan  4 16:32:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:32:55 +0000
Subject: [issue35649] http.client doesn't close. Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546637575.09.0.921505972067.issue35649@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  4 16:35:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:35:59 +0000
Subject: [issue35651] PEP 257 (active) references PEP 258 (rejected) as if it
 were active
In-Reply-To: <1546536866.6.0.633154963858.issue35651@roundup.psfhosted.org>
Message-ID: <1546637759.61.0.252179561533.issue35651@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Guido, you are the

----------
nosy: +goodger, gvanrossum, terry.reedy
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/issue35651>
_______________________________________

From report at bugs.python.org  Fri Jan  4 16:36:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:36:19 +0000
Subject: [issue35651] PEP 257 (active) references PEP 258 (rejected) as if it
 were active
In-Reply-To: <1546536866.6.0.633154963858.issue35651@roundup.psfhosted.org>
Message-ID: <1546637779.79.0.747498444199.issue35651@roundup.psfhosted.org>


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


----------
Removed message: https://bugs.python.org/msg333003

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

From report at bugs.python.org  Fri Jan  4 16:39:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:39:09 +0000
Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__
 from sorting howto
In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org>
Message-ID: <1546637949.61.0.407463768118.issue35654@roundup.psfhosted.org>


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


----------
versions: +Python 3.8 -Python 3.6

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

From report at bugs.python.org  Fri Jan  4 16:40:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 21:40:00 +0000
Subject: [issue35657] multiprocessing.Process.join() ignores timeout if child
 process use os.exec*()
In-Reply-To: <1546602767.92.0.99491105947.issue35657@roundup.psfhosted.org>
Message-ID: <1546638000.13.0.990439285808.issue35657@roundup.psfhosted.org>


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


----------
nosy: +davin, pitrou
stage:  -> needs patch
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  4 17:02:06 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jan 2019 22:02:06 +0000
Subject: [issue35657] multiprocessing.Process.join() ignores timeout if child
 process use os.exec*()
In-Reply-To: <1546602767.92.0.99491105947.issue35657@roundup.psfhosted.org>
Message-ID: <1546639326.73.0.567717588988.issue35657@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm in favor of #1 *and* not documenting it either.  I don't think it's reasonable for the documentation to enumerate all the kinds of situations where executing arbitrary code in a child process might lead to dysfunction.

Realistically, if you want to spawn a subprocess, you should just use subprocess, not multiprocessing + exec().

In other words, I'd like to close this issue as "won't fix" if nobody objects.

----------

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

From report at bugs.python.org  Fri Jan  4 17:03:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:03:45 +0000
Subject: [issue35606] Add prod() function to the math module
In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org>
Message-ID: <1546639425.48.0.35756370037.issue35606@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Computing the geometric mean of numbers require to compute the product of these numbers:
https://en.wikipedia.org/wiki/Geometric_mean

The geometric mean can be used to summarize benchmark results using different units to get a single number.

--

When computing the product of floats, is there a smart implementation reducing the error? I'm asking because math.fsum() doesn't use a naive loop but a smart implementation to minimize the error.

--

Mark Dickinson:
> On this subject, some effort has been made in the past to make (almost) all the math module functions behave consistently with respect to things like exceptions, overflow, infinities, nans, signed zeros, etc.

"versus"

R?mi Lapeyre:
> A naive implementation would also support user-defined types which would probably be a good thing IMO

Would it make sense to only implement product for an iterable of floats, as math.fsum()?

----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:04:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jan 2019 22:04:48 +0000
Subject: [issue35616] Change references to '4.0'.
In-Reply-To: <1546145542.58.0.745728606206.issue35616@roundup.psfhosted.org>
Message-ID: <1546639488.4.0.857752980912.issue35616@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After reading Serhiy's explanation, I agree that '4.0' is better than a specific '3.nn'.  I did not realize how much was still left to be done.  We can revisit this when there is a definite removal date.  A literal 'sometime' might be better, but not worth arguing for.  Most of the other occurrences of '4.0' are related to the old unicode API.

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

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

From report at bugs.python.org  Fri Jan  4 17:06:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:06:41 +0000
Subject: [issue35657] multiprocessing.Process.join() ignores timeout if child
 process use os.exec*()
In-Reply-To: <1546602767.92.0.99491105947.issue35657@roundup.psfhosted.org>
Message-ID: <1546639601.43.0.577966083762.issue35657@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:08:25 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 04 Jan 2019 22:08:25 +0000
Subject: [issue35606] Add prod() function to the math module
In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org>
Message-ID: <1546639705.12.0.242211779259.issue35606@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree with Mark that correctness, rather than performance, should be the main attraction of a stdlib implementation.

By the way "prod" is slightly obscure (though it's Numpy's chosen spelling), how about "product"?  After all, we went with the full "factorial".

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

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

From report at bugs.python.org  Fri Jan  4 17:09:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:09:47 +0000
Subject: [issue35622] RFE: Add os.sched_setattr() and os.sched_getattr()
 functions
In-Reply-To: <1546210790.69.0.579405254492.issue35622@roundup.psfhosted.org>
Message-ID: <1546639787.33.0.949701897886.issue35622@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: Add support for Linux SCHED_DEADLINE -> RFE: Add os.sched_setattr() and os.sched_getattr() functions
versions: +Python 3.8

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

From report at bugs.python.org  Fri Jan  4 17:12:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:12:34 +0000
Subject: [issue35611] open doesn't call IncrementalEncoder with final=True
In-Reply-To: <1546063215.14.0.206805691744.issue35611@roundup.psfhosted.org>
Message-ID: <1546639954.62.0.811799704284.issue35611@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:14:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:14:08 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1546640048.54.0.0320906221423.issue35627@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:18:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:18:53 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1546640333.61.0.89349938113.issue35627@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

mp_hang.py: I created the example into a script, I added the __main__ section described by Antoine. I cannot reproduce the bug on the Python master branch on Linux.

@June Kim: What is the output when it hangs? Can you try your example without VS Code? For example, try to run it in a cmd.exe terminal?

----------
Added file: https://bugs.python.org/file48023/mp_hang.py

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

From report at bugs.python.org  Fri Jan  4 17:27:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:27:15 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
In-Reply-To: <1546394840.15.0.0864584726941.issue35635@roundup.psfhosted.org>
Message-ID: <1546640835.58.0.0577928189113.issue35635@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Am I missing something ? Given the complexity of this, I would expect this to be better documented in the sections explaining how `asyncio.subprocess` and `threading` interact.

The current documentation says:

"To handle signals and to execute subprocesses, the event loop must be run in the main thread."

https://docs.python.org/dev/library/asyncio-dev.html#concurrency-and-multithreading

But I agree that the doc can be enhanced :-) Do you have suggestions?

----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:28:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:28:46 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
In-Reply-To: <1546394840.15.0.0864584726941.issue35635@roundup.psfhosted.org>
Message-ID: <1546640926.57.0.333227628353.issue35635@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

By the way, asyncio doc is outdated:
"The default asyncio event loop implementation on Windows does not support subprocesses. Subprocesses are available for Windows if a ProactorEventLoop is used. See Subprocess Support on Windows for details."
https://docs.python.org/dev/library/asyncio-subprocess.html#creating-subprocesses

It's no longer true in Python 3.8:

"Changed in version 3.8: On Windows, ProactorEventLoop is now the default event loop."
https://docs.python.org/dev/library/asyncio-platforms.html

----------

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

From report at bugs.python.org  Fri Jan  4 17:33:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:33:37 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1546641217.02.0.103377849613.issue35627@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I ran mp_hang.py on Windows 10 with Python 3.7.2: the script completes (it doesn't hang). The issue might be specific to VS Code (on Windows?).

----------

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

From report at bugs.python.org  Fri Jan  4 17:38:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:38:23 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1546641503.59.0.0836790636599.issue35378@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

bpo-35629 has been marked as a duplicate of this issue.

----------

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

From report at bugs.python.org  Fri Jan  4 17:40:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:40:33 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546641633.43.0.707715687963.issue35629@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I suggest you to write:

with multiprocessing.Pool(4) as pool: result = tuple(pool.imap(print, (1, 2, 3)))

On Python 3.8, your example will now log a resource warning since you don't close/terminate explicitly the pool.

----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:42:42 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 04 Jan 2019 22:42:42 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546641762.61.0.253669715327.issue35629@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

If you see the bottom of my issue, I've suggested (nearly) the same thing -- though I require python2.x compatibility so I'm using `contextlib.closing`

----------

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

From report at bugs.python.org  Fri Jan  4 17:42:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:42:50 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546641770.58.0.407709063686.issue35633@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Does the test pass if you open the file in read+write ("w+b") mode rather than write-only ("wb") mode?

I'm talking about this line:

open(support.TESTFN, 'wb')

Note: if you want to test, you have the modify the mode twice:
  "with open('%s', 'wb') as f:" % support.TESTFN,
and
  with open(support.TESTFN, 'wb') as f:

----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  4 17:43:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:43:26 +0000
Subject: [issue35633] test_eintr: test_lockf() fails with "PermissionError:
 [Errno 13] Permission denied" on AIX
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546641806.13.0.341892346347.issue35633@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_eintr fails on AIX since fcntl functions were modified -> test_eintr: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX

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

From report at bugs.python.org  Fri Jan  4 17:53:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:53:52 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1546642432.79.0.0983934091526.issue18747@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The issue is closed. If you want to change anything, please open a new issue. IMHO this issue is too long, it's better to start a fresh issue with up to date info, just mention this old issue: bpo-18747.

----------

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

From report at bugs.python.org  Fri Jan  4 17:58:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 22:58:06 +0000
Subject: [issue35616] Change references to '4.0'.
In-Reply-To: <1546145542.58.0.745728606206.issue35616@roundup.psfhosted.org>
Message-ID: <1546642686.84.0.997362808149.issue35616@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I disagree. It's acceptable to break the C API in a minor release if the change has been properly promoted, documented, announced, etc.

IMHO breaking the C API in 4.0 is going to send a bad signal to users.

Multiple core developers asked multiple times to wait until Python 2 is really dead before removing some features which are used on Python 2 and Python 3. So at least, we must wait until January 1st, 2020, before removing Py_UNICODE APIs.

I also would like to see the deprecation warning supported on Windows.

I didn't see any announcement of future removal of C API on the capi-sig mailing list.

----------

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

From report at bugs.python.org  Fri Jan  4 18:00:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:00:49 +0000
Subject: [issue35616] Change references to '4.0'.
In-Reply-To: <1546145542.58.0.745728606206.issue35616@roundup.psfhosted.org>
Message-ID: <1546642849.61.0.974971744349.issue35616@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> One or two versions after using Py_DEPRECATED for all deprecated functions (but not earlier than EOL of 2.7) we can make them issuing run-time warnings.

Maybe we can experiment adding warnings only in development mode, when python3 -X dev is used?

> I'm working on this.

Thanks :-)

----------

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

From report at bugs.python.org  Fri Jan  4 18:02:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:02:09 +0000
Subject: [issue35629] hang and/or leaked processes with
 multiprocessing.Pool(...).imap(...)
In-Reply-To: <1546277313.94.0.653504981022.issue35629@roundup.psfhosted.org>
Message-ID: <1546642929.01.0.480291973574.issue35629@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm using `contextlib.closing`

Oh, I missed that: good!

----------

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

From report at bugs.python.org  Fri Jan  4 18:03:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:03:13 +0000
Subject: [issue35633] test_eintr: test_lockf() fails with "PermissionError:
 [Errno 13] Permission denied" on AIX
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546642993.17.0.825782874667.issue35633@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Previous discussion at:
https://bugs.python.org/issue35189#msg332580

----------

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

From report at bugs.python.org  Fri Jan  4 18:03:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:03:58 +0000
Subject: [issue35189] PEP 475: fnctl functions are not retried if interrupted
 by a signal (EINTR)
In-Reply-To: <1541681130.38.0.788709270274.issue35189@psf.upfronthosting.co.za>
Message-ID: <1546643038.51.0.130304901117.issue35189@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Michael created bpo-35633: test_eintr: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX.

----------

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

From report at bugs.python.org  Fri Jan  4 18:06:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:06:15 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1546643175.28.0.233794599144.issue8538@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I reopen the issue since it seems like there are people requesting the feature. (I also removed myself from the issue, I'm not interested to implement it.)

----------
resolution: out of date -> 
status: closed -> open

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

From report at bugs.python.org  Fri Jan  4 18:19:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:19:25 +0000
Subject: [issue13927] Document time.ctime format
In-Reply-To: <1328215776.48.0.974828105123.issue13927@psf.upfronthosting.co.za>
Message-ID: <1546643965.94.0.195753648776.issue13927@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: Extra spaces in the output of time.ctime -> Document time.ctime format
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  4 18:31:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:31:03 +0000
Subject: [issue35432] str.format and string.Formatter bug with French (and
 other) locale
In-Reply-To: <1544133264.0.0.788709270274.issue35432@psf.upfronthosting.co.za>
Message-ID: <1546644663.89.0.749966529314.issue35432@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This bug is a duplicate of bpo-33954. Good news: it's now fixed in Python 3.6.8!

https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-8-release-candidate-1

"bpo-33954: For str.format(), float.__format__() and complex.__format__() methods for non-ASCII decimal point when using the ?n? formatter."

Note: I fixed other bugs with special locales (mostly LC_NUMERIC and/or LC_MONETARY using a different encoding than the LC_CTYPE locale).

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error for locales with non-ascii thousands separator

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

From report at bugs.python.org  Fri Jan  4 18:40:06 2019
From: report at bugs.python.org (Wanja Chresta)
Date: Fri, 04 Jan 2019 23:40:06 +0000
Subject: [issue35659] Add heapremove() function to heapq
Message-ID: <1546645205.64.0.740247003371.issue35659@roundup.psfhosted.org>


New submission from Wanja Chresta <wanja.chresta at gmail.com>:

Heap Queues are extremely useful data structures. They can, for example, be used to implement Dijkstra's algorithm for finding the shortest paths between nodes in a graph in O(edge * log vertices) time instead of (edge * vertices) without heaps.

One operation such implementations need, though, is the possibility to modify an element in the heap (and thus having to reorder it afterwards) in O(log n) time. One can model such an operation by removing a specific element from the heap and then adding the modified element.

So far, heapq only allows removing the first element through heappop; this is not what we need. Instead, we would want to support a heapremove function that removes an arbitrary element in the heap (if it exists) and raises ValueError if the value is not present.

list.remove cannot be used, since it needs O(n) time.

heapremove can be easily implemented by using bisect.bisect_left since heap is always sorted:

def heapremove(heap, x):
  i = bisect.bisect_left(heap, x)
  if heap[i] == x:
    del heap[i]
  else:
    raise ValueError

c.f. remove method in https://docs.oracle.com/javase/7/docs/api/java/util/PriorityQueue.html

----------
components: Library (Lib)
messages: 333024
nosy: Wanja Chresta
priority: normal
severity: normal
status: open
title: Add heapremove() function to heapq
versions: Python 3.8

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

From report at bugs.python.org  Fri Jan  4 18:41:51 2019
From: report at bugs.python.org (Wanja Chresta)
Date: Fri, 04 Jan 2019 23:41:51 +0000
Subject: [issue35659] Add heapremove() function to heapq
In-Reply-To: <1546645205.64.0.740247003371.issue35659@roundup.psfhosted.org>
Message-ID: <1546645311.13.0.158465869617.issue35659@roundup.psfhosted.org>


Change by Wanja Chresta <wanja.chresta at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Fri Jan  4 18:50:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:50:18 +0000
Subject: [issue28108] Python configure fails to detect tzname on platforms
 that have it.
In-Reply-To: <1473708835.14.0.84620259167.issue28108@psf.upfronthosting.co.za>
Message-ID: <1546645818.17.0.0546412564158.issue28108@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-35385.

----------

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

From report at bugs.python.org  Fri Jan  4 18:50:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Jan 2019 23:50:20 +0000
Subject: [issue35385] time module: why not using tzname from the glibc?
In-Reply-To: <1543834589.7.0.788709270274.issue35385@psf.upfronthosting.co.za>
Message-ID: <1546645820.08.0.910757758211.issue35385@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-28108.

----------

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

From report at bugs.python.org  Fri Jan  4 18:50:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 23:50:28 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546645828.97.0.397943794418.issue33987@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +10859

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

From report at bugs.python.org  Fri Jan  4 18:50:37 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 23:50:37 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546645837.79.0.037391571659.issue33987@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +10859, 10860

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

From report at bugs.python.org  Fri Jan  4 18:50:45 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 23:50:45 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546645845.57.0.17384666547.issue33987@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +10859, 10860, 10861

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

From report at bugs.python.org  Fri Jan  4 18:58:05 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 23:58:05 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546646285.87.0.947246370115.issue33987@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10860

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

From report at bugs.python.org  Fri Jan  4 18:58:18 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 04 Jan 2019 23:58:18 +0000
Subject: [issue33987] IDLE: use ttk.Frame for ttk widgets
In-Reply-To: <1530158550.76.0.56676864532.issue33987@psf.upfronthosting.co.za>
Message-ID: <1546646298.94.0.1051257949.issue33987@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10861

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

From report at bugs.python.org  Fri Jan  4 18:59:01 2019
From: report at bugs.python.org (Wanja Chresta)
Date: Fri, 04 Jan 2019 23:59:01 +0000
Subject: [issue35659] Add heapremove() function to heapq
In-Reply-To: <1546645205.64.0.740247003371.issue35659@roundup.psfhosted.org>
Message-ID: <1546646341.89.0.98369666308.issue35659@roundup.psfhosted.org>


Wanja Chresta <wanja.chresta at gmail.com> added the comment:

After thinking about it some more I realised that this doesn't make sense since heapq is based on lists and lists have an insertion complexity of O(n). Thus, they'll never read the needed O(log n) and heapq is the wrong place.

Never mind.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Jan  4 19:13:38 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 00:13:38 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
Message-ID: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>


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

Remove use of `from tkinter import *` from windows.py.

----------
assignee: terry.reedy
components: IDLE
messages: 333028
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Remove import * from window.py
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Jan  4 19:17:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 00:17:28 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546647448.99.0.0582616975468.issue35660@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +10862
stage:  -> patch review

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

From report at bugs.python.org  Fri Jan  4 19:17:32 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 00:17:32 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546647452.21.0.232598732649.issue35660@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10862, 10863
stage:  -> patch review

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

From report at bugs.python.org  Fri Jan  4 19:17:35 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 00:17:35 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546647455.36.0.193590168538.issue35660@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10862, 10863, 10864
stage:  -> patch review

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

From report at bugs.python.org  Fri Jan  4 19:50:25 2019
From: report at bugs.python.org (Tim Peters)
Date: Sat, 05 Jan 2019 00:50:25 +0000
Subject: [issue35659] Add heapremove() function to heapq
In-Reply-To: <1546645205.64.0.740247003371.issue35659@roundup.psfhosted.org>
Message-ID: <1546649425.5.0.689467279464.issue35659@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

For history, note that `bisect` doesn't always work in this context either:  a heap is NOT always in sorted order.  For example, this is "a (min) heap" too:  [1, 3, 2].

More, that's "the real" problem.  If we could find the element to be removed in log(n) time, then it's possible to remove it from the heap in log(n) time too (you can, e.g., bubble elements up to fill the interior hole, then move the last heap element into the leaf hole that may leave behind and possibly sift it up to restore the heap property; and each of those phases takes log(n) time).

----------
nosy: +tim.peters

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

From report at bugs.python.org  Fri Jan  4 19:58:04 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Jan 2019 00:58:04 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
Message-ID: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

When creating the pyvenv.cfg file, the prompt setting should be stored there so that tools can introspect on it (e.g. VS Code could read the value to tell users the name of the venv they have selected in the status bar).

----------
assignee: brett.cannon
components: Library (Lib)
messages: 333030
nosy: brett.cannon, vinay.sajip
priority: normal
severity: normal
stage: test needed
status: open
title: Store the venv prompt in pyvenv.cfg
type: behavior

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

From report at bugs.python.org  Fri Jan  4 19:58:17 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Jan 2019 00:58:17 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546649897.19.0.917220623789.issue35661@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
priority: normal -> low

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

From report at bugs.python.org  Fri Jan  4 19:58:17 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 05 Jan 2019 00:58:17 +0000
Subject: [issue18747] Re-seed OpenSSL's PRNG after fork
In-Reply-To: <1376570101.71.0.249202475923.issue18747@psf.upfronthosting.co.za>
Message-ID: <1546649897.28.0.00824952927538.issue18747@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I have no plans to work on the issue any more. OpenSSL 1.1.1 has fixed the RNG issue with a new DRBG implementation. Eventually all platforms will move to 1.1.1 because it also provides TLS 1.3.

In the mean time, application can work around the limitation by seeding OpenSSL by calling ssl.RAND_add().

----------

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

From report at bugs.python.org  Fri Jan  4 19:58:27 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Jan 2019 00:58:27 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546649907.17.0.000377456026493.issue35661@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.8

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

From report at bugs.python.org  Fri Jan  4 21:14:10 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Sat, 05 Jan 2019 02:14:10 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
In-Reply-To: <1546394840.15.0.0864584726941.issue35635@roundup.psfhosted.org>
Message-ID: <1546654450.26.0.655620558242.issue35635@roundup.psfhosted.org>


Stefan Seefeld <stefan at seefeld.name> added the comment:

That's quite an unfortunate limitation ! I'm working on a GUI frontend to a Python tool I wrote using asyncio, and the GUI (Qt-based) itself insists to run its own event loop in the main thread.

I'm not sure how to work around this limitation, but I can report that my previously reported strategy appears to be working well (so far).

What are the issues I should expect to encounter running an asyncio event loop in a worker thread ?

----------

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

From report at bugs.python.org  Fri Jan  4 21:23:10 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 05 Jan 2019 02:23:10 +0000
Subject: [issue35105] Document that CPython accepts "invalid" identifiers
In-Reply-To: <1540815891.13.0.788709270274.issue35105@psf.upfronthosting.co.za>
Message-ID: <1546654990.74.0.0538765185155.issue35105@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I agreed with @Raymond Hettinger, I will update the PR from your suggestion if no other ideas in next week.

----------

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

From report at bugs.python.org  Fri Jan  4 21:48:13 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 02:48:13 +0000
Subject: [issue35606] Add prod() function to the math module
In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org>
Message-ID: <1546656493.66.0.66033310358.issue35606@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't like the name overlap with itertools.product().  Currently, math and itertools have no overlapping names.  Also, I expect that like sum(), the prod() function will be used with generator comprehensions and should best be kept short and not dominating the rest of the expression.

It's true that factorial is spelled-out, but that was probably a mistake -- it has been somewhat awkward in expressions that contain factorial terms.  Ideally, we would have comb, perm, fact, and prod.

----------

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

From report at bugs.python.org  Fri Jan  4 21:54:51 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 05 Jan 2019 02:54:51 +0000
Subject: [issue35325] imp.find_module() return value documentation discrepancy
In-Reply-To: <1543303624.81.0.788709270274.issue35325@psf.upfronthosting.co.za>
Message-ID: <1546656891.12.0.57769235005.issue35325@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

> The documentation should state that "pathname" will be None (not the empty string) for built-in and frozen modules in order to be in line with the implementation.

Both the "file" and "pathname" will be None for built-in and frozen modules, right? In the PR @ericsnowcurrently suggested add:

>  If the module is built-in or frozen then *file* and *pathname* are both ``None`` and the *description* tuple contains empty...

I think it also works.

----------

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

From report at bugs.python.org  Fri Jan  4 22:25:27 2019
From: report at bugs.python.org (Jeff Robbins)
Date: Sat, 05 Jan 2019 03:25:27 +0000
Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug
Message-ID: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org>


New submission from Jeff Robbins <jeffr at livedata.com>:

Python 3.x defaults to using emulated condition variables on Windows.  I tested a build with native Windows condition variables (#define _PY_EMULATED_WIN_CV 0), and found a serious issue.

The problem is in condvar.h, in this routine:


/* This implementation makes no distinction about timeouts.  Signal
 * 2 to indicate that we don't know.
 */
Py_LOCAL_INLINE(int)
PyCOND_TIMEDWAIT(PyCOND_T *cv, PyMUTEX_T *cs, long long us)
{
    return SleepConditionVariableSRW(cv, cs, (DWORD)(us/1000), 0) ? 2 : -1;
}


The issue is that `SleepConditionVariableSRW` returns FALSE in the timeout case.  PyCOND_TIMEDWAIT returns -1 in that case. 

But... COND_TIMED_WAIT, which calls PyCOND_TIMEDWAIT, in ceval_gil.h, fatals(!) on a negative return value


#define COND_TIMED_WAIT(cond, mut, microseconds, timeout_result) \
    { \
        int r = PyCOND_TIMEDWAIT(&(cond), &(mut), (microseconds)); \
        if (r < 0) \
            Py_FatalError("PyCOND_WAIT(" #cond ") failed"); \



I'd like to suggest that we use the documented behavior of the OS API call already being used (SleepConditionVariableSRW https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleepconditionvariablesrw) and return 0 on regular success and 1 on timeout, like in the _POSIX_THREADS case.  

"""
Return Value
If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

If the timeout expires the function returns FALSE and GetLastError returns ERROR_TIMEOUT.
"""

I've tested this rewrite -- the main difference is in the FALSE case, check GetLastError() for ERROR_TIMEOUT and then *do not* treat this as a fatal error.
 


/*
 * PyCOND_TIMEDWAIT, in addition to returning negative on error,
 * thus returns 0 on regular success, 1 on timeout
*/
Py_LOCAL_INLINE(int)
PyCOND_TIMEDWAIT(PyCOND_T *cv, PyMUTEX_T *cs, long long us)
{
    BOOL result = SleepConditionVariableSRW(cv, cs, (DWORD)(us / 1000), 0);

    if (result)
        return 0;

    if (GetLastError() == ERROR_TIMEOUT)
        return 1;

    return -1;
}


I've attached the test I ran to reproduce the crash.

----------
components: Windows
files: thread_test2.py
messages: 333036
nosy: jeffr at livedata.com, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows #define _PY_EMULATED_WIN_CV 0 bug
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48024/thread_test2.py

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

From report at bugs.python.org  Fri Jan  4 23:20:45 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 04:20:45 +0000
Subject: [issue35625] Comprehension doc doesn't mention buggy class scope
 behavior
In-Reply-To: <1546253280.49.0.920078772343.issue35625@roundup.psfhosted.org>
Message-ID: <1546662045.53.0.334033020611.issue35625@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We should remove the "equivalent to for-loops" wording for list comprehensions.  That is a hold-over from 2.7 where it used to be true.  That said, the list comprehension section is too early in the tutorial to go into scopes and generators, so a full explanation will need to be deferred.

> As an aside, I agree with the developers who consider 
> this scope "limitation" a bug and not (paraphrasing) 
> "just how the language works", since the exact same two
> lines of code, which depend on no other variables or 
> functions, work in a function or module but not in a class.

If you view classes as just another nested scope, I can see why you might think the behavior is buggy, limited, or undesirable.  That however is not how the language is designed.  Think about why methods have to reference class variables using "self.classvar" rather than just "classvar".  When the methods run, they have access to their own locals() and to the module level globals().  To access the locals() for the class, they need use "self.classvar" or "classname.classvar".  This is central to how python works .  There are two separate lookup chains, one for variables (locals -> nested scopes -> globals -> __builtins__ -> NameError) and another for attributes (inst_dict -> class_dict -> parent_class_dict -> AttributeError).

Guido intentionally shifted list comprehensions to work like generator expressions.  In a class scope, they behave like methods in that they have access to the outer globals but no direct access to the locals() in the class.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Jan  4 23:59:47 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 04:59:47 +0000
Subject: [issue35624] Shelve sync issues while using Gevent
In-Reply-To: <1546243936.53.0.108056450415.issue35624@roundup.psfhosted.org>
Message-ID: <1546664387.55.0.914617968517.issue35624@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The docs already note a restriction: "the shelve module does not support concurrent read/write access to shelved objects".  We should further document that sync() is not thread-safe.  When sync() is running, the *writeback* attribute is set to False and other threads will stop updating the cache.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sat Jan  5 00:03:54 2019
From: report at bugs.python.org (Tanmay Jain)
Date: Sat, 05 Jan 2019 05:03:54 +0000
Subject: [issue35663] webbrowser.py firefox bug [python3, windows 10]
Message-ID: <1546664632.95.0.705177998493.issue35663@roundup.psfhosted.org>


New submission from Tanmay Jain <tanmayjain.cs at gmail.com>:

https://docs.python.org/3/library/webbrowser.html#webbrowser.controller.open

browser_controller = webbrowser.get()

result = browser_controller.open(url)# <-- return False even though firefox successfully opens url

# expected behavior when url is opened successfully in browser it should return True

# like it return True for chrome and edge.

----------
components: Library (Lib), Tkinter, Windows
messages: 333039
nosy: codextj, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: webbrowser.py firefox bug [python3, windows 10]
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat Jan  5 00:09:09 2019
From: report at bugs.python.org (Tanmay Jain)
Date: Sat, 05 Jan 2019 05:09:09 +0000
Subject: [issue35663] webbrowser.py firefox bug [python3, windows 10]
In-Reply-To: <1546664632.95.0.705177998493.issue35663@roundup.psfhosted.org>
Message-ID: <1546664949.36.0.386474237977.issue35663@roundup.psfhosted.org>


Tanmay Jain <tanmayjain.cs at gmail.com> added the comment:

>>> import webbrowser
>>> brwsr = webbrowser.get("C:/Program Files/Mozilla Firefox/firefox.exe %s")
>>> brwsr.open('www.google.com')
False # <-- even though firefox opens the url

>>> brwsr = webbrowser.get("C:/Program Files (x86)/Google/Chrome/Application/chrome.exe %s")
>>> brwsr.open('www.google.com')
True
>>> brwsr = webbrowser.get(using ='windows-default')
>>> brwsr.open('www.google.com')
True
>>>

----------

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

From report at bugs.python.org  Sat Jan  5 00:17:57 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 05:17:57 +0000
Subject: [issue35664] Optimize itemgetter()
Message-ID: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>


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

Improve performance by 33% by optimizing argument handling and by adding a fast path for the common case of a single non-negative integer index into a tuple (which is the typical use case in the standard library).

----------
components: Library (Lib)
messages: 333041
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Optimize itemgetter()
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Sat Jan  5 00:20:34 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 05:20:34 +0000
Subject: [issue35664] Optimize itemgetter()
In-Reply-To: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>
Message-ID: <1546665634.59.0.799469999839.issue35664@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +10865
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 00:20:38 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 05:20:38 +0000
Subject: [issue35664] Optimize itemgetter()
In-Reply-To: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>
Message-ID: <1546665638.39.0.369856044646.issue35664@roundup.psfhosted.org>


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


----------
keywords: +patch, patch
pull_requests: +10865, 10866
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 00:20:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jan 2019 05:20:40 +0000
Subject: [issue35664] Optimize itemgetter()
In-Reply-To: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>
Message-ID: <1546665640.58.0.481616849433.issue35664@roundup.psfhosted.org>


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


----------
keywords: +patch, patch, patch
pull_requests: +10865, 10866, 10867
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 00:28:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 05:28:12 +0000
Subject: [issue35325] imp.find_module() return value documentation discrepancy
In-Reply-To: <1543303624.81.0.788709270274.issue35325@psf.upfronthosting.co.za>
Message-ID: <1546666092.39.0.914388832648.issue35325@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +brett.cannon
versions:  -Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jan  5 00:38:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 05:38:13 +0000
Subject: [issue34439] Expose venv --prompt value to an environment value
In-Reply-To: <1534760450.03.0.56676864532.issue34439@psf.upfronthosting.co.za>
Message-ID: <1546666693.9.0.690059174983.issue34439@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

issue35328 seems like a related issue with a PR that sets VIRTUAL_ENV_PROMPT. Also see issue35661 to store the venv prompt in config file.

----------
nosy: +xtreak
versions:  -Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Jan  5 00:42:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 05:42:56 +0000
Subject: [issue35328] Set a environment variable for venv prompt
In-Reply-To: <1543335149.71.0.788709270274.issue35328@psf.upfronthosting.co.za>
Message-ID: <1546666976.37.0.433331168299.issue35328@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

issue34439 seems like a similar proposal. I am adding @vinay.sajip. Since this seems like a new feature I have removed 3.7 from the version list.

----------
components: +Library (Lib)
nosy: +vinay.sajip, xtreak
type:  -> enhancement
versions:  -Python 3.7

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

From report at bugs.python.org  Sat Jan  5 01:11:45 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 05 Jan 2019 06:11:45 +0000
Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug
In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org>
Message-ID: <1546668705.79.0.386706807304.issue35662@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

There's an existing issue for this somewhere - we've tried a couple times to switch over and run into various issues. I'm not in a place to find it right now, but worth looking.

----------

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

From report at bugs.python.org  Sat Jan  5 01:48:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 06:48:41 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1546670921.44.0.468600398788.issue35647@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +10868
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 01:48:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 06:48:47 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1546670927.7.0.455116514362.issue35647@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10868, 10869
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 01:48:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 06:48:55 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1546670935.0.0.726218608041.issue35647@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10868, 10869, 10870
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 02:40:56 2019
From: report at bugs.python.org (Ajay Mahato)
Date: Sat, 05 Jan 2019 07:40:56 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1546674056.62.0.826862687449.issue9305@roundup.psfhosted.org>


Ajay Mahato <ajjayymahato at gmail.com> added the comment:

I am taking up this issue.

----------

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

From report at bugs.python.org  Sat Jan  5 02:59:13 2019
From: report at bugs.python.org (Jeff Robbins)
Date: Sat, 05 Jan 2019 07:59:13 +0000
Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug
In-Reply-To: <1546668705.79.0.386706807304.issue35662@roundup.psfhosted.org>
Message-ID: <CAP5X+rfmSBFjLJ0WcdCu-4QCicMmxex7+r7-dieYPHxq8yTVrA@mail.gmail.com>


Jeff Robbins <jeffr at livedata.com> added the comment:

I did a search and couldn't find exactly this issue. This issue is about a
broken function. It is broken because it treats a timeout as a fatal error
which crashes your Python program.

I supplied a proposed fix for the function.

If there are other known issues or tests, happy to dig in.  Seems a shame
that Python 3 on Windows needs to be running on emulated condition
variables when the OS has (apparently) working actual ones.

Jeff

On Sat, Jan 5, 2019, 1:11 AM Steve Dower <report at bugs.python.org wrote:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> There's an existing issue for this somewhere - we've tried a couple times
> to switch over and run into various issues. I'm not in a place to find it
> right now, but worth looking.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35662>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Jan  5 02:59:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 07:59:41 +0000
Subject: [issue35664] Optimize itemgetter()
In-Reply-To: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>
Message-ID: <1546675181.58.0.985098312016.issue35664@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please provide microbenchmark results also for the following cases:

* Negative index with tuple.
* Slice index with tuple.
* Tuple subclass.
* List.
* Large (2**61 and -2**61) index.

I do not expect significant regression, but if it is, we should be aware.

If the above cases are not covered by tests, it may be worth to add them.

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

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

From report at bugs.python.org  Sat Jan  5 03:25:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Sat, 05 Jan 2019 08:25:56 +0000
Subject: [issue35633] test_eintr: test_lockf() fails with "PermissionError:
 [Errno 13] Permission denied" on AIX
In-Reply-To: <1546641808.08.0.752156151343.issue35633@roundup.psfhosted.org>
Message-ID: <E462EDD0-1CAA-4CD0-9E76-AE5178FB4C28@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I had tried ?wb+?, not ?w+b?. Is there a difference? I forget if I tried just ?w+?. 

But I?ll do them anyway/again to be sure. 

Sent from my iPhone

> On 4 Jan 2019, at 23:43, STINNER Victor <report at bugs.python.org> wrote:
> 
> 
> Change by STINNER Victor <vstinner at redhat.com>:
> 
> 
> ----------
> title: test_eintr fails on AIX since fcntl functions were modified -> test_eintr: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35633>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Jan  5 03:46:48 2019
From: report at bugs.python.org (Jeff Robbins)
Date: Sat, 05 Jan 2019 08:46:48 +0000
Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug
In-Reply-To: <1546668705.79.0.386706807304.issue35662@roundup.psfhosted.org>
Message-ID: <CAP5X+rc2PD0qFpyRt6rpfvOHo5DCD6-mMep7E6U_uof4YkZduw@mail.gmail.com>


Jeff Robbins <jeffr at livedata.com> added the comment:

I searched harder.  :-)

https://bugs.python.org/issue29871

I see that someone else already noticed this broken function, but I guess
it was left broken because of other issues with using condition variables
instead of the emulated ones?

Still, the code is wrong as written...

Jeff

On Sat, Jan 5, 2019, 1:11 AM Steve Dower <report at bugs.python.org wrote:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> There's an existing issue for this somewhere - we've tried a couple times
> to switch over and run into various issues. I'm not in a place to find it
> right now, but worth looking.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35662>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Jan  5 03:54:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 08:54:06 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546678446.16.0.45162619077.issue35634@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Ammar is right. This is a consequence of issue27358. Issue27358 was merely an optimization necessary for bytecode changes in 3.6. It was not noticed that it changes also the behavior for multidict kwargs. But I think that it was correct change. Specifying multiple keyword arguments with the same name is an error, and it does not matter whether names are duplicated in different kwargs or in the same kwarg. I think it is worth to ensure that duplicated names are forbidden in the case of a single kwarg too. Since kwarg should be converted to a dict, this check should not add significant overhead.

3.5 and 3.6 are in security-only fixes mode. And I think it is not worth to do such changes in 3.7. This could break working user code (even if can be considered incorrect), and we should avoid a breakage in bugfix releases without need.

I take it.

----------
assignee:  -> serhiy.storchaka
components: +Interpreter Core
versions:  -Python 3.7

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

From report at bugs.python.org  Sat Jan  5 05:40:19 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 05 Jan 2019 10:40:19 +0000
Subject: [issue35606] Add prod() function to the math module
In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org>
Message-ID: <1546684819.92.0.722263640348.issue35606@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, I would have to look up the documentation everytime I encounter "comb" and "perm", while the full names are intuitive to me.

"prod" and "fact" feel somewhat less obscure.

I suppose there are two possible audiences here:
- the expert math / itertools developer that values concise names when typing in complex expressions
- the occasional math / itertools user that would have to look up any non-intuitive name on every encounter

----------

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

From report at bugs.python.org  Sat Jan  5 06:05:10 2019
From: report at bugs.python.org (adiba)
Date: Sat, 05 Jan 2019 11:05:10 +0000
Subject: [issue35653] All regular expression match groups are the empty string
In-Reply-To: <1546550950.61.0.624475109311.issue35653@roundup.psfhosted.org>
Message-ID: <1546686310.77.0.641554237452.issue35653@roundup.psfhosted.org>


Change by adiba <adib1234 at hotmail.de>:


----------
nosy:  -adiba, ezio.melotti, mrabarnett

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

From report at bugs.python.org  Sat Jan  5 06:22:57 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Stelmach?=)
Date: Sat, 05 Jan 2019 11:22:57 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546687377.52.0.820102982542.issue35638@roundup.psfhosted.org>


?ukasz Stelmach <steelman at post.pl> added the comment:

Indeed. Thank you. I was sure I had tried this. However, this is still only a workaround and not the solution I need. I am working on a project now which uses pint https://pint.readthedocs.io/en/latest/ which uses format() and its relatives.

With "n" format present Python is missing locale-aware "f" formatter anyway.

----------

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

From report at bugs.python.org  Sat Jan  5 07:15:27 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 12:15:27 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546690527.51.0.950169776266.issue35634@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> (Just curious, what does d['a'] return?)

I was curious too and some results

$ python
Python 3.7.1rc2 (v3.7.1rc2:6c06ef7dc3, Oct 13 2018, 05:10:29)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multidict
>>> d = multidict.CIMultiDict([('a', 1), ('a', 2)])
>>> d['a']
1
>>> d.keys()
_KeysView('a', 'a')
>>> d.values()
_ValuesView(1, 2)
>>> d.items()
_ItemsView('a': 1, 'a': 2)
>>> dict(d)
{'a': 1}

In the original issue where PEP 448 was implemented there were some discussions around duplicates in kwargs. msg234413 for Guido's call on duplicates and the messages below discuss some more scenarios about overriding/rejecting duplicates. PEP 448 also has a note on duplicates in https://www.python.org/dev/peps/pep-0448/#specification

----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Jan  5 07:24:46 2019
From: report at bugs.python.org (=?utf-8?q?Vladimir_Peri=C4=87?=)
Date: Sat, 05 Jan 2019 12:24:46 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
Message-ID: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>


New submission from Vladimir Peri? <pervlad at gmail.com>:

In Python 3.7.1 on Windows 10 ssl library function call ssl.create_default_context(ssl.Purpose.SERVER_AUTH) raises an ssl error:

File "C:\Python37\lib\ssl.py", line 471, in _load_windows_store_certs
    self.load_verify_locations(cadata=certs)
ssl.SSLError: nested asn1 error (_ssl.c:3926)

In Python 3.6.4 same function call raises no error.

----------
assignee: christian.heimes
components: SSL
messages: 333054
nosy: christian.heimes, pervlad
priority: normal
severity: normal
status: open
title: Function ssl.create_default_context raises exception on Windows 10  when called with  ssl.Purpose.SERVER_AUTH) attribute
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat Jan  5 08:36:32 2019
From: report at bugs.python.org (=?utf-8?q?Vladimir_Peri=C4=87?=)
Date: Sat, 05 Jan 2019 13:36:32 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546695392.45.0.892714556719.issue35665@roundup.psfhosted.org>


Vladimir Peri? <pervlad at gmail.com> added the comment:

Same outcome in Python 3.7.2.
See first comment for detailed explanation of issue.

----------

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

From report at bugs.python.org  Sat Jan  5 08:38:43 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 05 Jan 2019 13:38:43 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546695523.14.0.442652385515.issue24928@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi xtreak,

> Thanks @nekobon for the patch. I am triaging old mock related issues. I think dict insertion order is maintained from 3.6 and guaranteed with 3.7 and above. But it would be good to add the unit test in the patch as a PR. I ran the test on master and it passes.

I am running the test on master and fail. I don't think that the orderdict on patch.dict is implement. 

Or maybe I am wronging somewhere

----------

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

From report at bugs.python.org  Sat Jan  5 08:58:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 13:58:38 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546696718.9.0.291097997999.issue24928@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please post the error and the command to run the test? On applying the patch on master I cannot see any errors with below commands : 

# Applying the patch with only test

$ wget https://bugs.python.org/file40488/issue24928.patch
$ git apply issue24928.patch
$ git checkout Lib/unittest/mock.py # Only tests are needed

# Running tests with no errors

* ./python.exe Lib/unittest/test/testmock/ 
* ./python.exe -m unittest -v unittest.test.testmock
* ./python.exe -m unittest -v unittest.test.testmock.testpatch

I can see an error running the file separately using `./python.exe Lib/unittest/test/testmock/testpatch.py` but I don't think it's related to the patch : 

./python.exe Lib/unittest/test/testmock/testpatch.py
............................................................................................F....
======================================================================
FAIL: test_special_attrs (__main__.PatchTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/unittest/test/testmock/testpatch.py", line 1870, in test_special_attrs
    self.assertEqual(foo.__module__, 'unittest.test.testmock.testpatch')
AssertionError: '__main__' != 'unittest.test.testmock.testpatch'
- __main__
+ unittest.test.testmock.testpatch


----------------------------------------------------------------------
Ran 97 tests in 0.704s

FAILED (failures=1)

Build info

$ ./python.exe
Python 3.8.0a0 (heads/master:47a2fced84, Jan  4 2019, 10:36:15)

----------
versions:  -Python 3.6

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

From report at bugs.python.org  Sat Jan  5 09:03:40 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 05 Jan 2019 14:03:40 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546697020.47.0.787412692968.issue24928@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Sorry I was wrong.

On 

```python
foo = OrderedDict()
foo['a'] = object()
foo['b'] = 'something'
```

I was write "first" and "second" like key and fail in

```python
@patch.dict(foo, OrderedDict(update_values))
def test():
    self.assertEqual(list(foo), sorted(foo))

test()
```

Sorry.

Now I am sending the PR

----------

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

From report at bugs.python.org  Sat Jan  5 09:07:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 14:07:58 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546697278.62.0.110064591026.issue24928@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

No problem :) I think the test can use a context manager instead of using test() and a decorator but that can be discussed on the PR.

Thanks!

----------

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

From report at bugs.python.org  Sat Jan  5 09:13:17 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 05 Jan 2019 14:13:17 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546697597.47.0.114539843611.issue24928@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
pull_requests: +10871

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

From report at bugs.python.org  Sat Jan  5 09:13:42 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 05 Jan 2019 14:13:42 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546697622.53.0.0518384085938.issue24928@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
pull_requests: +10871, 10872

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

From report at bugs.python.org  Sat Jan  5 09:14:06 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 05 Jan 2019 14:14:06 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1546697646.65.0.459995054031.issue24928@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
pull_requests: +10871, 10872, 10873

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

From report at bugs.python.org  Sat Jan  5 10:08:59 2019
From: report at bugs.python.org (Julien Palard)
Date: Sat, 05 Jan 2019 15:08:59 +0000
Subject: [issue35584] Wrong statement about ^ in howto/regex.rst
In-Reply-To: <1545775848.12.0.712150888896.issue35584@roundup.psfhosted.org>
Message-ID: <1546700939.68.0.993148954618.issue35584@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

yes.

----------

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

From report at bugs.python.org  Sat Jan  5 10:14:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 15:14:40 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1546701280.76.0.59005938888.issue35582@roundup.psfhosted.org>


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


----------
nosy: +vstinner

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

From report at bugs.python.org  Sat Jan  5 10:30:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 15:30:26 +0000
Subject: [issue35625] Comprehension doc doesn't mention buggy class scope
 behavior
In-Reply-To: <1546253280.49.0.920078772343.issue35625@roundup.psfhosted.org>
Message-ID: <1546702226.91.0.397940761154.issue35625@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue3692.

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

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

From report at bugs.python.org  Sat Jan  5 11:01:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:01:15 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546704075.26.0.302658980872.issue20182@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Seems PR 11328 introduced a compiler warning:

In file included from ./Include/Python.h:64:0,
                 from ./Python/sysmodule.c:17:
./Python/sysmodule.c:1597:14: warning: ?sys_clear_type_cache__doc__? defined but not used [-Wunused-variable]
 PyDoc_STRVAR(sys_clear_type_cache__doc__,
              ^
./Include/pymacro.h:70:37: note: in definition of macro ?PyDoc_VAR?
 #define PyDoc_VAR(name) static char name[]
                                     ^~~~
./Python/sysmodule.c:1597:1: note: in expansion of macro ?PyDoc_STRVAR?
 PyDoc_STRVAR(sys_clear_type_cache__doc__,
 ^~~~~~~~~~~~

----------

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

From report at bugs.python.org  Sat Jan  5 11:08:01 2019
From: report at bugs.python.org (Carl Bordum Hansen)
Date: Sat, 05 Jan 2019 16:08:01 +0000
Subject: [issue35666] Update design FAQ about assignment expression
Message-ID: <1546704480.61.0.245493701505.issue35666@roundup.psfhosted.org>


New submission from Carl Bordum Hansen <carl at bordum.dk>:

Hi there,

In ``Doc/faq/design.rst`` there is an explanation of why Python does not have assignment in expressions. This is dated since PEP 572 / Python 3.8.

Online version: https://docs.python.org/3/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression

I suggest updating it to the attached file. `git diff`:

```
diff --git a/Doc/faq/design.rst b/Doc/faq/design.rst
index e2d63a0323..e61284611d 100644
--- a/Doc/faq/design.rst
+++ b/Doc/faq/design.rst
@@ -149,7 +149,15 @@ to tell Python which namespace to use.
 Why can't I use an assignment in an expression?
 -----------------------------------------------
 
-Many people used to C or Perl complain that they want to use this C idiom:
+In Python 3.8 and newer, you can use assignment in an expression with the
+``:=`` operator (as described in :pep:`572`)::
+
+    while line := f.readline():
+        ...  # do something with line
+
+For more than 25 years it was not possible to do assignments in expressions in
+Python. Naturally, many people used to C or Perl would complain that they want
+to use this C idiom:
 
 .. code-block:: c
 
@@ -157,7 +165,7 @@ Many people used to C or Perl complain that they want to use this C idiom:
        // do something with line
    }
 
-where in Python you're forced to write this::
+where in Python you would be forced to write this::
 
    while True:
        line = f.readline()
@@ -165,8 +173,10 @@ where in Python you're forced to write this::
            break
        ...  # do something with line
 
-The reason for not allowing assignment in Python expressions is a common,
-hard-to-find bug in those other languages, caused by this construct:
+The reason different operators are used for assignment and assignment in
+expressions (``=`` and ``:=``, respectively), and why Python didn't allow
+assignment in expressions for a long time is a common, hard-to-find bug in
+those other languages, caused by this construct:
 
 .. code-block:: c
 
@@ -180,11 +190,6 @@ hard-to-find bug in those other languages, caused by this construct:
 The error is a simple typo: ``x = 0``, which assigns 0 to the variable ``x``,
 was written while the comparison ``x == 0`` is certainly what was intended.
 
-Many alternatives have been proposed.  Most are hacks that save some typing but
-use arbitrary or cryptic syntax or keywords, and fail the simple criterion for
-language change proposals: it should intuitively suggest the proper meaning to a
-human reader who has not yet been introduced to the construct.
-
 An interesting phenomenon is that most experienced Python programmers recognize
 the ``while True`` idiom and don't seem to be missing the assignment in
 expression construct much; it's only newcomers who express a strong desire to

```

----------
assignee: docs at python
components: Documentation
files: design.rst
messages: 333063
nosy: carlbordum, docs at python
priority: normal
severity: normal
status: open
title: Update design FAQ about assignment expression
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file48025/design.rst

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

From report at bugs.python.org  Sat Jan  5 11:26:53 2019
From: report at bugs.python.org (Michael Felt)
Date: Sat, 05 Jan 2019 16:26:53 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546641770.58.0.407709063686.issue35633@roundup.psfhosted.org>
Message-ID: <3e5d1e6c-6684-2b19-7343-780c7ec45846@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 04/01/2019 23:42, STINNER Victor wrote:
> STINNER Victor <vstinner at redhat.com> added the comment:
>
> Does the test pass if you open the file in read+write ("w+b") mode rather than write-only ("wb") mode?
>
> I'm talking about this line:
>
> open(support.TESTFN, 'wb')
>
> Note: if you want to test, you have the modify the mode twice:
>   "with open('%s', 'wb') as f:" % support.TESTFN,
> and
>   with open(support.TESTFN, 'wb') as f:

Without except containing PermissionError:

? +500????????? with kill_on_error(proc):
? +501????????????? with open(support.TESTFN, 'w+b') as f:
? +502????????????????? while True:? # synchronize the subprocess
? +503????????????????????? dt = time.monotonic() - start_time
? +504????????????????????? if dt > 60.0:
? +505????????????????????????? raise Exception("failed to sync child in
%.1f sec" % dt)
? +506????????????????????? try:
? +507????????????????????????? lock_func(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
? +508????????????????????????? lock_func(f, fcntl.LOCK_UN)
? +509????????????????????????? time.sleep(0.01)
? +510????????????????????? except BlockingIOError:
? +511????????????????????????? break
FAILS on test_lockf, passes on test_flock -> with open(support.TESTFN,
'w+b') as f:

FAILS on both test_lockf and test_flock (as expected I am guessing) ->
with open(support.TESTFN, 'r+b') as f:

I am not python savvy enough to get it tested using the syntax: ' "with
open('%s', 'wb') as f:" % support.TESTFN, '

? +500????????? with kill_on_error(proc):
? +501????????????? "with open('%s', 'wb') as f:" % support.TESTFN,
? +502????????????????? while True:? # synchronize the subprocess
? +503????????????????????? dt = time.monotonic() - start_time
? +504????????????????????? if dt > 60.0:
? +505????????????????????????? raise Exception("failed to sync child in
%.1f sec" % dt)
? +506????????????????????? try:
? +507????????????????????????? lock_func(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
? +508????????????????????????? lock_func(f, fcntl.LOCK_UN)
? +509????????????????????????? time.sleep(0.01)
? +510????????????????????? except BlockingIOError:
? +511????????????????????????? break

--- run eintr_tester.py ---
? File
"/data/prj/python/git/python3-3.8/Lib/test/eintrdata/eintr_tester.py",
line 502
??? while True:? # synchronize the subprocess
??? ^
IndentationError: unexpected indent
--- eintr_tester.py completed: exit code 1 ---

>
> ----------
> nosy: +vstinner
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35633>
> _______________________________________
>

----------
title: test_eintr: test_lockf() fails with "PermissionError: [Errno 13] Permission denied" on AIX -> test_eintr fails on AIX since fcntl functions were modified

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

From report at bugs.python.org  Sat Jan  5 11:28:34 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 16:28:34 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546705714.46.0.426705777247.issue35660@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10863

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

From report at bugs.python.org  Sat Jan  5 11:28:45 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 16:28:45 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546705725.76.0.522134388384.issue35660@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10864

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

From report at bugs.python.org  Sat Jan  5 11:29:59 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:29:59 +0000
Subject: [issue35666] Update design FAQ about assignment expression
In-Reply-To: <1546704480.61.0.245493701505.issue35666@roundup.psfhosted.org>
Message-ID: <1546705799.63.0.880442369325.issue35666@roundup.psfhosted.org>


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


----------
dependencies: +PEP 572: Assignment Expressions

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

From report at bugs.python.org  Sat Jan  5 11:32:25 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:32:25 +0000
Subject: [issue35666] Update design FAQ about assignment expression
In-Reply-To: <1546704480.61.0.245493701505.issue35666@roundup.psfhosted.org>
Message-ID: <1546705945.3.0.643643944505.issue35666@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This can be changed only after implementing PEP 572.

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

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

From report at bugs.python.org  Sat Jan  5 11:42:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:42:35 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546706555.79.0.0130882431816.issue35634@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +10875
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Jan  5 11:42:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:42:46 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546706566.81.0.978041686524.issue35634@roundup.psfhosted.org>


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


----------
keywords: +patch, patch
pull_requests: +10875, 10876
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Jan  5 11:42:58 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:42:58 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1546706578.52.0.0180178124984.issue35634@roundup.psfhosted.org>


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


----------
keywords: +patch, patch, patch
pull_requests: +10875, 10876, 10877
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Jan  5 11:43:58 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 16:43:58 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1546706638.46.0.584784139114.issue34838@roundup.psfhosted.org>


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


----------
dependencies: +Argument Clinic: inline parsing code for 1-argument functions, Argument Clinic: inline parsing code for functions with only positional parameters

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

From report at bugs.python.org  Sat Jan  5 12:41:12 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Jan 2019 17:41:12 +0000
Subject: [issue35651] PEP 257 (active) references PEP 258 (rejected) as if it
 were active
In-Reply-To: <1546536866.6.0.633154963858.issue35651@roundup.psfhosted.org>
Message-ID: <1546710072.51.0.673373238449.issue35651@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

A rejected PEP still exists in perpetuity, and can still be used as a reference. Also, the reason for PEP 258's rejection is not that it is invalid, but that it's not slated for stdlib inclusion. So I think that the reference is still useful, and I don't think there's anything that needs to be done here.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Jan  5 13:41:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jan 2019 18:41:21 +0000
Subject: [issue35660] IDLE: Remove import * from window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546713681.28.0.949042235418.issue35660@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'import *' is a PEP 8 violation. Depending in the * import to import sys is a bug.

----------
type: enhancement -> behavior

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

From report at bugs.python.org  Sat Jan  5 14:14:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 19:14:26 +0000
Subject: [issue35636] remove redundant check in unicode_hash(PyObject *self)
In-Reply-To: <1546413657.32.0.171614827801.issue35636@roundup.psfhosted.org>
Message-ID: <1546715666.59.0.792366719806.issue35636@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For historical reasons. In Python 2, str and unicode consisting of ASCII characters can be equal. Equal values should have the same hash. In Python 3, bytes and str are always different. This can cause subtle bugs in the code ported from Python 2. Options -b and -bb were added to help to catch such bugs. For increasing a chance of catching such bugs, hashes of bytes and str consisting of ASCII characters with same codes, should be equal.

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

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

From report at bugs.python.org  Sat Jan  5 14:19:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Jan 2019 19:19:38 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546715978.21.0.566797421405.issue35603@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, please make a documentation PR. Since this behavior can cause a security hole in the user code, make this note visually attractive (maybe use the "note" directive).

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

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

From report at bugs.python.org  Sat Jan  5 14:30:27 2019
From: report at bugs.python.org (=?utf-8?q?Michael_B=C3=BCsch?=)
Date: Sat, 05 Jan 2019 19:30:27 +0000
Subject: [issue35622] RFE: Add os.sched_setattr() and os.sched_getattr()
 functions
In-Reply-To: <1546210790.69.0.579405254492.issue35622@roundup.psfhosted.org>
Message-ID: <1546716627.33.0.361201482491.issue35622@roundup.psfhosted.org>


Michael B?sch <m at bues.ch> added the comment:

I would like to implement this feature.
So if somebody thinks that it's a bad idea to have this feature, please speak up now.

----------
nosy: +vstinner

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

From report at bugs.python.org  Sat Jan  5 14:32:24 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 05 Jan 2019 19:32:24 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1546716744.72.0.302798927715.issue8538@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

> I also removed myself from the issue, I'm not interested to implement it.

I would like to try and implement the change. I will open a PR shortly.

----------
nosy: +remi.lapeyre

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

From report at bugs.python.org  Sat Jan  5 14:51:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 19:51:57 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546717917.5.0.341275224647.issue35603@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +10878
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 14:52:05 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 19:52:05 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546717925.66.0.742060278517.issue35603@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +10878, 10879
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 14:52:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 19:52:13 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546717933.75.0.502452265387.issue35603@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +10878, 10879, 10880
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 14:56:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Jan 2019 19:56:40 +0000
Subject: [issue35603] table header in output of difflib.HtmlDiff.make_table is
 not escaped and can be rendered as code in the browser
In-Reply-To: <1545988680.87.0.068090288545.issue35603@roundup.psfhosted.org>
Message-ID: <1546718200.77.0.681618041363.issue35603@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have added a doc note under make_file docs which has docs for fromdesc and todesc. make_table refers to make_file for fromdesc and todesc docs. I have added a screenshot of the rendering using note and warning directive. I feel note directive is sufficient for this. Placement and wording suggestions are welcome.

----------

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

From report at bugs.python.org  Sat Jan  5 15:45:03 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 05 Jan 2019 20:45:03 +0000
Subject: [issue23057] [Windows] asyncio: support signal handlers on Windows
 (feature request)
In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za>
Message-ID: <1546721103.03.0.523585211333.issue23057@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 67ba547cf001d6b975cf6900aaf2bd5508dc6a87 by Andrew Svetlov (Vladimir Matveev) in branch 'master':
bpo-23057: Use 'raise' to emulate ctrl-c in proactor tests (#11274)
https://github.com/python/cpython/commit/67ba547cf001d6b975cf6900aaf2bd5508dc6a87


----------

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

From report at bugs.python.org  Sat Jan  5 16:19:09 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:19:09 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546723149.34.0.22075996357.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +10881
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Jan  5 16:19:15 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:19:15 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546723155.13.0.298212262499.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10881, 10882
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Jan  5 16:19:20 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:19:20 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546723160.05.0.143511456538.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10881, 10882, 10883
stage: test needed -> patch review

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

From report at bugs.python.org  Sat Jan  5 16:21:47 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:21:47 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546723307.57.0.120879975811.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10882

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

From report at bugs.python.org  Sat Jan  5 16:21:55 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:21:55 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1546723315.37.0.799682803085.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10883

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

From report at bugs.python.org  Sat Jan  5 16:30:51 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 05 Jan 2019 21:30:51 +0000
Subject: [issue35616] Change references to '4.0'.
In-Reply-To: <1546145542.58.0.745728606206.issue35616@roundup.psfhosted.org>
Message-ID: <1546723851.82.0.775265565403.issue35616@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Why not change the wording to read "... will be considered for removal in the next major Python release".

Note that removal of Py_UNICODE APIs will not only break compatibility with Python 2, but also with the early Python 3 releases.

And please also consider that we may see another change in the Unicode implementation... I've heard discussions about using UTF-8 as internal representation to address the issues with the current unified approach.

----------
nosy: +lemburg

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

From report at bugs.python.org  Sat Jan  5 16:34:31 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:34:31 +0000
Subject: [issue35667] activate for venv containing apostrophe doesn't work in
 powershell
Message-ID: <1546724069.06.0.00436819935865.issue35667@roundup.psfhosted.org>


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

On Windows 10, when I try to activate a venv in powershell where the name contains an apostrophe, I get the following error ("don't" is the name of the venv):

PS N:\projects\cpython\don't\Scripts> .\activate.ps1
At N:\projects\cpython\don't\Scripts\Activate.ps1:42 char:28
+     function global:prompt {
+                            ~
Missing closing '}' in statement block or type definition.
At N:\projects\cpython\don't\Scripts\Activate.ps1:37 char:40
+ if (! $env:VIRTUAL_ENV_DISABLE_PROMPT) {
+                                        ~
Missing closing '}' in statement block or type definition.
At N:\projects\cpython\don't\Scripts\Activate.ps1:43 char:61
+         Write-Host -NoNewline -ForegroundColor Green '(don't) '
+                                                             ~
Unexpected token ')' in expression or statement.
At N:\projects\cpython\don't\Scripts\Activate.ps1:43 char:63
+         Write-Host -NoNewline -ForegroundColor Green '(don't) '
+                                                               ~
The string is missing the terminator: '.
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : MissingEndCurlyBrace

This works OK in Command Prompt.

----------
components: Library (Lib)
messages: 333075
nosy: cheryl.sabella
priority: normal
severity: normal
status: open
title: activate for venv containing apostrophe doesn't work in powershell
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Jan  5 16:39:22 2019
From: report at bugs.python.org (Seval Geyik)
Date: Sat, 05 Jan 2019 21:39:22 +0000
Subject: [issue35625] Comprehension doc doesn't mention buggy class scope
 behavior
In-Reply-To: <1546253280.49.0.920078772343.issue35625@roundup.psfhosted.org>
Message-ID: <1546724362.64.0.625494712537.issue35625@roundup.psfhosted.org>


Change by Seval Geyik <gulseval1987 at gmail.com>:


----------
components: +email
nosy: +barry, r.david.murray
type: behavior -> security
Added file: https://bugs.python.org/file48026/keyfile.png

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

From report at bugs.python.org  Sat Jan  5 16:40:02 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 05 Jan 2019 21:40:02 +0000
Subject: [issue35616] Change references to '4.0'.
In-Reply-To: <1546145542.58.0.745728606206.issue35616@roundup.psfhosted.org>
Message-ID: <1546724402.01.0.686562715737.issue35616@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hello!

IMHO I don't think is good say  that they will remove on a version that is not planned yet. 

I agree with Marc-Andre is better say " they will be remove in the next major release"

----------

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

From report at bugs.python.org  Sat Jan  5 16:44:22 2019
From: report at bugs.python.org (anthony shaw)
Date: Sat, 05 Jan 2019 21:44:22 +0000
Subject: [issue35668] low test coverage for idlelib
Message-ID: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>


New submission from anthony shaw <anthony.p.shaw at gmail.com>:

idlelib is one of the lesser-tested libraries in cpython:
https://codecov.io/gh/python/cpython/tree/master/Lib/idlelib

Raising this issue and also volunteering to extend the test module to get coverage across major behaviours and functions that are missing tests.

----------
assignee: terry.reedy
components: IDLE, Library (Lib)
messages: 333077
nosy: anthony shaw, terry.reedy
priority: normal
severity: normal
status: open
title: low test coverage for idlelib
type: enhancement

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

From report at bugs.python.org  Sat Jan  5 16:58:48 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 21:58:48 +0000
Subject: [issue31887] docs for email.generator are missing a comment on
 special multipart/signed handling
In-Reply-To: <1509125027.89.0.213398074469.issue31887@psf.upfronthosting.co.za>
Message-ID: <1546725528.11.0.464476630162.issue31887@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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/issue31887>
_______________________________________

From report at bugs.python.org  Sat Jan  5 17:28:22 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 22:28:22 +0000
Subject: [issue4696] email module does not unfold headers
In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>
Message-ID: <1546727302.19.0.0537871097409.issue4696@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Although email policies are marked as provisional, I believe the changes in issue14731 would fix the original request in this issue.  If so, would it be possible to close this issue as resolved?  Thanks.

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Sat Jan  5 17:48:39 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 22:48:39 +0000
Subject: [issue33393] update config.guess and config.sub
In-Reply-To: <1525108484.46.0.682650639539.issue33393@psf.upfronthosting.co.za>
Message-ID: <1546728519.31.0.467393848754.issue33393@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Is this intended as a global ticket to be used to update these files on a regular basis?  Or should a new ticket be created every time the files are updated?  Thanks!

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Sat Jan  5 18:07:24 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 23:07:24 +0000
Subject: [issue30487] DOC: automatically create a venv and install Sphinx when
 running make
In-Reply-To: <1495817388.46.0.640927890572.issue30487@psf.upfronthosting.co.za>
Message-ID: <1546729644.8.0.344374899987.issue30487@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I believe this can be closed as resolved?  Thanks.

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Sat Jan  5 18:18:26 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sat, 05 Jan 2019 23:18:26 +0000
Subject: [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1546730306.36.0.557575549869.issue13127@roundup.psfhosted.org>


Ashwin Ramaswami <aramaswamis at gmail.com> added the comment:

This behavior appears to be working as expected per the documentation when using Python 3.7.1. I am able to change name, but changing localName gives me a NoModificationAllowedErr error.

----------
nosy: +Ashwin Ramaswami
versions: +Python 3.7 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jan  5 18:27:00 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 05 Jan 2019 23:27:00 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
In-Reply-To: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>
Message-ID: <1546730820.43.0.871071157398.issue34431@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Hi Jonathan,

Did you have any additional questions about opening a pull request for these changes?  Thanks!

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Sat Jan  5 18:47:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Jan 2019 23:47:31 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546732051.68.0.544937513929.issue35668@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I (we) agree that idlelib needs even better test coverage.  Some history:
1. I added idle_test/ 5-1/2 years ago.  Only the calltip module had automated tests easily converted to unittests (test_calltip).
2. Other exiting tests, requiring human judgement, were debugged, completed, and converted to 'htests', driven by idle_test.htest.  Properly measuring idlelib coverage requires excluding htest code (up to 20% of a module).
3. idle_test/README.txt has information on testing IDLE and local conventions.  Perhaps more should be added about mocking.
4. We should now be using ttk widgets whenever possible.  I would like to add an up-to-date widget-testing doc.

Some modules need doctests and a bit of refactoring before adding tests.  Tests for a specific module should be a separate issue.

Testing tkinter is hard. Can you tell us a bit about your python, tkinter, and testing experience?


Cheryl Sabella wrote the majority of tests added in the last year+, and Tal Einat wrote test_squeezer.  I suggest you review some of their recent work.  They should be able to answer most questions as well as me.

----------
nosy: +cheryl.sabella, taleinat
title: low test coverage for idlelib -> Improve test coverage for idlelib
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Jan  5 20:09:28 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Jan 2019 01:09:28 +0000
Subject: [issue35649] http.client doesn't close. Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546736968.44.0.567772080136.issue35649@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +10884
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 20:09:34 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Jan 2019 01:09:34 +0000
Subject: [issue35649] http.client doesn't close. Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546736974.53.0.280885469157.issue35649@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +10884, 10885
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 20:09:41 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Jan 2019 01:09:41 +0000
Subject: [issue35649] http.client doesn't close. Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546736981.6.0.586066000354.issue35649@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +10884, 10885, 10887
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 20:09:48 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Jan 2019 01:09:48 +0000
Subject: [issue35649] http.client doesn't close. Infinite loop
In-Reply-To: <1546533708.33.0.81545579375.issue35649@roundup.psfhosted.org>
Message-ID: <1546736988.5.0.636489167146.issue35649@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10884, 10885, 10886, 10887
stage:  -> patch review

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

From report at bugs.python.org  Sat Jan  5 20:22:51 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 01:22:51 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546737771.0.0.903969604943.issue35668@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

thanks terry, 

Some great pointers there, I'll review the exiting work and the README doc.

With regards to my experience, I have quite extensive experience with python testing. Most of which would be open-source on my Github profile https://github.com/tonybaloney
Some of the larger Python projects I've contributed test suites to would be SaltStack, Apache Libcloud and StackStorm.
I've contributed to the tox project and pytest.
I also write tutorials on Python testing (mostly for beginners) like this one https://realpython.com/python-testing/

I admit I don't have much experience with tkinter. 

It does sound like a challenge, but definitely one that I'm willing to research and approach responsibly.

----------

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

From report at bugs.python.org  Sat Jan  5 21:07:01 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 02:07:01 +0000
Subject: [issue21257] Document parse_headers function of http.client
In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za>
Message-ID: <1546740421.88.0.69837900183.issue21257@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch
pull_requests: +10888
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 21:07:08 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 02:07:08 +0000
Subject: [issue21257] Document parse_headers function of http.client
In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za>
Message-ID: <1546740428.25.0.65375886485.issue21257@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10888, 10889
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 21:07:14 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 02:07:14 +0000
Subject: [issue21257] Document parse_headers function of http.client
In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za>
Message-ID: <1546740434.22.0.327612639699.issue21257@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10888, 10889, 10890
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 21:07:19 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 02:07:19 +0000
Subject: [issue21257] Document parse_headers function of http.client
In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za>
Message-ID: <1546740439.61.0.993233188067.issue21257@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10888, 10889, 10890, 10891
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jan  5 21:17:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jan 2019 02:17:40 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546741060.97.0.531664759219.issue35668@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Great.  I suggest then that you start with untested, normal, non-GUI (non-tkinter) code, assuming that you can find some.  This can mean segregating functional code from gui code if they are currently intertwined.  As point 1 above suggested, IDLE, which dates from about 2000, was originally written without automated testing in mind.

I should have added above
5. 7 months ago, finished #33855 'Minimally test every implementation module'.
In a few cases, that meant import the file, create an instance of the main module, and make a couple of minimal assertions.  The 'coverage' of such files mostly means no syntax errors and X% ran without an exception.

Such code still needs 'does the right thing' tests.  Part of my intention was to make adding those easier by removing the initial boilerplate as a barrier.

----------

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

From report at bugs.python.org  Sat Jan  5 21:24:09 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 02:24:09 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546741449.93.0.73991580059.issue35668@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

I was looking at the debugger.py module as being a good place the start, writing test cases for the Idb, Debugger, StackViewer and NamespaceViewer by patching out the dependant components (bdb, Idb, etc.

I might start there, raise a PR against it and do a module at a time, then work my way up to some of the trickier, tkinter-based modules.

----------

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

From report at bugs.python.org  Sat Jan  5 21:34:45 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 06 Jan 2019 02:34:45 +0000
Subject: [issue30487] DOC: automatically create a venv and install Sphinx when
 running make
In-Reply-To: <1495817388.46.0.640927890572.issue30487@psf.upfronthosting.co.za>
Message-ID: <1546742085.05.0.236214046067.issue30487@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

@cheryl.sabella I am ok with closing this, but the original motivation for this work was from @zack.ware so he should weigh in.

I am not going to work on this any further for the forseeable future (I've got my hands full already with the asyncio docs I'm trying to write in #34831).

----------

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

From report at bugs.python.org  Sat Jan  5 21:37:41 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 06 Jan 2019 02:37:41 +0000
Subject: [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1546742261.51.0.759363068031.issue34831@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

A quick note to say I have not abandoned this, it's just that life got complicated for me in late 2018. I intend to pick up progress again within the next month or two.

----------

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

From report at bugs.python.org  Sat Jan  5 22:26:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jan 2019 03:26:47 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546745207.9.0.255467354908.issue35668@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I like that choice.  There are 15 open issues for debugger and I have notes on a few possible enhancements.

----------

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

From report at bugs.python.org  Sun Jan  6 01:26:58 2019
From: report at bugs.python.org (Tim Peters)
Date: Sun, 06 Jan 2019 06:26:58 +0000
Subject: [issue35606] Add prod() function to the math module
In-Reply-To: <1546025352.75.0.868813504694.issue35606@roundup.psfhosted.org>
Message-ID: <1546756018.68.0.673382172365.issue35606@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'd like to divorce `prod()` from floating-point complications.  The `sum()` builtin has proved extremely handy, even for floats, in large part because it's type-agnostic and straightforward.  While I'd usually use `prod()` on ints and Fractions, in almost all cases I have for multiplying floats a dirt simple implementation would work fine too (e.g., I don't multiply NaNs or infinities to begin with, overflow and underflow can't occur in context, and I usually couldn't care less about the accuracy of the trailing bits).

Not that floats should suffer benign neglect forever, but heroically complex - and expensive - float implementations should get their own function, like `fprod()` (like they got their own `fsum()` function).  Likewise if, e.g., someone wants an `iprod()` that makes heroic efforts to reorder partial products to speed multiplying sequences of giant integers, or `matprod()` to re-associate matrix multiplications in an optimal way, or ...

----------

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

From report at bugs.python.org  Sun Jan  6 02:02:02 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jan 2019 07:02:02 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546758122.24.0.693913699792.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +10892

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

From report at bugs.python.org  Sun Jan  6 02:02:16 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jan 2019 07:02:16 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546758136.37.0.312496336249.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +10892, 10893

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

From report at bugs.python.org  Sun Jan  6 02:02:30 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jan 2019 07:02:30 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546758150.92.0.536524507829.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +10892, 10893, 10894

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

From report at bugs.python.org  Sun Jan  6 02:02:52 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jan 2019 07:02:52 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546758172.45.0.817803015988.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10893

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

From report at bugs.python.org  Sun Jan  6 02:03:18 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jan 2019 07:03:18 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546758198.83.0.158439827248.issue20182@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -10894

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

From report at bugs.python.org  Sun Jan  6 02:04:54 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 06 Jan 2019 07:04:54 +0000
Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5
 files
In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za>
Message-ID: <1546758294.84.0.74017497838.issue20182@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

Thanks Serhiy! The compiler doesn't warn about that on Windows.

See PR GH-11444 with a fix.

----------

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

From report at bugs.python.org  Sun Jan  6 03:10:56 2019
From: report at bugs.python.org (jimbo1qaz_ via Gmail)
Date: Sun, 06 Jan 2019 08:10:56 +0000
Subject: [issue35306] OSError [WinError 123] when testing if pathlib.Path('*')
 (asterisks) exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1546762256.49.0.737730299602.issue35306@roundup.psfhosted.org>


jimbo1qaz_ via Gmail <jimbo1qaz at gmail.com> added the comment:

Should Path.resolve() also avoid raising OSError?

Path('*').resolve()

Traceback (most recent call last):
...truncated
  File "<ipython-input-5-4fa2fec5c8b3>", line 1, in <module>
    Path('*').resolve()
  File "C:\Users\jimbo1qaz\AppData\Local\Programs\Python\Python37\lib\pathlib.py", line 1134, in resolve
    s = self._flavour.resolve(self, strict=strict)
  File "C:\Users\jimbo1qaz\AppData\Local\Programs\Python\Python37\lib\pathlib.py", line 192, in resolve
    s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '*'


os.path.realpath('"*')
Out[8]: 'C:\\Users\\jimbo1qaz\\Dropbox\\encrypted\\code\\corrscope\\"*'
os.path.abspath('*"')
Out[13]: 'C:\\Users\\jimbo1qaz\\Dropbox\\encrypted\\code\\corrscope\\*"'

(sidenote: what os.path operation does Path.resolve() match? Path('nonexistent').resolve() returns a relative path on Python 3.7.1, whereas Path().resolve() returns an absolute path.)

----------

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

From report at bugs.python.org  Sun Jan  6 03:54:37 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 08:54:37 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546764877.4.0.0816206901344.issue19974@roundup.psfhosted.org>


Change by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
pull_requests: +10895
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 03:54:48 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 08:54:48 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546764888.56.0.842818834371.issue19974@roundup.psfhosted.org>


Change by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
pull_requests: +10895, 10896
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 03:54:58 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 08:54:58 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546764898.9.0.736423622962.issue19974@roundup.psfhosted.org>


Change by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
pull_requests: +10895, 10896, 10898
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 03:55:11 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 08:55:11 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546764911.85.0.96076884738.issue19974@roundup.psfhosted.org>


Change by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
pull_requests: +10895, 10896, 10897, 10898
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 03:57:32 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 08:57:32 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546765052.24.0.684265039179.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

Martin Panter,

I have modernized the patch.

About your suggestion:
1. "import errno" -> Yes, this is unnecessary. I have removed it.
2. Use os.path.lexists instead of os.path.islink for broken symlink -> The thing is os.path.islink returns True also for broken symlink. I could not find a case where these methods return different result.

----------

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

From report at bugs.python.org  Sun Jan  6 04:08:12 2019
From: report at bugs.python.org (Yigit Can)
Date: Sun, 06 Jan 2019 09:08:12 +0000
Subject: [issue35669] tar symlink
Message-ID: <1546765691.35.0.523415727187.issue35669@roundup.psfhosted.org>


New submission from Yigit Can <yigitcnyilmaz at gmail.com>:

##Summary:
A TAR file can escape the Python working directory with symlink.

#Steps to reproduce:
1- Create a directory in Desktop (for example : testbolum)
2- Enter the path with "cd" command.
3- Create a symbolic link with "ln" command ( ln -s ../ symlink ).
4- Create a test files with "touch" command (touch ../testfile)
5- Create a tar file with "tar" command line tool ( tar -czvf proofofconcept.tar symlink/ symlink/testfile)
6- Delete "symlink" with "rm" command
7- Delete "../testfile" with "rm" command
8- Run "extract_tar.py"
You can see "testfile" in "../" path
Proof of concept: "status_python.mp4"

##Status on ptar:
Apply the steps to reproduce for "ptar". ptar warning the user. You can see "status_on_ptarsymlink_file.mp4".

##Status on tar:
Apply the steps to reproduce for "tar". tar warning the user. You can see "status_on_tarsymlink_file.mp4".



#Note for Step 3:
You can set a other path for example ( ln -s /user/test/area/ symlink)

Python should be check symbolic link . The user may not be aware of this.  This issue may also cause the software service to run in macos.


##Proof of concept files:
http://yigittestman.000webhostapp.com/ta/

##Impact:
when the user tar file is extracting, the file will be sent to the desired location of the attacker. This issue may also cause the software service to mount in macOS.

----------
components: Library (Lib), Windows, macOS
messages: 333094
nosy: Yilmaz, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: tar symlink
type: security
versions: Python 2.7, Python 3.8

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

From report at bugs.python.org  Sun Jan  6 04:30:39 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 09:30:39 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546767039.35.0.823665331662.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

"I could not find a case where these methods return different result." -> This is wrong. My mistake. os.lexists returns True for non symbolic link file while os.islink returns False.

----------

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

From report at bugs.python.org  Sun Jan  6 04:36:02 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 09:36:02 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546767362.67.0.565806747998.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

Sorry, Martin. I just understood what you suggested. I thought you were saying lexists to replace islink, but it is to replace the complex if condition. Let me work on it.

----------

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

From report at bugs.python.org  Sun Jan  6 04:38:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 06 Jan 2019 09:38:30 +0000
Subject: [issue35669] tar symlink
In-Reply-To: <1546765691.35.0.523415727187.issue35669@roundup.psfhosted.org>
Message-ID: <1546767510.9.0.280757763077.issue35669@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Is this similar to issue21109?

----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Jan  6 04:44:05 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Jan 2019 09:44:05 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546767845.18.0.258563397417.issue19974@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

About ?lexists?, I meant using it instead of ?os.path.exits? (not ?islink?). On Linux:

>>> targetpath = 'target'
>>> os.symlink('nonexistant', dst=targetpath)  # Make a broken symlink
>>> os.system('ls -l')
total 0
lrwxrwxrwx 1 vadmium vadmium 11 Jan  6 09:28 target -> nonexistant
0
>>> os.path.exists(targetpath)  # Doesn't register broken symlinks
False
>>> os.path.lexists(targetpath)  # Does register it
True

Did you try extracting a tar file over a broken link? (I haven?t tried your code; I?m just going on theory.)

----------

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

From report at bugs.python.org  Sun Jan  6 04:48:37 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 09:48:37 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546768117.24.0.475566921054.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

After experimenting with lexists, I don't think I can simplify it with lexists.

----------

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

From report at bugs.python.org  Sun Jan  6 04:58:26 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 06 Jan 2019 09:58:26 +0000
Subject: [issue35483] tarfile.extractall on existing symlink in Ubuntu
 overwrites target file, not symlink, unlinke GNU tar
In-Reply-To: <1544714559.52.0.788709270274.issue35483@psf.upfronthosting.co.za>
Message-ID: <1546768706.95.0.138169521443.issue35483@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jan  6 05:26:48 2019
From: report at bugs.python.org (Creation Elemental)
Date: Sun, 06 Jan 2019 10:26:48 +0000
Subject: [issue35670] os functions return '??' for unicode characters in paths
 on windows
Message-ID: <1546770407.32.0.613838233923.issue35670@roundup.psfhosted.org>


New submission from Creation Elemental <arceusthe at gmail.com>:

I have a few files that contain emojis in their names, and also a folder that has such. Commands like `os.getcwd`, `os.listdir`, `os.path.realpath`, etc. will cause this to happen. However, this is only, as far as I can tell, happening on pure windows distributions. This does not happen in the cygwin64 version I have, nor does it happen in python3.

For example, say you have a folder simply called '?'. If you run python inside of it and run `os.getcwd()` you will simply get `'??'` as the result. This breaks MANY of my programs that depend on knowing exactly where they are, and knowing the contents of a directory to pass to other functions.

----------
components: Windows
messages: 333100
nosy: Creation Elemental, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os functions return '??' for unicode characters in paths on windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan  6 06:07:33 2019
From: report at bugs.python.org (Yigit Can)
Date: Sun, 06 Jan 2019 11:07:33 +0000
Subject: [issue35669] tar symlink
In-Reply-To: <1546765691.35.0.523415727187.issue35669@roundup.psfhosted.org>
Message-ID: <1546772853.01.0.793160422182.issue35669@roundup.psfhosted.org>


Yigit Can <yigitcnyilmaz at gmail.com> added the comment:

Similar but not same.

----------

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

From report at bugs.python.org  Sun Jan  6 06:16:33 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 11:16:33 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546773393.27.0.597606247168.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

I have added test case for broken symlinks. I am not sure whether this is necessary or not. But anyway I have added it.

----------

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

From report at bugs.python.org  Sun Jan  6 06:28:20 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 11:28:20 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546774100.68.0.658362263559.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

Martin, thank you for your advice. I have added additional two test cases for broken symlink case.
1. broken symlink overwrites ordinary file,
2. ordinary file overwrites broken symlink.

I hope that is enough. Let me know if you have another concern.

----------

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

From report at bugs.python.org  Sun Jan  6 06:30:53 2019
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 06 Jan 2019 11:30:53 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1546774253.38.0.703907080311.issue19974@roundup.psfhosted.org>


Vajrasky Kok <sky.kok at speaklikeaking.com> added the comment:

Correction:
1. broken symlink overwrites valid symlink,
2. ordinary file overwrites broken symlink.

----------

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

From report at bugs.python.org  Sun Jan  6 07:13:14 2019
From: report at bugs.python.org (Markus Elfring)
Date: Sun, 06 Jan 2019 12:13:14 +0000
Subject: [issue35671] reserved identifier violation
Message-ID: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>


New submission from Markus Elfring <elfring at users.sourceforge.net>:

I would like to point out that identifiers like ?__DYNAMIC_ANNOTATIONS_H__? and ?_Py_memory_order? do not fit to the expected naming convention of the C++ language standard.
https://www.securecoding.cert.org/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier

Would you like to adjust your selection for unique names?
* https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/dynamic_annotations.h#L56
* https://github.com/python/cpython/blob/130893debfd97c70e3a89d9ba49892f53e6b9d79/Include/internal/pycore_atomic.h#L36

----------
components: Interpreter Core
messages: 333105
nosy: elfring
priority: normal
severity: normal
status: open
title: reserved identifier violation
type: security
versions: Python 3.7

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

From report at bugs.python.org  Sun Jan  6 07:27:04 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Jan 2019 12:27:04 +0000
Subject: [issue35670] os functions return '??' for unicode characters in paths
 on windows
In-Reply-To: <1546770407.32.0.613838233923.issue35670@roundup.psfhosted.org>
Message-ID: <1546777624.89.0.952255471571.issue35670@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a known issue. See for example issue13247 and issue16656. It cannot be fixed in Python 2. The only thing that can be done is to document it (see issue16700).

----------
nosy: +serhiy.storchaka
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jan  6 07:34:04 2019
From: report at bugs.python.org (Jorge Teran)
Date: Sun, 06 Jan 2019 12:34:04 +0000
Subject: [issue35672] Error on divide
Message-ID: <1546778042.38.0.180444315145.issue35672@roundup.psfhosted.org>


New submission from Jorge Teran <jteranp at gmail.com>:

The following code produces an error in the diivision in python 3.5, 3.7 works in python 2.7

import math
import sys

x=int(1000112004278059472142857)
y1=int(1000003)
y2=int(1000033)
y3=int(1000037)
y4=int(1000039)
print (int(y1y2y3y4))
print (x)
#this product equals x Correct
print (int(y2y3*y4))
n=int(x / y1)
print (n)
#n is an incorrect answer
#works in pythoin 2.7
#Gives an incorrect answe in python 3.6.7, 3.7.1

----------
components: Interpreter Core
messages: 333107
nosy: Jorge Teran
priority: normal
severity: normal
status: open
title: Error on divide
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Jan  6 07:37:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Jan 2019 12:37:52 +0000
Subject: [issue35672] Error on divide
In-Reply-To: <1546778042.38.0.180444315145.issue35672@roundup.psfhosted.org>
Message-ID: <1546778272.21.0.523041406087.issue35672@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I got:

NameError: name 'y1y2y3y4' is not defined.

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

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

From report at bugs.python.org  Sun Jan  6 07:53:45 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Sun, 06 Jan 2019 12:53:45 +0000
Subject: [issue35672] Error on divide
In-Reply-To: <1546778042.38.0.180444315145.issue35672@roundup.psfhosted.org>
Message-ID: <1546779225.06.0.284705836582.issue35672@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

@Jorge Teran
The division operator was changed in python 3. Now, if you use '/' for division between ints, the result would still be float. To get the same effect as python 2.x, you will have to use '//', i.e. floor division

----------
nosy: +FR4NKESTI3N

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

From report at bugs.python.org  Sun Jan  6 07:55:24 2019
From: report at bugs.python.org (Jorge Teran)
Date: Sun, 06 Jan 2019 12:55:24 +0000
Subject: [issue35672] Error on divide
In-Reply-To: <1546779225.06.0.284705836582.issue35672@roundup.psfhosted.org>
Message-ID: <CADmHXfGBsg7Jufx8o-8y_8jqWTtpg4gfAx1-2ae548gPa6aDsA@mail.gmail.com>


Jorge Teran <jteranp at gmail.com> added the comment:

Thanks

El dom., 6 de ene. de 2019 08:53, Yash Aggarwal <report at bugs.python.org>
escribi?:

>
> Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:
>
> @Jorge Teran
> The division operator was changed in python 3. Now, if you use '/' for
> division between ints, the result would still be float. To get the same
> effect as python 2.x, you will have to use '//', i.e. floor division
>
> ----------
> nosy: +FR4NKESTI3N
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35672>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Jan  6 08:23:25 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Jan 2019 13:23:25 +0000
Subject: [issue35673] Loader for namespace packages
Message-ID: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The documentation for import lib.machinery.ModuleSpec says that the attribute "loader" should be None for namespace packages (see <https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec>)

In reality the loader for namespace packages is an instance of a private class, and that class does not conform to the importlib.abc.Loader ABC.

To reproduce:

* Create and empty directory "namespace"
* (Optionally) create an empty "module.py" in that directory
* Start a python shell and follow along:

Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import namespace
>>> namespace.__loader__
<_frozen_importlib_external._NamespaceLoader object at 0x104c7bdd8>
>>> import importlib.abc
>>> isinstance(namespace.__loader__, importlib.abc.Loader)
False
>>> import importlib.util
>>> importlib.util.find_spec('namespace')
ModuleSpec(name='namespace', loader=<_frozen_importlib_external._NamespaceLoader object at 0x104c7bdd8>, submodule_search_locations=_NamespacePath(['/Users/ronald/Projects/pyobjc-hg/modulegraph2/namespace']))

Note how "namespace" has an attribute named "__loader__" that is not None, and the same is true for the ModuleSpec found using importlib.util.find_spec.  The loader does not claim to conform to any Loader ABC (but provides all methods required for conformance to the InspectLoader ABC)

I'm not sure if this should be two issues:

1) Documentation doesn't match behaviour

2) The loader for namespace packages isn't registered with the relevant ABCs

P.S. the latter is also true for zipimport.zipimporter.

----------
components: Library (Lib)
messages: 333111
nosy: brett.cannon, ronaldoussoren
priority: normal
severity: normal
status: open
title: Loader for namespace packages
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Jan  6 08:42:11 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 06 Jan 2019 13:42:11 +0000
Subject: [issue35672] Error on divide
In-Reply-To: <1546778042.38.0.180444315145.issue35672@roundup.psfhosted.org>
Message-ID: <1546782131.37.0.828765896711.issue35672@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

There is no need to call int() on a literal int: 1000003 is already an int, calling int() on it is just wasting time and making confusing code.

print (int(y1y2y3y4))

gives a NameError, since you don't have a variable "y1y2y3y4" defined. Please don't retype your example code from memory, make sure it works and then copy and paste code we can actually run.

I think we can simplify your example to this:

x = 1000112004278059472142857
y = 1000003
print(x/y)
print(int(x/y))


which correctly prints 

1.0001090039510477e+18
1000109003951047619

as the division operator uses floating point division in Python 3. Use the floor-division operator // to duplicate the Python 2 behaviour for ints.

Closing this as not a bug.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jan  6 08:47:26 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 06 Jan 2019 13:47:26 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546782446.25.0.410379051783.issue35668@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Welcome Anthony!

Please ask me any questions you may have.  My only suggestion at this point would be for you to feel free to add any docstrings/comments to the module as you go.  Having the docstrings really helps in understanding the tests and vice versa.

----------

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

From report at bugs.python.org  Sun Jan  6 09:05:33 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Jan 2019 14:05:33 +0000
Subject: [issue35625] Comprehension doc doesn't mention buggy class scope
 behavior
In-Reply-To: <1546253280.49.0.920078772343.issue35625@roundup.psfhosted.org>
Message-ID: <1546783533.07.0.196628864473.issue35625@roundup.psfhosted.org>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
components:  -email
nosy:  -barry, r.david.murray
type: security -> behavior

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

From report at bugs.python.org  Sun Jan  6 09:06:01 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Jan 2019 14:06:01 +0000
Subject: [issue35625] Comprehension doc doesn't mention buggy class scope
 behavior
In-Reply-To: <1546253280.49.0.920078772343.issue35625@roundup.psfhosted.org>
Message-ID: <1546783561.85.0.319100726305.issue35625@roundup.psfhosted.org>


Change by R. David Murray <rdmurray at bitdance.com>:


Removed file: https://bugs.python.org/file48026/keyfile.png

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

From report at bugs.python.org  Sun Jan  6 09:14:29 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Jan 2019 14:14:29 +0000
Subject: [issue4696] email module does not unfold headers
In-Reply-To: <1229633967.92.0.395336973724.issue4696@psf.upfronthosting.co.za>
Message-ID: <1546784069.32.0.197329716875.issue4696@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The new email API is no longer provisional.  It isn't the *default* yet, but it isn't provisional.  So yes, this is resolved.

Cheryl, if you see places in the current docs that still say provisional, please open an issue to remove those.

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

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

From report at bugs.python.org  Sun Jan  6 11:56:25 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 06 Jan 2019 16:56:25 +0000
Subject: [issue30487] DOC: automatically create a venv and install Sphinx when
 running make
In-Reply-To: <1495817388.46.0.640927890572.issue30487@psf.upfronthosting.co.za>
Message-ID: <1546793785.51.0.95317108573.issue30487@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


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

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

From report at bugs.python.org  Sun Jan  6 12:24:43 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 17:24:43 +0000
Subject: [issue35551] Encoding and alias issues
In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za>
Message-ID: <1546795483.59.0.771971578786.issue35551@roundup.psfhosted.org>


Ashwin Ramaswami <aramaswamis at gmail.com> added the comment:

"iso8859_1" is already an alias for "latin_1", though. https://github.com/python/cpython/blob/master/Lib/encodings/aliases.py#L432

----------
nosy: +epicfaace

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

From report at bugs.python.org  Sun Jan  6 12:25:57 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 17:25:57 +0000
Subject: [issue35551] Encoding and alias issues
In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za>
Message-ID: <1546795557.39.0.567457365072.issue35551@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch
pull_requests: +10899
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 12:26:07 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 17:26:07 +0000
Subject: [issue35551] Encoding and alias issues
In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za>
Message-ID: <1546795567.05.0.477901439778.issue35551@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10899, 10900
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 12:26:13 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 17:26:13 +0000
Subject: [issue35551] Encoding and alias issues
In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za>
Message-ID: <1546795573.36.0.173029673727.issue35551@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10899, 10900, 10902
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 12:26:19 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 17:26:19 +0000
Subject: [issue35551] Encoding and alias issues
In-Reply-To: <1545386892.27.0.788709270274.issue35551@psf.upfronthosting.co.za>
Message-ID: <1546795579.6.0.605439749655.issue35551@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10899, 10900, 10901, 10902
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 12:44:57 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Jan 2019 17:44:57 +0000
Subject: [issue35671] reserved identifier violation
In-Reply-To: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>
Message-ID: <1546796697.27.0.997463138283.issue35671@roundup.psfhosted.org>


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


----------
nosy: +vstinner

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

From report at bugs.python.org  Sun Jan  6 13:17:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 06 Jan 2019 18:17:40 +0000
Subject: [issue35667] activate for venv containing apostrophe doesn't work in
 powershell
In-Reply-To: <1546724069.06.0.00436819935865.issue35667@roundup.psfhosted.org>
Message-ID: <1546798660.09.0.381551090002.issue35667@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

>From the error I think the quotes are not properly escaped while doing text replacement in venv activate file template at [0] while it's generated? On linux/Mac double quotes are used and hence the error is not triggered with single quote in virtualenv name. Using double quote in virtualenv name triggers the parse error.

$  python3.7 -m venv py37\"-bpo-35667-venv
$  source py37\"-bpo-35667-venv/bin/activate
py37"-bpo-35667-venv/bin/activate:57: parse error near `then'

Looking into the py37\"-bpo-35667-venv/bin/activate script there is below line where the double quote is unbalanced : 

    if [ "x(py37"-bpo-35667-venv) " != x ] ; then
	PS1="(py37"-bpo-35667-venv) ${PS1:-}"
    else

I tried escaping the quotes with backslash at [0] but I get a similar error. I guess it's similar case in Powershell as I can see from Activate.ps1 but I haven't tested it. I am not sure about the difference in semantics between powershell and command prompt with respect to quoting since I don't have access to Windows.

py37\'-bpo-35667-venv/bin/Activate.ps1 file with unbalanced quote

    function global:prompt {
        Write-Host -NoNewline -ForegroundColor Green '(py37'-bpo-35667-venv) '
        _OLD_VIRTUAL_PROMPT
    }


[0] https://github.com/python/cpython/blob/a5b76167dedf4d15211a216c3ca7b98e3cec33b8/Lib/venv/__init__.py#L280

----------
nosy: +vinay.sajip, xtreak

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

From report at bugs.python.org  Sun Jan  6 13:28:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Jan 2019 18:28:53 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1546799333.25.0.385268787193.issue35582@roundup.psfhosted.org>


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


----------
pull_requests: +10903

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

From report at bugs.python.org  Sun Jan  6 13:28:58 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Jan 2019 18:28:58 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1546799338.37.0.246973404539.issue35582@roundup.psfhosted.org>


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


----------
pull_requests: +10903, 10904

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

From report at bugs.python.org  Sun Jan  6 14:37:13 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 19:37:13 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1546803433.65.0.416823183615.issue12707@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch
pull_requests: +10905
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 14:37:26 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 19:37:26 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1546803446.66.0.729962612402.issue12707@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10905, 10906
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 14:37:40 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 19:37:40 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1546803460.46.0.790936611406.issue12707@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10905, 10906, 10908
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 14:37:53 2019
From: report at bugs.python.org (Ashwin Ramaswami)
Date: Sun, 06 Jan 2019 19:37:53 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1546803473.39.0.760285658894.issue12707@roundup.psfhosted.org>


Change by Ashwin Ramaswami <aramaswamis at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10905, 10906, 10907, 10908
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Jan  6 15:31:31 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 06 Jan 2019 20:31:31 +0000
Subject: [issue35488] pathlib Path.match does not behave as described
In-Reply-To: <1544769623.98.0.788709270274.issue35488@psf.upfronthosting.co.za>
Message-ID: <1546806691.77.0.50681713818.issue35488@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 83da926b89daf80013ea966037c2c0e1e9d25c6b by Brett Cannon (Anthony Shaw) in branch 'master':
bpo-35488: Add tests for ** glob matching in pathlib (GH-11171)
https://github.com/python/cpython/commit/83da926b89daf80013ea966037c2c0e1e9d25c6b


----------

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

From report at bugs.python.org  Sun Jan  6 15:46:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 06 Jan 2019 20:46:19 +0000
Subject: [issue35670] os functions return '??' for unicode characters in paths
 on windows
In-Reply-To: <1546770407.32.0.613838233923.issue35670@roundup.psfhosted.org>
Message-ID: <1546807579.6.0.998518303801.issue35670@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

To be more clear, the fix is literally Python 3 and the str/bytes change. You've discovered one of the reasons that was necessary.

----------

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

From report at bugs.python.org  Sun Jan  6 15:50:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jan 2019 20:50:54 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546807854.35.0.461028923713.issue35660@roundup.psfhosted.org>


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


----------
title: IDLE: Remove import * from window.py -> IDLE: Fix imports in window.py

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

From report at bugs.python.org  Sun Jan  6 15:55:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jan 2019 20:55:54 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546808154.79.0.218725720573.issue35660@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 11303dd6035a7d7f78025ce5a3e3b9bdf7380c9a by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-35660: Fix imports in idlelib.window (#11434)
https://github.com/python/cpython/commit/11303dd6035a7d7f78025ce5a3e3b9bdf7380c9a


----------

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

From report at bugs.python.org  Sun Jan  6 15:56:30 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Jan 2019 20:56:30 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546808190.9.0.429567495891.issue35660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10909

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

From report at bugs.python.org  Sun Jan  6 15:56:36 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Jan 2019 20:56:36 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546808196.57.0.329985902074.issue35660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10909, 10910

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

From report at bugs.python.org  Sun Jan  6 15:56:42 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Jan 2019 20:56:42 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546808202.52.0.822483437902.issue35660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10909, 10910, 10912

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

From report at bugs.python.org  Sun Jan  6 15:56:48 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Jan 2019 20:56:48 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546808208.25.0.00311767867859.issue35660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10909, 10910, 10911, 10912

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

From report at bugs.python.org  Sun Jan  6 16:13:32 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Jan 2019 21:13:32 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546809212.34.0.334905662966.issue35660@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset be37dbff1ce3fa2ddd9115352b31ac0f6b44c193 by Miss Islington (bot) in branch '3.7':
bpo-35660: Fix imports in idlelib.window (GH-11434)
https://github.com/python/cpython/commit/be37dbff1ce3fa2ddd9115352b31ac0f6b44c193


----------
nosy: +miss-islington

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

From report at bugs.python.org  Sun Jan  6 16:29:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 06 Jan 2019 21:29:58 +0000
Subject: [issue35660] IDLE: Fix imports in window.py
In-Reply-To: <1546647216.45.0.186888273611.issue35660@roundup.psfhosted.org>
Message-ID: <1546810198.97.0.148659910838.issue35660@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jan  6 17:05:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jan 2019 22:05:08 +0000
Subject: [issue35671] reserved identifier violation
In-Reply-To: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>
Message-ID: <1546812308.08.0.505238486463.issue35671@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hi, I'm sorry but I don't understand your problem. Are you trying to build Python using C++? If yes, do you get a compilation error? I'm not sure that it's supported.

Or do you try to build a C extension for Python using a C++ compiler?

----------

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

From report at bugs.python.org  Sun Jan  6 17:16:09 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 06 Jan 2019 22:16:09 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546812969.53.0.39234062524.issue35673@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Sun Jan  6 17:22:01 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 06 Jan 2019 22:22:01 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546813321.87.0.333162095423.issue35673@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

On the first point, I'd categorize this as a documentation bug, and in fact, it's inconsistent with the language reference, which doesn't have the same language:

https://docs.python.org/3/reference/import.html#__loader__

On the second point, it probably does make sense to register the ABC.

----------

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

From report at bugs.python.org  Sun Jan  6 17:46:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 06 Jan 2019 22:46:47 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546814807.19.0.387171279635.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Gregory:
> Thanks for all your research and reference links on this!  As a _posixsubprocess maintainer, I am not against either posix_spawn or vfork being used directly in the future when feasible.

Are you against using posix_spawn() in subprocess? Or only in _posixsubprocess?

--

Alexey Izbyshev identified a difference between _posixsubprocess and posix_spawn() PR 11242: error handling depends a lot on the libc implementation.
https://github.com/python/cpython/pull/11242#issuecomment-449478778

* On recent glibc, posix_spawn() fails (non-zero return value) and set errno to ENOENT if the executed program doesn't exist... but not all platforms have this behavior.
* On FreeBSD, if setting posix_spawn() "attributes" or execute posix_spawn() "file actions" fails, posix_spawn() succeed but the child process exits immediately with exit code 127 without trying to call execv(). If execv() fails, posix_spawn() succeed, but the child process exit with exit code 127.
* The worst seems to be: "In my test on Ubuntu 14.04, ./python -c "import subprocess; subprocess.call(['/xxx'], close_fds=False, restore_signals=False)" silently returns with zero exit code."

execv() can fail for a lot of different reasons. Extract of Linux execve() manual page:
---
       E2BIG  The total number of bytes in the environment (envp) and argument list (argv) is too large.

       EACCES Search permission is denied on a component of the path prefix of filename or the name of a script interpreter.  (See also
              path_resolution(7).)

       EACCES The file or a script interpreter is not a regular file.

       EACCES Execute permission is denied for the file or a script or ELF interpreter.

       EACCES The filesystem is mounted noexec.

       EAGAIN (since Linux 3.1)
              Having  changed  its  real  UID  using one of the set*uid() calls, the caller was?and is now still?above its RLIMIT_NPROC
              resource limit (see setrlimit(2)).  For a more detailed explanation of this error, see NOTES.

       EFAULT filename or one of the pointers in the vectors argv or envp points outside your accessible address space.

       EINVAL An ELF executable had more than one PT_INTERP segment (i.e., tried to name more than one interpreter).

       EIO    An I/O error occurred.

       EISDIR An ELF interpreter was a directory.

       ELIBBAD
              An ELF interpreter was not in a recognized format.

       ELOOP  Too many symbolic links were encountered in resolving filename or the name of a script or ELF interpreter.

       ELOOP  The maximum recursion limit was reached during  recursive  script  interpretation  (see  "Interpreter  scripts",  above).
              Before Linux 3.8, the error produced for this case was ENOEXEC.

       EMFILE The per-process limit on the number of open file descriptors has been reached.

       ENAMETOOLONG
              filename is too long.

       ENFILE The system-wide limit on the total number of open files has been reached.

       ENOENT The  file  filename or a script or ELF interpreter does not exist, or a shared library needed for the file or interpreter
              cannot be found.

       ENOEXEC
              An executable is not in a recognized format, is for the wrong architecture, or has some other format error that means  it
              cannot be executed.

       ENOMEM Insufficient kernel memory was available.

       ENOTDIR
              A component of the path prefix of filename or a script or ELF interpreter is not a directory.

       EPERM  The  filesystem  is  mounted  nosuid, the user is not the superuser, and the file has the set-user-ID or set-group-ID bit
              set.

       EPERM  The process is being traced, the user is not the superuser and the file has the set-user-ID or set-group-ID bit set.

       EPERM  A "capability-dumb" applications would not obtain the full set of permitted capabilities granted by the executable  file.
              See capabilities(7).

       ETXTBSY
              The specified executable was open for writing by one or more processes.
---

Simply exit with exit code 127 (FreeBSD behavior) doesn't allow to know if the program have been executed or not.

For example, "git bisect run" depends on the exit code: exit code 127 means "command not found". But with posix_spawn(), exit code 127 can means something else...

I'm disappointed by the qualify of the posix_spawn() implementation on FreeBSD and old glibc...

--

I'm now confused.

Should we still use posix_spawn() on some platforms? For example, posix_spawn() seems to have a well defined error reporting according to its manual page:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/posix_spawn.2.html

"""
RETURN VALUES
     If the pid argument is NULL, no pid is returned to the calling process;
     if it is non-NULL, then posix_spawn() and posix_spawnp() functions return
     the process ID of the child process into the pid_t variable pointed to by
     the pid argument and return a 0 on success.  If an error occurs, they
     return a non-zero error code as the function return value, and no child
     process is created.

ERRORS
     The posix_spawn() and posix_spawnp() functions will fail and return to
     the calling process if:

     [EINVAL]           The value specified by file_actions or attrp is
                        invalid.

     [E2BIG]            The number of bytes in the new process's argument list
                        is larger than the system-imposed limit.  This limit
                        is specified by the sysctl(3) MIB variable
                        KERN_ARGMAX.

     [EACCES]           Search permission is denied for a component of the
                        path prefix.

     [EACCES]           The new process file is not an ordinary file.

     [EACCES]           The new process file mode denies execute permission.

     [EACCES]           The new process file is on a filesystem mounted with
                        execution disabled (MNT_NOEXEC in <sys/mount.h>).

     [EFAULT]           The new process file is not as long as indicated by
                        the size values in its header.

     [EFAULT]           Path, argv, or envp point to an illegal address.

     [EIO]              An I/O error occurred while reading from the file sys-tem. system.
                        tem.

     [ELOOP]            Too many symbolic links were encountered in translat-ing translating
                        ing the pathname.  This is taken to be indicative of a
                        looping symbolic link.

     [ENAMETOOLONG]     A component of a pathname exceeded {NAME_MAX} charac-ters, characters,
                        ters, or an entire path name exceeded {PATH_MAX} char-acters. characters.
                        acters.

     [ENOENT]           The new process file does not exist.

     [ENOEXEC]          The new process file has the appropriate access per-mission, permission,
                        mission, but has an unrecognized format (e.g., an
                        invalid magic number in its header).

     [ENOMEM]           The new process requires more virtual memory than is
                        allowed by the imposed maximum (getrlimit(2)).

     [ENOTDIR]          A component of the path prefix is not a directory.

     [ETXTBSY]          The new process file is a pure procedure (shared text)
                        file that is currently open for writing or reading by
                        some process.
"""

Would it be reasonable to use posix_spawn() but only on platforms where the implementation is known to be "good"?

Good would mean that execv() and posix_spawn() errors (setting attributes or file actions failures) are properly reported to the parent process.

For example, use posix_spawn() in subprocess on "recent" glibc (which minimum version?) and macOS (where it's a syscall)?

----------

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

From report at bugs.python.org  Sun Jan  6 18:19:08 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 23:19:08 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546816748.97.0.170316154052.issue35668@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

thanks Cheryl,

here's my branch https://github.com/tonybaloney/cpython/tree/idlelib_tests

I've already seen some code which is 17 years old!

----------

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

From report at bugs.python.org  Sun Jan  6 18:48:54 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 23:48:54 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546818534.16.0.476226082677.issue35668@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +10913
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 18:49:00 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 23:49:00 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546818540.68.0.563074108836.issue35668@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch, patch
pull_requests: +10913, 10914
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 18:49:06 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 23:49:06 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546818546.85.0.400874964563.issue35668@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch, patch, patch
pull_requests: +10913, 10914, 10916
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 18:49:12 2019
From: report at bugs.python.org (anthony shaw)
Date: Sun, 06 Jan 2019 23:49:12 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546818552.82.0.269722338526.issue35668@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10913, 10914, 10915, 10916
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 19:09:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:09:00 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546819740.25.0.147194311563.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +10917
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 19:09:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:09:12 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546819752.18.0.608355461552.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +10917, 10918
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 19:09:14 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 07 Jan 2019 00:09:14 +0000
Subject: [issue35667] activate for venv containing apostrophe doesn't work in
 powershell
In-Reply-To: <1546724069.06.0.00436819935865.issue35667@roundup.psfhosted.org>
Message-ID: <1546819754.15.0.302360804411.issue35667@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I am not sure about the difference in semantics between powershell and 
> command prompt with respect to quoting since

CMD only uses single quotes in `for /f` loops, in which it's either a command or a literal string (w/ the "usebackq" option). This is not a problem in activate.bat. 

Double quotes in file names generally shouldn't be a problem in Windows. As far as I know, only the named-pipe file system allows them in pipe-file names (e.g. r'\\?\pipe\"pipename"'), and for regular files they're allowed in stream names (e.g. 'filename:"streamname"'). Otherwise, double quote should be reserved in file names as the DOS_DOT wildcard character.

----------
nosy: +eryksun

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

From report at bugs.python.org  Sun Jan  6 19:09:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:09:22 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546819762.17.0.0481226953851.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10917, 10918, 10919
stage:  -> patch review

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

From report at bugs.python.org  Sun Jan  6 19:13:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:13:23 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546820003.1.0.351247921295.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 11452 which is based on PR 11242 but adds support for 'env' and 'restore_signals' parameters and checks the operating system and libc version to decide if posix_spawn() can be used by subprocess.

In my implementation, posix_spawn() is only used on macOS and glibc 2.26 or newer (and glibc 2.24 and newer on Linux).

According to Alexey Izbyshev, musl should be safe as well, but I don't know how to test musl on my Fedora, nor how to check if Python is linked to musl, nor what is the minimum musl version which is safe.

----------

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

From report at bugs.python.org  Sun Jan  6 19:15:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:15:39 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546820139.69.0.104959811842.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

"The native spawn(2) system introduced in Oracle Solaris 11.4 shares a lot of code with the forkx(2) and execve(2)."
https://blogs.oracle.com/solaris/posix_spawn-as-an-actual-system-call

----------

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

From report at bugs.python.org  Sun Jan  6 19:46:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:46:09 +0000
Subject: [issue35674] Expose os.posix_spawnp()
Message-ID: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>


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

bpo-20104 exposed os.posix_spawn(), but not os.posix_spawnp().

os.posix_spawnp() would be useful to support executable with no directory. See bpo-35537 "use os.posix_spawn in subprocess".

I'm not sure what is the best API:

* Add os.posix_spawnp()? duplicate the documentation and some parts of the C code (but share most of the C code)
* Add a new optional parameter to os.posix_spawn()? Ideas of names: 'use_path' or 'search_executable'. Internally, the glibc uses SPAWN_XFLAGS_USE_PATH flag to distinguish posix_spawn() and posix_spawnp().

execvp() uses the PATH environment variable, or use confstr(_CS_PATH) if PATH is not set. I guess that posix_spawnp() also uses confstr(_CS_PATH) if PATH is not set.

Currently, my favorite option is to add a new optional 'use_path' parameter to the existing os.posix_spawn() function.

----------
components: Interpreter Core
messages: 333128
nosy: pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Expose os.posix_spawnp()
versions: Python 3.8

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

From report at bugs.python.org  Sun Jan  6 19:47:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:47:02 +0000
Subject: [issue20104] expose posix_spawn(p)
In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za>
Message-ID: <1546822022.95.0.52512279585.issue20104@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Serhiy:
> And os.posix_spawnp() still is not implemented.

I created bpo-35674 to see how to expose this feature.

----------

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

From report at bugs.python.org  Sun Jan  6 19:49:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:49:10 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1546822150.93.0.745187123619.issue35674@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Historically, Python used to mimick the libc: there are os.stat() and os.lstat() for example. But later, os.stat(*, follow_symlinks=False) keyword-only parameter has been added: if true, lstat() is used internally.

----------

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

From report at bugs.python.org  Sun Jan  6 19:49:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 00:49:48 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1546822188.81.0.294790013582.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I created bpo-35674: "Expose os.posix_spawnp()" to later support executable with no directory in subprocess.

----------

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

From report at bugs.python.org  Sun Jan  6 22:35:06 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Jan 2019 03:35:06 +0000
Subject: [issue34439] Expose venv --prompt value to an environment value
In-Reply-To: <1534760450.03.0.56676864532.issue34439@psf.upfronthosting.co.za>
Message-ID: <1546832106.97.0.163767807779.issue34439@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Duplicate of bpo-35328, which has a PR.

----------
nosy: +vinay.sajip
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jan  6 22:37:42 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 07 Jan 2019 03:37:42 +0000
Subject: [issue35530] Counter-intuitive logging API
In-Reply-To: <1545178149.93.0.788709270274.issue35530@psf.upfronthosting.co.za>
Message-ID: <1546832262.93.0.258195824857.issue35530@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

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

From report at bugs.python.org  Sun Jan  6 22:51:13 2019
From: report at bugs.python.org (Andrew Brezovsky)
Date: Mon, 07 Jan 2019 03:51:13 +0000
Subject: [issue29515] socket module missing IPPROTO_IPV6,
 IPPROTO_IPV4 on Windows
In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za>
Message-ID: <1546833073.22.0.0839459001036.issue29515@roundup.psfhosted.org>


Andrew Brezovsky <abrezovsky at gmail.com> added the comment:

Can confirm this is still a problem in latest versions of 3.5, 3.6, and 3.7

Any progress made on this?

----------
nosy: +abrezovsky

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

From report at bugs.python.org  Sun Jan  6 22:56:06 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 03:56:06 +0000
Subject: [issue35675] IDLE: Refactor config_key module.
Message-ID: <1546833365.65.0.740704370404.issue35675@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Continuation of #35598.  Cheryl said there (rearranged):
"PR11427 refactors the main frame from the window.  My main goal in splitting them was more for readability rather than for being able to add it to a Tabbed window.  As a follow up to this refactor, I hope to split the Basic and Advanced frames into their own tabs, mostly to clean up the create_widgets and to organize the supporting functions."


A pair of tabs on a ttk Notebook would make this more like configdialog.

----------
messages: 333134
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: Refactor config_key module.
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Jan  6 22:57:41 2019
From: report at bugs.python.org (David Mertz)
Date: Mon, 07 Jan 2019 03:57:41 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1546833461.88.0.753365697707.issue33084@roundup.psfhosted.org>


David Mertz <david.mertz at gmail.com> added the comment:

I believe that the current behavior of `statistics.median[|_low|_high\]` is simply broken.  It relies on the particular behavior of Python sorting, which only utilizes `.__lt__()` between objects, and hence does not require a total order.

I can think of absolutely no way to characterize these as reasonable results:

Python 3.7.1 | packaged by conda-forge | (default, Nov 13 2018, 09:50:42)
>>> statistics.median([9, 9, 9, nan, 1, 2, 3, 4, 5])
1
>>> statistics.median([9, 9, 9, nan, 1, 2, 3, 4])
nan

----------
nosy: +David Mertz

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

From report at bugs.python.org  Sun Jan  6 22:58:35 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 07 Jan 2019 03:58:35 +0000
Subject: [issue35675] IDLE: Refactor config_key module.
In-Reply-To: <1546833365.65.0.740704370404.issue35675@roundup.psfhosted.org>
Message-ID: <1546833515.29.0.0962607192472.issue35675@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +10920

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

From report at bugs.python.org  Sun Jan  6 23:01:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 04:01:19 +0000
Subject: [issue35598] IDLE: Modernize config_key module
In-Reply-To: <1545942477.09.0.499754382121.issue35598@roundup.psfhosted.org>
Message-ID: <1546833679.83.0.114984324106.issue35598@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I moved PR 11427 to new issue #35675.

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

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

From report at bugs.python.org  Sun Jan  6 23:06:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 04:06:19 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546833979.33.0.956639382839.issue35668@roundup.psfhosted.org>


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


----------
pull_requests:  -10916

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

From report at bugs.python.org  Sun Jan  6 23:06:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 04:06:38 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546833998.73.0.199341654646.issue35668@roundup.psfhosted.org>


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


----------
pull_requests:  -10915

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

From report at bugs.python.org  Sun Jan  6 23:06:50 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 04:06:50 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546834010.45.0.495801845571.issue35668@roundup.psfhosted.org>


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


----------
pull_requests:  -10914

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

From report at bugs.python.org  Sun Jan  6 23:17:48 2019
From: report at bugs.python.org (=?utf-8?b?15DXldeo15kg16jXldeT15HXqNeS?=)
Date: Mon, 07 Jan 2019 04:17:48 +0000
Subject: [issue35676] class TestCase: docs are not correct
Message-ID: <1546834667.39.0.848001961358.issue35676@roundup.psfhosted.org>


New submission from ???? ?????? <uri at speedy.net>:

I think some functions of `class TestCase` are not documented correctly in the docs. For example in https://docs.python.org/3.5/library/unittest.html and also https://docs.python.org/3.6/library/unittest.html and https://docs.python.org/3.7/library/unittest.html.

Some of the functions which are not documented correctly:

assertListEqual
assertSetEqual
assertDictEqual
assertIsNone

And many other functions.

You can see some more details on https://github.com/python/typeshed/issues/2716.

----------
assignee: docs at python
components: Documentation
messages: 333137
nosy: docs at python, ???? ??????
priority: normal
severity: normal
status: open
title: class TestCase: docs are not correct
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Jan  6 23:27:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 04:27:37 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546835257.46.0.141431360678.issue35668@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I like having multiple commits with explanatory messages.  They get squashed when merging into master.  Unless I get distracted and forget, I will squash the messages.

----------

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

From report at bugs.python.org  Sun Jan  6 23:27:43 2019
From: report at bugs.python.org (=?utf-8?b?15DXldeo15kg16jXldeT15HXqNeS?=)
Date: Mon, 07 Jan 2019 04:27:43 +0000
Subject: [issue35676] class TestCase: docs are not correct
In-Reply-To: <1546834667.39.0.848001961358.issue35676@roundup.psfhosted.org>
Message-ID: <1546835263.74.0.800251992216.issue35676@roundup.psfhosted.org>


???? ?????? <uri at speedy.net> added the comment:

1. I think the main problem is where it's documented "first, second" while the real argument names are different.

2. I think maybe https://docs.python.org/2.7/library/unittest.html is also affected in functions such as:

assertGreater(first, second, msg=None)
assertGreaterEqual(first, second, msg=None)
assertLess(first, second, msg=None)
assertLessEqual(first, second, msg=None)

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

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

From report at bugs.python.org  Sun Jan  6 23:30:16 2019
From: report at bugs.python.org (=?utf-8?b?15DXldeo15kg16jXldeT15HXqNeS?=)
Date: Mon, 07 Jan 2019 04:30:16 +0000
Subject: [issue35676] class TestCase: docs are not correct
In-Reply-To: <1546834667.39.0.848001961358.issue35676@roundup.psfhosted.org>
Message-ID: <1546835416.05.0.866904121709.issue35676@roundup.psfhosted.org>


Change by ???? ?????? <uri at speedy.net>:


----------
versions: +Python 3.4, Python 3.8

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

From report at bugs.python.org  Mon Jan  7 02:25:12 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Jan 2019 07:25:12 +0000
Subject: [issue35643] SyntaxWarning: invalid escape sequence in
 Modules/_sha3/cleanup.py
In-Reply-To: <1546455707.05.0.304016401963.issue35643@roundup.psfhosted.org>
Message-ID: <1546845912.7.0.834430484332.issue35643@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 3e0144a6c95433f347bb7e44a98c84deae8853ff by Benjamin Peterson (Miss Islington (bot)) in branch '3.6':
closes bpo-35643: Fix a SyntaxWarning: invalid escape sequence in Modules/_sha3/cleanup.py (GH-11413)
https://github.com/python/cpython/commit/3e0144a6c95433f347bb7e44a98c84deae8853ff


----------

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

From report at bugs.python.org  Mon Jan  7 03:16:40 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 07 Jan 2019 08:16:40 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546849000.7.0.108946297375.issue35673@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

@barry: I agree on both.

Do you know why the namespace package loader lies about the source and code? Both .get_source() and .get_code() return a value that isn't None.

And likewise: Why is the namespace package loader a private class, other loaders are exposed in importlib.machinery?  This makes it hard to detect PEP420 style namespace packages without relying on private APIs, esp. combined with the behaviour of .get_source() and .get_code().

----------

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

From report at bugs.python.org  Mon Jan  7 03:18:56 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 08:18:56 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546849136.65.0.048153211296.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +10921

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

From report at bugs.python.org  Mon Jan  7 03:19:12 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 08:19:12 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546849152.12.0.544450993303.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +10921, 10922

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

From report at bugs.python.org  Mon Jan  7 03:19:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 08:19:15 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1546849155.95.0.275855958419.issue35674@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

To add some context, the follow_symlinks parameter was added to os.stat() after adding support of *at() functions (like openat() and fstatat()). Since both C functions stat() and lstat() are superseded by fstatat(), the latter was exposed at Python level as adding new keyword-only parameters to os.stat(). This allowed to avoid significant increasing the number of functions in the os module.

Since there is no function that supersedes both posix_spawn() and posix_spawnp(), this may be an argument for exposing them as separate functions at Python level. Although this argument is not very strong.

----------

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

From report at bugs.python.org  Mon Jan  7 03:19:27 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 08:19:27 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546849167.33.0.34926338134.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +10921, 10922, 10923

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

From report at bugs.python.org  Mon Jan  7 03:30:36 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Mon, 07 Jan 2019 08:30:36 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546849836.68.0.865752527382.issue35596@roundup.psfhosted.org>


Change by Marc Schlaich <marc.schlaich at googlemail.com>:


----------
nosy: +schlamar

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

From report at bugs.python.org  Mon Jan  7 04:18:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 09:18:02 +0000
Subject: [issue35677] Do not automount in stat() by default
Message-ID: <1546852678.92.0.232634094535.issue35677@roundup.psfhosted.org>


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

There is a subtle difference between implementations of os.stat() that use system calls stat() and fstatat(). On Linux, fstatat() by default automounts the terminal ("basename") component of pathname if it is a directory that is an automount point. The Linux-specific AT_NO_AUTOMOUNT flag should be set to prevent automounting. Both stat() and lstat() act as though AT_NO_AUTOMOUNT was set.

Therefore os.stat() should set AT_NO_AUTOMOUNT if it is defined to simulate the behavior of stat() and lstat(). New keyword parameter can be added to os.stat() in new Python release to control this behavior.

There is the same issue with DirEntry.stat().

----------
components: Extension Modules
messages: 333143
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Do not automount in stat() by default
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Jan  7 04:30:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 09:30:35 +0000
Subject: [issue35677] Do not automount in stat() by default
In-Reply-To: <1546852678.92.0.232634094535.issue35677@roundup.psfhosted.org>
Message-ID: <1546853435.67.0.194887095766.issue35677@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +10924
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 04:30:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 09:30:40 +0000
Subject: [issue35677] Do not automount in stat() by default
In-Reply-To: <1546852678.92.0.232634094535.issue35677@roundup.psfhosted.org>
Message-ID: <1546853440.78.0.88143975354.issue35677@roundup.psfhosted.org>


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


----------
keywords: +patch, patch
pull_requests: +10924, 10925
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 04:30:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 09:30:45 +0000
Subject: [issue35677] Do not automount in stat() by default
In-Reply-To: <1546852678.92.0.232634094535.issue35677@roundup.psfhosted.org>
Message-ID: <1546853445.6.0.130918192909.issue35677@roundup.psfhosted.org>


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


----------
keywords: +patch, patch, patch
pull_requests: +10924, 10925, 10926
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 06:38:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 11:38:33 +0000
Subject: [issue4926] putenv() accepts names containing '=',
 return value of unsetenv() not checked
In-Reply-To: <1231803037.62.0.52390349364.issue4926@psf.upfronthosting.co.za>
Message-ID: <1546861113.9.0.433592853533.issue4926@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The original issues seem fixed.

As for leaks in posix_putenv_garbage on Windows, it is better to open a new issue for this.

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

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

From report at bugs.python.org  Mon Jan  7 06:54:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 11:54:37 +0000
Subject: [issue35257] Avoid leaking linker flags into distutils: add
 PY_LDFLAGS_NODIST
In-Reply-To: <1542298441.4.0.788709270274.issue35257@psf.upfronthosting.co.za>
Message-ID: <1546862077.12.0.146318229178.issue35257@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

New changeset 92f90242994652d6b7afe0a2c8a61cf2bccc8c32 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-35257: fix broken BLDSHARED - needs LDFLAGS too (GH-11297)
https://github.com/python/cpython/commit/92f90242994652d6b7afe0a2c8a61cf2bccc8c32

Since Ned pushed a new fix, I ran again my tests on the 3.7 branch with ./configure CC=clang --with-lto --prefix /opt/py37 --enable-shared:

(1) 4 => ok
(2) 0, False => ok
(3) 0 => ok

Good! It works (in my tests).

--

"make sharedmods" runs "LDSHARED=$BLDSHARED (...) ./python setup.py build"

"make libpython(...)" uses $(BLDSHARED) to link libpython.

Modules/makesetup uses BLDSHARED to build C extensions of the stdlib. Example from generated Makefile:

"Modules/posix$(EXT_SUFFIX): Modules/posixmodule.o; $(BLDSHARED) Modules/posixmodule.o -o Modules/posix$(EXT_SUFFIX) (...)"

distutils has a customize_compiler() function which uses LDSHARED from Makefile (can be overriden by environment variables): it doesn't use BLDSHARED.

It seems like BLDSHARED is only used to build Python itself and stdlib modules. So I agree that it's ok to add PY_LDFLAGS_NODIST flags to BLDSHARED.

----------

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

From report at bugs.python.org  Mon Jan  7 07:09:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 12:09:18 +0000
Subject: [issue17703] Trashcan mechanism segfault during interpreter
 finalization in Python 2.7.4
In-Reply-To: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za>
Message-ID: <1546862958.31.0.357149956221.issue17703@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This issue is closed. Can you please open a new issue? Try to describe the bug that you have and what you attemped to fix it.

----------

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

From report at bugs.python.org  Mon Jan  7 07:47:55 2019
From: report at bugs.python.org (MaximilianSP)
Date: Mon, 07 Jan 2019 12:47:55 +0000
Subject: [issue35678] Issue with execute_child in startupinfo
Message-ID: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>


New submission from MaximilianSP <maximilian.sprengel at bam.de>:

Whenever startupinfo is called, python crashes on my Computer. I have added the file showing the error traceback. I have seen a few bug Reports related to startupinfo on Windows. Not sure what the issue is and I hope you can help me. 

I am running the python code via spyder. My apologies if this is not the forum for these Kind of questions.

----------
components: Windows
files: Win Error 87_ in execute child startupinfo.png
messages: 333147
nosy: MaximilianSP, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Issue with execute_child in startupinfo
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48027/Win Error 87_ in execute child startupinfo.png

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

From report at bugs.python.org  Mon Jan  7 08:38:27 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Mon, 07 Jan 2019 13:38:27 +0000
Subject: [issue34431] Docs does not eval allows code object as argument
In-Reply-To: <1534608199.83.0.56676864532.issue34431@psf.upfronthosting.co.za>
Message-ID: <1546868307.44.0.748857017861.issue34431@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

This graceful reminder is most welcome. At present, it's not help I'm short of, but time. I've given myself a reminder, to spend time on this before the end of this month (January 2019).

Once again, thank you for this reminder. This is something I want to do. It would be my first Python contribution.

----------

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

From report at bugs.python.org  Mon Jan  7 08:46:33 2019
From: report at bugs.python.org (Corey Bryant)
Date: Mon, 07 Jan 2019 13:46:33 +0000
Subject: [issue34173] [3.7] deadlock in
 /usr/lib/python3.7/concurrent/futures/thread.py
In-Reply-To: <1532454888.31.0.56676864532.issue34173@psf.upfronthosting.co.za>
Message-ID: <CADn0iZ2Pd2m4X40a0iJGS9J3TRPZZME4CQRQJGG4zxtkTJ7Zsg@mail.gmail.com>


Corey Bryant <corey.bryant at canonical.com> added the comment:

I think we can close this issue. It was narrowed down to eventlet. Please
see: https://github.com/eventlet/eventlet/issues/508

On Tue, Jul 24, 2018 at 1:54 PM Karthikeyan Singaravelan <
report at bugs.python.org> wrote:

>
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
>
> Sorry for the noise about the title change. It seems you have edited it
> while I was typing my comment. There was a form error while I tried submit
> but I ignored it to try again and it had set my title. I have reverted back
> to your edit.
>
> Thanks
>
> ----------
> title: [3.7] possible race condition in
> /usr/lib/python3.7/concurrent/futures/thread.py -> [3.7] deadlock in
> /usr/lib/python3.7/concurrent/futures/thread.py
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34173>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jan  7 08:55:53 2019
From: report at bugs.python.org (Hernot)
Date: Mon, 07 Jan 2019 13:55:53 +0000
Subject: [issue35679] pdb restart hooks
Message-ID: <1546869350.93.0.529177618496.issue35679@roundup.psfhosted.org>


New submission from Hernot <christoph at out-world.com>:

I like the PDB debugger it is a quite powerfull tool, despite a few donws. One is that cleanup code eg registered by debugged script, module is not executed on restart. a crude hack is to check whether pdb is invoked via python -mpdb using inspect and decorate pdb._runscript and psb._runmodule methods with own versions calling registered cleanup methods before returning to main.

A cleaner approach would be if either pdb intercepts atexit calls recording any method which is registered by a call to atexit.register or provide it's own atexit method to register methods which pdb should call to revert to a clean enviroment expected by the script or module at startup.

open to any discussion, examples will follow as necessary.

----------
components: Demos and Tools, Library (Lib)
messages: 333150
nosy: Hernot
priority: normal
severity: normal
status: open
title: pdb restart hooks
type: enhancement

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

From report at bugs.python.org  Mon Jan  7 09:06:18 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Mon, 07 Jan 2019 14:06:18 +0000
Subject: [issue33084] Computing median,
 median_high an median_low in statistics library
In-Reply-To: <1521179882.82.0.467229070634.issue33084@psf.upfronthosting.co.za>
Message-ID: <1546869978.85.0.202812265139.issue33084@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

Based on a quick review of the python docs, the bug report, PEP 450
and this thread, I suggest

1. More carefully draw attention to the NaN feature, in the
documentation for existing Python versions.
2. Consider revising statistics.py so that it raises an exception,
when passed NaN data.

This implies dividing this issue into two parts: legacy and future.

For more information, see:
https://mail.python.org/pipermail/python-ideas/2019-January/054872.html

----------
nosy: +jfine2358

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

From report at bugs.python.org  Mon Jan  7 09:08:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Jan 2019 14:08:41 +0000
Subject: [issue34173] [3.7] deadlock in
 /usr/lib/python3.7/concurrent/futures/thread.py
In-Reply-To: <1532115107.08.0.56676864532.issue34173@psf.upfronthosting.co.za>
Message-ID: <1546870121.26.0.126784486679.issue34173@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the info. I am closing it as third party.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Jan  7 09:36:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:36:50 +0000
Subject: [issue35678] Issue with execute_child in startupinfo
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1546871810.36.0.733753049204.issue35678@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The screenshot says "OSError: [WinError 87] Falscher Parameter" at Lib/subprocess.py:1178 which is this call:

                hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
                                         # no special security
                                         None, None,
                                         int(not close_fds),
                                         creationflags,
                                         env,
                                         os.fspath(cwd) if cwd is not None else None,
                                         startupinfo)

According to the traceback, the call is:

subprocess.check_output([execStr,"-3",self.geofile,"-o",self.vtkFile])

Can you please dump these parameters? Are they all strings?

IMHO execStr, self.geofile or self.vtkFile is not a valid string and it's a bug in your code.

Context:

* bpo-34044
* commit 29be3bd3c9aed0190e60096a603120cacda82375
* Comments on the commit: https://github.com/python/cpython/commit/29be3bd3c9aed0190e60096a603120cacda82375#commitcomment-31855236

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 09:38:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:38:34 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1546871914.25.0.0324398641535.issue35678@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

"Issue with execute_child in startupinfo"

I don't think that the issue is related to startupinfo at all, since you don't specify this parameter in your check_output() call. Python shows you "startupinfo)" in the traceback because the function call takes multiple lines in the source code.

This issue is not a crash: it's possible to catch the exception and continue the execution.

----------
title: Issue with execute_child in startupinfo -> subprocess.check_output(): OSError: [WinError 87]
type: crash -> 

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

From report at bugs.python.org  Mon Jan  7 09:40:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:40:56 +0000
Subject: [issue35677] Do not automount in stat() by default
In-Reply-To: <1546852678.92.0.232634094535.issue35677@roundup.psfhosted.org>
Message-ID: <1546872056.36.0.0526129743961.issue35677@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

What if someone relies on the current behavior of os.stat(filename, dir_fd=fd)? Would it make sense to add a new "automount=False" optional parameter to os.stat()? AT_NO_AUTOMOUNT would only be added if automount is false.

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 09:43:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:43:44 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546872224.81.0.765899565072.issue35283@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I suggest to start with:

* Updating docstrings to recommend use is_alive() instead of isAlive(), and add a deprecation warning for Thread.isAlive

We may apply such changes to Python 3.7, maybe also emit a PendingDeprecationWarning.

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 09:46:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:46:53 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1546872413.86.0.767569575645.issue35633@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Since you are getting indentation error, I'm not sure about your test. Can you please apply the patch below and run again test_eintr? Does it still fail with PermissionError?

diff --git a/Lib/test/eintrdata/eintr_tester.py b/Lib/test/eintrdata/eintr_tester.py
index 25c169bde5..4db5dc9045 100644
--- a/Lib/test/eintrdata/eintr_tester.py
+++ b/Lib/test/eintrdata/eintr_tester.py
@@ -492,13 +492,13 @@ class FNTLEINTRTest(EINTRBaseTest):
         self.addCleanup(support.unlink, support.TESTFN)
         code = '\n'.join((
             "import fcntl, time",
-            "with open('%s', 'wb') as f:" % support.TESTFN,
+            "with open('%s', 'w+b') as f:" % support.TESTFN,
             "   fcntl.%s(f, fcntl.LOCK_EX)" % lock_name,
             "   time.sleep(%s)" % self.sleep_time))
         start_time = time.monotonic()
         proc = self.subprocess(code)
         with kill_on_error(proc):
-            with open(support.TESTFN, 'wb') as f:
+            with open(support.TESTFN, 'w+b') as f:
                 while True:  # synchronize the subprocess
                     dt = time.monotonic() - start_time
                     if dt > 60.0:

----------

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

From report at bugs.python.org  Mon Jan  7 09:49:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:49:04 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546872544.79.0.870696325581.issue35665@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> self.load_verify_locations(cadata=certs)
> ...
> ssl.SSLError: nested asn1 error (_ssl.c:3926)

It seems like one of your certificate is invalid.

> In Python 3.6.4 same function call raises no error.

We frequently update OpenSSL in Python. You can get OpenSSL version using:

$ python3
Python 3.7.2 (default, Jan  3 2019, 09:14:01) 
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.1 FIPS  11 Sep 2018'
>>> ssl.OPENSSL_VERSION_INFO
(1, 1, 1, 0, 15)
>>> ssl.OPENSSL_VERSION_NUMBER
269488143
>>> hex(ssl.OPENSSL_VERSION_NUMBER)
'0x1010100f'

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 09:52:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:52:14 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546872734.21.0.430310390126.issue35665@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Would it be possible to attach the certification to the issue so someone can try to reproduce the issue? (but don't attach any private key ;-))

----------

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

From report at bugs.python.org  Mon Jan  7 09:56:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:56:10 +0000
Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug
In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org>
Message-ID: <1546872970.93.0.201128393137.issue35662@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 09:57:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:57:44 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546873064.16.0.278082681771.issue32592@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hello 2018, I reopen the issue and change the version to Python 3.8.

----------
resolution: out of date -> 
status: closed -> open
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Mon Jan  7 09:59:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:59:46 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546873186.12.0.0158735214089.issue32592@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10927
stage: resolved -> patch review

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

From report at bugs.python.org  Mon Jan  7 09:59:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 14:59:58 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546873198.01.0.66054192762.issue32592@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10927, 10928
stage: resolved -> patch review

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

From report at bugs.python.org  Mon Jan  7 10:00:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:00:07 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546873207.99.0.326947947909.issue32592@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10927, 10928, 10929
stage: resolved -> patch review

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

From report at bugs.python.org  Mon Jan  7 10:01:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:01:31 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546873291.46.0.0781901353044.issue32592@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I failed to fix failures on my PR. It's now too late for Python 3.7.

I will try to redo PR 5231 in small chunks to better control the risk. I extracted os.cpu_count() changed as a new PR: PR 11457.

I already updated time.monotonic() documentation in a previous change:

commit 3ab064e80a9be1e6e9c62437fffb92bde9c5e1fb
Author: Victor Stinner <vstinner at redhat.com>
Date:   Mon Dec 17 12:12:34 2018 +0100

    bpo-23451: Update time.monotonic() documentation (GH-11190)
    
    bpo-23451, bpo-22117: Python 3.5 requires Windows Vista or newer,
    time.monotonic() is now always system-wide.

----------

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

From report at bugs.python.org  Mon Jan  7 10:09:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:09:17 +0000
Subject: [issue35560] format(float(123), "00") causes segfault in debug builds
In-Reply-To: <1545474042.87.0.98272194251.issue35560@roundup.psfhosted.org>
Message-ID: <1546873757.17.0.269549568628.issue35560@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 3f7983a25a3d19779283c707fbdd5bc91b1587ef by Victor Stinner (Xtreak) in branch 'master':
bpo-35560: Remove assertion from format(float, "n") (GH-11288)
https://github.com/python/cpython/commit/3f7983a25a3d19779283c707fbdd5bc91b1587ef


----------

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

From report at bugs.python.org  Mon Jan  7 10:09:56 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Jan 2019 15:09:56 +0000
Subject: [issue35560] format(float(123), "00") causes segfault in debug builds
In-Reply-To: <1545474042.87.0.98272194251.issue35560@roundup.psfhosted.org>
Message-ID: <1546873796.93.0.816762623589.issue35560@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10930

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

From report at bugs.python.org  Mon Jan  7 10:15:59 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Jan 2019 15:15:59 +0000
Subject: [issue35676] unittest assert helper methods have incorrect signature
 in docs
In-Reply-To: <1546834667.39.0.848001961358.issue35676@roundup.psfhosted.org>
Message-ID: <1546874159.21.0.525046637236.issue35676@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Looking at git history it seems there were some changes done in issue10573 to use (actual, expected) for consistency and later changed to use (first, second) in the same issue at msg126911. Discussion for the issue : https://mail.python.org/pipermail/python-dev/2010-December/106875.html

I think this is a bug as seen from typeshed https://github.com/python/typeshed/pull/2724/. But I will defer it to the maintainer to take a call on the same given there was a discussion in the past.

Removing versions that are on security fix only mode. I am changing the subject. Feel free to reword/revert.

----------
nosy: +ezio.melotti, xtreak
title: class TestCase: docs are not correct -> unittest assert helper methods have incorrect signature in docs
versions:  -Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jan  7 10:16:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:16:09 +0000
Subject: [issue35624] Shelve sync issues while using Gevent
In-Reply-To: <1546243936.53.0.108056450415.issue35624@roundup.psfhosted.org>
Message-ID: <1546874169.72.0.315242220568.issue35624@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 10:17:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:17:28 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1546874248.43.0.301504696878.issue35381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: Heap-allocated posixmodule types -> posixmodule: convert statically allocated types (DirEntryType & ScandirIteratorType) to heap-allocated  types

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

From report at bugs.python.org  Mon Jan  7 10:23:53 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Mon, 07 Jan 2019 15:23:53 +0000
Subject: [issue30170] "tests may fail,
 unable to create temporary directory" warning on buildbot: add a
 cleanup step to buildbots
In-Reply-To: <1493212642.62.0.333467089335.issue30170@psf.upfronthosting.co.za>
Message-ID: <1546874633.9.0.538607982914.issue30170@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

I got this error trying to build Python 3.6.7, why is this closed?

Running PGInstrument|x64 interpreter...
E:\RepoGiT\3.6\lib\test\support\__init__.py:1029: RuntimeWarning: tests may fail, unable to create temp dir: D:\Users\yorch\AppData\Local\Temp\test_python_15660
  with temp_dir(path=name, quiet=quiet) as temp_path:
Run tests sequentially

----------
nosy: +neyuru

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

From report at bugs.python.org  Mon Jan  7 10:24:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:24:40 +0000
Subject: [issue35550] Some define guards for Solaris are wrong
In-Reply-To: <1545386883.42.0.788709270274.issue35550@psf.upfronthosting.co.za>
Message-ID: <1546874680.28.0.145838601138.issue35550@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Do you want to fix the 2.7 branch as well?

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 10:25:29 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Mon, 07 Jan 2019 15:25:29 +0000
Subject: [issue30170] "tests may fail,
 unable to create temporary directory" warning on buildbot: add a
 cleanup step to buildbots
In-Reply-To: <1493212642.62.0.333467089335.issue30170@psf.upfronthosting.co.za>
Message-ID: <1546874729.3.0.181560303527.issue30170@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

May I add that this directory exists, maybe before this run tried to create it and hence not being able to do it as the first post suggested?

----------

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

From report at bugs.python.org  Mon Jan  7 10:26:01 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 15:26:01 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546874761.69.0.155895373834.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +10931

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

From report at bugs.python.org  Mon Jan  7 10:26:12 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 15:26:12 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546874772.89.0.195604188776.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +10931, 10932

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

From report at bugs.python.org  Mon Jan  7 10:26:22 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Jan 2019 15:26:22 +0000
Subject: [issue35560] format(float(123), "00") causes segfault in debug builds
In-Reply-To: <1545474042.87.0.98272194251.issue35560@roundup.psfhosted.org>
Message-ID: <1546874782.78.0.993272605841.issue35560@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9a413faa8708e5c2df509e97d48f18685c198b24 by Miss Islington (bot) in branch '3.7':
bpo-35560: Remove assertion from format(float, "n") (GH-11288)
https://github.com/python/cpython/commit/9a413faa8708e5c2df509e97d48f18685c198b24


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Jan  7 10:26:24 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 15:26:24 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546874784.89.0.829469743654.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +10931, 10932, 10933

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

From report at bugs.python.org  Mon Jan  7 10:27:38 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 07 Jan 2019 15:27:38 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546874858.28.0.3226018912.issue35665@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The certs are coming from Windows' trust store. Could you please dump the trust store for me and attach the result to the bug tracker. The following script is untested but should work. I don't have access to a Windows machine at the moment.

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS)
certs = []
for storename in ("CA", "ROOT"):
    certs.append(storename)
    for cert, encoding, trust in ssl.enum_certificates(storename):
        if encoding == "x509_asn":
            if trust is True or ssl.Purpose.SERVER_AUTH.oid in trust:
                try:
                    ctx.load_verify_locations(cadata=cert)
                except Exception as e:
                    certs.append(str(e))
                certs.append(ssl.DER_cert_to_PEM_cert(cert))

with open('cacerts.pem', 'w') as f:
    f.write('\n'.join(certs))

----------

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

From report at bugs.python.org  Mon Jan  7 10:27:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:27:54 +0000
Subject: [issue35560] format(float(123), "00") causes segfault in debug builds
In-Reply-To: <1545474042.87.0.98272194251.issue35560@roundup.psfhosted.org>
Message-ID: <1546874874.66.0.612497048852.issue35560@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Karthikeyan Singaravelan for the bug report and the fix!

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

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

From report at bugs.python.org  Mon Jan  7 10:28:14 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 07 Jan 2019 15:28:14 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1546874894.94.0.00757865181468.issue35283@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@vstinner
Thanks, I've submitted PR 11459 for 3.7 which emit PendingDeprecationWarning.

----------

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

From report at bugs.python.org  Mon Jan  7 10:43:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:43:13 +0000
Subject: [issue35218] decompressing and then re-compressing zipfiles with
 Python 3 zipfile loses flag_bits
In-Reply-To: <1542033501.3.0.788709270274.issue35218@psf.upfronthosting.co.za>
Message-ID: <1546875793.19.0.945982632167.issue35218@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hi,

> I'm unable to fill in your contributor agreement form

Is there a specific reason why you cannot fill it?

If you cannot cannot fill it, can someone else convert your patch into a PR?

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 10:43:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:43:58 +0000
Subject: [issue31450] Subprocess exceptions re-raised in parent process do not
 have child_traceback attribute
In-Reply-To: <1505305550.33.0.881104489386.issue31450@psf.upfronthosting.co.za>
Message-ID: <1546875838.0.0.992551357624.issue31450@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Jan  7 10:47:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 15:47:11 +0000
Subject: [issue34522] PyTypeObject's tp_base initialization bug
In-Reply-To: <1535401541.74.0.56676864532.issue34522@psf.upfronthosting.co.za>
Message-ID: <1546876031.82.0.0831204914486.issue34522@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  7 11:06:47 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 07 Jan 2019 16:06:47 +0000
Subject: [issue35671] reserved identifier violation
In-Reply-To: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>
Message-ID: <1546877207.23.0.904415831854.issue35671@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

See: <https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier>

Basically all names starting with double underscores are reserved for the implementation in C++. Likewise for all names starting with an underscore when defining globals (such as function names).

IIRC C has similar rules for double underscores and for underscore followed by an uppercase letter, but I don't have a handy reference for those.

In general Python's use of these symbols should be safe enough, it is highly unlikely that a C/C++ implementation uses names starting with "_Py" even if those are reserved for the implementation.

@elfring: Do you run into actual problems due to Python's use of these identifiers?

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Mon Jan  7 11:13:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 16:13:04 +0000
Subject: [issue35671] reserved identifier violation
In-Reply-To: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>
Message-ID: <1546877584.32.0.113912827491.issue35671@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

__DYNAMIC_ANNOTATIONS_H__ can be replaced with PY_DYNAMIC_ANNOTATIONS_H.

I don't understand why _Py_memory_order and only _Py_memory_order is a problem. We have tons of symbols starting with _Py: functions, defines, variables, etc.

----------

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

From report at bugs.python.org  Mon Jan  7 11:26:56 2019
From: report at bugs.python.org (MaximilianSP)
Date: Mon, 07 Jan 2019 16:26:56 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1546878416.95.0.646615068004.issue35678@roundup.psfhosted.org>


MaximilianSP <maximilian.sprengel at bam.de> added the comment:

Thank you for the input Victor. I will need a little time to dig in the code and check the attributes. I am fairly new to python :)

You are right that the code doesn't crash. Just I cannot continue with the following steps. That is why I thought it crashed.

----------

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

From report at bugs.python.org  Mon Jan  7 11:38:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Jan 2019 16:38:44 +0000
Subject: [issue35664] Optimize itemgetter()
In-Reply-To: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>
Message-ID: <1546879124.38.0.11806878007.issue35664@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 2d53bed79c1953390f85b191c72855e457e09305 by Raymond Hettinger in branch 'master':
bpo-35664: Optimize operator.itemgetter (GH-11435)
https://github.com/python/cpython/commit/2d53bed79c1953390f85b191c72855e457e09305


----------

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

From report at bugs.python.org  Mon Jan  7 11:39:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Jan 2019 16:39:30 +0000
Subject: [issue35664] Optimize itemgetter()
In-Reply-To: <1546665476.73.0.183501211971.issue35664@roundup.psfhosted.org>
Message-ID: <1546879170.6.0.810449274646.issue35664@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  7 11:41:06 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 07 Jan 2019 16:41:06 +0000
Subject: [issue35680] [2.7] Coverity scan: Passing freed pointer "name" as an
 argument to "Py_BuildValue" in _bsddb module.
Message-ID: <1546879265.59.0.976013250068.issue35680@roundup.psfhosted.org>


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

Results from a recent static analysis scan for python2:

Error: USE_AFTER_FREE (CWE-825):
Python-2.7.15/Modules/_bsddb.c:6697: freed_arg: "free" frees "name".
Python-2.7.15/Modules/_bsddb.c:6715: pass_freed_arg: Passing freed pointer "name" as an argument to "Py_BuildValue".

6713|       RETURN_IF_ERR();  /* Maybe the size is not the problem */
6714|   
6715|->     retval = Py_BuildValue("s", name);
6716|       free(name);
6717|       return retval;

Attaching a draft patch.

----------
components: Extension Modules
files: bsddb_fix.patch
keywords: patch
messages: 333176
nosy: cstratak
priority: normal
severity: normal
status: open
title: [2.7] Coverity scan: Passing freed pointer "name" as an argument to "Py_BuildValue" in _bsddb module.
versions: Python 2.7
Added file: https://bugs.python.org/file48028/bsddb_fix.patch

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

From report at bugs.python.org  Mon Jan  7 12:03:23 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jan 2019 17:03:23 +0000
Subject: [issue35680] [2.7] Coverity scan: Passing freed pointer "name" as an
 argument to "Py_BuildValue" in _bsddb module.
In-Reply-To: <1546879265.59.0.976013250068.issue35680@roundup.psfhosted.org>
Message-ID: <1546880603.63.0.984312221563.issue35680@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is no bug here. "name" is freed only when err == EINVAL. And the RETURN_IF_ERR() macro will return from the function if err != 0. So that a freed pointer will never passed to Py_BuildValue().

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

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

From report at bugs.python.org  Mon Jan  7 12:19:03 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 07 Jan 2019 17:19:03 +0000
Subject: [issue35680] [2.7] Coverity scan: Passing freed pointer "name" as an
 argument to "Py_BuildValue" in _bsddb module.
In-Reply-To: <1546879265.59.0.976013250068.issue35680@roundup.psfhosted.org>
Message-ID: <1546881543.53.0.823001598487.issue35680@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Indeed it's not a bug per se, more like code readability issue, if however it's not deemed as an issue, it can be closed.

----------

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

From report at bugs.python.org  Mon Jan  7 12:44:27 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 07 Jan 2019 17:44:27 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546872413.86.0.767569575645.issue35633@roundup.psfhosted.org>
Message-ID: <a605d463-9e09-bd0a-307c-372fde56113f@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 07/01/2019 15:46, STINNER Victor wrote:
> STINNER Victor <vstinner at redhat.com> added the comment:
>
> Since you are getting indentation error, I'm not sure about your test. Can you please apply the patch below and run again test_eintr? Does it still fail with PermissionError?

I was clearly a bit blind.. Now with:

? +490? class FNTLEINTRTest(EINTRBaseTest):
? +491????? def _lock(self, lock_func, lock_name):
? +492????????? self.addCleanup(support.unlink, support.TESTFN)
? +493????????? code = '\n'.join((
? +494????????????? "import fcntl, time",
? +495????????????? "with open('%s', 'w+b') as f:" % support.TESTFN,
? +496????????????? "?? fcntl.%s(f, fcntl.LOCK_EX)" % lock_name,
? +497????????????? "?? time.sleep(%s)" % self.sleep_time))
? +498????????? start_time = time.monotonic()
? +499????????? proc = self.subprocess(code)
? +500????????? with kill_on_error(proc):
? +501????????????? with open(support.TESTFN, 'w+b') as f:
? +502????????????????? while True:? # synchronize the subprocess
? +503????????????????????? dt = time.monotonic() - start_time
? +504????????????????????? if dt > 60.0:
? +505????????????????????????? raise Exception("failed to sync child in
%.1f sec" % dt)
? +506????????????????????? try:
? +507????????????????????????? lock_func(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
? +508????????????????????????? lock_func(f, fcntl.LOCK_UN)
? +509????????????????????????? time.sleep(0.01)
? +510????????????????????? except BlockingIOError:
? +511????????????????????????? break

I get - PermissionError - as before.

root at x066:[/data/prj/python/python3-3.8]./python -m test -v test_eintr
== CPython 3.8.0a0 (heads/master-dirty:b4ea8bb080, Jan 1 2019, 18:24:36) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /data/prj/python/python3-3.8/build/test_python_3342514
== CPU count: 8
== encodings: locale=ISO8859-1, FS=iso8859-1
Run tests sequentially
0:00:00 [1/1] test_eintr
test_all (test.test_eintr.EINTRTests) ...
--- run eintr_tester.py ---
test_flock (__main__.FNTLEINTRTest) ... ok
test_lockf (__main__.FNTLEINTRTest) ... ERROR
test_read (__main__.OSEINTRTest) ... ok
test_wait (__main__.OSEINTRTest) ... ok
test_wait3 (__main__.OSEINTRTest) ... ok
test_wait4 (__main__.OSEINTRTest) ... ok
test_waitpid (__main__.OSEINTRTest) ... ok
test_write (__main__.OSEINTRTest) ... ok
test_devpoll (__main__.SelectEINTRTest) ... skipped 'need select.devpoll'
test_epoll (__main__.SelectEINTRTest) ... skipped 'need select.epoll'
test_kqueue (__main__.SelectEINTRTest) ... skipped 'need select.kqueue'
test_poll (__main__.SelectEINTRTest) ... ok
test_select (__main__.SelectEINTRTest) ... ok
test_sigtimedwait (__main__.SignalEINTRTest) ... ok
test_sigwaitinfo (__main__.SignalEINTRTest) ... ok
test_accept (__main__.SocketEINTRTest) ... ok
test_open (__main__.SocketEINTRTest) ... ok
test_os_open (__main__.SocketEINTRTest) ... ok
test_recv (__main__.SocketEINTRTest) ... ok
test_recvmsg (__main__.SocketEINTRTest) ... ok
test_send (__main__.SocketEINTRTest) ... ok
test_sendall (__main__.SocketEINTRTest) ... ok
test_sendmsg (__main__.SocketEINTRTest) ... ok
test_sleep (__main__.TimeEINTRTest) ... ok

======================================================================
ERROR: test_lockf (__main__.FNTLEINTRTest)
----------------------------------------------------------------------
Traceback (most recent call last):
? File
"/data/prj/python/git/python3-3.8/Lib/test/eintrdata/eintr_tester.py",
line 522, in test_lockf
??? self._lock(fcntl.lockf, "lockf")
? File
"/data/prj/python/git/python3-3.8/Lib/test/eintrdata/eintr_tester.py",
line 507, in _lock
??? lock_func(f, fcntl.LOCK_EX | fcntl.LOCK_NB)
PermissionError: [Errno 13] Permission denied

----------------------------------------------------------------------
Ran 24 tests in 9.098s

FAILED (errors=1, skipped=3)
--- eintr_tester.py completed: exit code 1 ---
FAIL

======================================================================
FAIL: test_all (test.test_eintr.EINTRTests)
----------------------------------------------------------------------
Traceback (most recent call last):
? File "/data/prj/python/git/python3-3.8/Lib/test/test_eintr.py", line
31, in test_all
??? self.fail("eintr_tester.py failed")
AssertionError: eintr_tester.py failed

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

Ran 1 test in 9.674s

FAILED (failures=1)
test test_eintr failed
test_eintr failed

== Tests result: FAILURE ==

>
> diff --git a/Lib/test/eintrdata/eintr_tester.py b/Lib/test/eintrdata/eintr_tester.py
> index 25c169bde5..4db5dc9045 100644
> --- a/Lib/test/eintrdata/eintr_tester.py
> +++ b/Lib/test/eintrdata/eintr_tester.py
> @@ -492,13 +492,13 @@ class FNTLEINTRTest(EINTRBaseTest):
>          self.addCleanup(support.unlink, support.TESTFN)
>          code = '\n'.join((
>              "import fcntl, time",
> -            "with open('%s', 'wb') as f:" % support.TESTFN,
> +            "with open('%s', 'w+b') as f:" % support.TESTFN,
>              "   fcntl.%s(f, fcntl.LOCK_EX)" % lock_name,
>              "   time.sleep(%s)" % self.sleep_time))
>          start_time = time.monotonic()
>          proc = self.subprocess(code)
>          with kill_on_error(proc):
> -            with open(support.TESTFN, 'wb') as f:
> +            with open(support.TESTFN, 'w+b') as f:
>                  while True:  # synchronize the subprocess
>                      dt = time.monotonic() - start_time
>                      if dt > 60.0:
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35633>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jan  7 12:51:53 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Jan 2019 17:51:53 +0000
Subject: [issue35672] Error on divide
In-Reply-To: <1546778042.38.0.180444315145.issue35672@roundup.psfhosted.org>
Message-ID: <1546883513.05.0.943376742406.issue35672@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

For reference, the OP reported the issue initially at https://github.com/python/psf-infra-meta/issues/17 (but it was closed because that's not the right tracker).

The y1y2y3y4 etc. are multiplications (mangled by not quoting the code in GitHub and then copy/paste from the rendered code).

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

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

From report at bugs.python.org  Mon Jan  7 13:44:27 2019
From: report at bugs.python.org (=?utf-8?q?Vladimir_Peri=C4=87?=)
Date: Mon, 07 Jan 2019 18:44:27 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546886667.93.0.838804343391.issue35665@roundup.psfhosted.org>


Vladimir Peri? <pervlad at gmail.com> added the comment:

Public Certificate file cert.pem is attached.

Version of ssl lib in pythons on my machine:
Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.1.0j  20 Nov 2018'

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2q  20 Nov 2018'

----------
Added file: https://bugs.python.org/file48029/cacerts.pem

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

From report at bugs.python.org  Mon Jan  7 14:50:07 2019
From: report at bugs.python.org (Markus Elfring)
Date: Mon, 07 Jan 2019 19:50:07 +0000
Subject: [issue35671] reserved identifier violation
In-Reply-To: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>
Message-ID: <1546890607.33.0.85107444447.issue35671@roundup.psfhosted.org>


Markus Elfring <elfring at users.sourceforge.net> added the comment:

* How do you think about to reduce the tampering with the reserved name space in mentioned source code (and also in related components)?
* Would you like to avoid that this software depends on undefined behaviour?

----------

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

From report at bugs.python.org  Mon Jan  7 14:53:42 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 07 Jan 2019 19:53:42 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546890822.62.0.386984330604.issue35665@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Your Windows cert store contains multiple invalid certificates. The first failing certificate is the custom "MUPCA Root", which looks like a certificate from http://ca.mup.gov.rs/sertifikati.html. The serial number seems to be badly formated or padded. There is nothing we can do about erroneous and bad certificates.

$ openssl x509 -in ca.pem 
unable to load certificate
140613019477824:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal padding:crypto/asn1/a_int.c:187:
140613019477824:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:627:Field=serialNumber, Type=X509_CINF
140613019477824:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:627:Field=cert_info, Type=X509
140613019477824:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:crypto/pem/pem_oth.c:33:

$ openssl asn1parse -in ca.pem  
    0:d=0  hl=4 l=1300 cons: SEQUENCE          
    4:d=1  hl=4 l= 764 cons: SEQUENCE          
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim: INTEGER           :02
   13:d=2  hl=2 l=   4 prim: INTEGER           :BAD INTEGER:[00000066]
   19:d=2  hl=2 l=  13 cons: SEQUENCE          
   21:d=3  hl=2 l=   9 prim: OBJECT            :sha1WithRSAEncryption
   32:d=3  hl=2 l=   0 prim: NULL              
   34:d=2  hl=2 l=  83 cons: SEQUENCE          
   36:d=3  hl=2 l=  19 cons: SET               
   38:d=4  hl=2 l=  17 cons: SEQUENCE          
   40:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   45:d=5  hl=2 l=  10 prim: UTF8STRING        :MUPCA Root
   57:d=3  hl=2 l=  29 cons: SET               
   59:d=4  hl=2 l=  27 cons: SEQUENCE          
   61:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   66:d=5  hl=2 l=  20 prim: UTF8STRING        :MUP Republike Srbije
   88:d=3  hl=2 l=  16 cons: SET               
   90:d=4  hl=2 l=  14 cons: SEQUENCE          
   92:d=5  hl=2 l=   3 prim: OBJECT            :localityName
   97:d=5  hl=2 l=   7 prim: UTF8STRING        :Beograd
  106:d=3  hl=2 l=  11 cons: SET               
  108:d=4  hl=2 l=   9 cons: SEQUENCE          
  110:d=5  hl=2 l=   3 prim: OBJECT            :countryName
  115:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :RS
  119:d=2  hl=2 l=  30 cons: SEQUENCE          
  121:d=3  hl=2 l=  13 prim: UTCTIME           :100227161918Z
  136:d=3  hl=2 l=  13 prim: UTCTIME           :200227161918Z
  ...

$ wget http://ca.mup.gov.rs/MUPCARoot.crt
$ openssl x509 -in MUPCARoot.crt -inform DER
unable to load certificate
140699773712192:error:0D0E20DD:asn1 encoding routines:c2i_ibuf:illegal padding:crypto/asn1/a_int.c:187:
140699773712192:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:627:Field=serialNumber, Type=X509_CINF
140699773712192:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:627:Field=cert_info, Type=X509

----------

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

From report at bugs.python.org  Mon Jan  7 15:05:02 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 07 Jan 2019 20:05:02 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546891502.33.0.677357529496.issue35665@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

OpenSSL 1.1.0 is more strict than OpenSSL 1.0.2. That's why you don't see the issue with Python 3.6 but with 3.7. The problem is explained in https://mta.openssl.org/pipermail/openssl-dev/2016-February/005100.html

The CA has encoded the integer 102 (0x66) as "02 04 00
00 00 66", which violates the DER standard. The correct encoding is "02 01  66".

>>> from asn1crypto.core import Integer
>>> import binascii
>>> binascii.hexlify(Integer(102).dump())
b'020166'

----------

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

From report at bugs.python.org  Mon Jan  7 15:26:02 2019
From: report at bugs.python.org (Arthur Goldberg)
Date: Mon, 07 Jan 2019 20:26:02 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1546892762.45.0.746267910335.issue2506@roundup.psfhosted.org>


Arthur Goldberg <arthur.goldberg at mssm.edu> added the comment:

This issue is well into the 2nd decade of debate.

Who has the power to effect this change?

Happy New Year
Arthur

----------

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

From report at bugs.python.org  Mon Jan  7 15:33:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Jan 2019 20:33:44 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546893224.4.0.883944337424.issue32592@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

AFAIK, it was specifically Martin Loewis who did not want a specific list in PEP 11.  Since he is long inactive, I think you and Steve should feel free to change that.

----------

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

From report at bugs.python.org  Mon Jan  7 17:32:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:32:51 +0000
Subject: [issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes
In-Reply-To: <1527774159.9.0.682650639539.issue33717@psf.upfronthosting.co.za>
Message-ID: <1546900371.56.0.303421671829.issue33717@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10934

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

From report at bugs.python.org  Mon Jan  7 17:32:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:32:57 +0000
Subject: [issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes
In-Reply-To: <1527774159.9.0.682650639539.issue33717@psf.upfronthosting.co.za>
Message-ID: <1546900377.6.0.638356009532.issue33717@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10934, 10935

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

From report at bugs.python.org  Mon Jan  7 17:33:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:33:03 +0000
Subject: [issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes
In-Reply-To: <1527774159.9.0.682650639539.issue33717@psf.upfronthosting.co.za>
Message-ID: <1546900383.21.0.447805220154.issue33717@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10934, 10935, 10936

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

From report at bugs.python.org  Mon Jan  7 17:35:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:35:08 +0000
Subject: [issue32710] test_asyncio:
 ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving()
 leaked [4, 4, 3] memory blocks on AMD64 Windows8.1 Refleaks 3.x
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546900508.58.0.537758347189.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +10937
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 17:35:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:35:15 +0000
Subject: [issue32710] test_asyncio:
 ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving()
 leaked [4, 4, 3] memory blocks on AMD64 Windows8.1 Refleaks 3.x
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546900515.6.0.090902540952.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +10937, 10938
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 17:35:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:35:24 +0000
Subject: [issue32710] test_asyncio:
 ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving()
 leaked [4, 4, 3] memory blocks on AMD64 Windows8.1 Refleaks 3.x
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546900524.19.0.266447497666.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10937, 10938, 10939
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 17:46:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Jan 2019 22:46:25 +0000
Subject: [issue32592] Drop support of Windows Vista in Python 3.7
In-Reply-To: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>
Message-ID: <1546901185.01.0.103910368075.issue32592@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I'd rather leave it specified as it is in PEP 11, though perhaps specifying it explicitly in the release schedule PEPs would be helpful? Up to release managers.

----------

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

From report at bugs.python.org  Mon Jan  7 17:56:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jan 2019 22:56:10 +0000
Subject: [issue32710] test_asyncio:
 ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving()
 leaked [4, 4, 3] memory blocks on AMD64 Windows8.1 Refleaks 3.x
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546901770.12.0.821297254976.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset df8e1fb4e388e18430a9be8c6ceeb03c330f166c by Victor Stinner in branch 'master':
bpo-32710: test_asyncio: test_sendfile reset policy (GH-11461)
https://github.com/python/cpython/commit/df8e1fb4e388e18430a9be8c6ceeb03c330f166c


----------

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

From report at bugs.python.org  Mon Jan  7 18:09:04 2019
From: report at bugs.python.org (Tatz Sekine)
Date: Mon, 07 Jan 2019 23:09:04 +0000
Subject: [issue35681] urllib.request.HTTPPasswordMgr.add_password requires
 more information for HTTPPasswordMgrWithDefaultRealm
Message-ID: <1546902543.15.0.573868900421.issue35681@roundup.psfhosted.org>


New submission from Tatz Sekine <tsekine at google.com>:

TL;DR
  HTTPPasswordMgrWithDefaultRealm.add_password() doesn't have proper documentation.

All known version of urllib.request (or urllib2 in Python 2.x) documentaion have the same issue.

Details:

HTTPPasswordMgrWithDefaultRealm object doesn't have its own documentation. Instead of that, HTTPPasswordMgr's doc have information for those 2 objects:
https://docs.python.org/3.8/library/urllib.request.html?highlight=httppasswordmgr#http-password-mgr

Both objects have just 2 functions: add_password() and find_user_password(). The doc for find_user_password() has explanation how different between those 2 objects, while the one for add_password() doesn't.

One of the missing explanation for HTTPPasswordMgrWithDefaultRealm.add_passowrd() is the value of realm. The document has now "realm, user and passwd must be strings.", but realm could be None for HTTPPasswordMgrWithDefaultRealm, to set default realm-less password.

That's typical use case of HTTPPasswordMgrWithDefaultRealm.add_password(), or, that's exactly urllib howto doc mentions in
 https://docs.python.org/3.8/howto/urllib2.html?highlight=httppasswordmgrwithdefaultrealm

Conclusion:

So, documentation of HTTPPasswordMgr.add_passoword() should have additional explanation for realm which could be None for HTTPPasswordMgrWithDefaultRealm. Or, HTTPPasswordMgrWithDefaultRealm objects could have independent section from HTTPPasswordMgr, to clarify its usage.

Why is this matter?
  Typeshed (https://github.com/python/typeshed) depends on the doc. I (or somebody else in the company) will report it separately.

----------
assignee: docs at python
components: Documentation
messages: 333189
nosy: docs at python, tsekine
priority: normal
severity: normal
status: open
title: urllib.request.HTTPPasswordMgr.add_password requires more information for HTTPPasswordMgrWithDefaultRealm
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/issue35681>
_______________________________________

From report at bugs.python.org  Mon Jan  7 19:27:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:27:31 +0000
Subject: [issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes
In-Reply-To: <1527774159.9.0.682650639539.issue33717@psf.upfronthosting.co.za>
Message-ID: <1546907251.3.0.2257502621.issue33717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset ddd7c422fd89a053700f9ed5272cf732ccb09088 by Victor Stinner in branch 'master':
bpo-33717: pythoninfo logs information of all clocks (GH-11460)
https://github.com/python/cpython/commit/ddd7c422fd89a053700f9ed5272cf732ccb09088


----------

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

From report at bugs.python.org  Mon Jan  7 19:48:32 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Tue, 08 Jan 2019 00:48:32 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
In-Reply-To: <1546394840.15.0.0864584726941.issue35635@roundup.psfhosted.org>
Message-ID: <1546908512.18.0.786568541744.issue35635@roundup.psfhosted.org>


Stefan Seefeld <stefan at seefeld.name> added the comment:

OK, so while I have been able to work around the issues (by using `quamash` to bridge between `asyncio` and `Qt`), I'd still like to understand the rationale behind the limitation that any subprocess-managing event-loop has to run in the main thread. Is this really an architectural limitation or a limit of the current implementation ?

And to your question: As I wasn't really expecting such a limitation, I would have expected 
    "To handle signals and to execute subprocesses, the event loop must be run in the main thread."

to be written much more prominently (as a warning admonition even, perhaps).

----------

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

From report at bugs.python.org  Mon Jan  7 19:55:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:55:40 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546908940.51.0.470550600014.issue35682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +10940
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 19:55:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:55:55 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1546908955.88.0.769639252952.issue32622@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10944

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

From report at bugs.python.org  Mon Jan  7 19:55:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:55:55 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546908955.85.0.0476270351731.issue35682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +10940, 10941
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 19:56:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:56:10 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546908970.47.0.974203805887.issue35682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10940, 10941, 10943
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 19:56:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:56:24 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546908984.14.0.478236128604.issue35682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +10940, 10941, 10942, 10943
stage:  -> patch review

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

From report at bugs.python.org  Mon Jan  7 19:58:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:58:10 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546909090.18.0.181343247813.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_asyncio: ProactorEventLoopTests.test_sendfile_close_peer_in_middle_of_receiving() leaked [4, 4, 3] memory blocks on AMD64 Windows8.1 Refleaks 3.x -> test_asyncio: ProactorEventLoopTests sendfile tests leak references on Windows

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

From report at bugs.python.org  Mon Jan  7 19:50:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 00:50:49 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
Message-ID: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>


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

Running ProactorEventLoopTests.test_sendfile_close_peer_in_the_middle_of_receiving() logs a bug in _force_close(): see logs below. Extract of _force_close():

    def _force_close(self, exc):
        if self._empty_waiter is not None:
            if exc is None:
                self._empty_waiter.set_result(None)
            else:
                self._empty_waiter.set_exception(exc)
        ...

Problem: _empty_waiter can be already done. For example, it can be created directly as done:

    def _make_empty_waiter(self):
        ...
        self._empty_waiter = self._loop.create_future()
        if self._write_fut is None:
            self._empty_waiter.set_result(None)
        return self._empty_waiter

Attached PR fixes _force_close(): do nothing if _empty_waiter is already done.

The regression comes from the following change:

commit a19fb3c6aaa7632410d1d9dcb395d7101d124da4
Author: Andrew Svetlov <andrew.svetlov at gmail.com>
Date:   Sun Feb 25 19:32:14 2018 +0300

    bpo-32622: Native sendfile on windows (#5565)
    
    * Support sendfile on Windows Proactor event loop naively.


Logs:

vstinner at WIN C:\vstinner\python\master>python -X dev -m test test_asyncio -m test.test_asyncio.test_sendfile.ProactorEventLoopTests.test_sendfile_close_peer_in_the_middle_of_receiving
Running Debug|x64 interpreter...
Run tests sequentially 
0:00:00 [1/1] test_asyncio 
Exception in callback _ProactorReadPipeTransport._loop_reading(<_OverlappedF...events.py:452>) 
handle: <Handle _ProactorReadPipeTransport._loop_reading(<_OverlappedF...events.py:452>) created at C:\vstinner\python\master\lib\asyncio\windows_events.py:82>
source_traceback: Object created at (most recent call last):
  File "C:\vstinner\python\master\lib\test\test_asyncio\test_sendfile.py", line 125, in run_loop
    return self.loop.run_until_complete(coro)
  File "C:\vstinner\python\master\lib\asyncio\base_events.py", line 576, in run_until_complete
    self.run_forever()
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 315, in run_forever
    super().run_forever()
  File "C:\vstinner\python\master\lib\asyncio\base_events.py", line 544, in run_forever
    self._run_once()
  File "C:\vstinner\python\master\lib\asyncio\base_events.py", line 1729, in _run_once
    event_list = self._selector.select(timeout)
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 421, in select
    self._poll(timeout)
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 750, in _poll
    f.set_exception(e)
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 82, in set_exception
    super().set_exception(exception)
Traceback (most recent call last):
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 444, in finish_recv
    return ov.getresult()
OSError: [WinError 64] The specified network name is no longer available

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\vstinner\python\master\lib\asyncio\proactor_events.py", line 256, in _loop_reading
    data = fut.result()
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 748, in _poll
    value = callback(transferred, key, ov)
  File "C:\vstinner\python\master\lib\asyncio\windows_events.py", line 448, in finish_recv
    raise ConnectionResetError(*exc.args)
ConnectionResetError: [WinError 64] The specified network name is no longer available

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\vstinner\python\master\lib\asyncio\events.py", line 81, in _run
    self._context.run(self._callback, *self._args)
  File "C:\vstinner\python\master\lib\asyncio\proactor_events.py", line 283, in _loop_reading
    self._force_close(exc)
  File "C:\vstinner\python\master\lib\asyncio\proactor_events.py", line 118, in _force_close
    self._empty_waiter.set_exception(exc)
asyncio.exceptions.InvalidStateError: invalid state

== Tests result: SUCCESS ==

1 test OK.

Total duration: 531 ms
Tests result: SUCCESS

----------
components: Windows, asyncio
messages: 333192
nosy: asvetlov, paul.moore, steve.dower, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: asyncio: bug in _ProactorBasePipeTransport._force_close()
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Jan  7 20:08:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 01:08:40 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546909720.17.0.329043242319.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Update:

* test.test_asyncio.test_sendfile.ProactorEventLoopTests.test_sendfile_close_peer_in_the_middle_of_receiving leaks 1 reference per run: this bug is caused by bpo-35682 and fixed by PR 11462
* test.test_asyncio.test_sendfile.ProactorEventLoopTests.test_sendfile_fallback_close_peer_in_the_middle_of_receiving leaks 1 reference per run: I don't understand why.

I spent a lot of time to investigate test_sendfile_fallback_close_peer_in_the_middle_of_receiving() leak and I don't understand the issue. The main loop is BaseEventLoop._sendfile_fallback(). For the specific case of this test, the loop can be simplified to:

        proto = _SendfileFallbackProtocol(transp)
        try:
            while True:
                data = b'x' * (1024 * 64)
                await proto.drain()
                transp.write(data)
        finally:
            await proto.restore()

The server closes the connection after it gets 1024 bytes. The client socket gets a ConnectionAbortedError exception in _ProactorBaseWritePipeTransport._loop_writing() which calls _fatal_error():

        except OSError as exc:
            self._fatal_error(exc, 'Fatal write error on pipe transport')

_fatal_error() calls _force_close() which sets _closing to True and calls protocol.connection_lost(). In the meanwhile, drain() raises ConnectionError because is_closing() is true:

    async def drain(self):
        if self._transport.is_closing():
            raise ConnectionError("Connection closed by peer")
        ...

----------

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

From report at bugs.python.org  Mon Jan  7 20:27:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 01:27:21 +0000
Subject: [issue35642] _asynciomodule.c compiled in both pythoncore.vcxproj and
 _asyncio.vcxproj
In-Reply-To: <1546452351.49.0.287032771837.issue35642@roundup.psfhosted.org>
Message-ID: <1546910841.89.0.523856926802.issue35642@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset fbf50683b3a2301097d5cd48bc68b530c1e1720f by Steve Dower (Gregory Szorc) in branch 'master':
bpo-35642: Remove asynciomodule.c from pythoncore.vcxproj (GH-11410)
https://github.com/python/cpython/commit/fbf50683b3a2301097d5cd48bc68b530c1e1720f


----------
nosy: +steve.dower

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

From report at bugs.python.org  Mon Jan  7 20:27:38 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 08 Jan 2019 01:27:38 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
In-Reply-To: <1546394840.15.0.0864584726941.issue35635@roundup.psfhosted.org>
Message-ID: <1546910858.5.0.924059982783.issue35635@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The limitation is a consequence of how Linux works.
Unix has no cross-platform API for non-blocking waiting for child process finish except handling SIGCHILD signal.

On the other hand signal handlers in Python should work in the main thread.

Your trick with a loop creation in the main thread and actual running in another thread can work, but asyncio doesn't guarantee it.
The behavior can be broken in next releases, sorry.

IIRC we discussed this scenario recently, official support for transferring a loop between threads is a too strict limitation, not all third-party implementations are ready for that.

----------

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

From report at bugs.python.org  Mon Jan  7 20:47:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 01:47:11 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1546912031.63.0.848217889889.issue32622@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 80fda712c83f5dd9560d42bf2aa65a72b18b7759 by Victor Stinner in branch 'master':
bpo-35682: Fix _ProactorBasePipeTransport._force_close() (GH-11462)
https://github.com/python/cpython/commit/80fda712c83f5dd9560d42bf2aa65a72b18b7759


----------

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

From report at bugs.python.org  Mon Jan  7 20:47:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 01:47:23 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546912043.08.0.0449612182996.issue35682@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 80fda712c83f5dd9560d42bf2aa65a72b18b7759 by Victor Stinner in branch 'master':
bpo-35682: Fix _ProactorBasePipeTransport._force_close() (GH-11462)
https://github.com/python/cpython/commit/80fda712c83f5dd9560d42bf2aa65a72b18b7759


----------

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

From report at bugs.python.org  Mon Jan  7 20:48:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 01:48:44 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546912124.54.0.915212430392.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Interesting commit. No idea if it's related.

commit 79790bc35fe722a49977b52647f9b5fe1deda2b7
Author: Victor Stinner <vstinner at redhat.com>
Date:   Fri Jun 8 00:25:52 2018 +0200

    bpo-33694: Fix race condition in asyncio proactor (GH-7498)
    
    The cancellation of an overlapped WSARecv() has a race condition
    which causes data loss because of the current implementation of
    proactor in asyncio.
    
    No longer cancel overlapped WSARecv() in _ProactorReadPipeTransport
    to work around the race condition.
    
    Remove the optimized recv_into() implementation to get simple
    implementation of pause_reading() using the single _pending_data
    attribute.
    
    Move _feed_data_to_bufferred_proto() to protocols.py.
    
    Remove set_protocol() method which became useless.

----------

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

From report at bugs.python.org  Mon Jan  7 20:54:28 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Tue, 08 Jan 2019 01:54:28 +0000
Subject: [issue35635] asyncio.create_subprocess_exec() only works in main
 thread
In-Reply-To: <1546910858.5.0.924059982783.issue35635@roundup.psfhosted.org>
Message-ID: <6c654727-4b7f-0074-9211-6c02337731a5@seefeld.name>


Stefan Seefeld <stefan at seefeld.name> added the comment:

> The limitation is a consequence of how Linux works.
> Unix has no cross-platform API for non-blocking waiting for child process finish except handling SIGCHILD signal.

Why does the `wait()` have to be non-blocking ? We can call it once in 
response to the reception of a `SIGCHILD`, where we know the call 
wouldn't block. Then we can pass the `pid` to whatever event loop 
created the subprocess to do the cleanup there...

> On the other hand signal handlers in Python should work in the main thread.

That's fine.

> Your trick with a loop creation in the main thread and actual running in another thread can work, but asyncio doesn't guarantee it.
> The behavior can be broken in next releases, sorry.

Yeah, I observed some strange issues that looked like they could be 
fixed by someone intimately familiar with `asyncio`. But given the 
documented limitation, it seemed wise not to descend into that rabbit 
hole, and so I (at least temporarily) abandoned the entire approach.

--

Stefan

       ...ich hab' noch einen Koffer in Berlin...

----------

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

From report at bugs.python.org  Mon Jan  7 20:54:51 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 01:54:51 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546912491.31.0.00103592170538.issue35682@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10945

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

From report at bugs.python.org  Mon Jan  7 20:55:06 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 01:55:06 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546912506.79.0.401660703125.issue35682@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10945, 10946

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

From report at bugs.python.org  Mon Jan  7 20:55:06 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 01:55:06 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1546912506.81.0.00745656636537.issue32622@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10949

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

From report at bugs.python.org  Mon Jan  7 20:55:21 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 01:55:21 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546912521.47.0.686698578024.issue35682@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10945, 10946, 10947

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

From report at bugs.python.org  Mon Jan  7 20:55:30 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 08 Jan 2019 01:55:30 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546912530.7.0.752213526894.issue35673@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Mon Jan  7 20:55:32 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 01:55:32 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546912532.82.0.296340461064.issue35682@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10945, 10946, 10947, 10948

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

From report at bugs.python.org  Mon Jan  7 20:59:55 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 08 Jan 2019 01:59:55 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546849000.7.0.108946297375.issue35673@roundup.psfhosted.org>
Message-ID: <6C2F367B-4B66-41D2-B164-AB85884BD37E@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 7, 2019, at 03:16, Ronald Oussoren <report at bugs.python.org> wrote:
> 
> Do you know why the namespace package loader lies about the source and code? Both .get_source() and .get_code() return a value that isn't None.

> And likewise: Why is the namespace package loader a private class, other loaders are exposed in importlib.machinery?  This makes it hard to detect PEP420 style namespace packages without relying on private APIs, esp. combined with the behaviour of .get_source() and .get_code().

I don?t remember the history of this.  I wonder if Brett or Eric have any additional insights.

----------

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

From report at bugs.python.org  Mon Jan  7 21:15:28 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 02:15:28 +0000
Subject: [issue32622] Implement loop.sendfile
In-Reply-To: <1517080969.81.0.467229070634.issue32622@psf.upfronthosting.co.za>
Message-ID: <1546913728.42.0.269565766883.issue32622@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 88bd26a72eb4ab341cf19bea78a0039fbe4be3a2 by Miss Islington (bot) in branch '3.7':
bpo-35682: Fix _ProactorBasePipeTransport._force_close() (GH-11462)
https://github.com/python/cpython/commit/88bd26a72eb4ab341cf19bea78a0039fbe4be3a2


----------

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

From report at bugs.python.org  Mon Jan  7 21:15:36 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 02:15:36 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546913736.29.0.945849242776.issue35682@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 88bd26a72eb4ab341cf19bea78a0039fbe4be3a2 by Miss Islington (bot) in branch '3.7':
bpo-35682: Fix _ProactorBasePipeTransport._force_close() (GH-11462)
https://github.com/python/cpython/commit/88bd26a72eb4ab341cf19bea78a0039fbe4be3a2


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Jan  7 21:15:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 02:15:57 +0000
Subject: [issue35682] asyncio: bug in _ProactorBasePipeTransport._force_close()
In-Reply-To: <1546908648.7.0.754492801962.issue35682@roundup.psfhosted.org>
Message-ID: <1546913757.5.0.533783048062.issue35682@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Mon Jan  7 21:26:35 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 02:26:35 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546914395.93.0.502919801731.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Looks like zipimport in 3.7 always rejected CHECKED_HASH pycs, while in 3.8 it always accepts them (or runs it through a validation process that passes them when the source file doesn't exist - I only confirmed by testing a build, not by walking through the new sources).

Rather than changing the old zipimport now, it's more correct to fix the embeddable ZIP build to specify UNCHECKED_HASH.

----------
assignee:  -> steve.dower

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

From report at bugs.python.org  Mon Jan  7 21:31:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 02:31:46 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546914706.0.0.13048092849.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

And I assume now that the reason it broke in 3.7.2 is because the pyc mode for the embeddable distro changed. Which means the right place for tests is in a separate build that uses properly laid out Python rather than testing in the source tree (like what I have in the windows-appx-tests.yml file and Tools/msi/testrelease.bat script, but apparently also for the embeddable distro).

----------

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

From report at bugs.python.org  Mon Jan  7 21:57:35 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 02:57:35 +0000
Subject: [issue35374] Windows doc build does not find autodetected hhc.exe
In-Reply-To: <1543743728.61.0.788709270274.issue35374@psf.upfronthosting.co.za>
Message-ID: <1546916255.03.0.399443171911.issue35374@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset e61cc481e02b758c8d8289163102c236d0658a55 by Steve Dower (chrullrich) in branch 'master':
bpo-35374: Avoid trailing space in hhc file name if found on PATH. (GH-10849)
https://github.com/python/cpython/commit/e61cc481e02b758c8d8289163102c236d0658a55


----------

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

From report at bugs.python.org  Mon Jan  7 21:58:07 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 02:58:07 +0000
Subject: [issue35374] Windows doc build does not find autodetected hhc.exe
In-Reply-To: <1543743728.61.0.788709270274.issue35374@psf.upfronthosting.co.za>
Message-ID: <1546916287.98.0.937813653316.issue35374@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10950

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

From report at bugs.python.org  Mon Jan  7 21:58:19 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 02:58:19 +0000
Subject: [issue35374] Windows doc build does not find autodetected hhc.exe
In-Reply-To: <1543743728.61.0.788709270274.issue35374@psf.upfronthosting.co.za>
Message-ID: <1546916299.87.0.851948786381.issue35374@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10950, 10951

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

From report at bugs.python.org  Mon Jan  7 21:58:23 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 02:58:23 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546916303.6.0.889577127835.issue35596@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +10953
stage: test needed -> patch review

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

From report at bugs.python.org  Mon Jan  7 21:58:29 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 02:58:29 +0000
Subject: [issue35374] Windows doc build does not find autodetected hhc.exe
In-Reply-To: <1543743728.61.0.788709270274.issue35374@psf.upfronthosting.co.za>
Message-ID: <1546916309.99.0.175983814706.issue35374@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10950, 10951, 10952

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

From report at bugs.python.org  Mon Jan  7 21:58:45 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 02:58:45 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546916325.23.0.322700288865.issue35596@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +10953, 10954
stage: test needed -> patch review

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

From report at bugs.python.org  Mon Jan  7 21:59:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 02:59:04 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546916344.84.0.730023152872.issue35596@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +10953, 10954, 10955
stage: test needed -> patch review

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

From report at bugs.python.org  Mon Jan  7 22:04:17 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 03:04:17 +0000
Subject: [issue35374] Windows doc build does not find autodetected hhc.exe
In-Reply-To: <1543743728.61.0.788709270274.issue35374@psf.upfronthosting.co.za>
Message-ID: <1546916657.26.0.319496248337.issue35374@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5d1e0124cf562153a681d1b5b362e7c8e23edea9 by Miss Islington (bot) in branch '3.7':
bpo-35374: Avoid trailing space in hhc file name if found on PATH. (GH-10849)
https://github.com/python/cpython/commit/5d1e0124cf562153a681d1b5b362e7c8e23edea9


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Jan  7 22:07:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 03:07:28 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546916848.8.0.49956933085.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Attached test_aiosend.py is a simplified version of test to trigger the reference leak. Copy it to Lib/test/ and run:

vstinner at WIN C:\vstinner\python\master>python -m test test_aiosend -R 3:3
Running Debug|x64 interpreter...
Run tests sequentially
0:00:00 [1/1] test_aiosend
beginning 6 repetitions
123456
......
test_aiosend leaked [1, 1, 1] references, sum=3
test_aiosend leaked [1, 2, 1] memory blocks, sum=4
test_aiosend failed

== Tests result: FAILURE ==

1 test failed:
    test_aiosend

Total duration: 548 ms
Tests result: FAILURE

----------
Added file: https://bugs.python.org/file48030/test_aiosend.py

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

From report at bugs.python.org  Mon Jan  7 22:11:50 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 08 Jan 2019 03:11:50 +0000
Subject: [issue35550] Some define guards for Solaris are wrong
In-Reply-To: <1545386883.42.0.788709270274.issue35550@psf.upfronthosting.co.za>
Message-ID: <1546917110.86.0.764293414757.issue35550@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
assignee: gregory.p.smith -> 

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

From report at bugs.python.org  Mon Jan  7 22:23:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 03:23:08 +0000
Subject: [issue35374] Windows doc build does not find autodetected hhc.exe
In-Reply-To: <1543743728.61.0.788709270274.issue35374@psf.upfronthosting.co.za>
Message-ID: <1546917788.05.0.0411260749668.issue35374@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Mon Jan  7 23:16:26 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 08 Jan 2019 04:16:26 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1546920986.74.0.806900617856.issue26467@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

Perhaps it's possible to vendor asynctest mock in the same vein as `mock` found it's way into unittest?

The real power of `asynctest` is in constructs like:

with asynctest.mock.patch("module.Class", autospec=True):
    ...

Where mock instances know what methods are async.

----------
nosy: +Dima.Tisnek
versions: +Python 3.8 -Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Jan  7 23:19:13 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 04:19:13 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines
Message-ID: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>


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

Azure Pipelines can now support container jobs: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=vsts&tabs=yaml

I experimented with enabling a manylinux1 build a while back, which should now be able to use identical steps to the POSIX build. With the new syntax, we can enable CI (and perhaps PR?) builds using the snippet below:

- job: ManyLinux1_CI_Tests
  displayName: ManyLinux1 CI Tests
  dependsOn: Prebuild
  condition: |
    and(
        and(
            succeeded(),
            eq(variables['manylinux'], 'true')
        ),
        eq(dependencies.Prebuild.outputs['tests.run'], 'true')
    )

  resources:
    containers:
    - container: manylinux1
      image: dockcross:manylinux-x64

  pool:
    vmImage: ubuntu-16.04

  container: manylinux1

  variables:
    testRunTitle: '$(build.sourceBranchName)-manylinux1'
    testRunPlatform: manylinux1

  steps:
  - template: ./posix-steps.yml


I don't have time right now to test this change, but someone else might. It's certainly going to be easier for someone to test it by adding this to the PR build first (or set up a build on your own Pipelines instance).

Maybe there are other more relevant containers we should be testing in?

----------
components: Cross-Build
messages: 333209
nosy: Alex.Willmer, barry, steve.dower, zach.ware
priority: normal
severity: normal
status: open
title: Enable manylinux1 builds on Pipelines
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Jan  8 00:02:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 08 Jan 2019 05:02:00 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1546923720.02.0.197297571195.issue26467@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Jan  8 00:42:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 08 Jan 2019 05:42:51 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1546926171.27.0.997021841487.issue35656@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Looking at the code ANY is simply implemented with __eq__ always returning True at https://github.com/python/cpython/blob/e61cc481e02b758c8d8289163102c236d0658a55/Lib/unittest/mock.py#L1957 . I am not sure how APPROXIMATE can be implemented in terms of floating point like rounding up or down? Do you have any examples in mind over a sample implementation or example of how they should behave in various scenarios?

----------
nosy: +xtreak
versions: +Python 3.8

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

From report at bugs.python.org  Tue Jan  8 01:41:06 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 08 Jan 2019 06:41:06 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546929666.71.0.476675486712.issue35673@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Namespace packages (PEP 420) predate ModuleSpec (PEP 451). So, I think this probably happened when 451 was implemented. Maybe Eric Snow recalls?

I say this without having looked at it very deeply.

As to why the namespace package loader is a private class: it never occurred to me someone would care about inspecting it.

----------
nosy: +eric.snow

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

From report at bugs.python.org  Tue Jan  8 03:36:28 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 08 Jan 2019 08:36:28 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1546936588.68.0.74301733945.issue35674@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I would go with exposing  posix_spawnp() as a separate function to rule out any arguments.

I am working on this in this regard unless anyone has a different view.

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Tue Jan  8 03:46:40 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Jan 2019 08:46:40 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546937200.06.0.471690583901.issue35673@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The background for all of this: I'm currently rewriting modulegraph (https://pypi.org/project/modulegraph/) to use importlib instead of its own implementation of the import mechanism.

I currently detect PEP420 style namespace packages, but I'm not sure if I really need that information.  With the current behaviour of the namespace loader I probably do, because I'd otherwise end up with creating an __init__.py for these packages when I use the generated module graph in py2app to copy modules into an application bundle.

----------

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

From report at bugs.python.org  Tue Jan  8 04:12:09 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 08 Jan 2019 09:12:09 +0000
Subject: [issue35673] Loader for namespace packages
In-Reply-To: <1546781003.0.0.391060889435.issue35673@roundup.psfhosted.org>
Message-ID: <1546938729.11.0.997208387134.issue35673@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think exposing _NamespaceLoader as NamespaceLoader and registering the ABC make sense. That would make this in to a feature request for 3.8.

----------

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

From report at bugs.python.org  Tue Jan  8 04:38:24 2019
From: report at bugs.python.org (=?utf-8?q?Vladimir_Peri=C4=87?=)
Date: Tue, 08 Jan 2019 09:38:24 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546940304.48.0.50375162228.issue35665@roundup.psfhosted.org>


Vladimir Peri? <pervlad at gmail.com> added the comment:

Thank you all for this expeditive help. Sorry for taking your time.
I will remove bad certificates from my machine.
Thanks again.

I will try to close this one.

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

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

From report at bugs.python.org  Tue Jan  8 04:58:30 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 09:58:30 +0000
Subject: [issue35568] Expose the C raise() function in the signal module,
 for use on Windows
In-Reply-To: <1545537356.71.0.0770528567349.issue35568@roundup.psfhosted.org>
Message-ID: <1546941510.29.0.584792496292.issue35568@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c24c6c2c9357da99961bf257078240529181daf3 by Miss Islington (bot) (Vladimir Matveev) in branch 'master':
bpo-35568: add 'raise_signal' function (GH-11335)
https://github.com/python/cpython/commit/c24c6c2c9357da99961bf257078240529181daf3


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jan  8 04:59:37 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 08 Jan 2019 09:59:37 +0000
Subject: [issue35568] Expose the C raise() function in the signal module,
 for use on Windows
In-Reply-To: <1545537356.71.0.0770528567349.issue35568@roundup.psfhosted.org>
Message-ID: <1546941577.11.0.106550242049.issue35568@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jan  8 05:28:54 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 08 Jan 2019 10:28:54 +0000
Subject: [issue35684] Windows "embedded" Python downloads are malformed
Message-ID: <1546943332.69.0.924867771355.issue35684@roundup.psfhosted.org>


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

~$ unzip -l /tmp/python-3.7.2-embed-amd64.zip 
Archive:  /tmp/python-3.7.2-embed-amd64.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
    99856  2018-12-23 23:10   python.exe
    98320  2018-12-23 23:10   pythonw.exe
  3780624  2018-12-23 23:09   python37.dll
    58896  2018-12-23 23:10   python3.dll
    85232  2018-12-10 22:06   vcruntime140.dll
   200208  2018-12-23 23:10   pyexpat.pyd
    26640  2018-12-23 23:10   select.pyd
  1073168  2018-12-23 23:10   unicodedata.pyd
    28688  2018-12-23 23:10   winsound.pyd
    71184  2018-12-23 23:10   _asyncio.pyd
    89104  2018-12-23 23:10   _bz2.pyd
    22544  2018-12-23 23:10   _contextvars.pyd
   133136  2018-12-23 23:10   _ctypes.pyd
   267792  2018-12-23 23:10   _decimal.pyd
   209424  2018-12-23 23:10   _elementtree.pyd
    38928  2018-12-23 23:10   _hashlib.pyd
   257040  2018-12-23 23:10   _lzma.pyd
    39440  2018-12-23 23:10   _msi.pyd
    29200  2018-12-23 23:10   _multiprocessing.pyd
    44048  2018-12-23 23:10   _overlapped.pyd
    27664  2018-12-23 23:10   _queue.pyd
    75792  2018-12-23 23:10   _socket.pyd
    85520  2018-12-23 23:10   _sqlite3.pyd
   123408  2018-12-23 23:10   _ssl.pyd
  2480296  2018-12-23 22:20   libcrypto-1_1-x64.dll
   523944  2018-12-23 22:20   libssl-1_1-x64.dll
  1190416  2018-12-23 23:10   sqlite3.dll
    85232  2018-12-10 22:06   vcruntime140.dll
  2386539  2018-12-23 23:14   python37.zip
       79  2018-12-23 23:14   python37._pth
---------                     -------
 13632362                     30 files

Notice that "vcruntime140.dll" appears twice on this list, once near the top and once near the bottom.

If we try to unpack this using the powershell Expand-Archive command, it fails with:

Failed to create file 'D:\a\1\s\python-dir\vcruntime140.dll' while expanding the archive file 
'D:\a\1\s\python.zip' contents as the file 'D:\a\1\s\python-dir\vcruntime140.dll' already exists. Use the -Force 
parameter if you want to overwrite the existing directory 'D:\a\1\s\python-dir\vcruntime140.dll' contents when 
expanding the archive file.

Probably it would be better to only include one copy of vcruntime140.dll :-)

----------
assignee: steve.dower
messages: 333217
nosy: njs, steve.dower
priority: normal
severity: normal
status: open
title: Windows "embedded" Python downloads are malformed

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

From report at bugs.python.org  Tue Jan  8 05:32:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 08 Jan 2019 10:32:41 +0000
Subject: [issue35684] Windows "embedded" Python downloads are malformed
In-Reply-To: <1546943332.69.0.924867771355.issue35684@roundup.psfhosted.org>
Message-ID: <1546943561.4.0.555758245775.issue35684@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems this is fixed as part of related issue issue35596

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Jan  8 05:37:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Jan 2019 10:37:30 +0000
Subject: [issue35684] Windows "embedded" Python downloads are malformed
In-Reply-To: <1546943332.69.0.924867771355.issue35684@roundup.psfhosted.org>
Message-ID: <1546943850.96.0.453981120881.issue35684@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'

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

From report at bugs.python.org  Tue Jan  8 05:38:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 10:38:05 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546943885.98.0.952925523589.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 872bd2b57ce8e4ea7a54acb3934222c0e4e7276b by Steve Dower in branch 'master':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/872bd2b57ce8e4ea7a54acb3934222c0e4e7276b


----------

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

From report at bugs.python.org  Tue Jan  8 05:38:30 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 10:38:30 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546943885.98.0.952925523589.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 872bd2b57ce8e4ea7a54acb3934222c0e4e7276b by Steve Dower in branch 'master':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/872bd2b57ce8e4ea7a54acb3934222c0e4e7276b


----------
pull_requests: +10956

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

From report at bugs.python.org  Tue Jan  8 05:38:32 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 10:38:32 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546943885.98.0.952925523589.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 872bd2b57ce8e4ea7a54acb3934222c0e4e7276b by Steve Dower in branch 'master':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/872bd2b57ce8e4ea7a54acb3934222c0e4e7276b


----------
pull_requests: +10956, 10958

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

From report at bugs.python.org  Tue Jan  8 05:38:33 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 10:38:33 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546943885.98.0.952925523589.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 872bd2b57ce8e4ea7a54acb3934222c0e4e7276b by Steve Dower in branch 'master':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/872bd2b57ce8e4ea7a54acb3934222c0e4e7276b


----------
pull_requests: +10956, 10957, 10958

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

From report at bugs.python.org  Tue Jan  8 05:39:44 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 08 Jan 2019 10:39:44 +0000
Subject: [issue35684] Windows "embedded" Python downloads are malformed
In-Reply-To: <1546943332.69.0.924867771355.issue35684@roundup.psfhosted.org>
Message-ID: <1546943984.83.0.898433691286.issue35684@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

You're right, good catch!

----------
resolution: duplicate -> fixed
stage: resolved -> 
superseder: Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings' -> 

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

From report at bugs.python.org  Tue Jan  8 05:46:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 08 Jan 2019 10:46:07 +0000
Subject: [issue35684] Windows "embedded" Python downloads are malformed
In-Reply-To: <1546943332.69.0.924867771355.issue35684@roundup.psfhosted.org>
Message-ID: <1546944367.15.0.966260753529.issue35684@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
stage:  -> resolved
superseder:  -> Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'

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

From report at bugs.python.org  Tue Jan  8 05:56:26 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 10:56:26 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546944986.94.0.235970433406.issue35596@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 69f64b67e43c65c2178c865fd1be80ed07f02d3c by Miss Islington (bot) in branch '3.7':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/69f64b67e43c65c2178c865fd1be80ed07f02d3c


----------

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

From report at bugs.python.org  Tue Jan  8 06:07:48 2019
From: report at bugs.python.org (Petter S)
Date: Tue, 08 Jan 2019 11:07:48 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1546945668.24.0.684739181753.issue35656@roundup.psfhosted.org>


Petter S <petter.strandmark at gmail.com> added the comment:

Yes, something like this:

    class APPROXIMATE:
        """Takes a floating point number and implements approximate equality."""

        def __init__(self, value):
            self.value = value

        def __eq__(self, other):
            return abs(self.value - other) / (abs(self.value) + abs(other)) < 1e-6

        def __repr__(self):
            return f"APPROXIMATE({self.value})"


Then the following would hold:

    got = {
    "name": "Petter",
    "length": 1.900001
    }

    expected = {
    "name": "Petter",
    "length": APPROXIMATE(1.9)
    }

    assert got == expected

But not

    got["length"] = 1.8
    assert got == expected

----------

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

From report at bugs.python.org  Tue Jan  8 06:29:52 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Tue, 08 Jan 2019 11:29:52 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1546946992.56.0.706559863884.issue35656@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

I feel it would be better to have tolerance as an argument.

----------
nosy: +FR4NKESTI3N

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

From report at bugs.python.org  Tue Jan  8 06:45:02 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 08 Jan 2019 11:45:02 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1546947902.31.0.671854035842.issue35665@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I also checked how other implementations deal with invalid DER encoding. NSS 3.41, Firefox, and Chromium accept the certifiate.

NSS shows the serial number as "102 (0x66)"
Firefox and Chromium display the serial number as "00:00:00:66".

$ echo "password" > passwd
$ certutil -d . -f passwd -N
$ certutil -d . -f passwd -A -n ca -i ../ca.pem -t C,C,C
$ certutil -d . -L -n ca
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 102 (0x66)
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "C=RS,L=Beograd,O=MUP Republike Srbije,CN=MUPCA Root"
        Validity:
            Not Before: Sat Feb 27 16:19:18 2010
            Not After : Thu Feb 27 16:19:18 2020
        Subject: "C=Re...,L=Beograd,O=MUP Republike Srbije,CN=MUPCA Resursi"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    ea:69:46:bc:c7:70:00:d5:f5:32:8d:c7:4e:ad:3a:a5:
                    d3:29:7e:a2:46:12:a9:dd:57:75:b1:49:95:80:20:ed:
                    9b:68:6b:e3:c5:55:d8:64:15:68:42:ab:a3:f7:c0:96:
                    37:08:51:cb:05:ca:b5:99:f6:07:a6:8b:f2:cd:d2:f5:
                    d6:16:12:da:bf:a8:0b:9c:45:5d:ac:79:1d:a8:67:47:
                    ee:7f:83:40:f8:58:00:d5:dd:c4:c9:52:1b:d2:f4:ce:
                    e1:fa:8a:66:d3:18:86:1e:ea:fc:0a:8b:b5:ec:49:cd:
                    86:bf:8b:7e:b0:61:81:ec:ea:99:4f:64:82:96:93:9d:
                    ab:80:7d:a7:27:65:00:d4:12:26:98:45:64:7e:76:0b:
                    98:ff:16:50:49:0c:45:20:82:ce:2e:23:a2:65:3a:b7:
                    44:cd:51:00:d9:bf:e3:1f:de:23:1d:57:e9:32:c3:55:
                    f0:24:af:d4:cf:cd:9e:77:1f:19:7e:1c:03:5b:7a:e4:
                    75:84:3b:d4:1d:e9:23:d6:8c:f2:8f:b2:0d:e3:79:df:
                    9e:03:1e:0e:15:5b:7b:0c:dd:6e:4d:82:86:5a:63:79:
                    64:b5:07:79:dd:fd:08:e3:d6:cb:60:01:fd:82:11:59:
                    2c:8d:22:f8:f9:91:59:b1:cd:12:7b:39:6d:08:82:5d
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Basic Constraints
            Critical: True
            Data: Is a CA with no maximum path length.

            Name: Certificate Key Usage
            Critical: True
            Usages: Certificate Signing
                    CRL Signing

            Name: Authority Information Access
            Method: PKIX CA issuers access method
            Location: 
                URI: "http://ca.mup.gov.rs/MUPCARoot.crt"

            Name: Certificate Subject Key ID
            Data:
                cb:f9:00:a9:b7:b6:c1:6f:44:43:d0:22:ad:fc:0e:6e:
                cc:8f:f6:0f

            Name: Certificate Authority Key Identifier
            Key ID:
                3f:66:b0:0f:66:fb:f0:10:2e:61:a4:6f:ef:2c:95:8a:
                14:72:6f:71

            Name: CRL Distribution Points
            Distribution point:
                URI: "http://ca.mup.gov.rs/MUPCARoot.crl"

    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption

----------

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

From report at bugs.python.org  Tue Jan  8 06:51:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 11:51:18 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1546948278.5.0.571013730645.issue35674@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm ok to expose posix_spawnp() as os.posix_spawnp().

Even if we expose posix_spawnp() as os.posix_spawnp(), we can still reconsider to add posix_spawnp() feature into os.posix_spawn() as an optional keyword parameter later :-) Honestly, I have no strong preference for the API. My main problem with the keyword option is the risk of name conflict if a new feature is added to posix_spawn() with a name similar to my proposed name "use_path".

----------

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

From report at bugs.python.org  Tue Jan  8 07:37:58 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 08 Jan 2019 12:37:58 +0000
Subject: [issue35685] Add samples on patch.dict of the use of decorator and in
 class
Message-ID: <1546951077.39.0.591357222806.issue35685@roundup.psfhosted.org>


New submission from Emmanuel Arias <emmanuelarias30 at gmail.com>:

Hi!

I create this PR to add a samples of the use of patch.dict with decorator on method and class. I think that is a good improve because the doc mentions the use of patch.dict with decorator on method and class but don't show any samples. 

Other, question, why on unittest.mock documentation is used `assert *something* == *something*` and it is not used the assertEquals (and others)? IMHO this would be better for unittest docs.

Regards

----------
assignee: docs at python
components: Documentation
messages: 333226
nosy: docs at python, eamanu, michael.foord
priority: normal
severity: normal
status: open
title: Add samples on patch.dict of the use of decorator and in class
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Jan  8 07:43:17 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 08 Jan 2019 12:43:17 +0000
Subject: [issue35685] Add samples on patch.dict of the use of decorator and in
 class
In-Reply-To: <1546951077.39.0.591357222806.issue35685@roundup.psfhosted.org>
Message-ID: <1546951397.58.0.94232753265.issue35685@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch
pull_requests: +10959
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan  8 07:43:24 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 08 Jan 2019 12:43:24 +0000
Subject: [issue35685] Add samples on patch.dict of the use of decorator and in
 class
In-Reply-To: <1546951077.39.0.591357222806.issue35685@roundup.psfhosted.org>
Message-ID: <1546951404.26.0.123991247734.issue35685@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10959, 10960
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan  8 07:43:31 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 08 Jan 2019 12:43:31 +0000
Subject: [issue35685] Add samples on patch.dict of the use of decorator and in
 class
In-Reply-To: <1546951077.39.0.591357222806.issue35685@roundup.psfhosted.org>
Message-ID: <1546951411.21.0.719019900624.issue35685@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10959, 10960, 10961
stage:  -> patch review

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

From report at bugs.python.org  Tue Jan  8 08:03:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:03:34 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546952614.2.0.0346881139013.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10962

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

From report at bugs.python.org  Tue Jan  8 08:03:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:03:40 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546952620.73.0.734046958652.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10962, 10963

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

From report at bugs.python.org  Tue Jan  8 08:03:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:03:49 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546952629.55.0.487958155112.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +10962, 10963, 10964

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

From report at bugs.python.org  Tue Jan  8 08:12:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:12:47 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546953167.19.0.141507424105.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

It took me 1 year, a few sleepless nights, multiple attempts to understand the leak, but I eventually found it! WSASend() doesn't release the memory if it fails immediately. I wrote PR 11469 to fix the memory leak. ReadFile() has the same bug, I also fixed it.

By the way, the _overlapped.Overlapped type has no traverse function: it may help the garbage collector to add once, since asyncio is famous for building reference cycles by design (Future.set_exception()).

----------

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

From report at bugs.python.org  Tue Jan  8 08:23:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:23:19 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546953799.82.0.873920447737.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a234e148394c2c7419372ab65b773d53a57f3625 by Victor Stinner in branch 'master':
bpo-32710: Fix leak in Overlapped_WSASend() (GH-11469)
https://github.com/python/cpython/commit/a234e148394c2c7419372ab65b773d53a57f3625


----------

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

From report at bugs.python.org  Tue Jan  8 08:23:33 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 13:23:33 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546953813.84.0.0948998208698.issue32710@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10965

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

From report at bugs.python.org  Tue Jan  8 08:23:42 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 13:23:42 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546953822.5.0.8113708153.issue32710@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10965, 10966

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

From report at bugs.python.org  Tue Jan  8 08:23:51 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 13:23:51 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546953831.26.0.265333648126.issue32710@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10965, 10966, 10967

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

From report at bugs.python.org  Tue Jan  8 08:33:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:33:15 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546954395.62.0.204830804437.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I ran test_asyncio refleak hunting on Windows, and there is no more leak!

vstinner at WIN C:\vstinner\python\master>python -m test test_asyncio -R 3:3 
(...)
Total duration: 13 min 24 sec
Tests result: SUCCESS

I will close this PR once the 3.7 backport is merged.

----------

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

From report at bugs.python.org  Tue Jan  8 08:40:52 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Jan 2019 13:40:52 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546954852.51.0.0804958568203.issue32710@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 88ad48bc98980a40591cc5521703dbb0ad3a9b17 by Miss Islington (bot) in branch '3.7':
bpo-32710: Fix leak in Overlapped_WSASend() (GH-11469)
https://github.com/python/cpython/commit/88ad48bc98980a40591cc5521703dbb0ad3a9b17


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jan  8 08:46:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 13:46:28 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1546955188.9.0.373213598871.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Tue Jan  8 09:40:04 2019
From: report at bugs.python.org (Ayappan)
Date: Tue, 08 Jan 2019 14:40:04 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1546958404.11.0.280588445148.issue35198@roundup.psfhosted.org>


Ayappan <ayappanec at gmail.com> added the comment:

Not sure what went wrong here.
I used gcc & g++ and didn't hit this issue.

----------

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

From report at bugs.python.org  Tue Jan  8 09:41:38 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Tue, 08 Jan 2019 14:41:38 +0000
Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up
 exceptions
In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za>
Message-ID: <1546958498.13.0.11880160831.issue9400@roundup.psfhosted.org>


Marc Schlaich <marc.schlaich at googlemail.com> added the comment:

Davin, why isn't just one of the simple one-line patches applied. This would be much more reasonable instead of closing this as won't fix. 

This is a really ugly bug and it took me hours to find the cause...

----------
nosy: +schlamar

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

From report at bugs.python.org  Tue Jan  8 10:16:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 15:16:18 +0000
Subject: [issue33834] test_asyncio:
 test_sendfile_close_peer_in_the_middle_of_receiving() of ProactorEventLoop
 logs InvalidStateError error
In-Reply-To: <1528725802.67.0.592728768989.issue33834@psf.upfronthosting.co.za>
Message-ID: <1546960578.11.0.0489140812436.issue33834@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Duplicate of bpo-35682 and fixed by:

commit 80fda712c83f5dd9560d42bf2aa65a72b18b7759
Author: Victor Stinner <vstinner at redhat.com>
Date:   Tue Jan 8 02:46:59 2019 +0100

    bpo-35682: Fix _ProactorBasePipeTransport._force_close() (GH-11462)
    
    bpo-32622, bpo-35682: Fix asyncio.ProactorEventLoop.sendfile(): don't
    attempt to set the result of an internal future if it's already done.
    
    Fix asyncio _ProactorBasePipeTransport._force_close(): don't set the
    result of _empty_waiter if it's already done.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> asyncio: bug in _ProactorBasePipeTransport._force_close()

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

From report at bugs.python.org  Tue Jan  8 11:20:40 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Jan 2019 16:20:40 +0000
Subject: [issue35671] reserved identifier violation
In-Reply-To: <1546776792.69.0.991179182294.issue35671@roundup.psfhosted.org>
Message-ID: <1546964440.05.0.0580407180782.issue35671@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

(changed the type from "security" because this is not a security incident).

Both ISO C and C++ define "reserved identifiers" that are reserved for the implementation and where use in programs is undefined behaviour. However, these definitions reserve *all* global symbols starting with an underscore, while such symbols are commonly used for private names in libraries. Not just in the Python implementation, but throughout the C/C++ ecosystem. 

Changing both as a large impact on the CPython implementation due to changing identifiers for private symbols, and there is no clear way to pick new names that clearly and concisely indicate that names are private (esp. not without inventing a new convention).  Such a change could also not be done for all released versions of Python (that is, for 3.8 at the earliest), which leads to an increased maintenance cost as well due to a higher chance for merge conflicts when back porting bug fixes. 

Because of this it is IMHO not worthwhile to change the names of private symbols in the CPython implementation unless there is clear evidence that a particular symbol causes problems with compilers.

That said, changing the include guard with double underscores would be fine because that name doesn't follow the regular CPython coding style.

P.S. A draft of an ISO C std: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf. Section 7.1.3 defines what reserved identifiers are.

----------
type: security -> enhancement

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

From report at bugs.python.org  Tue Jan  8 11:55:04 2019
From: report at bugs.python.org (Chris Billington)
Date: Tue, 08 Jan 2019 16:55:04 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1546966504.25.0.689746659009.issue33944@roundup.psfhosted.org>


Chris Billington <chrisjbillington at gmail.com> added the comment:

I develop analysis software for physics research, in which the user analyses their data using Python that they write themselves (my application functions as a kind of scheduler for when the analysis scripts should run and with what input). This software has a concept of 'the user's modules', which the user can import from anywhere. When the application is installed, it installs a .pth file to add this 'userlib' folder to the Python path. This way the user can maintain importable modules that they re-use in their analysis without having to put them on PyPI or anything like that (which would be impractical since they are often being hacked on and don't have anything resembling a release cycle). It is important that these modules aren't just available from within the environment my application provides, as that is a bit too rigid - the user should be able to use the normal Python REPL or IPython or whatever to develop and test their code when the 'scheduler' is not in control of running it. 

I'm not sure what I would do instead if .pth files went away. Modifying PYTHONPATH is messy since it applies to all python versions, whereas .pth files are nicely specific only to the one Python installation. sitecustomize.py is messy because if it already exists I need to programmatically modify it to add or remove my changes (and contend with the fact that other packages may be doing the same), whereas a .pth file is nicely separate.

I didn't even know about the arbitrary code execution capabilities of .pth files and don't really care, but keeping the ability to add directories to the Python path would be nice, as the alternatives for doing this are unappealing (and for my application, putting the code the user is hacking on daily deep inside a Conda environment folder hierarchy is unappealing too).

----------
nosy: +Chris Billington

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

From report at bugs.python.org  Tue Jan  8 12:03:22 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Tue, 08 Jan 2019 17:03:22 +0000
Subject: [issue35686] memoryview contextmanager causing strange crash
Message-ID: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>


New submission from Thomas Waldmann <thomas.j.waldmann at gmail.com>:

See there:

https://github.com/borgbackup/borg/pull/4247

I did the first changeset after seeing some strange exception popping up which it was handling another exception - which I assumed was related to memoryview.release not being called in the original code.

So it was clear to me, that we should use the CM there. So I added that (first changeset) and that made the code always fail (see first travis-ci link).

Then removed the CM again and replaced it with functionally equivalent try/finally (second changeset) - that worked.

So, the question is whether there is some issue in CPython's memoryview contextmanager code that make it fail in such a strange way.

----------
messages: 333236
nosy: Thomas.Waldmann
priority: normal
severity: normal
status: open
title: memoryview contextmanager causing strange crash
type: crash
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Jan  8 12:20:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 08 Jan 2019 17:20:00 +0000
Subject: [issue35686] memoryview contextmanager causing strange crash
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546968000.63.0.329943185075.issue35686@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Can you please add a simple reproducer in Python with what the test is trying to do without dependencies from the project? perhaps with a sample of relevant files used by the test in Travis.

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Jan  8 12:46:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Jan 2019 17:46:19 +0000
Subject: [issue35686] memoryview contextmanager causing strange crash
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546969579.44.0.755739918685.issue35686@roundup.psfhosted.org>


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


----------
nosy: +skrah

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

From report at bugs.python.org  Tue Jan  8 13:08:10 2019
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 08 Jan 2019 18:08:10 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546970890.23.0.869872032698.issue35686@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

We use "crash" for segmentation fault, but this appears to be a regular traceback that includes BufferError.

The BufferError message appears to be from mmapmodule.c.

----------
title: memoryview contextmanager causing strange crash -> BufferError with memory.release()
type: crash -> behavior

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

From report at bugs.python.org  Tue Jan  8 13:12:17 2019
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 08 Jan 2019 18:12:17 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546971137.45.0.562235471737.issue35686@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The behavior seems to be correct to me: If there are exports, the memoryview cannot be released.

The application needs to ensure that release() is not called when
there are exports left.

----------

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

From report at bugs.python.org  Tue Jan  8 13:12:34 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Tue, 08 Jan 2019 18:12:34 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546971154.76.0.708225165051.issue35686@roundup.psfhosted.org>


Thomas Waldmann <thomas.j.waldmann at gmail.com> added the comment:

working, but potentially problematic because .release is not always called (e.g. in case of an exception).

----------
Added file: https://bugs.python.org/file48031/issue35686a.py

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

From report at bugs.python.org  Tue Jan  8 13:13:18 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Tue, 08 Jan 2019 18:13:18 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546971198.83.0.382558641503.issue35686@roundup.psfhosted.org>


Thomas Waldmann <thomas.j.waldmann at gmail.com> added the comment:

with context manager, does not work.

----------
Added file: https://bugs.python.org/file48032/issue35686b.py

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

From report at bugs.python.org  Tue Jan  8 13:13:52 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Tue, 08 Jan 2019 18:13:52 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546971232.13.0.20213702153.issue35686@roundup.psfhosted.org>


Thomas Waldmann <thomas.j.waldmann at gmail.com> added the comment:

with try/finally: works.

----------
Added file: https://bugs.python.org/file48033/issue35686c.py

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

From report at bugs.python.org  Tue Jan  8 13:23:20 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Tue, 08 Jan 2019 18:23:20 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546971800.26.0.876710901441.issue35686@roundup.psfhosted.org>


Thomas Waldmann <thomas.j.waldmann at gmail.com> added the comment:

hmm, issue tracker does not make it easy to see which file was uploaded for which comment, so:

a: original code, works, potentially problematic exception handling (memoryview not always being released)

b: using the memoryview context manager, fails with BufferError

c: using try/finally to make sure memoryview is released: works

----------

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

From report at bugs.python.org  Tue Jan  8 13:28:40 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Tue, 08 Jan 2019 18:28:40 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546972120.61.0.786558816909.issue35686@roundup.psfhosted.org>


Thomas Waldmann <thomas.j.waldmann at gmail.com> added the comment:

I see 2 issues here:

1. I would expect that the CM approach (b) behaves equivalent to try/finally (c), but it does not and even causes an exception.

2. The traceback given in the BufferError (in (b)) is misleading, it points to the "print", but should rather point to mmap.__exit__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35686>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:01:04 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Jan 2019 19:01:04 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1546974064.74.0.482702820242.issue2506@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

If someone can get a PR into a state that is acceptable, then this can be resolved, Arthur. But at this point that hasn't occurred.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:03:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Jan 2019 19:03:18 +0000
Subject: [issue35676] unittest assert helper methods have incorrect signature
 in docs
In-Reply-To: <1546834667.39.0.848001961358.issue35676@roundup.psfhosted.org>
Message-ID: <1546974198.99.0.0690678071785.issue35676@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +michael.foord, rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35676>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:05:03 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 08 Jan 2019 19:05:03 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1546974303.04.0.163302253233.issue35683@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Enable manylinux1 builds on Pipelines -> Enable manylinux1 builds on Pipelines for CI testing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:06:22 2019
From: report at bugs.python.org (David Wilson)
Date: Tue, 08 Jan 2019 19:06:22 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1546974381.99.0.772570352196.issue35486@roundup.psfhosted.org>


David Wilson <dw at botanicus.net> added the comment:

Hi Nick,

The purpose of ModuleNotFoundError is clear and unrelated to the problem documented here. The problem is that due to the introduction of ModuleNotFoundError, ImportError's semantics have been changed within a minor release in a breaking, backwards-incompatible manner.

As of Python 3.5, ImportError meant both "ImportError" and "ModuleNotFoundError". As of 3.6, the senses are distinct, and thus code written against ImportError as it existed in 3.5 no longer works correctly as of 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:35:30 2019
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 08 Jan 2019 19:35:30 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546976130.47.0.432543270001.issue35686@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Well, the problem in b) is that data[:2] creates a new memoryview,
so the underlying ManagedBufferObject now has two exports:

  - One from the context manager.

  - The second from the slice.

So memoryview.__exit__() decrements on export, but the second one
is hanging.

This actually works as expected because the ManagedBufferObject
cannot know that it could also release the slice. That's what I
meant by saying that it's the application's responsibility to
release all views that are based on the context manager's view.


One way of doing so would be this:

with open(fn, 'rb') as fd:
    with mmap.mmap(fd.fileno(), 0, access=mmap.ACCESS_READ) as mm:
        with memoryview(mm) as data:
            with data[:2] as theslice:
                print(theslice)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35686>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:44:45 2019
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 08 Jan 2019 19:44:45 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546976685.52.0.150464661827.issue35686@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

s/on export/one export/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35686>
_______________________________________

From report at bugs.python.org  Tue Jan  8 14:47:53 2019
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 08 Jan 2019 19:47:53 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546976873.59.0.0227161724848.issue35686@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Or, obviously:

with open(fn, 'rb') as fd:
    with mmap.mmap(fd.fileno(), 0, access=mmap.ACCESS_READ) as mm:
        with memoryview(mm)[:2] as data:
            print(data)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35686>
_______________________________________

From report at bugs.python.org  Tue Jan  8 15:46:03 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 20:46:03 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546980363.08.0.0412058872582.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is now resolved, and only through modifying the build scripts. Which means I can take the existing build and republish a fixed embeddable package without needing a new release.

Unless Ned would prefer a complete release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:11:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Jan 2019 21:11:48 +0000
Subject: [issue6143] IDLE - an extension to clear the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1546981908.38.0.546012659245.issue6143@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

An SO question today got me to look more at SO questions and discussion, and this appears to be the most requested feature.

https://stackoverflow.com/questions/1432480/any-way-to-clear-pythons-idle-window - 2009, 129 upvotes, 32 answers (not all read yet)

... (15 other hits for [python-idle] clear screen)

https://stackoverflow.com/questions/54083355/how-to-clear-the-screen-in-idle-on-imac - 2019 today

So I want to revisit this after we do a bit more on squeezer.  I want to add 'Clear and Restart' to the Shell menu, as Raymond suggested, so I am inclined to 'clear and restart' this discussion by closing this issue and reopening #17632 as a followup.

----------
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6143>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:21:32 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Jan 2019 21:21:32 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546982492.58.0.366166101935.issue35596@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

It seems like this need not trigger a complete new release and, ATM, I'm not aware of any other showstopper problems that would otherwise trigger an early 3.7.3.  One question would be how and where to document this change in the build artificat.  Suggestions, Steve?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:23:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jan 2019 21:23:19 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546982599.3.0.685202188228.issue35596@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This is now resolved, and only through modifying the build scripts. Which means I can take the existing build and republish a fixed embeddable package without needing a new release.

Since Python itself doesn't make, I'm ok to not change the Python release. But for pratical issues, would it be possible to use a different *filename*? For example, Python website rely a lot on CDN caching. It can be surprising to have two files with the same name but different content.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:32:59 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Jan 2019 21:32:59 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546983179.96.0.285210521979.issue35596@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

CDN caching on python.org is not a problem; we know how to clear out the cache.  But I also strongly dislike silent updates of released files so I agree that names should be changed if we do end up agreeing to replace one or more files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:41:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 21:41:49 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546983709.23.0.0301960859747.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I know how to purge the CDN cache, so that's not an issue. And there's no good reason to leave the old one up.

Perhaps we can just add a note to the download page and I'll post on a couple of lists? This is basically a product recall, and those are usually advertised at the point of sale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:45:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 21:45:42 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546983942.27.0.397289429087.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I can add a .post1 into the version number in the zip file? Still want to take the old one down though, and if anyone is using any sort of script to get this file then it'll be just as annoying for the link to be broken as getting a broken download.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:48:23 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 21:48:23 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546984103.19.0.226465638087.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I can add ".post1" to the version number in the file name, but I'd still want to take down the broken one. And anyone who's generating the download URL will get a broken link, which IMO is just as bad as a broken download when we could fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 16:57:50 2019
From: report at bugs.python.org (Addons Zz)
Date: Tue, 08 Jan 2019 21:57:50 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
Message-ID: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>


New submission from Addons Zz <addonszz at outlook.com>:

Create this program and run with `Python 3.6.3`:
```python
import unittest

class StdErrUnitTests(unittest.TestCase):

    def test_function_name(self):
        expected = "testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary\n" \
                "testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}"

        actual = "15:49:35:912.348986 - testing.main_unit_tests - dictionary\n" \
                "15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}"

        self.assertEqual(expected, actual)

if __name__ == '__main__':
    unittest.main()
```

### Actual output

```diff
F
======================================================================
FAIL: test_function_name (__main__.StdErrUnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\bug_assert_unittests.py", line 13, in test_function_name
    self.assertEqual(expected, actual)
AssertionError: "testing.main_unit_tests.test_dictionaryBa[114 chars]nk'}" != "15:49:35:912.348986 - testing.main_unit_t[94 chars]nk'}"
- testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
- testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}+ 15:49:35:912.348986 - testing.main_unit_tests - dictionary
+ 15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
```

### Expected output

```diff
F
======================================================================
FAIL: test_function_name (__main__.StdErrUnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\bug_assert_unittests.py", line 13, in test_function_name
    self.assertEqual(expected, actual)
AssertionError: "testing.main_unit_tests.test_dictionaryBa[114 chars]nk'}" != "15:49:35:912.348986 - testing.main_unit_t[94 chars]nk'}"
- testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
- testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}
+ 15:49:35:912.348986 - testing.main_unit_tests - dictionary
+ 15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
```

### Differences between actual and expected output

```diff
@@ -7,7 +7,8 @@
     self.assertEqual(expected, actual)
 AssertionError: "testing.main_unit_tests.test_dictionaryBa[114 chars]nk'}" != "15:49:35:912.348986 - testing.main_unit_t[94 chars]nk'}"
 - testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
-- testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}+ 15:49:35:912.348986 - testing.main_unit_tests - dictionary
+- testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}
++ 15:49:35:912.348986 - testing.main_unit_tests - dictionary
 + 15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}
```

This kind of bug frequently happens. On this case, it is not putting a new line before the `+`. Other cases, it is not putting a new line before the `?`.

----------
components: Tests, Windows
messages: 333258
nosy: addons_zz, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: The unittest module diff is missing/forgetting/not putting newline before + and ? for some inputs
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:02:42 2019
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 08 Jan 2019 22:02:42 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
 string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1546984962.71.0.879115867193.issue2517@roundup.psfhosted.org>


Change by Piotr Dobrogost <bugs.python at p.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2517>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:03:59 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Jan 2019 22:03:59 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546985039.64.0.378635404114.issue35596@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I think we should change the name (post1 is fine), delete the original file, update the file name link in the release page (https://www.python.org/downloads/release/python-372/) to use the new name, and add a sentence or two to the release page describing the change.  If you could write up something for the page, I can add it and change the file name when ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:37:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Jan 2019 22:37:54 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546987074.29.0.582653636463.issue35596@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It would be weird if building from sources will not give the same distribution as downloaded from official site. It would be not fair to alternate distributors.

I think this is a time to release 3.7.2.1. This would be not the first time of using the fourth number in the version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:38:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 22:38:49 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1546987129.96.0.665493645623.issue35687@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This doesn't appear to be Windows-specific or related to our test suite, so I updated the tags and added the unittest experts.

----------
nosy: +ezio.melotti, michael.foord, rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:39:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 22:39:19 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1546987159.3.0.465051935196.issue35687@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
nosy:  -steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:45:21 2019
From: report at bugs.python.org (mattip)
Date: Tue, 08 Jan 2019 22:45:21 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windos Store
Message-ID: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>


New submission from mattip <matti.picus at gmail.com>:

After enabling Insider and installing Python3.7 from the Windows Store, I open a cmd window and do `pip install --user numpy` which runs to completion. But I cannot `import numpy`. 

The NumPy `mutiarray` c-extension module in the `numpy/core` directory depends on an `OpenBLAS` DLL that is installed into the `numpy/.libs` directory. But even after adding that directory to the `PATH` before running python (and checking with `depends.exe` that the `multiarray` c-extension module is now not missing any dependencies) I still cannot `import numpy`.

See also NumPy issue https://github.com/numpy/numpy/issues/12667

----------
components: Windows
messages: 333262
nosy: brett.cannon, mattip, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: "pip install --user numpy" fails on Python from the Windos Store
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:50:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 08 Jan 2019 22:50:54 +0000
Subject: [issue35689] IDLE: Docstrings and test for colorizer
Message-ID: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

Add docstrings and unittests for colorizer.py.

----------
assignee: terry.reedy
components: IDLE
messages: 333263
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Docstrings and test for colorizer
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35689>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:56:12 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 08 Jan 2019 22:56:12 +0000
Subject: [issue35689] IDLE: Docstrings and test for colorizer
In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org>
Message-ID: <1546988172.15.0.35869565484.issue35689@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +10968
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35689>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:56:18 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 08 Jan 2019 22:56:18 +0000
Subject: [issue35689] IDLE: Docstrings and test for colorizer
In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org>
Message-ID: <1546988178.55.0.014242784766.issue35689@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +10968, 10969
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35689>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:56:23 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 08 Jan 2019 22:56:23 +0000
Subject: [issue35689] IDLE: Docstrings and test for colorizer
In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org>
Message-ID: <1546988183.83.0.71392007024.issue35689@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10968, 10969, 10970
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35689>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:58:07 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 08 Jan 2019 22:58:07 +0000
Subject: [issue35689] IDLE: Docstrings and test for colorizer
In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org>
Message-ID: <1546988287.3.0.10571017946.issue35689@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35689>
_______________________________________

From report at bugs.python.org  Tue Jan  8 17:58:17 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 08 Jan 2019 22:58:17 +0000
Subject: [issue35689] IDLE: Docstrings and test for colorizer
In-Reply-To: <1546987852.48.0.500936785043.issue35689@roundup.psfhosted.org>
Message-ID: <1546988297.68.0.138755807786.issue35689@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -10970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35689>
_______________________________________

From report at bugs.python.org  Tue Jan  8 18:00:39 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Jan 2019 23:00:39 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546988439.8.0.533877632736.issue35596@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> It would be weird if building from sources will not give the same distribution as downloaded from official site. It would be not fair to alternate distributors.

Yes, I agree with that in general but, as I understand it, the change here affects only how the Windows embeddable distribution is packaged.  I don't think we expect alternate distributors to produce such distributions - or do we know of such cases?  And, even if so, it's not a big deal for a third-party to pick up the change. There are parts of the PC and Mac source tree that really are intended only for building of python.org binary releases.  If the changes affected the python executables or standard library files, that would be a very different matter.  It is a trade-off; I just don't think that this is the type of change that needs to trigger a new release cycle and I don't want to go down the path of creating a new level of release.  When was the last time we had a 3.x.y.z? I don't recall one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 18:06:58 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Jan 2019 23:06:58 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1546988818.7.0.900039270765.issue35687@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Also, if you can, please verify that you can reproduce the problem with a current version of Python 3.  3.7.2 is the current maintenance release and 3.6.8 was the final maintenance release of 3.6.x.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 18:25:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 08 Jan 2019 23:25:08 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1546989908.47.0.274044389179.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Agreed. My plan is to just replace the precompiled ZIP file of the standard library in the embeddable package with one with PYCs missing the "check source" bit that the old zipimport rejects. It's as simple as a 1 line change in a supporting script in PC/layout (though the actual change I made is more significant to support other use cases).

The binary and library sources are so identical this doesn't even require a rebuild. And anyone building their own distro from source using this script will hit the issue and find this bug. The only reason I missed it was because I tested against master, not realising that the new zipimport changed behaviour here. Nobody else will be blindly releasing these packages with only tests against an incompatible versions the way we do (and now I have tests).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:07:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 00:07:09 +0000
Subject: [issue35690] IDLE: Fix and test debugger.
Message-ID: <1546992428.61.0.963144948304.issue35690@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Move PR 11451 from #35668.
* Remove use of blank comments to make blank lines.
* Greatly expand test_debugger.
* Fix a couple of issues discovered while writing tests.  (It is possible that one of these caused one of the reported debugger bugs, but we don't need to determine that now.)

----------
messages: 333267
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Fix and test debugger.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35690>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:07:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 00:07:17 +0000
Subject: [issue35690] IDLE: Fix and test debugger.
In-Reply-To: <1546992428.61.0.963144948304.issue35690@roundup.psfhosted.org>
Message-ID: <1546992437.9.0.261937141206.issue35690@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35690>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:08:05 2019
From: report at bugs.python.org (anthony shaw)
Date: Wed, 09 Jan 2019 00:08:05 +0000
Subject: [issue35690] IDLE: Fix and test debugger.
In-Reply-To: <1546992428.61.0.963144948304.issue35690@roundup.psfhosted.org>
Message-ID: <1546992485.43.0.703238094293.issue35690@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +10971
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35690>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:15:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 00:15:08 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546992908.53.0.0786161965425.issue35668@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -10913

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35668>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:27:58 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 09 Jan 2019 00:27:58 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1546993678.0.0.555594897036.issue35686@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Or, obviously:
> 
> with open(fn, 'rb') as fd:
>     with mmap.mmap(fd.fileno(), 0, access=mmap.ACCESS_READ) as mm:
>         with memoryview(mm)[:2] as data:
>             print(data)

Doesn't this rely on the immediate finalization of the unreferenced memoryview instance that creates the slice? It would be nice if memoryview supported alternate constructors memoryview(obj, stop) and memoryview(obj, start, stop[, step]).

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35686>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:33:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 00:33:26 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546994006.1.0.968346885148.issue35668@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I moved the debugger tests to #35690.  I want to keep this issue for general discussion of testing IDLE, and possibly related PRs improving the documentation thereof.

Serhiy Storchaka, the current tkinter maintainer, and I, have decided that IDLE should run with the implicit default root mechanism disabled.  (It allows bugs unless there are no explicit Tk() calls in the process.)

Therefore, tests should run the same way.  But when I put 'tk.NoDefaultRoot()' in the always-run part of test.test_idle, which is usually run with test.regrtest, there were problems.  So I moved it to the 'if main' clause that runs the IDLE suite directly with unittest.  But this clause only executes when test_idle is the main module, such as when one runs 'python -m test.test_idle' instead of 'python -m test -ugui', with or without 'test_idle added to restrict testing to test_idle.

I will add the consequence for the debugger test to the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35668>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:41:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 00:41:29 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1546994489.44.0.0959774740438.issue35687@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:51:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 00:51:59 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1546995119.59.0.0822633599386.issue35638@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

?ukasz Stelmach:
> It is currently impossible to format floating point numbers with an arbitrary number of decimal digits AND the decimal point matching locale settings.

I would like to warn you that handling properly locales can be very tricky. I just wrote an article about that:
https://vstinner.github.io/locale-bugfixes-python3.html


Stefan Krah:
> My main concern with 'm' for libmpdec is that I'd like to reserve it
for LC_MONETARY.

Since it seems like we are still at the "idea" stage, would it make sense to add a function which accept options to choose how to format a number?

* decimal point
* thousands separator
* grouping

Because there are more and more format variants. See for example Python/formatter_unicode.c. It has 5 "locale types":

* LT_NO_LOCALE
* LT_DEFAULT_LOCALE
* LT_UNDERSCORE_LOCALE
* LT_UNDER_FOUR_LOCALE
* LT_CURRENT_LOCALE

and it uses this structure:

/* Locale info needed for formatting integers and the part of floats
   before and including the decimal. Note that locales only support
   8-bit chars, not unicode. */
typedef struct {
    PyObject *decimal_point;
    PyObject *thousands_sep;
    const char *grouping;
    char *grouping_buffer;
} LocaleInfo;

There is the locale but also "underscore" separator for thousands: see PEP 515.

I'm not talking about adding something into format(), but add a method to float maybe. Or add a function somewhere else.

--

By the way, the decimal module doesn't support properly the following corner case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote https://github.com/python/cpython/pull/5191 but I abandonned my change.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35638>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:54:10 2019
From: report at bugs.python.org (anthony shaw)
Date: Wed, 09 Jan 2019 00:54:10 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546995250.31.0.705127309531.issue35668@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
pull_requests: +10972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35668>
_______________________________________

From report at bugs.python.org  Tue Jan  8 19:54:15 2019
From: report at bugs.python.org (anthony shaw)
Date: Wed, 09 Jan 2019 00:54:15 +0000
Subject: [issue35668] Improve test coverage for idlelib
In-Reply-To: <1546724660.21.0.411261013357.issue35668@roundup.psfhosted.org>
Message-ID: <1546995255.91.0.898363186441.issue35668@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
pull_requests: +10972, 10973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35668>
_______________________________________

From report at bugs.python.org  Tue Jan  8 20:39:50 2019
From: report at bugs.python.org (Wencan Deng)
Date: Wed, 09 Jan 2019 01:39:50 +0000
Subject: [issue35691] cpython3.7.2 make test failed
Message-ID: <1546997989.54.0.929715073405.issue35691@roundup.psfhosted.org>


New submission from Wencan Deng <i at wencan.org>:

os: Linux skynet 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
gcc: gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516


FAIL: test_startup_imports (test.test_site.StartupImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wencan/Downloads/Python-3.7.2/Lib/test/test_site.py", line 532, in test_startup_imports
    self.assertFalse(modules.intersection(collection_mods), stderr)
AssertionError: {'collections', 'operator', 'functools', 'types', 'keyword', 'reprlib', 'heapq'} is not false : import _frozen_importlib # frozen
import _imp # builtin
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import '_warnings' # <class '_frozen_importlib.BuiltinImporter'>
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# installing zipimport hook
import 'zipimport' # <class '_frozen_importlib.BuiltinImporter'>
# installed zipimport hook
import '_frozen_importlib_external' # <class '_frozen_importlib.FrozenImporter'>
import '_io' # <class '_frozen_importlib.BuiltinImporter'>
import 'marshal' # <class '_frozen_importlib.BuiltinImporter'>
import 'posix' # <class '_frozen_importlib.BuiltinImporter'>
import _thread # previously loaded ('_thread')
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import _weakref # previously loaded ('_weakref')
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/__init__.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__init__.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/__init__.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/codecs.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/codecs.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/codecs.cpython-37.pyc'
import '_codecs' # <class '_frozen_importlib.BuiltinImporter'>
import 'codecs' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f07a940>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/aliases.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/aliases.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/aliases.cpython-37.pyc'
import 'encodings.aliases' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f095358>
import 'encodings' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f07a3c8>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/utf_8.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/utf_8.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/utf_8.cpython-37.pyc'
import 'encodings.utf_8' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f099080>
import '_signal' # <class '_frozen_importlib.BuiltinImporter'>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/latin_1.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/latin_1.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/encodings/__pycache__/latin_1.cpython-37.pyc'
import 'encodings.latin_1' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f099b38>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/io.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/io.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/io.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/abc.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/abc.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/abc.cpython-37.pyc'
import '_abc' # <class '_frozen_importlib.BuiltinImporter'>
import 'abc' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f0a4160>
import 'io' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f099d68>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/_bootlocale.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/_bootlocale.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/_bootlocale.cpython-37.pyc'
import '_locale' # <class '_frozen_importlib.BuiltinImporter'>
import '_bootlocale' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f0a4780>
Python 3.7.2 (default, Jan  9 2019, 09:31:17) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/site.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/site.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/site.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/os.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/os.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/os.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/stat.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/stat.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/stat.cpython-37.pyc'
import '_stat' # <class '_frozen_importlib.BuiltinImporter'>
import 'stat' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f042128>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/posixpath.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/posixpath.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/posixpath.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/genericpath.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/genericpath.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/genericpath.cpython-37.pyc'
import 'genericpath' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f046be0>
import 'posixpath' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f042860>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/_collections_abc.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/_collections_abc.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/_collections_abc.cpython-37.pyc'
import '_collections_abc' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f050278>
import 'os' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f0afda0>
# /home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/_sitebuiltins.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/build/../Lib/_sitebuiltins.py
# code object from '/home/wencan/Downloads/Python-3.7.2/build/../Lib/__pycache__/_sitebuiltins.cpython-37.pyc'
import '_sitebuiltins' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f034198>
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/types.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/types.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/types.cpython-37.pyc'
import 'types' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f0080b8>
# /home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/__init__.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/importlib/__init__.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/__init__.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/warnings.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/warnings.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/warnings.cpython-37.pyc'
import 'warnings' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f008f98>
import 'importlib' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f008b70>
# /home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/util.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/importlib/util.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/util.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/abc.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/importlib/abc.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/abc.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/machinery.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/importlib/machinery.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/importlib/__pycache__/machinery.cpython-37.pyc'
import 'importlib.machinery' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f01cb70>
import 'importlib.abc' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f01c320>
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/contextlib.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/contextlib.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/contextlib.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/Lib/collections/__pycache__/__init__.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/collections/__init__.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/collections/__pycache__/__init__.cpython-37.pyc'
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/operator.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/operator.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/operator.cpython-37.pyc'
import '_operator' # <class '_frozen_importlib.BuiltinImporter'>
import 'operator' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3efd12b0>
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/keyword.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/keyword.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/keyword.cpython-37.pyc'
import 'keyword' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3efdd358>
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/heapq.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/heapq.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/heapq.cpython-37.pyc'
# extension module '_heapq' loaded from '/home/wencan/Downloads/Python-3.7.2/build/build/lib.linux-x86_64-3.7/_heapq.cpython-37m-x86_64-linux-gnu.so'
# extension module '_heapq' executed from '/home/wencan/Downloads/Python-3.7.2/build/build/lib.linux-x86_64-3.7/_heapq.cpython-37m-x86_64-linux-gnu.so'
import '_heapq' # <_frozen_importlib_external.ExtensionFileLoader object at 0x7fac3efe3278>
import 'heapq' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3efddcc0>
import 'itertools' # <class '_frozen_importlib.BuiltinImporter'>
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/reprlib.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/reprlib.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/reprlib.cpython-37.pyc'
import 'reprlib' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3efe3358>
import '_collections' # <class '_frozen_importlib.BuiltinImporter'>
import 'collections' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3efb4470>
# /home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/functools.cpython-37.pyc matches /home/wencan/Downloads/Python-3.7.2/Lib/functools.py
# code object from '/home/wencan/Downloads/Python-3.7.2/Lib/__pycache__/functools.cpython-37.pyc'
import '_functools' # <class '_frozen_importlib.BuiltinImporter'>
import 'functools' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3efb4860>
import 'contextlib' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f01c9e8>
import 'importlib.util' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f011630>
# possible namespace for /usr/local/lib/python3.7/site-packages/sphinxcontrib
import 'site' # <_frozen_importlib_external.SourceFileLoader object at 0x7fac3f0adac8>

----------
components: Build
messages: 333271
nosy: Wencan Deng
priority: normal
severity: normal
status: open
title: cpython3.7.2 make test failed
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35691>
_______________________________________

From report at bugs.python.org  Tue Jan  8 20:44:42 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 01:44:42 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1546998282.75.0.428957892217.issue35687@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to exist on master. Since they are multilines assertMultiLineEqual is used and is there something incorrect during the diff calculation using ndiff due to absence of '\n'? The current diff is calculated as below with difflib.ndiff and seems to produce incorrect output due to absence of newline. The last change was done for single string comparison with issue9174.

difflib.ndiff calculation done internally for the below reproducer

$ ./python.exe
Python 3.8.0a0 (heads/master:a234e14839, Jan  8 2019, 21:57:35)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import difflib
>>> print(''.join(difflib.ndiff(['a\n', 'b'], ['c\n', 'd'])))
- a
- b+ c
+ d
>>> print(''.join(difflib.ndiff(['a\n', 'b\n'], ['c\n', 'd\n']))) # Possible correct candidate?
- a
- b
+ c
+ d

A simpler reproducer

import unittest

class StdErrUnitTests(unittest.TestCase):

    def test_function_name(self):
        expected = "a\nb"
        actual = "c\nd"

        self.assertEqual(expected, actual)

    def test_function_name_newlines_end(self):
        expected = "a\nb\n"
        actual = "c\nd\n"

        self.assertEqual(expected, actual) # produces extra new line at the diff in the end with \d\n


if __name__ == '__main__':
    unittest.main()

$ ./python.exe ../backups/bpo35687_1.py
FF
======================================================================
FAIL: test_function_name (__main__.StdErrUnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo35687_1.py", line 9, in test_function_name
    self.assertEqual(expected, actual)
AssertionError: 'a\nb' != 'c\nd'
- a
- b+ c
+ d

======================================================================
FAIL: test_function_name_newlines_end (__main__.StdErrUnitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo35687_1.py", line 15, in test_function_name_newlines_end
    self.assertEqual(expected, actual)
AssertionError: 'a\nb\n' != 'c\nd\n'
- a
- b
+ c
+ d


----------------------------------------------------------------------
Ran 2 tests in 0.003s

FAILED (failures=2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 20:52:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 01:52:43 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1546998763.62.0.674294080192.issue35687@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Searching further this seems to be reported earlier with issue24780 with caret displayed wrongly which was also due to newline missing. But the sample case reported here is also listed at one of the examples in https://bugs.python.org/issue24780#msg258466 . There is an open patch with review in the issue. I guess this is a duplicate of issue24780 then?

Related sample case at msg258466

======================================================================
FAIL: test_notrailingnewline_2 (__main__.AssertEqualTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 18, in test_notrailingnewline_2
    self.assertEqual("a\nbcdf", "a\nbddg")
AssertionError: 'a\nbcdf' != 'a\nbddg'
  a
- bcdf+ bddg

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Tue Jan  8 20:55:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 01:55:07 +0000
Subject: [issue24780] difflib.ndiff produces unreadable output when input
 missing trailing newline
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1546998907.25.0.991331190852.issue24780@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Tue Jan  8 21:10:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 02:10:08 +0000
Subject: [issue35691] cpython3.7.2 make test failed
In-Reply-To: <1546997989.54.0.929715073405.issue35691@roundup.psfhosted.org>
Message-ID: <1546999808.57.0.0235738136009.issue35691@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Searching for the error message I reported a very similar one in the past issue34177 that is caused due to installed python causing some problem being imported in the test

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35691>
_______________________________________

From report at bugs.python.org  Tue Jan  8 22:00:16 2019
From: report at bugs.python.org (Jordan Hueckstaedt)
Date: Wed, 09 Jan 2019 03:00:16 +0000
Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises
 WinError instead of returning False
Message-ID: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org>


New submission from Jordan Hueckstaedt <assumptionsoup at gmail.com>:

Tested in 3.7.0 on windows 10.
This looks related to https://bugs.python.org/issue22759


>>> import pathlib
>>> pathlib.Path(r"E:\Whatever\blah.txt").exists()  # This drive doesn't exist
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\jordanhu\AppData\Local\Continuum\anaconda2\envs\py3\lib\pathlib.py", line 1318, in exists
    self.stat()
  File "C:\Users\jordanhu\AppData\Local\Continuum\anaconda2\envs\py3\lib\pathlib.py", line 1140, in stat
    return self._accessor.stat(self)
PermissionError: [WinError 21] The device is not ready: 'E:\\Whatever\\blah.txt'
>>> pathlib.Path(r"C:\Whatever\blah.txt").exists() # This drive exists
False

----------
messages: 333275
nosy: Jordan Hueckstaedt
priority: normal
severity: normal
status: open
title: pathlib.Path.exists() on non-existent drive raises WinError instead of returning False
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35692>
_______________________________________

From report at bugs.python.org  Tue Jan  8 22:18:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 03:18:26 +0000
Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises
 WinError instead of returning False
In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org>
Message-ID: <1547003906.59.0.468658252711.issue35692@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35692>
_______________________________________

From report at bugs.python.org  Tue Jan  8 22:23:07 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Jan 2019 03:23:07 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1547004187.62.0.69084815042.issue35596@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I've updated the files and sent Ned the info needed to confirm and update the download page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 23:25:06 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 04:25:06 +0000
Subject: [issue24780] difflib.ndiff produces unreadable output when input
 missing trailing newline
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547007906.82.0.512294526748.issue24780@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Looking at the patch and the relevant function this doesn't seem to be a problem with difflib.ndiff but with unittest's display algorithm. This causes confusion about the issue and I propose changing the subject to reflect this unless difflib maintainers think this is an issue with ndiff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Tue Jan  8 23:30:37 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 09 Jan 2019 04:30:37 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1547008237.17.0.291757522414.issue35596@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks, Steve.  The download page for 3.7.2 has now been updated with the URLs for the modified embeddable files, the CDN caches updated, and the original embeddable download files and their GPG signature files are no longer accessible so references to the original URLs will result in hard failures.  I considered updating the 3.7.2 blog announcement but decided against it as likely adding more confusion than it was worth.  There just aren't that many users yet of the embeddable files.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Tue Jan  8 23:46:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 04:46:51 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windows Store
In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>
Message-ID: <1547009211.69.0.355088366735.issue35688@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
title: "pip install --user numpy" fails on Python from the Windos Store -> "pip install --user numpy" fails on Python from the Windows Store

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:01:35 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:01:35 +0000
Subject: [issue35693] test_httpservers fails
Message-ID: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>


New submission from Jorge Ramos <neyuru at gmail.com>:

when running <rt.bat -x64> test_httpservers fails:


0:04:53 [171/407] test_httpservers
E:\RepoGiT\3.6\lib\socket.py:144: ResourceWarning: unclosed <socket.socket [closed] fd=1312, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  _socket.socket.__init__(self, family, type, proto, fileno)
E:\RepoGiT\3.6\lib\test\support\__init__.py:1542: ResourceWarning: unclosed <socket.socket [closed] fd=1988, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  gc.collect()
test test_httpservers failed -- multiple errors occurred; run in verbose mode for details


full run on attached file

----------
components: Tests, Windows
files: run.txt
messages: 333279
nosy: neyuru, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_httpservers fails
versions: Python 3.6
Added file: https://bugs.python.org/file48034/run.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:08:15 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:08:15 +0000
Subject: [issue35694] missing modules on test suite
Message-ID: <1547010493.14.0.290956143834.issue35694@roundup.psfhosted.org>


New submission from Jorge Ramos <neyuru at gmail.com>:

when running <rt.bat -x64> some tests where skipped due to missing modules:

0:02:52 [ 86/407] test_crypt
test_crypt skipped -- No module named '_crypt'
0:02:55 [ 93/407] test_dbm_gnu
test_dbm_gnu skipped -- No module named '_gdbm'
0:02:55 [ 94/407] test_dbm_ndbm -- test_dbm_gnu skipped
test_dbm_ndbm skipped -- No module named '_dbm'
0:05:25 [183/407/1] test_ioctl
test_ioctl skipped -- No module named 'fcntl'
0:07:43 [224/407/1] test_nis
test_nis skipped -- No module named 'nis'


full verbose on attached file

----------
components: Tests, Windows
files: run.txt
messages: 333280
nosy: neyuru, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: missing modules on test suite
versions: Python 3.6
Added file: https://bugs.python.org/file48035/run.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35694>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:10:31 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 05:10:31 +0000
Subject: [issue35694] missing modules on test suite
In-Reply-To: <1547010493.14.0.290956143834.issue35694@roundup.psfhosted.org>
Message-ID: <1547010631.49.0.67526530049.issue35694@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This is expected, the named modules or accelerators do not exist on Windows.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35694>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:13:55 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:13:55 +0000
Subject: [issue35695] missing attributes
Message-ID: <1547010834.19.0.61434721558.issue35695@roundup.psfhosted.org>


New submission from Jorge Ramos <neyuru at gmail.com>:

while running <rt.bat -x64>:

0:04:26 [136/407] test_fork1
test_fork1 skipped -- object <module 'os' from 'E:\\RepoGiT\\3.6\\lib\\os.py'> has no attribute 'fork'
0:11:56 [384/407/1] test_wait4 -- test_wait3 skipped
test_wait4 skipped -- object <module 'os' from 'E:\\RepoGiT\\3.6\\lib\\os.py'> has no attribute 'fork'

see attached file

----------
components: Tests, Windows
files: run.txt
messages: 333282
nosy: neyuru, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: missing attributes
versions: Python 3.6
Added file: https://bugs.python.org/file48036/run.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35695>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:16:12 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 05:16:12 +0000
Subject: [issue35695] missing attributes
In-Reply-To: <1547010834.19.0.61434721558.issue35695@roundup.psfhosted.org>
Message-ID: <1547010972.97.0.905766472048.issue35695@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

This is expected; `os.fork` does not exist on Windows.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35695>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:17:49 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:17:49 +0000
Subject: [issue35694] missing modules on test suite
In-Reply-To: <1547010493.14.0.290956143834.issue35694@roundup.psfhosted.org>
Message-ID: <1547011069.35.0.596202735831.issue35694@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

Got it (y)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35694>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:19:35 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:19:35 +0000
Subject: [issue35695] missing attributes
In-Reply-To: <1547010834.19.0.61434721558.issue35695@roundup.psfhosted.org>
Message-ID: <1547011175.46.0.0281473825982.issue35695@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

Got it, maybe the warnings should be more explanatory, like this one:

0:06:17 [219/407/1] test_multiprocessing_fork
test_multiprocessing_fork skipped -- fork is not available on Windows
0:06:17 [220/407/1] test_multiprocessing_forkserver -- test_multiprocessing_fork skipped
test_multiprocessing_forkserver skipped -- forkserver is not available on Windows

just my 2 cents.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35695>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:23:00 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 05:23:00 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547011380.97.0.201206265615.issue35693@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Try running `rt.bat -x64 -v test_httpservers`, which will run just that test in verbose mode.  If that happens to pass, try `rt.bat -x64 -wW`, which will show the verbose output of a failed test and retry just the failed test at the end of the full run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:25:12 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:25:12 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547011512.97.0.733142312814.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

Got it, i'll get back with the results

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 00:28:35 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 05:28:35 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547011715.98.0.889038411278.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

The test failed, the results on attached file!

----------
Added file: https://bugs.python.org/file48037/failed.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 01:12:31 2019
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 09 Jan 2019 06:12:31 +0000
Subject: [issue24780] difflib.ndiff produces unreadable output when input
 missing trailing newline
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547014351.96.0.0881127544747.issue24780@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

When I first created the issue, the title I chose was about unittest ("unittest assertEqual difference output foiled by newlines"), but someone else changed it for some reason. You're welcome to change it back to something more like the original.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Wed Jan  9 01:47:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Jan 2019 06:47:02 +0000
Subject: [issue35596] Fatal Python error: initfsencoding: unable to load the
 file system codec zipimport.ZipImportError: can't find module 'encodings'
In-Reply-To: <1545927507.21.0.851075424973.issue35596@roundup.psfhosted.org>
Message-ID: <1547016422.78.0.809799206315.issue35596@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> When was the last time we had a 3.x.y.z? I don't recall one.

My apologies, it seems my memory has tricked me. I thought there was on in the 3.3 branch, but it was just that the third number was bumped again just a month ago after a bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35596>
_______________________________________

From report at bugs.python.org  Wed Jan  9 01:53:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Jan 2019 06:53:06 +0000
Subject: [issue35677] Do not automount in stat() by default
In-Reply-To: <1546852678.92.0.232634094535.issue35677@roundup.psfhosted.org>
Message-ID: <1547016786.5.0.0345216423328.issue35677@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I was going to merge PR 11455 as a bug fix and backport it to 3.7, and add a new "automount=False" optional parameter in a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35677>
_______________________________________

From report at bugs.python.org  Wed Jan  9 03:08:59 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 09 Jan 2019 08:08:59 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1547021339.29.0.107832166891.issue34656@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Should this go to 3.4 and 3.5 as well, since it is a security thing?

http://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-20406.html

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Wed Jan  9 04:26:41 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 09 Jan 2019 09:26:41 +0000
Subject: [issue35696] remove unnecessary operation in long_compare()
Message-ID: <1547025999.59.0.0318422017652.issue35696@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

static int
long_compare(PyLongObject *a, PyLongObject *b)
{
    ....
}

This function in /Objects/longobject.c is used to compare two PyLongObject's value.
We only need the sign, converting to -1 or +1 is not necessary.

----------
messages: 333293
nosy: Ma Lin
priority: normal
severity: normal
status: open
title: remove unnecessary operation in long_compare()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35696>
_______________________________________

From report at bugs.python.org  Wed Jan  9 04:27:33 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 09 Jan 2019 09:27:33 +0000
Subject: [issue35696] remove unnecessary operation in long_compare()
In-Reply-To: <1547025999.59.0.0318422017652.issue35696@roundup.psfhosted.org>
Message-ID: <1547026053.87.0.681781337181.issue35696@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch
pull_requests: +10974
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35696>
_______________________________________

From report at bugs.python.org  Wed Jan  9 04:27:41 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 09 Jan 2019 09:27:41 +0000
Subject: [issue35696] remove unnecessary operation in long_compare()
In-Reply-To: <1547025999.59.0.0318422017652.issue35696@roundup.psfhosted.org>
Message-ID: <1547026061.37.0.353820985566.issue35696@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch, patch
pull_requests: +10974, 10975
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35696>
_______________________________________

From report at bugs.python.org  Wed Jan  9 04:27:45 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 09 Jan 2019 09:27:45 +0000
Subject: [issue35696] remove unnecessary operation in long_compare()
In-Reply-To: <1547025999.59.0.0318422017652.issue35696@roundup.psfhosted.org>
Message-ID: <1547026065.62.0.134733173768.issue35696@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10974, 10975, 10976
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35696>
_______________________________________

From report at bugs.python.org  Wed Jan  9 04:33:25 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Jan 2019 09:33:25 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1547026405.23.0.0683298251208.issue34656@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not sure this issue should be classified as a security issue. It can cause DDOS, because pickle should not be used with untrusted data. If it is used, the program has more severe security issues than just DDOS.

The crash could be triggered by accident, but this is very unlikely. I doubts that this happened even once in real world.  Libraries used for handling a large amount of data (like NumPy) use more efficient pickle representation, and can provide even more efficient alternate serialization methods. Note that integers and floats are not memoized, this increases the complexity and size of data that could be affected by this bug.

But I think that this fix needs a news entry. Do you mind to add it Benjamin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Wed Jan  9 05:07:44 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 09 Jan 2019 10:07:44 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547028464.77.0.841350035324.issue24780@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks @chris.jerdonek. I have reverted the title to original report. Since CPython now accepts PR if any one of the original authors can convert their patch to a PR with tests then it will be great.

----------
title: difflib.ndiff produces unreadable output when input missing trailing newline -> unittest assertEqual difference output foiled by newlines

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Wed Jan  9 05:09:23 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 10:09:23 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1547028563.67.0.985967187906.issue35638@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> Since it seems like we are still at the "idea" stage, would it make sense to add a function which accept options to choose how to format a number?

Maybe, but I think for format() Eric's latest proposal on python-ideas is great ("*f" for "f + LC_NUMERIC", "$f" for "f + LC_MONETARY".

For me that's sufficient. Does locale.format_string() handle the other cases?


> By the way, the decimal module doesn't support properly the following corner case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote https://github.com/python/cpython/pull/5191 but I abandonned my change.

Well, I *discovered and opened* #7442 several years ago, and you said:

"I see that various people contributed to the issue, but it looks like the only user asking for the request is Stefan Krah. I prefer to close the issue and wait until more users ask for it before considering again the patch, or find a different way to implement the feature (support LC_NUMERIC and LC_CTYPE locales using a different encoding)."


So why would you think that I'm not aware of that issue? It has low priority for me and I hesitate to depend on the official locale functions in decimal because I don't want to be involved in additional issue reports in that area.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35638>
_______________________________________

From report at bugs.python.org  Wed Jan  9 05:49:57 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Stelmach?=)
Date: Wed, 09 Jan 2019 10:49:57 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1547030997.18.0.688831936278.issue35638@roundup.psfhosted.org>


?ukasz Stelmach <steelman at post.pl> added the comment:

I'd appreciate, if we continued the discussion at python-ideas, where I posted the idea[1]. There has already been several valuable comments.

[1] https://mail.python.org/pipermail/python-ideas/2019-January/054793.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35638>
_______________________________________

From report at bugs.python.org  Wed Jan  9 05:50:33 2019
From: report at bugs.python.org (Addons Zz)
Date: Wed, 09 Jan 2019 10:50:33 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1547031033.94.0.702624283107.issue35687@roundup.psfhosted.org>


Addons Zz <addonszz at outlook.com> added the comment:

The issue is also reproducible, by directly using difflib:
```python
import difflib

def bugged_diff(expected, actual):
    expected = expected.splitlines( 1 )
    actual = actual.splitlines( 1 )

    # diff = difflib.ndiff( expected, actual )
    if expected != actual:
        diff = difflib.context_diff( expected, actual, fromfile='expected input', tofile='actual output', lineterm='\n' )
        return '\n' + ''.join( diff )


if __name__ == '__main__':
    expected = "testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary\n" \
            "testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}"

    actual = "15:49:35:912.348986 - testing.main_unit_tests - dictionary\n" \
            "15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}"

    print( expected, actual )
```

It outputs:
```
testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'} 15:49:35:912.348986 - testing.main_unit_tests - dictionary
15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}
```

But it should be: (still missing the new line on the same place as `assertEqual` does)
```
testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'} 
15:49:35:912.348986 - testing.main_unit_tests - dictionary
15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Wed Jan  9 05:56:08 2019
From: report at bugs.python.org (Addons Zz)
Date: Wed, 09 Jan 2019 10:56:08 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1547031368.68.0.364902152295.issue35687@roundup.psfhosted.org>


Addons Zz <addonszz at outlook.com> added the comment:

* Correction
```python
import difflib

def bugged_diff(expected, actual):
    expected = expected.splitlines( 1 )
    actual = actual.splitlines( 1 )

    # diff = difflib.ndiff( expected, actual )
    if expected != actual:
        diff = difflib.context_diff( expected, actual, fromfile='expected input', tofile='actual output', lineterm='\n' )
        return '\n' + ''.join( diff )


if __name__ == '__main__':
    expected = "testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary\n" \
            "testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}"

    actual = "15:49:35:912.348986 - testing.main_unit_tests - dictionary\n" \
            "15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}"

    print( bugged_diff( expected, actual ) )
```

Outputs:
```
*** expected input
--- actual output
***************
*** 1,2 ****
! testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
! testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}--- 1,2 ----
! 15:49:35:912.348986 - testing.main_unit_tests - dictionary
! 15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}
```

May be it should be:
```

*** expected input
--- actual output
***************
*** 1,2 ****
! testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary
! testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}
--- 1,2 ----
! 15:49:35:912.348986 - testing.main_unit_tests - dictionary
! 15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:04:13 2019
From: report at bugs.python.org (Addons Zz)
Date: Wed, 09 Jan 2019 11:04:13 +0000
Subject: [issue35687] The unittest module diff is missing/forgetting/not
 putting newline before + and ? for some inputs
In-Reply-To: <1546984668.06.0.145226274602.issue35687@roundup.psfhosted.org>
Message-ID: <1547031853.57.0.059554856156.issue35687@roundup.psfhosted.org>


Addons Zz <addonszz at outlook.com> added the comment:

I applied the patch from https://bugs.python.org/file44679 and it fixed the issue for this example using the unittest module:
```python
import unittest

class StdErrUnitTests(unittest.TestCase):

    def test_function_name(self):
        expected = "testing.main_unit_tests.test_dictionaryBasicLogging:416 - dictionary\n" \
                "testing.main_unit_tests.test_dictionaryBasicLogging:417 - dictionary {1: 'defined_chunk'}"

        actual = "15:49:35:912.348986 - testing.main_unit_tests - dictionary\n" \
                "15:49:35:918.879986 - testing.main_unit_tests - dictionary {1: 'defined_chunk'}"

        self.assertEqual(expected, actual)

if __name__ == '__main__':
    unittest.main()
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35687>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:29:49 2019
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 09 Jan 2019 11:29:49 +0000
Subject: [issue35550] Some define guards for Solaris are wrong
In-Reply-To: <1545386883.42.0.788709270274.issue35550@psf.upfronthosting.co.za>
Message-ID: <1547033389.29.0.789160171985.issue35550@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

We are building previous versions of Python with Solaris Studio which works with define guards as they are right now. 3.7 is first version build with gcc. We don't plan to switch to gcc on 2.7 and so it doesn't affect us.

But I guess if this fix can be done easily, it would be correct to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35550>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:31:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:31:50 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
Message-ID: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The decimal module support formatting a number in the "n" formatting type if the LC_NUMERIC locale uses a different encoding than the LC_CTYPE locale. 

Example with attached decimal_locale.py on Fedora 29 with Python 3.7.2:

$ python3 decimal_locale.py 
LC_NUMERIC locale: uk_UA.koi8u
decimal_point: ',' = ',' = U+002c
thousands_sep: '\xa0' = '\xa0' = U+00a0
Traceback (most recent call last):
  File "/home/vstinner/decimal_locale.py", line 16, in <module>
    text = format(num, "n")
ValueError: invalid decimal point or unsupported combination of LC_CTYPE and LC_NUMERIC

Attached PR modify the _decimal module to support this corner case.

Note: I already wrote PR 5191 last year, but I abandoned the PR in the meanwhile.

--

Supporting non-ASCII decimal point and thousands separator has a long history and a list of now fixed issues:

* bpo-7442
* bpo-13706
* bpo-25812
* bpo-28604 (LC_MONETARY)
* bpo-31900
* bpo-33954

I even wrote an article about these bugs :-)
https://github.com/python/cpython/pull/5191

Python 3.7.2 now supports different encodings for LC_NUMERIC, LC_MONETARY and LC_CTYPE locales. format(int, "n") sets temporarily LC_CTYPE to LC_NUMERIC to decode decimal_point and thousands_sep from the correct encoding. The LC_CTYPE locale is only changed if it's different than LC_NUMERIC locale and if the decimal point and/or thousands separator is non-ASCII. It's implemented in this function:

int
_Py_GetLocaleconvNumeric(struct lconv *lc,
                         PyObject **decimal_point, PyObject **thousands_sep)

Function used by locale.localeconv() and format() (for "n" type).

I decided to fix the bug when I was fixing other locale bugs because we now got enough bug reports.

Copy of my msg309980:

"""
> I would not consider this a bug in Python, but rather in the locale settings passed to setlocale().

Past 10 years, I repeated to every single user I met that "Python 3 is right, your system setup is wrong". But that's a waste of time. People continue to associate Python3 and Unicode to annoying bugs, because they don't understand how locales work.

Instead of having to repeat to each user that "hum, maybe your config is wrong", I prefer to support this non convential setup and work as expected ("it just works"). With my latest implementation, setlocale() is only done when LC_CTYPE and LC_NUMERIC are different, which is the corner case which "shouldn't occur in practice".
"""

----------
components: Library (Lib)
files: decimal_locale.py
messages: 333302
nosy: vstinner
priority: normal
severity: normal
status: open
title: decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE
versions: Python 3.8
Added file: https://bugs.python.org/file48038/decimal_locale.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:33:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:33:50 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547033630.94.0.405719565791.issue35697@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, I was wrong: bpo-25812 has not been fixed yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:36:37 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 11:36:37 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547033797.21.0.900830672261.issue35697@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
assignee:  -> skrah
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:41:28 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 11:41:28 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547034088.42.0.19563564006.issue35697@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Since #7442 (again, *I* discovered this and it is *mentioned* in the
_decimal sources), there have been zero bug reports about decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:42:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:42:56 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547034176.77.0.707916427895.issue35697@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +10977
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:43:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:43:02 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547034182.29.0.319254280179.issue35697@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +10977, 10978
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:43:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:43:07 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547034187.72.0.216862762896.issue35697@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +10977, 10978, 10979
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:46:13 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 09 Jan 2019 11:46:13 +0000
Subject: [issue35698] Division by 2 in statistics.median
Message-ID: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>


New submission from Jonathan Fine <jfine2358 at gmail.com>:

When len(data) is odd, median returns the average of the two middle values. This average is computed using
        i = n//2
        return (data[i - 1] + data[i])/2

This results in the following behaviour

>>> from fractions import Fraction
>>> from statistics import median
>>> F1 = Fraction(1, 1)

>>> median([1])
1
>>> median([1, 1]) # Example 1.
1.0

>>> median([F1])
Fraction(1, 1)
>>> median([F1, F1])
Fraction(1, 1)

>>> median([2, 2, 1, F1]) # Example 2.
Fraction(3, 2)

>>> median([2, 2, F1, 1]) # Example 3.
1.5

Perhaps, when len(data) is odd, it would be better to test the two middle values for equality. This would resolve Example 1. It would not help with Examples 2 and 3, which might not have a satisfactory solution.

See also issue 33084.

----------
messages: 333305
nosy: jfine2358
priority: normal
severity: normal
status: open
title: Division by 2 in statistics.median
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:47:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:47:21 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547034441.52.0.0858685788424.issue35697@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, I wrote PR 11474. Correct result with this PR:

$ ./python decimal_locale.py 
LC_NUMERIC locale: uk_UA.koi8u
decimal_point: ',' = ',' = U+002c
thousands_sep: '\xa0' = '\xa0' = U+00a0
format: '1\xa0200,5' = 1 200,5 = U+0031 U+00a0 U+0032 U+0030 U+0030 U+002c U+0035

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:50:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:50:11 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547034611.46.0.585545476981.issue35697@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Stefan Krah:
> Since #7442 (again, *I* discovered this and it is *mentioned* in the
_decimal sources), ...

I closed bpo-7442 in the meanwhile, so I opened this new issue specific to the decimal module.

> ... there have been zero bug reports about decimal.

Well, here you have :-) A bug report about decimal.

I let you decide what to do with this bug. I wrote a fix. It's up to you to merge it, reject it or do nothing :-)

I wanted to make sure that the bug is fixed in all parts of the Python stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:53:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:53:37 +0000
Subject: [issue25812] locale.nl_langinfo() can't decode value
In-Reply-To: <1449350345.3.0.205814810685.issue25812@psf.upfronthosting.co.za>
Message-ID: <1547034817.59.0.967582042804.issue25812@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Since this bug has been reported, locale.localeconv() has been fixed in bpo-31900 to temporarily set LC_CTYPE to LC_NUMERIC to decode numeric fields of localeconv() from the proper encoding. I guess that a similar fix can be applied to locale.nl_langinfo(): set LC_CTYPE to LC_NUMERIC if the parameter is a numeric field.

I only knew locale.nl_langinfo(locale.CODESET). I didn't know that this function accepted other arguments :-)

I even wrote an article about these locale bugs :-)
https://github.com/python/cpython/pull/5191

See also bpo-35697: "decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25812>
_______________________________________

From report at bugs.python.org  Wed Jan  9 06:58:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 11:58:33 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547035113.63.0.650028193044.issue35698@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> When len(data) is odd, median returns the average of the two middle values.

I'm not sure that I understand your issue. Do you consider that it's a bug? It's part of the definition of the median function, no?
https://en.wikipedia.org/wiki/Median#Finite_set_of_numbers

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Wed Jan  9 07:00:25 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 12:00:25 +0000
Subject: [issue35697] decimal: formatter error if LC_NUMERIC uses a different
 encoding than LC_CTYPE
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547035225.57.0.400029838038.issue35697@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Don't you find it strange to close #7442 in mutual agreement and now
mention the word "bug" 50 times?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 07:18:09 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 12:18:09 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547036289.27.0.878553665461.issue35697@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
title: decimal: formatter error if LC_NUMERIC uses a different encoding than LC_CTYPE -> _decimal: Implement the previously rejected changes from #7442.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 07:39:16 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 12:39:16 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547037556.57.0.923517303303.issue35697@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Also Marc-Andre does not consider this a bug in #31900.  The
presentation of this issue is increasingly bizarre.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 07:53:55 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Wed, 09 Jan 2019 12:53:55 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Message-ID: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>


New submission from Marc Schlaich <marc.schlaich at googlemail.com>:

vshwere.exe doesn't return Build Tools 2017 per default. This means Build Tools 2017 are not detected by distutils in 3.7.2 and you get the famous "Microsoft Visual C++ 14.0 is required" error.

Please see https://github.com/Microsoft/vswhere/issues/125 for more details.

The solution is to add 

    "-products", "*",

to the vswhere.exe call.

This is a regression of https://bugs.python.org/issue35067.

----------
components: Distutils
messages: 333312
nosy: dstufft, eric.araujo, schlamar, steve.dower
priority: normal
severity: normal
status: open
title: distutils cannot find Build Tools 2017 since 3.7.2
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:07:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 13:07:59 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547039279.18.0.558757498385.issue35697@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Stefan Krah:
> Don't you find it strange to close #7442 in mutual agreement and now
mention the word "bug" 50 times?

We agreed to close the bug in 2014. In the meanwhile, more and more people reported the same bug (multiple similar bug reports and more and more frequent messages). So I decided to fix the bug instead of explaining to users that they must not do that :-)


> Also Marc-Andre does not consider this a bug in #31900.  The
presentation of this issue is increasingly bizarre.

Aha, maybe I misunderstood him when he wrote (msg309981):

"Sounds like a good compromise :-)"

--

I'm not sure of what you are asking here. You are the maintainer of the decimal module. If you consider that it's not worth it, just close the issue. It's up to you ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:13:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 13:13:43 +0000
Subject: [issue35550] Some define guards for Solaris are wrong
In-Reply-To: <1545386883.42.0.788709270274.issue35550@psf.upfronthosting.co.za>
Message-ID: <1547039623.96.0.272300297212.issue35550@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> We don't plan to switch to gcc on 2.7 and so it doesn't affect us.

Ok. I close the issue. If anyone wants to fix 2.7, please go ahead :-)

----------
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35550>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:14:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 13:14:43 +0000
Subject: [issue35638] Introduce fixed point locale aware format type for
 floating point numbers
In-Reply-To: <1546428301.89.0.74748590824.issue35638@roundup.psfhosted.org>
Message-ID: <1547039683.75.0.27288265986.issue35638@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> By the way, the decimal module doesn't support properly the following corner case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote https://github.com/python/cpython/pull/5191 but I abandonned my change.

FYI I opened bpo-35697 to discuss the decimal module case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35638>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:15:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 13:15:15 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547039715.17.0.926527014054.issue35697@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, I forgot to mention the context: I reported this issue as follow-up to discussions on bpo-35638: "Introduce fixed point locale aware format type for floating point numbers".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:20:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 13:20:55 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547040055.8.0.0470624121806.issue35697@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Extract of Stefan Krah's msg333296 of bpo-35638:

> So why would you think that I'm not aware of that issue?

Oh, I never said that.

I wrote "By the way, the decimal module doesn't support properly the following corner case: LC_NUMERIC using an encoding different than LC_CTYPE encoding. I wrote https://github.com/python/cpython/pull/5191 but I abandonned my change." as a reminder for myself. I found again the bug when I wrote my article, and I realized that I abandoned my PR when I had my burnout, and not because the fix was "officially" rejected.

So I opened this issue to get an official statement :-)


> It has low priority for me and I hesitate to depend on the official locale functions in decimal because I don't want to be involved in additional issue reports in that area.

As I wrote in my PR, I'm not very happy of my proposed implementation. But let's discuss options to fix it :-)

I don't understand "I don't want to be involved in additional issue reports in that area". If the bug is fixed, why do you expect more bug reports? You wrote that nobody reported any issue related to formatting a decimal number using the locale since 2009.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:31:39 2019
From: report at bugs.python.org (Peter Vex)
Date: Wed, 09 Jan 2019 13:31:39 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
Message-ID: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>


New submission from Peter Vex <petiacdc at gmail.com>:

When you want to simply place a widget on a window and you also want to store the reference for that widget in a variable you can't do that in one line, which is really unpleasant, because when you create a new widget these things are usually the first what you want to do with a widget and breaking it two line is just making things more complicated.

For example, if you want to create 3 label, place it next to each other and store their reference:

import tkinter as tk
root = tk.Tk()

# you can't do that:
# here the variables assigned to None, since grid() returns 'nothing'
label1 = tk.Label(root).grid(row=0, column=0)
label2 = tk.Label(root).grid(row=0, column=1)
label3 = tk.Label(root).grid(row=0, column=2)

# actually, you must do this:
label1 = tk.Label(root)
label1.grid(row=0, column=0)
label2 = tk.Label(root)
label2.grid(row=0, column=1)
label3 = tk.Label(root)
label3.grid(row=0, column=2)

----------
components: Tkinter
messages: 333318
nosy: Peter Vex
priority: normal
pull_requests: 10980
severity: normal
status: open
title: Place, Pack and Grid should return the widget
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:38:46 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 09 Jan 2019 13:38:46 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041126.19.0.0518656758456.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset cbb16459934eaf29c7c7d362939cd05550b2f21f by Senthil Kumaran (Sanyam Khurana) in branch 'master':
bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (#10639)
https://github.com/python/cpython/commit/cbb16459934eaf29c7c7d362939cd05550b2f21f


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:39:11 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:39:11 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041151.77.0.544322487039.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10981
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:39:20 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:39:20 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041160.75.0.112880387675.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10981, 10982
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:39:32 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:39:32 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041172.51.0.545306726332.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10982, 10985

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:39:40 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:39:40 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041180.87.0.693557659041.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10981, 10982, 10983, 10985
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:39:47 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:39:47 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041187.86.0.366372097887.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10981, 10982, 10983, 10984, 10985
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:39:54 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:39:54 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547041194.3.0.921571590484.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10982, 10983, 10984, 10985, 10986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 08:56:51 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 13:56:51 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547042211.76.0.390753560538.issue24746@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 53cf5f084b01cb16630361be5377047c068d2b44 by Miss Islington (bot) in branch '3.7':
bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (GH-10639)
https://github.com/python/cpython/commit/53cf5f084b01cb16630361be5377047c068d2b44


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 09:12:36 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 09 Jan 2019 14:12:36 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547043156.48.0.474172742511.issue35697@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I mean issue reports like #33954 or #35195.  These are just
two examples, and I'm NOT claiming that they are related.

But if functions like _PyUnicode_InsertThousandsGrouping()
*were* used in _decimal, I'd feel compelled to investigate.

Now I don't have to. I'd investigate #35195 for example, perhaps
just to find out that it has an entirely different cause.


Sometimes not being dependent on API functions is a virtue if
the code does not change very often.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Wed Jan  9 09:46:32 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 09 Jan 2019 14:46:32 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547045192.23.0.100989230326.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 5d9ae8b9df8371dd65514e0d60b561fd37056986 by Senthil Kumaran (Miss Islington (bot)) in branch '3.6':
bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (GH-10639) (#11477)
https://github.com/python/cpython/commit/5d9ae8b9df8371dd65514e0d60b561fd37056986


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 09:51:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Jan 2019 14:51:35 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547045495.97.0.154349903099.issue35700@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Methods place(), pack() and grid() correspond to corresponding Tk commands. These commands return nothing (empty string) in Tk, and Tkinter methods return nothing (None) in Python. If they will became returning something meaningful in future versions of Tk, we will lost a chance to translate this to Python if make them now returning the widget itself.

Note also that method chaining is not commonly used in Python. This code would look pretty unpythonic.

For these reasons I am against this idea.

----------
nosy: +gpolo, serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:19:01 2019
From: report at bugs.python.org (Peter Vex)
Date: Wed, 09 Jan 2019 15:19:01 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547047141.85.0.910676233957.issue35700@roundup.psfhosted.org>


Peter Vex <petiacdc at gmail.com> added the comment:

I can somewhat agreed with your point, even if it's not too realistic, but reasonable enough.

Also, I'd only use method chaining, because that'd be the only option. I can't pass an argument to tk.Label at creation like 'manager="grid"' or anything like that. In any case, I think doing it in a separate line makes the code longer and less readable even if it's pythonic.

Thanks for your consideration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:20:06 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 15:20:06 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1547047206.18.0.305691994153.issue8538@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +10987
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:20:25 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 15:20:25 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1547047225.41.0.6779391916.issue8538@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch
pull_requests: +10987, 10988
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:20:44 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 15:20:44 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1547047244.47.0.70499190557.issue8538@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch, patch
pull_requests: +10987, 10988, 10989
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:36:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 15:36:11 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048171.31.0.831938387328.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +10990

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:36:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 15:36:21 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048181.88.0.262707718042.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +10990, 10991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:36:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 15:36:32 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048192.11.0.873522725975.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +10990, 10991, 10992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:40:04 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 15:40:04 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048404.56.0.801550604582.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -10992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:40:14 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 15:40:14 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1547048414.28.0.324742833871.issue8538@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I made a first proposal for this feature in PR 11478, I had to adapt argparse.Action to customize how the action is represented in the usage string by adding a format_usage() method that would default to the current behavior if not overridden.

Other methods to do this may be better but I did not find them.

----------
versions: +Python 3.7, Python 3.8 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:40:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 15:40:21 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048421.22.0.0147000178067.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -10991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:44:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 15:44:11 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048651.82.0.353767631135.issue35641@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ee6559436797032b816dfb8c6376c9a451014962 by Terry Jan Reedy in branch 'master':
bpo-35641: Move IDLE blurb to IDLE directory (#11479)
https://github.com/python/cpython/commit/ee6559436797032b816dfb8c6376c9a451014962


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:44:15 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 15:44:15 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547048655.2.0.0834008704162.issue35698@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

What do you think median([1, 1.0]) should return?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:44:27 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 15:44:27 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048667.95.0.563688988012.issue35641@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10993

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:44:39 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 15:44:39 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048679.69.0.969179927507.issue35641@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10993, 10994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:44:51 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 15:44:51 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048691.19.0.34489742711.issue35641@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +10993, 10994, 10995

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:49:44 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 09 Jan 2019 15:49:44 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547048984.89.0.790474733809.issue35641@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6f76ef81596bbd885957b7fea3f40024ed9d6797 by Miss Islington (bot) in branch '3.7':
bpo-35641: Move IDLE blurb to IDLE directory (GH-11479)
https://github.com/python/cpython/commit/6f76ef81596bbd885957b7fea3f40024ed9d6797


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 10:50:56 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 15:50:56 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547049056.81.0.0157858622452.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

The thread doesn't display the attachment icon in bugtracker webpage, so I will copy the output here:

E:\RepoGiT\3.6>PCbuild\rt.bat -x64 -v test_httpservers
Deleting .pyc files ...
0 .pyc deleted
Cleaning _pth files ...

E:\RepoGiT\3.6>"E:\RepoGiT\3.6\PCbuild\amd64\python.exe"  -u -Wd -E -bb -m test  -v test_httpservers
== CPython 3.6.8+ (heads/3.6:c2340619a7, Jan 7 2019, 21:35:13) [MSC v.1916 64 bit (AMD64)]
== Windows-10-10.0.17763-SP0 little-endian
== cwd: E:\RepoGiT\3.6\build\test_python_19808
== CPU count: 8
== encodings: locale=cp1252, FS=utf-8
Run tests sequentially
0:00:00 [1/1] test_httpservers
test_err (test.test_httpservers.RequestHandlerLoggingTestCase) ... ok
test_get (test.test_httpservers.RequestHandlerLoggingTestCase) ... ok
test_close_connection (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_date_time_string (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_error (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_header (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_response_only (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_length (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_unbuffered_when_continue (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_html_escape_on_error (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_0_9 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_1_0 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_1_1 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_request_length (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_too_many_headers (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_1_0 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_1_1 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_rejected (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_command (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_error_content_length (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_handler (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_head_via_send_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_close (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_internal_key_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_latin1_header (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_request_line_trimming (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_custom_status (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_explain_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_blank (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_bogus (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_digits (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_invalid (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none_get (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_get (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL
test_head (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_html_escape_filename (test.test_httpservers.SimpleHTTPServerTestCase) ... skipped 'Can not create file <test&>.txt on current file system'
test_invalid_requests (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_path_without_leading_slash (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL
test_undecodable_filename (test.test_httpservers.SimpleHTTPServerTestCase) ... skipped 'undecodable name cannot be decoded on win32'
test_authorization (test.test_httpservers.CGIHTTPServerTestCase) ... E:\RepoGiT\3.6\lib\encodings\cp1252.py:21: ResourceWarning: unclosed <socket.socket [closed] fd=992, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  class IncrementalDecoder(codecs.IncrementalDecoder):
E:\RepoGiT\3.6\lib\encodings\cp1252.py:21: ResourceWarning: unclosed <socket.socket [closed] fd=756, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  class IncrementalDecoder(codecs.IncrementalDecoder):
ok
test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_invaliduri (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_issue19435 (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_nested_cgi_path_issue21323 (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_no_leading_slash (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_os_environ_is_not_altered (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_post (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_with_continuous_slashes (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_with_multiple_question_mark (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_url_collapse_path (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_urlquote_decoding_in_cgi_check (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_arguments (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_start_with_double_slash (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_windows_colon (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_all (test.test_httpservers.MiscTestCase) ... ok

======================================================================
FAIL: test_get (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 408, in test_get
    self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 360, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != <HTTPStatus.NOT_FOUND: 404>

======================================================================
FAIL: test_path_without_leading_slash (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 462, in test_path_without_leading_slash
    self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 360, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != <HTTPStatus.NOT_FOUND: 404>

----------------------------------------------------------------------

Ran 59 tests in 3.339s

FAILED (failures=2, skipped=2)
test test_httpservers failed
test_httpservers failed

== Tests result: FAILURE ==

1 test failed:
    test_httpservers

Total duration: 3 sec 515 ms
Tests result: FAILURE
About to run again without deleting .pyc first:
Presione una tecla para continuar . . .

E:\RepoGiT\3.6>"E:\RepoGiT\3.6\PCbuild\amd64\python.exe"  -u -Wd -E -bb -m test  -v test_httpservers
== CPython 3.6.8+ (heads/3.6:c2340619a7, Jan 7 2019, 21:35:13) [MSC v.1916 64 bit (AMD64)]
== Windows-10-10.0.17763-SP0 little-endian
== cwd: E:\RepoGiT\3.6\build\test_python_16136
== CPU count: 8
== encodings: locale=cp1252, FS=utf-8
Run tests sequentially
0:00:00 [1/1] test_httpservers
test_err (test.test_httpservers.RequestHandlerLoggingTestCase) ... ok
test_get (test.test_httpservers.RequestHandlerLoggingTestCase) ... ok
test_close_connection (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_date_time_string (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_error (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_header (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_response_only (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_length (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_unbuffered_when_continue (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_html_escape_on_error (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_0_9 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_1_0 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_1_1 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_request_length (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_too_many_headers (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_1_0 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_1_1 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_rejected (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_command (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_error_content_length (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_handler (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_head_via_send_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_close (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_internal_key_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_latin1_header (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_request_line_trimming (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_custom_status (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_explain_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_blank (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_bogus (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_digits (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_invalid (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none_get (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_get (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL
test_head (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_html_escape_filename (test.test_httpservers.SimpleHTTPServerTestCase) ... skipped 'Can not create file <test&>.txt on current file system'
test_invalid_requests (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_path_without_leading_slash (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL
test_undecodable_filename (test.test_httpservers.SimpleHTTPServerTestCase) ... skipped 'undecodable name cannot be decoded on win32'
test_authorization (test.test_httpservers.CGIHTTPServerTestCase) ... E:\RepoGiT\3.6\lib\encodings\cp1252.py:21: ResourceWarning: unclosed <socket.socket [closed] fd=996, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  class IncrementalDecoder(codecs.IncrementalDecoder):
E:\RepoGiT\3.6\lib\encodings\cp1252.py:21: ResourceWarning: unclosed <socket.socket [closed] fd=976, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  class IncrementalDecoder(codecs.IncrementalDecoder):
ok
test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_invaliduri (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_issue19435 (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_nested_cgi_path_issue21323 (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_no_leading_slash (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_os_environ_is_not_altered (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_post (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_with_continuous_slashes (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_with_multiple_question_mark (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_url_collapse_path (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_urlquote_decoding_in_cgi_check (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_arguments (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_start_with_double_slash (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_windows_colon (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_all (test.test_httpservers.MiscTestCase) ... ok

======================================================================
FAIL: test_get (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 408, in test_get
    self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 360, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != <HTTPStatus.NOT_FOUND: 404>

======================================================================
FAIL: test_path_without_leading_slash (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 462, in test_path_without_leading_slash
    self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
  File "E:\RepoGiT\3.6\lib\test\test_httpservers.py", line 360, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != <HTTPStatus.NOT_FOUND: 404>

----------------------------------------------------------------------

Ran 59 tests in 3.144s

FAILED (failures=2, skipped=2)
test test_httpservers failed
test_httpservers failed

== Tests result: FAILURE ==

1 test failed:
    test_httpservers

Total duration: 3 sec 297 ms
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 11:05:39 2019
From: report at bugs.python.org (Petter S)
Date: Wed, 09 Jan 2019 16:05:39 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1547049939.21.0.992607554479.issue35656@roundup.psfhosted.org>


Petter S <petter.strandmark at gmail.com> added the comment:

Agreed! The code above was a quick example. There are also functions in the standard library for approximate float matching that the "real" code would use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35656>
_______________________________________

From report at bugs.python.org  Wed Jan  9 11:39:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 16:39:06 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547051946.05.0.551324776747.issue35066@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Paul Ganssle asked me to look at PR 10692. This issue is about consistency, so I don't understand this part of the change:

        try:
            _time.strftime('%')
        except ValueError:
self.skipTest('time module does not support trailing %')

Would why datetime have the same behavior on all platforms, but time.strftime('%') may or may not raise an exception depending on the libc?

Can't we get the same behavior on all platforms and the same behavior in time and datetime module. Honestly, I have no preference between always raising an exception or always success (just copy trailing "%").

This issue reminds me the old bpo-16322: time.strftime("%z") fails to format properly the timezone name. I would suggest to "preprocess" the input string passed to the C function strftime() / wcsftime() to replace %z or %Z with the timezone name, but only pass format substrings?

Something similar can be done for the trailing "%": pass a substring (without the trailing %) to strftime() / wcsftime(), and later append "%".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Wed Jan  9 11:51:59 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 16:51:59 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547052719.02.0.503473948392.issue35700@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I agree with Serhiy that we shouldn't do this; tkinter is (mostly) just a thin wrapper around Tcl/Tk and this isn't enough of a win to deviate from that.  In any case, this would be an enhancement that could only go into 3.8 at this point.

For your particular example, it would prefer to read the following anyway:

```
import tkinter as tk

root = tk.Tk()

labels = []
for i in range(3):
    label = tk.Label(root)
    label.grid(row=0, column=i)
    labels.append(label)
```


Or if you really want this feature in your own code, try this out:

```
import tkinter as tk
from functools import partial

def _mapped(method, widget, *args, **kwargs):
    getattr(widget, method)(*args, **kwargs)
    return widget

packed = partial(_mapped, 'pack')
gridded = partial(_mapped, 'grid')
placed = partial(_mapped, 'place')

root = tk.Tk()

label1 = gridded(tk.Label(root), row=0, column=0)
label2 = gridded(tk.Label(root), row=0, column=1)
label3 = gridded(tk.Label(root), row=0, column=2)
```

----------
nosy: +zach.ware
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 11:59:08 2019
From: report at bugs.python.org (MaximilianSP)
Date: Wed, 09 Jan 2019 16:59:08 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1547053148.29.0.455447366306.issue35678@roundup.psfhosted.org>


MaximilianSP <maximilian.sprengel at bam.de> added the comment:

Hello Victor, 

a new version of the code has been released and I now get another error. I will mark the issue as resolved. Thank you for the quick response!

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35678>
_______________________________________

From report at bugs.python.org  Wed Jan  9 11:59:52 2019
From: report at bugs.python.org (MaximilianSP)
Date: Wed, 09 Jan 2019 16:59:52 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1547053192.99.0.998610357395.issue35678@roundup.psfhosted.org>


Change by MaximilianSP <maximilian.sprengel at bam.de>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35678>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:05:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 17:05:35 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1547053535.32.0.289434521509.issue35678@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, you're welcome ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35678>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:09:33 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 17:09:33 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547053773.23.0.867226623274.issue35693@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

No need to paste the output; it's linked between the form at the top and the first message.  It's not shown on the issue list view because it's not a patch.

The next step is to see if it still fails when you build from the `master` branch since 3.6 is now closed to anything but security fixes.  Debugging is likely to be up to you, though; this doesn't happen on any of our CI platforms or on my own machines.  We can give you tips on how to go about that debugging here or via IRC or Zulip, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:13:54 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 17:13:54 +0000
Subject: [issue35397] Undeprecate and document urllib.parse.unwrap
In-Reply-To: <1543879550.52.0.788709270274.issue35397@psf.upfronthosting.co.za>
Message-ID: <1547054034.96.0.19929171564.issue35397@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +10996
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35397>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:13:55 2019
From: report at bugs.python.org (Michael Saah)
Date: Wed, 09 Jan 2019 17:13:55 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1547051946.05.0.551324776747.issue35066@roundup.psfhosted.org>
Message-ID: <CAAGJmtR-G9DgXy5cWdVVx0tAYzv=0Z6TAy5KRhUVqzpZK2Jz1g@mail.gmail.com>


Michael Saah <mike.saah at gmail.com> added the comment:

Hi Victor, thanks for taking a look.

> Would why datetime have the same behavior on all platforms, but time.strftime('%') may or may not raise an exception depending on the libc?

If I understand the call stack correctly, datetime does not have the
same behavior on all platforms. datetime does some preprocessing and
then hands the resulting format string down to time.strftime, which in
turn passes it down to the system. The time module does not check for
trailing %.

To be honest, I can't claim to understand the strftime
system-dependence, as I couldn't find good documentation of it nor
could I find error handling code. The C version of datetime.strftime
really just said "There's a lone trailing %; doesn't make sense." when
making the check. The python version of datetime did not make this
check, and neither does any version of the time module's strftime.

> Something similar can be done for the trailing "%": pass a substring (without the trailing %) to strftime() / wcsftime(), and later append "%".

I like this idea, as it gets around the ill-defined parameters of
system-dependence that I'm working with. This change would need to
made to the time module, and would be in addition to the changes I've
already made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:14:01 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 17:14:01 +0000
Subject: [issue35397] Undeprecate and document urllib.parse.unwrap
In-Reply-To: <1543879550.52.0.788709270274.issue35397@psf.upfronthosting.co.za>
Message-ID: <1547054041.14.0.432679535084.issue35397@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch
pull_requests: +10996, 10997
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35397>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:14:07 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 09 Jan 2019 17:14:07 +0000
Subject: [issue35397] Undeprecate and document urllib.parse.unwrap
In-Reply-To: <1543879550.52.0.788709270274.issue35397@psf.upfronthosting.co.za>
Message-ID: <1547054047.44.0.146464119739.issue35397@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch, patch
pull_requests: +10996, 10997, 10998
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35397>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:19:07 2019
From: report at bugs.python.org (Peter Vex)
Date: Wed, 09 Jan 2019 17:19:07 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547054347.55.0.12327601192.issue35700@roundup.psfhosted.org>


Peter Vex <petiacdc at gmail.com> added the comment:

Thank you Zachary, very interesting examples, to say the least!

----------
type: enhancement -> behavior
versions: +Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:21:06 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 17:21:06 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547054466.13.0.256122264137.issue35700@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:37:05 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 09 Jan 2019 17:37:05 +0000
Subject: [issue35701] 3.8 needlessly breaks weak references for UUIDs
Message-ID: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

I 100% agree with the aim of #30977 (reduce uuid.UUID() memory footprint), but it broke compatibility for any application that was weak referencing UUID instances (which seems a reasonable thing to do; a strong reference to a UUID can be stored in a single master container or passed through a processing pipeline, while also keying WeakKeyDictionary with cached supplementary data). I specifically noticed this because I was about to do that very thing in a processing flow, then noticed UUIDs in 3.6 were a bit heavyweight, memory-wise, went to file a bug on memory usage to add __slots__, and discovered someone had already done it for me.

Rather than break compatibility in 3.8, why not simply include '__weakref__' in the __slots__ listing? It would also remove the need for a What's New level description of the change, since the description informs people that:

1. Instances can no longer be weak-referenced (which adding __weakref__ would undp)
2. Instances can no longer add arbitrary attributes. (which was already the case in terms of documented API, programmatically enforced via a __setattr__ override, so it seems an unnecessary thing to highlight outside of Misc/NEWS)

The cost of changing __slots__ from:

    __slots__ = ('int', 'is_safe')

to:

    __slots__ = 'int', 'is_safe', '__weakref__'

would only be 4-8 bytes (for 64 bit Python, total cost of object + int would go from 100 to 108 bytes, still about half of the pre-__slots__ cost of 212 bytes), and avoid breaking any code that might rely on being able to weak reference UUIDs.

I've marked this as release blocker for the time being because if 3.8 actually releases with this change, it will cause back compat issues that might prevent people relying on UUID weak references from upgrading their code.

----------
components: Library (Lib)
keywords: 3.7regression, easy
messages: 333338
nosy: Nir Soffer, josh.r, serhiy.storchaka, taleinat, vstinner, wbolster
priority: release blocker
severity: normal
stage: needs patch
status: open
title: 3.8 needlessly breaks weak references for UUIDs
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Wed Jan  9 12:47:24 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 09 Jan 2019 17:47:24 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547056044.6.0.102696643795.issue35700@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Closing as rejected; to my knowledge, *no* built-in Python method both mutate an object and returns the object just mutated, precisely because:

1. It allows for chaining that leads fairly quickly to unreadable code (Python is not Perl/Ruby)

2. It creates doubt as to whether the original object was mutated or not (if list.sort returns a sorted list, it becomes unclear as to whether the original list was sorted as well, or whether a new list was returned; sortedlist = unsortedlist.sort() might give an inaccurate impression of what was going on). Zachary's example of using top-level functions to do the work instead is basically the same practicality compromise that sorted makes in relation to list.sort.

----------
nosy: +josh.r
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 13:05:04 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 09 Jan 2019 18:05:04 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547057104.04.0.306130813383.issue35698@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

vstinner: The problem isn't the averaging, it's the type inconsistency. In both examples (median([1]), median([1, 1])), the median is unambiguously 1 (no actual average is needed; the values are identical), yet it gets converted to 1.0 only in the latter case.

I'm not sure it's possible to fix this though; right now, there is consistency among two cases:

1. When the length is odd, you get the median by identity (and therefore type and value are unchanged)
2. When the length is even, you get the median by adding and dividing by 2 (so for ints, the result is always float).

A fix that changed that would add yet another layer of complexity:

1. When the length is odd, you get the median by identity (and therefore type and value are unchanged)
2. When the length is even, 
  a. If the two middle values are equal (possibly only if they have equal types as well, to resolve the issue with [1, 1.0] or [1, True]), return the first of the two middle values (median by identity as in #1)
  b. Otherwise, you get the median by adding and dividing by 2

And note the required type checking in 2a required to even make it that consistent. Even if we accepted that, we'd pretty quickly get into a debate over whether median([3, 5]) should try to return 4 instead of 4.0, given that the median is representable in the source type (which would further damage consistency).

If anything, I think the best design would have been to *always* include a division step (so odd length cases performed middle_elem / 1, while even did (middle_elem1 + middle_elem2) / 2) so the behavior was consistent regardless odd vs. even input length, but that shipped has probably sailed, given the documented behavior specifically notes that the precise middle data point is itself returned for the odd case.

I think the solution for people concerned is to explicitly convert int values to be median-ed to fractions.Fraction (or decimal.Decimal) ahead of time, so floating point math never gets involved, and the return type is consistent regardless of length.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Wed Jan  9 13:43:47 2019
From: report at bugs.python.org (Sanyam Khurana)
Date: Wed, 09 Jan 2019 18:43:47 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547059427.97.0.562095259502.issue24746@roundup.psfhosted.org>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +10999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 13:43:56 2019
From: report at bugs.python.org (Sanyam Khurana)
Date: Wed, 09 Jan 2019 18:43:56 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547059436.45.0.678095476776.issue24746@roundup.psfhosted.org>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +10999, 11000

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 14:03:11 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 09 Jan 2019 19:03:11 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547060591.73.0.143691242215.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 02e33d9567aa4bd612f9f08053acbfd5e68480d0 by Senthil Kumaran (Sanyam Khurana) in branch '2.7':
[2.7] bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (#11482)
https://github.com/python/cpython/commit/02e33d9567aa4bd612f9f08053acbfd5e68480d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 14:17:24 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Jan 2019 19:17:24 +0000
Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises
 WinError instead of returning False
In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org>
Message-ID: <1547061444.01.0.841780995353.issue35692@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
components: +Library (Lib), Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35692>
_______________________________________

From report at bugs.python.org  Wed Jan  9 14:18:38 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 09 Jan 2019 19:18:38 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1546958404.11.0.280588445148.issue35198@roundup.psfhosted.org>
Message-ID: <d8505617-9523-0a57-326e-ce87501bccb1@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 08/01/2019 15:40, Ayappan wrote:
> Ayappan <ayappanec at gmail.com> added the comment:
>
> Not sure what went wrong here.
> I used gcc & g++ and didn't hit this issue.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35198>
> _______________________________________
>
Well, it is probably an issue with xlc as I have vac.C and
vacpp.cmp.core installed (aka xlc and xlC). These days it seems only gcc
environment gets tested in depth and portability issues with "posix"
compilers get missed.

GCC is a fine compiler - just not the one I am using for a number of
"logistical" reasons.

Thanks for the update!

Michael

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35198>
_______________________________________

From report at bugs.python.org  Wed Jan  9 14:20:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 19:20:42 +0000
Subject: [issue35700] Place, Pack and Grid should return the widget
In-Reply-To: <1547040697.39.0.463281400773.issue35700@roundup.psfhosted.org>
Message-ID: <1547061642.3.0.0318078333587.issue35700@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

1. (Josh beat me here.)  One of Python's design features is that stdlib functions/methods that mutate (or register) an object never (as far as I can remember) return the object.  (If they return anything other than None, it is something other than the object.  List.pop returns a member, not the list.)  Changing this rule either in particular cases or in general has been rejected by Guido multiple times.  A new proposal for particular exceptions would have to be approved by the still-in-the-future new design decision process.  It would likely start with posting to python-ideas list.

Consistency of this rule is a feature.  If people got used to writing 'item = Widget(...).geo_manager(...)', they would more often make the mistake of writing buggy code like 'items = lister().sort()'


2. (Based on experience with IDLE.)  The toy example with 3 one-line statements creating 3 blank Labels admittedly looks nice and neat.  And in such situations, can actually get close today.

label1 = tk.Label(root); label1.grid(row=0, column=0)
label2 = tk.Label(root); label2.grid(row=0, column=1)
label3 = tk.Label(root); label3.grid(row=0, column=2)

However, in real situations, the widget creation statement is often or usually in the body of a class method and starts with at least an 8 space indent.  The call nearly always has a content argument and often other configuration arguments.  Such statements often require more than one line even without the manager call added.  Manager calls may also have additional arguments.  The result is ragged code and if manager calls are appended, they are not so easy to pick out.

I believe a majority of experienced tkinter users prefer a style omitted from the opening example: create a batch of widgets; then lay them out.  The following untested example shows the idea.  It keeps the row and column numbers close together and includes parent grid calls in the layout section.

class Viewframe(Frame):
    def __init__(self, parent, ...)
        ...
        self.populate()
    def populate(self):
        label = Label(self, text='hello world', ...)
        button = Button(self, text='press me), command=lambda: <do something>)
        text = Text(self, ...)

        label.grid(row=0, column=0)
        button.grid(row=1, column=0)
        text.grid(row=0, column=1, rowspan=2, sticky='NSEW')
        self.columnconfigure(column=1, weight=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35700>
_______________________________________

From report at bugs.python.org  Wed Jan  9 14:21:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 19:21:55 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547061715.82.0.648423580547.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -10995

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 14:22:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 09 Jan 2019 19:22:17 +0000
Subject: [issue35641] IDLE: calltips not properly formatted for functions
 without doc-strings
In-Reply-To: <1546447419.98.0.0355519553361.issue35641@roundup.psfhosted.org>
Message-ID: <1547061737.38.0.272147841928.issue35641@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -10994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35641>
_______________________________________

From report at bugs.python.org  Wed Jan  9 16:03:58 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 21:03:58 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547067838.48.0.974000858527.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

Ok, thank you. Here are my findings:

steps taken:

1) download today's version of 3.7.2 and 3.8.0 alpha 0
2) navigate to tools/msi
3) run build.bat -x64 (to create amd64 folder under pcbuild)
4) navigate to pcbuild
5) run rt.bat -x64 -v test_httpservers

results:

1) FAILED for 3.7.2 (same as 3.6.8)
2) SUCCESS for 3.8.0 alpha 0

According to PEP-0537 python 3.7.2 is still under bugfixes, so, can I help in something to sort this out?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 16:09:08 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 21:09:08 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547068148.16.0.368209392938.issue35693@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Certainly! Bugfixes, in library or test code, are still welcome on 3.7.

----------
stage:  -> test needed
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 16:09:20 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 09 Jan 2019 21:09:20 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547068148.16.0.368209392938.issue35693@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Certainly! Bugfixes, in library or test code, are still welcome on 3.7.

----------
stage:  -> test needed
versions: +Python 3.7, Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 16:10:01 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 21:10:01 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547068201.98.0.0449803253475.issue35693@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 16:55:38 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 09 Jan 2019 21:55:38 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547070938.1.0.996590289683.issue35674@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I also think to expose posix_spawnp() as os.posix_spawnp() seems the more consistent thing to do as the os/posix module tries to mirror glibc as much as possible, which helps with discoverability and cross-reference with man pages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Wed Jan  9 16:56:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 21:56:30 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547070990.25.0.892960183876.issue35674@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Pablo:
> I also think to expose posix_spawnp() as os.posix_spawnp() seems the more consistent thing to do as the os/posix module tries to mirror glibc as much as possible, which helps with discoverability and cross-reference with man pages.

Ok. Let's do that.

@Joannah Nanjekye: Don't hesitate to come to me if you need my help to implement that ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:13:08 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 09 Jan 2019 22:13:08 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1547071988.66.0.221137299425.issue35493@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

@Antoine Do you think we should start planning one of these long term solutions or we should start trying to use Process.sentinel as a short term solution for this particular issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:14:55 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 09 Jan 2019 22:14:55 +0000
Subject: [issue33437] Defining __init__ in enums
In-Reply-To: <1525687357.98.0.682650639539.issue33437@psf.upfronthosting.co.za>
Message-ID: <1547072095.27.0.0418516476147.issue33437@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33437>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:15:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Jan 2019 22:15:23 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547072123.22.0.493682682315.issue35698@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> vstinner: The problem isn't the averaging, it's the type inconsistency.

>>> type(statistics.median([1]))
<class 'int'>
>>> type(statistics.median([1,2]))
<class 'float'>

Which consistency? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:20:29 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Jan 2019 22:20:29 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1547072429.64.0.363059773716.issue35493@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

If using Process.sentinel looks easy enough, then go for it.  Existing users of multiprocessing.Pool will benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:43:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Jan 2019 22:43:05 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547073785.82.0.159756208879.issue35699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Excellent catch! Are you interested in creating a PR?

Also, I don't recall whether we are handling multiple installs or not, but if we are not I would rather explicitly list the products that may include compilers than using "*" (since there are and will be more products that do not). If we're checking for installed packages as well and iterating over all results then "*" will be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:45:07 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Wed, 09 Jan 2019 22:45:07 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547073907.03.0.975388633134.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

I have realized that results from rt.bat differ from those when running buildrelease.bat (see example below)
Why do the tests run OK in rt.bat but fail in buildrelase.bat?

To my best understanding, the tests are summoned directly via rt.bat but also from buildrelease.bat (because these are used to generate data for the PGO optimization process right?)- but when run from the buildrelease.bat file, the tests are in "silent" mode, just fatal errors are displayed at the command prompt as opposed to <rt.bat -x64 -wW>.

Is there a way to pass some arguments to buildrelease.bat so that the tests run in verbose mode? This is important, because that way i can know exactly which tests fail.

-----------------------------------------------------------------

EXAMPLE

verbose from <rt.bat -x64 -wW> in test_distutils:
************************************************************************
0:03:57 [113/418] test_distutils
xxmodule.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmpy9gd5kib\Release\Users\yorch\AppData\Local\Temp\tmpy9gd5kib\xx.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmpy9gd5kib\Release\Users\yorch\AppData\Local\Temp\tmpy9gd5kib\xx.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmpxp_bpi50\tempt\Users\yorch\AppData\Local\Temp\tmpmz5_h8sb\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmpxp_bpi50\tempt\Users\yorch\AppData\Local\Temp\tmpmz5_h8sb\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmpxp_bpi50\tempt\Users\yorch\AppData\Local\Temp\tmpmz5_h8sb\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmpxp_bpi50\tempt\Users\yorch\AppData\Local\Temp\tmpmz5_h8sb\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
xxmodule.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmptd13yi9i\Release\Users\yorch\AppData\Local\Temp\tmptd13yi9i\xx.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmptd13yi9i\Release\Users\yorch\AppData\Local\Temp\tmptd13yi9i\xx.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmp4ttgsjp5\tempt\Users\yorch\AppData\Local\Temp\tmp1yxs7b6r\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmp4ttgsjp5\tempt\Users\yorch\AppData\Local\Temp\tmp1yxs7b6r\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmp4ttgsjp5\tempt\Users\yorch\AppData\Local\Temp\tmp1yxs7b6r\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmp4ttgsjp5\tempt\Users\yorch\AppData\Local\Temp\tmp1yxs7b6r\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
xxmodule.c
   Creando biblioteca build\temp.win-amd64-3.8\Release\xx.cp38-win_amd64.lib y objeto build\temp.win-amd64-3.8\Release\xx.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada

E:\RepoGiT\3.8\build\test_python_2512>exit 1

E:\RepoGiT\3.8\build\test_python_2512>exit 0
0:04:41 [114/418] test_docxmlrpc -- test_distutils passed in 44 sec 267 ms
***********************************************************************

verbose from buildrelease.bat -x64 from test_distutils
***********************************************************************
xxmodule.c
E:\RepoGiT\3.8\include\Python.h(8): fatal error C1083: No se puede abrir el archivo incluir: 'pyconfig.h': No such file or directory
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmpwzeadhd1\tempt\Users\yorch\AppData\Local\Temp\tmp196_7v3c\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmpwzeadhd1\tempt\Users\yorch\AppData\Local\Temp\tmp196_7v3c\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmpwzeadhd1\tempt\Users\yorch\AppData\Local\Temp\tmp196_7v3c\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmpwzeadhd1\tempt\Users\yorch\AppData\Local\Temp\tmp196_7v3c\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
xxmodule.c
E:\RepoGiT\3.8\include\Python.h(8): fatal error C1083: No se puede abrir el archivo incluir: 'pyconfig.h': No such file or directory
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmp9093ml9w\tempt\Users\yorch\AppData\Local\Temp\tmpsn45j3j7\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmp9093ml9w\tempt\Users\yorch\AppData\Local\Temp\tmpsn45j3j7\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
foo.c
   Creando biblioteca D:\Users\yorch\AppData\Local\Temp\tmp9093ml9w\tempt\Users\yorch\AppData\Local\Temp\tmpsn45j3j7\foo.cp38-win_amd64.lib y objeto D:\Users\yorch\AppData\Local\Temp\tmp9093ml9w\tempt\Users\yorch\AppData\Local\Temp\tmpsn45j3j7\foo.cp38-win_amd64.exp
Generando c?digo
Generaci?n de c?digo finalizada
xxmodule.c
E:\RepoGiT\3.8\include\Python.h(8): fatal error C1083: No se puede abrir el archivo incluir: 'pyconfig.h': No such file or directory

D:\Users\yorch\AppData\Local\Temp\test_python_4848>exit 1

D:\Users\yorch\AppData\Local\Temp\test_python_4848>exit 0
*********************************************************************

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 17:52:23 2019
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 09 Jan 2019 22:52:23 +0000
Subject: [issue35404] Document how to import _structure in email.message
In-Reply-To: <1543914095.32.0.788709270274.issue35404@psf.upfronthosting.co.za>
Message-ID: <1547074343.44.0.345231580025.issue35404@roundup.psfhosted.org>


Brian Curtin <brian at python.org> added the comment:


New changeset e394ba32147f687b6bc7518d461f1d84211698e0 by Brian Curtin (Charles-Axel Dein) in branch 'master':
bpo-35404: Clarify how to import _structure in email.message doc (GH-10886)
https://github.com/python/cpython/commit/e394ba32147f687b6bc7518d461f1d84211698e0


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35404>
_______________________________________

From report at bugs.python.org  Wed Jan  9 18:40:19 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 09 Jan 2019 23:40:19 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1547077219.89.0.492648997133.issue35493@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +11001
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Wed Jan  9 18:40:27 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 09 Jan 2019 23:40:27 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1547077227.31.0.0656550402458.issue35493@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11001, 11002
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Wed Jan  9 18:40:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 09 Jan 2019 23:40:36 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1547077236.14.0.322489345291.issue35493@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11001, 11002, 11003
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Wed Jan  9 18:50:33 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 09 Jan 2019 23:50:33 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1547077833.53.0.914420622554.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Adding my comment from the PR review:

Dealing with leading/trailing whitespace could get interesting here. All the other values can be trimmed at both ends, while this one (currently) must have one space removed from the start.

Perhaps we should insert the repr of the prompt instead? Or at least double-quote it and escape internal quotes and backslashes?

----------
nosy: +cheryl.sabella, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:02:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:02:46 +0000
Subject: [issue35593] Register standard browser: Chrome
In-Reply-To: <1545917779.17.0.514318907905.issue35593@roundup.psfhosted.org>
Message-ID: <1547078566.67.0.859343099365.issue35593@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The patch won't work on my machine - "chrome[.exe]" is not on my PATH:

>>> import shutil
>>> shutil.which("chrome")
>>> import webbrowser
>>> webbrowser.register("chrome", None, webbrowser.BackgroundBrowser("chrome"))
>>> webbrowser.get("chrome")
<webbrowser.BackgroundBrowser object at 0x00000252203B40B8>
>>> webbrowser.get("chrome").open("https://stevedower.id.au/")
False

Perhaps this also requires an update to shutil.which() on Windows to inspect HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths?

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35593>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:04:55 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:04:55 +0000
Subject: [issue35593] Register standard browser: Chrome
In-Reply-To: <1545917779.17.0.514318907905.issue35593@roundup.psfhosted.org>
Message-ID: <1547078695.42.0.551115020179.issue35593@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The "8232_1.patch" patch on #8232 implements a registry-based lookup (including for Chrome) that will be far more reliable than the current process's environment. So it's not a direct duplicate, but the proposed fix will resolve this issue as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35593>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:17:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 00:17:52 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547079472.36.0.375088022382.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:18:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 00:18:01 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547079481.25.0.324819819099.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11004, 11005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:18:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 00:18:10 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547079490.8.0.561528868913.issue32710@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11004, 11005, 11006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:19:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:19:31 +0000
Subject: [issue34855] batch file variables
In-Reply-To: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>
Message-ID: <1547079571.9.0.693412426815.issue34855@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6aedfa6b9ac324587f64133c23757a66a8f355bb by Steve Dower (antektek) in branch 'master':
bpo-34855: Fix EXTERNALS_DIR build variable for Windows (GH-11177)
https://github.com/python/cpython/commit/6aedfa6b9ac324587f64133c23757a66a8f355bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:19:42 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 00:19:42 +0000
Subject: [issue34855] batch file variables
In-Reply-To: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>
Message-ID: <1547079582.71.0.180326764883.issue34855@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:19:52 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 00:19:52 +0000
Subject: [issue34855] batch file variables
In-Reply-To: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>
Message-ID: <1547079592.62.0.728591105686.issue34855@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11007, 11008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:20:02 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 00:20:02 +0000
Subject: [issue34855] batch file variables
In-Reply-To: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>
Message-ID: <1547079602.34.0.2388841891.issue34855@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11007, 11008, 11009

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:39:50 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:39:50 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1547080790.22.0.0820206251825.issue35683@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +11010
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:39:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:39:57 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1547080797.84.0.377692416078.issue35683@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch
pull_requests: +11010, 11011
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:40:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:40:05 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1547080805.95.0.892091035547.issue35683@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch, patch
pull_requests: +11010, 11011, 11012
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:46:43 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 00:46:43 +0000
Subject: [issue34855] batch file variables
In-Reply-To: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>
Message-ID: <1547081203.2.0.0859475976838.issue34855@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2bd5f7e91add6a20c311d46c332c4325b1e77883 by Miss Islington (bot) in branch '3.7':
bpo-34855: Fix EXTERNALS_DIR build variable for Windows (GH-11177)
https://github.com/python/cpython/commit/2bd5f7e91add6a20c311d46c332c4325b1e77883


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:47:18 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:47:18 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547081238.58.0.301675484794.issue35693@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The tests mostly fail in the PGO run because they are highly sensitive to the source tree layout. We've never fixed them because they aren't that important to the PGO run - failure cases help with training - and the real tests pass fine under their more controlled conditions.

Don't rely on the PGO run for pass/fails. If you particularly want to fix them, I'd suggest coming up with a (provably) better set of training data, or focusing on running tests from alternate layouts (use the recent PC/layout script to generate sensible layouts in alternate locations).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:47:55 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 10 Jan 2019 00:47:55 +0000
Subject: [issue34855] batch file variables
In-Reply-To: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>
Message-ID: <1547081275.71.0.949207589277.issue34855@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34855>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:52:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 00:52:45 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547081565.4.0.641158083596.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +11013
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:52:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 00:52:56 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547081576.0.0.0691345247982.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +11013, 11014
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Wed Jan  9 19:53:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 00:53:05 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547081585.98.0.802573081533.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11013, 11014, 11015
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Wed Jan  9 20:29:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 01:29:45 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547083785.58.0.31572523956.issue24746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

test_doctest starts to fail on AMD64 Windows8.1 Refleaks 2.7:

https://buildbot.python.org/all/#/builders/33/builds/471

It may be related to:

New changeset 02e33d9567aa4bd612f9f08053acbfd5e68480d0 by Senthil Kumaran (Sanyam Khurana) in branch '2.7':
[2.7] bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (#11482)
https://github.com/python/cpython/commit/02e33d9567aa4bd612f9f08053acbfd5e68480d0

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Wed Jan  9 20:31:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 01:31:37 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547083897.94.0.23335732637.issue24746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Yeah, I confirm that it's a regression caused by commit 02e33d9567aa4bd612f9f08053acbfd5e68480d0:

"./python -m test test_doctest test_doctest" fails after this commit, but pass before this commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 01:15:16 2019
From: report at bugs.python.org (Sanyam Khurana)
Date: Thu, 10 Jan 2019 06:15:16 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547100916.19.0.361951836365.issue24746@roundup.psfhosted.org>


Sanyam Khurana <sanyam.khurana01 at gmail.com> added the comment:

Hi Victor,

Senthil reverted the backport commit on 2.7 branch.

Is there a way I can test reference leaks in CPython? Is it using valgrind or some other tool? Can you please point me to that?

I can then see if I can fix this on 2.7

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 01:33:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 06:33:36 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1547100916.19.0.361951836365.issue24746@roundup.psfhosted.org>
Message-ID: <CA+3bQGGEEB40u4rChvffTxqKsSUSOJjg14_jsyOpS1vPiT3RVQ@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

In short, this buildbot runs "./python -m test -R 3:3 test_doctest". But
here the bug is just that running the test twice in a row fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:01:47 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Thu, 10 Jan 2019 07:01:47 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547103707.84.0.819815208253.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

Thanks! 

About the alternate set of training data, how (where) do I find it? and about the layouts, can you point me in the right direction as to learn about them, into what they do? or try to achieve? and how to use them?

Quoting Steve Dower ( https://bugs.python.org/issue35299#msg330347 ), the test suite implemented in this project is as good as any other generic workload, which is easily accessible from this repo (I don't know what was he referring to in "ease of accessibility") but I understand it is not the only one out there. So, if there are as many combinations possible as from choosing the tests (the ones implemented here and/or others), why did python choose this in particular? It has to be "good enough" isn't it? and if so, why PGO optimizations where "left out" of the bug tracking loop? It may be not as important in reality, but people like me, crave for optimizations =) 

So, I would love the PGO feature to be revived here, what happened to previous work done here ( https://bugs.python.org/issue26359 )?. But I know also that I am daydreaming. I would appreciate any help, for me to keep digging into it, as I do not know where to start.

thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:18:48 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 10 Jan 2019 07:18:48 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547104728.14.0.0896326161292.issue35699@roundup.psfhosted.org>


Marc Schlaich <marc.schlaich at googlemail.com> added the comment:

We are passing arguments

 -latest        (Return only the newest version and last installed.)

and

 "-requires", "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",

So this should handle the cases multiple installs and different products without compilers.

I try to get a PR ready.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:25:57 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 10 Jan 2019 07:25:57 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547105157.17.0.782312937959.issue35699@roundup.psfhosted.org>


Change by Marc Schlaich <marc.schlaich at googlemail.com>:


----------
keywords: +patch
pull_requests: +11016
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:26:04 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 10 Jan 2019 07:26:04 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547105164.58.0.695857627702.issue35699@roundup.psfhosted.org>


Change by Marc Schlaich <marc.schlaich at googlemail.com>:


----------
keywords: +patch, patch
pull_requests: +11016, 11017
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:26:11 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 10 Jan 2019 07:26:11 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547105171.39.0.190912355999.issue35699@roundup.psfhosted.org>


Change by Marc Schlaich <marc.schlaich at googlemail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11016, 11017, 11018
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:43:38 2019
From: report at bugs.python.org (Ricardo F)
Date: Thu, 10 Jan 2019 07:43:38 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
Message-ID: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>


New submission from Ricardo F <rfraile at rfraile.eu>:

Finally since the release of OSX 10.12 the equivalent from the FreeBSD and OpenBSD "CLOCK_UPTIME" is available on Darwin under the name "CLOCK_UPTIME_RAW":

CLOCK_UPTIME FreeBSD [1]:
Starts at zero when the kernel boots and increments monotonically in SI seconds while the machine is running.

CLOCK_UPTIME OpenBSD [2]:
Time whose absolute value is the time the system has been running and not suspended, providing accurate uptime measurement, both absolute and interval

CLOCK_UPTIME_RAW Darwin [3]:
Clock that increments monotonically, tracking the time since an arbitrary point, unaffected by frequency or time adjustments and not increment while the system is asleep.


It would be useful to have it available on time module [4] for this platform.

As the behaviour is equivalent, maybe it can be assigned to the existing time.CLOCK_UPTIME funtion.




Thanks,



[1] - https://www.freebsd.org/cgi/man.cgi?query=clock_gettime
[2] - https://man.openbsd.org/clock_gettime.2
[3] - http://www.manpagez.com/man/3/clock_gettime_nsec_np/
[4] - https://docs.python.org/3/library/time.htm

----------
components: macOS
messages: 333366
nosy: ned.deily, rfrail3, ronaldoussoren
priority: normal
severity: normal
status: open
title: clock_gettime: Add new identifier CLOCK_UPTIME_RAW for Darwin
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:49:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:49:21 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106561.42.0.478624696069.issue24746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh. The 3.6, 3.7 and master changes broke the Refleaks buildbots... By the way, why was such bugfix merged into the 3.6 branch which is now in security-only mode?

Please fix this bug ASAP, or I will revert the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:51:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:51:49 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106709.41.0.362372553771.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11020

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:52:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:52:03 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106723.45.0.350463662673.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11020, 11021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:52:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:52:18 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106738.1.0.486818066422.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11020, 11021, 11022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:54:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:54:23 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106863.38.0.357496502289.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:54:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:54:38 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106878.55.0.24486326913.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11023, 11024

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:54:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:54:52 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106892.08.0.292832060834.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11023, 11024, 11025

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:55:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:55:11 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106911.22.0.329693890703.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11026

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:55:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:55:23 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106923.78.0.785120639031.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11026, 11027

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:55:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:55:36 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106936.21.0.99520012997.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11026, 11027, 11028

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 02:56:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 07:56:09 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547106969.84.0.578687006425.issue24746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 03:05:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 08:05:11 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547107511.67.0.66234571148.issue35702@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 03:38:16 2019
From: report at bugs.python.org (Yoong Hor Meng)
Date: Thu, 10 Jan 2019 08:38:16 +0000
Subject: [issue35703] Underscores in numeric literals cannot be before or
 after decimal (.)
Message-ID: <1547109495.23.0.369119620159.issue35703@roundup.psfhosted.org>


New submission from Yoong Hor Meng <yoonghm at gmail.com>:

s = 1_234.567_8
print(float(s))  # It works

s = 1_234._567
print(float(s))  # It does not work

s = 1_234_.567
print(float(s))  # It does not work too

----------
components: Interpreter Core
messages: 333368
nosy: yoonghm
priority: normal
severity: normal
status: open
title: Underscores in numeric literals cannot be before or after decimal (.)
type: crash
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35703>
_______________________________________

From report at bugs.python.org  Thu Jan 10 03:44:36 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Jan 2019 08:44:36 +0000
Subject: [issue35703] Underscores in numeric literals cannot be before or
 after decimal (.)
In-Reply-To: <1547109495.23.0.369119620159.issue35703@roundup.psfhosted.org>
Message-ID: <1547109876.22.0.409619870205.issue35703@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is intentional, see <https://docs.python.org/3/reference/lexical_analysis.html#floating-point-literals>.

In floating point literals the underscores must always be between two digits.

----------
nosy: +ronaldoussoren
resolution:  -> not a bug
status: open -> pending
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35703>
_______________________________________

From report at bugs.python.org  Thu Jan 10 03:49:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Jan 2019 08:49:29 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547110169.27.0.673752416356.issue35702@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 04:12:52 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 10 Jan 2019 09:12:52 +0000
Subject: [issue35704] On AIX,
 test_unpack_archive_xztar fails with default MAXDATA settings
Message-ID: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

By default AIX builds 32-bit applications - and the combined .data, .bss and .stack areas share one memory segment of 256 Mbyte.

This can be modified by either specifying a larger value for maxdata during linking (e.g., with LDFLAGS=-bmaxdata:0x40000000) or using the program ldedit (e.g., ldedit -b maxdata:0x40000000).

The subtest test_shutil.test_unpack_archive_xztar fails with the default. The patch here looks at the MAXDATA value of the executable XCOFF headers and skips the test when AIX is 32-bit and MAXDATA < 0x20000000.

This helps the result of AIX bots to be more accurate - as this so-called failure is not an issue with python itself.

----------
components: Tests
messages: 333370
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: On AIX, test_unpack_archive_xztar fails with default MAXDATA settings
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35704>
_______________________________________

From report at bugs.python.org  Thu Jan 10 04:22:59 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 10 Jan 2019 09:22:59 +0000
Subject: [issue35704] On AIX,
 test_unpack_archive_xztar fails with default MAXDATA settings
In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org>
Message-ID: <1547112179.7.0.589914830548.issue35704@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
keywords: +patch
pull_requests: +11029
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35704>
_______________________________________

From report at bugs.python.org  Thu Jan 10 04:49:11 2019
From: report at bugs.python.org (ossdev)
Date: Thu, 10 Jan 2019 09:49:11 +0000
Subject: [issue35705] libffi support is not there for windows on ARM64
Message-ID: <1547113749.84.0.713221399914.issue35705@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
components: ctypes
nosy: ossdev07
priority: normal
severity: normal
status: open
title: libffi support is not there for windows on ARM64
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35705>
_______________________________________

From report at bugs.python.org  Thu Jan 10 06:09:59 2019
From: report at bugs.python.org (Ricardo F)
Date: Thu, 10 Jan 2019 11:09:59 +0000
Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default
 language set to English
In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za>
Message-ID: <1547118599.25.0.72359762387.issue18378@roundup.psfhosted.org>


Ricardo F <rfraile at rfraile.eu> added the comment:

I still have this issue on MacOS Mojave 10.14

Python 3.7.2 (default, Dec 27 2018, 07:35:06)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getdefaultlocale()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python/3.7.2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/locale.py", line 568, in getdefaultlocale
    return _parse_localename(localename)
  File "/usr/local/Cellar/python/3.7.2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/locale.py", line 495, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: UTF-8
>>>

$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

----------
nosy: +rfrail3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18378>
_______________________________________

From report at bugs.python.org  Thu Jan 10 06:21:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Jan 2019 11:21:36 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547119296.9.0.306744018893.issue24746@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +11030

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 06:21:50 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Jan 2019 11:21:50 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547119310.34.0.329052613007.issue24746@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +11030, 11031

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 06:22:02 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Jan 2019 11:22:02 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547119322.92.0.271065427838.issue24746@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +11030, 11031, 11032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 06:22:14 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 10 Jan 2019 11:22:14 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547119334.78.0.611155285585.issue24746@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I made https://github.com/python/cpython/pull/11501 to fix this problem. After my patch:

? ./python.exe -m test test_doctest test_doctest
Run tests sequentially
0:00:00 load avg: 1.82 [1/2] test_doctest
0:00:02 load avg: 1.82 [2/2] test_doctest

== Tests result: SUCCESS ==

All 2 tests OK.

Total duration: 5 sec 286 ms
Tests result: SUCCESS

----------
nosy: +pablogsal
pull_requests: +11032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 06:59:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Jan 2019 11:59:10 +0000
Subject: [issue35705] libffi support is not there for windows on ARM64
Message-ID: <1547121550.49.0.236282242813.issue35705@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

https://bugs.python.org/issue33125#msg314311 seems to be a related ticket that tracks this.

----------
nosy: +steve.dower, xtreak, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35705>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:01:27 2019
From: report at bugs.python.org (ossdev)
Date: Thu, 10 Jan 2019 12:01:27 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
 non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1547121687.14.0.979116280953.issue3705@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
pull_requests: +11033

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:01:34 2019
From: report at bugs.python.org (ossdev)
Date: Thu, 10 Jan 2019 12:01:34 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
 non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1547121694.49.0.0226036894461.issue3705@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
pull_requests: +11033, 11034

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:01:43 2019
From: report at bugs.python.org (ossdev)
Date: Thu, 10 Jan 2019 12:01:43 +0000
Subject: [issue3705] py3k fails under Windows if "-c" or "-m" is given a
 non-ascii value
In-Reply-To: <1219860341.22.0.260624764626.issue3705@psf.upfronthosting.co.za>
Message-ID: <1547121703.33.0.812210347342.issue3705@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
pull_requests: +11033, 11034, 11035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3705>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:18:48 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Thu, 10 Jan 2019 12:18:48 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547122728.81.0.875373312208.issue35698@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

I read PEP 450 as saying that statistics.py can be used by "any secondary school student". This is not true for most Python libraries.

In this context, the difference between a float and an int is important. Consider
   statistics.median([2] * n)

As a secondary school student, knowing the definition of median, I might expect the value to be 2, for any n > 0. What else could it be. However, the present code gives 2 for n odd, and 2.0 for n even.

I think that this issue is best approached by taking the point of view of a secondary school student. Or perhaps even a primary school student who knows fractions. (A teacher might use statistics.py to create learning materials.)

By the way, 2 and 2.0 are not interchangeable. For example
>>> [1] * 2.0
TypeError: can't multiply sequence by non-int of type 'float'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:27:10 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 10 Jan 2019 12:27:10 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547123230.94.0.688615071057.issue35674@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Now that there is consesus, I am working on a PR for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:33:45 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 10 Jan 2019 12:33:45 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547123625.98.0.276368588902.issue35702@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I am working on this.

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:44:48 2019
From: report at bugs.python.org (Yoong Hor Meng)
Date: Thu, 10 Jan 2019 12:44:48 +0000
Subject: [issue35703] Underscores in numeric literals cannot be before or
 after decimal (.)
In-Reply-To: <1547109495.23.0.369119620159.issue35703@roundup.psfhosted.org>
Message-ID: <1547124288.52.0.149811830106.issue35703@roundup.psfhosted.org>


Change by Yoong Hor Meng <yoonghm at gmail.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35703>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:47:52 2019
From: report at bugs.python.org (ossdev)
Date: Thu, 10 Jan 2019 12:47:52 +0000
Subject: [issue35705] libffi support is not there for windows on ARM64
In-Reply-To: <1547121550.49.0.236282242813.issue35705@roundup.psfhosted.org>
Message-ID: <1547124472.46.0.934148817193.issue35705@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
keywords: +patch
pull_requests: +11036
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35705>
_______________________________________

From report at bugs.python.org  Thu Jan 10 07:52:20 2019
From: report at bugs.python.org (=?utf-8?q?Lorc=C3=A1n_Mc_Donagh?=)
Date: Thu, 10 Jan 2019 12:52:20 +0000
Subject: [issue27682] wsgiref BaseHandler / SimpleHandler can raise additional
 errors when handling an error
In-Reply-To: <1470313993.65.0.630797703267.issue27682@psf.upfronthosting.co.za>
Message-ID: <1547124740.81.0.0302156627384.issue27682@roundup.psfhosted.org>


Change by Lorc?n Mc Donagh <lorcan.mcdonagh at gmail.com>:


----------
nosy: +lorcan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27682>
_______________________________________

From report at bugs.python.org  Thu Jan 10 08:08:51 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 10 Jan 2019 13:08:51 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1547125731.62.0.478668020599.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Currently, the prompt is enclosed in parentheses, both in the venv and when storing:

PS N:\projects\cpython> python -m venv testvenv --prompt="  prompt with spaces   "
Running Release|Win32 interpreter...
PS N:\projects\cpython> .\testvenv\Scripts\activate
(  prompt with spaces   ) PS N:\projects\cpython>

Contents of pyvenv.cfg:
home = N:\projects\cpython\PCbuild\win32
include-system-site-packages = false
version = 3.8.0
prompt = (  prompt with spaces   ) 

I also tested using quotes in the prompt, which lead to opening issue 35667.  

Here's a prompt that itself has parentheses:
PS N:\projects\cpython> python -m venv testvenv --prompt="(my prompt)"
Running Release|Win32 interpreter...
PS N:\projects\cpython> .\testvenv\Scripts\activate
((my prompt)) PS N:\projects\cpython>

It seemed to me that the parenthesis would allow the retrieval of both the original prompt definition and how it looked in display.  Maybe my tests didn't demonstrate this clearly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Thu Jan 10 08:14:28 2019
From: report at bugs.python.org (Stephan Troyer)
Date: Thu, 10 Jan 2019 13:14:28 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windows Store
In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>
Message-ID: <1547126068.8.0.688000435135.issue35688@roundup.psfhosted.org>


Change by Stephan Troyer <stephantroyer at live.at>:


----------
nosy: +stephtr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Thu Jan 10 08:56:30 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 10 Jan 2019 13:56:30 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547128590.07.0.266087702534.issue35702@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +11037
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 08:56:42 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 10 Jan 2019 13:56:42 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547128602.41.0.38338548356.issue35702@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11037, 11038
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 08:56:52 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 10 Jan 2019 13:56:52 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547128612.03.0.608200005212.issue35702@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11037, 11038, 11039
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:05:01 2019
From: report at bugs.python.org (Dieter Weber)
Date: Thu, 10 Jan 2019 14:05:01 +0000
Subject: [issue35706] Making an embedded Python interpreter use a venv is
 difficult
Message-ID: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org>


New submission from Dieter Weber <dieter at uellue.de>:

Python virtual environments are awesome! Using venvs with an embedded Python interpreter has proven difficult, unfortunately. With conda environments it works. See appended a sample file to reproduce the behavior.

The core of the problem seems to be that a venv doesn't contain a full Python installation, and Py_Initialize() apparently doesn't support setting up the combination of venv directories and base installation correctly, i.e. setting sys.prefix and sys.base_prefix and potentially other values.

Observed behavior when trying to use a venv:

"""
Initializing... Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00001e90 (most recent call first):
"""

Expected behavior:
Setting Py_SetPythonHome() to a venv works and sets up all paths and prefixes correctly to use the venv, just like it does for a conda environment.

----------
files: Source.cpp
messages: 333378
nosy: Dieter Weber
priority: normal
severity: normal
status: open
title: Making an embedded Python interpreter use a venv is difficult
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file48039/Source.cpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35706>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:10:02 2019
From: report at bugs.python.org (Dieter Weber)
Date: Thu, 10 Jan 2019 14:10:02 +0000
Subject: [issue35706] Making an embedded Python interpreter use a venv is
 difficult
In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org>
Message-ID: <1547129402.44.0.941581273685.issue35706@roundup.psfhosted.org>


Change by Dieter Weber <dieter at uellue.de>:


Added file: https://bugs.python.org/file48040/Source.cpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35706>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:10:03 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 10 Jan 2019 14:10:03 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547129403.77.0.494897301095.issue35066@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I agree with Victor on this. In the future, I'd really like to see us do our best to add cross-platform uniformity to Python's strftime and strptime support. If there really is a platform out there that doesn't support a trailing `%`, I like the idea of stripping it off before passing it to the system strftime/wcstrftime.

That said, I don't think this should be a blocker on Michael's PR. I think that his contribution by itself improves on the current state of things and there's no pressing *need* to solve them both at the same time. Unless I'm misunderstanding, I think the existing PR is a prerequisite for solving the problem on all platforms anyway.

Michael - do you think you can / would you like to add the functionality that Victor mentioned to your existing PR? If not, I recommend we merge the current PR and open a new issue for "Lone trailing % not supported on all platforms".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:10:13 2019
From: report at bugs.python.org (Dieter Weber)
Date: Thu, 10 Jan 2019 14:10:13 +0000
Subject: [issue35706] Making an embedded Python interpreter use a venv is
 difficult
In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org>
Message-ID: <1547129413.72.0.491319380987.issue35706@roundup.psfhosted.org>


Change by Dieter Weber <dieter at uellue.de>:


Removed file: https://bugs.python.org/file48039/Source.cpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35706>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:12:27 2019
From: report at bugs.python.org (Dieter Weber)
Date: Thu, 10 Jan 2019 14:12:27 +0000
Subject: [issue35706] Make it easier to use a venv with an embedded Python
 interpreter
In-Reply-To: <1547129099.62.0.924394155356.issue35706@roundup.psfhosted.org>
Message-ID: <1547129547.84.0.20626510149.issue35706@roundup.psfhosted.org>


Change by Dieter Weber <dieter at uellue.de>:


----------
title: Making an embedded Python interpreter use a venv is difficult -> Make it easier to use a venv with an embedded Python interpreter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35706>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:13:00 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 10 Jan 2019 14:13:00 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1547129580.59.0.811158792437.issue24928@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Ping :-)

Thanks Karthikeyan for the PR review. 

Would someone else like review it, please?

Thanks!
Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:23:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 14:23:23 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547130203.59.0.292785268277.issue35702@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> As the behaviour is equivalent, maybe it can be assigned to the existing time.CLOCK_UPTIME funtion.

Nah, in Python we map directly to OS constant and don't try to be smart. It's up to the user of these constants to make their own choice.

Use Python functions for portable behavior: time.monotonic(), time.perf_counter(), etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:29:43 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 14:29:43 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547130583.75.0.177173662853.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset c5dc60ea858b8ccf78e8d26db81c307a8f9b2314 by Senthil Kumaran (Pablo Galindo) in branch 'master':
bpo-24746: Fix doctest failures when running the testsuite with -R (#11501)
https://github.com/python/cpython/commit/c5dc60ea858b8ccf78e8d26db81c307a8f9b2314


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:31:24 2019
From: report at bugs.python.org (Ivan Levchenko)
Date: Thu, 10 Jan 2019 14:31:24 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1547130684.05.0.328024011439.issue31710@roundup.psfhosted.org>


Ivan Levchenko <levchenko.i at gmail.com> added the comment:

Was having the same issue compiling python 3.7.1 against locally compilied libffi 3.2.1. 
Setting CPPFLAGS and LDFLAGS was not enough and was still getting the same error: INFO: Could not locate ffi libs and/or headers
Everything worked as soon as i added PKG_CONFIG_PATH to point to the location of the directory that had libffi.pc
For me that was /foo/bar/distrib/libffi-3.2.1/x86_64-unknown-linux-gnu 
Can test if it works with this:
pkg-config libffi --cflags-only-I

----------
nosy: +Ivan Levchenko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Thu Jan 10 09:41:46 2019
From: report at bugs.python.org (Michael Saah)
Date: Thu, 10 Jan 2019 14:41:46 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1547129403.77.0.494897301095.issue35066@roundup.psfhosted.org>
Message-ID: <CAAGJmtQrFdVMdzzBDyQ6vyDA31kZEoMLP8jJQmE255Wog+PQsQ@mail.gmail.com>


Michael Saah <mike.saah at gmail.com> added the comment:

> Michael - do you think you can / would you like to add the functionality that Victor mentioned to your existing PR? If not, I recommend we merge the current PR and open a new issue for "Lone trailing % not supported on all platforms".

I'd be happy to do so, but can't commit to a timeline at the moment.
As long as there's no worry that the branch goes stale in the
meantime, I'd say you can leave it open. Maybe it would be best though
to merge and open a new issue, given the independence of the two
fixes.

I'll leave that as a judgement call to you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:27:40 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 15:27:40 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1547134060.4.0.0486263763341.issue33498@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11040
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:27:44 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 15:27:44 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1547134064.53.0.305926770326.issue33498@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11040, 11041
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:27:51 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 15:27:51 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1547134071.78.0.964963079059.issue33498@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11040, 11041, 11042
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:27:58 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 15:27:58 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1547134078.58.0.659842316667.issue33498@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11040, 11041, 11042, 11043
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:30:27 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 10 Jan 2019 15:30:27 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547134227.97.0.608624846213.issue35698@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

> As a secondary school student, knowing the definition of median, I might expect the value to be 2, for any n > 0.

The secondary school student would be wrong, wouldn't he?

The median of a set is not expected to be a part of the set. Especially for ints since division by 1 or 2 is not closed for integers.

Would the same student expect median([2, 4, 6, 8]) to be part of the set of even integers?

I think one taking the median of a set should always ready to deal with floating point arithmetic the result is not guaranteed to be an integer. Going from hoops to make it so when it is equivalent to an integer is rather misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:33:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 15:33:22 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547134402.34.0.701103950797.issue35698@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I suggest to close the issue as "not a bug". IMHO statistics.median() respects the defintion of the mathematical median function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:37:40 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 15:37:40 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547134660.84.0.447872550324.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11044

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:37:54 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 15:37:54 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547134674.01.0.979391015341.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11044, 11045

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:38:04 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 15:38:04 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547134684.46.0.918606918369.issue24746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11044, 11045, 11046

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:43:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Jan 2019 15:43:43 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1547135023.51.0.343442047325.issue33498@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am against this. shutil provides higher level API than pathlib, and pathlib should not depend on shutil. pathlib.Path represents a path, and its methods usually does involve filesystem operations, or involve just a single filesystem operation. shutil.rmtree() is a complex operation that needs to perform several simple operations, and it should be together with other complex operations in the shutil module.

----------
nosy: +giampaolo.rodola, pitrou, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:45:02 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 15:45:02 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547135101.99.0.504697046096.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi All,

It was my mistake to merge this in into 3.6, I didn't realize 3.6 was in bugfix mode now. Also I went by the versions (previously) set in this bpo issue.

For the regression caused in refleaks, I think, Pablo's patch will fix it, and I am verifying it here - https://buildbot.python.org/all/#/builders/1/builds/468

This will be backported to 3.7 ( I notice viktor triggered already: https://github.com/python/cpython/pull/11505) and I will cherrpick this to 2.7.

Finally, since the the port to 3.6 was a mistake, I will revert that.

This will make sure that bug is fixed all the supported versions, target branches tests are successful and 3.6 remains unaffected.

----------
assignee: CuriousLearner -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:45:10 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jan 2019 15:45:10 +0000
Subject: [issue33498] pathlib.Path wants an rmtree method
In-Reply-To: <1526308235.34.0.682650639539.issue33498@psf.upfronthosting.co.za>
Message-ID: <1547135110.06.0.977182366154.issue33498@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed there is no reason to put all useful path informations under the Path class.  Writing method calls instead of function calls is not an ideal.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33498>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:57:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 15:57:31 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547135851.2.0.346059740513.issue24746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Finally, since the the port to 3.6 was a mistake, I will revert that.

I wrote PR 11499 but I closed it because PR #11501 has been merged, but yeah, maybe a revert is the best option for 3.6.

No problem, the status change of the 3.6 branch is very new, and not everybody got the memo ;-)
https://devguide.python.org/#status-of-python-branches

See this discussion:
https://discuss.python.org/t/remove-needs-backport-to-3-6-label/563

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 10:58:41 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 10 Jan 2019 15:58:41 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
Message-ID: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

This used to work correctly in Python 2:

class Half(object):
    def __float__(self):
        return 0.5
import time
time.sleep(Half())

With Python 3.6, one gets instead

Traceback (most recent call last):
  File "test.py", line 6, in <module>
    time.sleep(Half())
TypeError: an integer is required (got type Half)

----------
messages: 333391
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: time.sleep() should support objects with __float__
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:02:31 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 16:02:31 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547136151.27.0.269192923619.issue24746@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1cbd17c6987afc48c16caa7ccc7d19b01fbd39f2 by Miss Islington (bot) in branch '3.7':
bpo-24746: Fix doctest failures when running the testsuite with -R (GH-11501)
https://github.com/python/cpython/commit/1cbd17c6987afc48c16caa7ccc7d19b01fbd39f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:08:04 2019
From: report at bugs.python.org (Nj Hsiong)
Date: Thu, 10 Jan 2019 16:08:04 +0000
Subject: [issue35708] lib2to3 failed to convert as refactor's fixes not
 search.pyc files
Message-ID: <1547136482.81.0.227627171679.issue35708@roundup.psfhosted.org>


New submission from Nj Hsiong <nj.hsiong at gmail.com>:

python3's lib2to3 would fail in silence if python3 and its packages are installed as compiled .pyc files.

Root cause is in Lib/lib2to3/refactor.py, the function get_all_fix_names only searches '.py' fix names.

=========below is workaround=========
--- a/Lib/lib2to3/refactor.py
+++ b/Lib/lib2to3/refactor.py
@@ -37,6 +37,12 @@
             if remove_prefix:
                 name = name[4:]
             fix_names.append(name[:-3])
+        if name.startswith("fix_") and name.endswith(".pyc"):
+            if remove_prefix:
+                name = name[4:]
+            name = name[:-4]
+            if name not in fix_names:
+                fix_names.append(name)
     return fix_names

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 333393
nosy: njhsio
priority: normal
severity: normal
status: open
title: lib2to3 failed to convert as refactor's fixes not search.pyc files
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35708>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:12:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Jan 2019 16:12:35 +0000
Subject: [issue35470] A deadly decref in _PyImport_FindExtensionObjectEx()
In-Reply-To: <1544618557.73.0.788709270274.issue35470@psf.upfronthosting.co.za>
Message-ID: <1547136755.7.0.0895576221915.issue35470@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 89c4f90df97f6039325e354167e8f507bf199fd9 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-35470: Fix a reference counting bug in _PyImport_FindExtensionObjectEx(). (GH-11128)
https://github.com/python/cpython/commit/89c4f90df97f6039325e354167e8f507bf199fd9


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35470>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:12:50 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 16:12:50 +0000
Subject: [issue35470] A deadly decref in _PyImport_FindExtensionObjectEx()
In-Reply-To: <1544618557.73.0.788709270274.issue35470@psf.upfronthosting.co.za>
Message-ID: <1547136770.02.0.488895882774.issue35470@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11047

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35470>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:12:55 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 16:12:55 +0000
Subject: [issue35470] A deadly decref in _PyImport_FindExtensionObjectEx()
In-Reply-To: <1544618557.73.0.788709270274.issue35470@psf.upfronthosting.co.za>
Message-ID: <1547136775.44.0.224783544314.issue35470@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11047, 11048

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35470>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:14:21 2019
From: report at bugs.python.org (AVINASH MISHRA)
Date: Thu, 10 Jan 2019 16:14:21 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547136861.85.0.071238300684.issue35707@roundup.psfhosted.org>


AVINASH MISHRA <avinashmishra1997 at gmail.com> added the comment:

hey i am a total newbie to open source contribution.
can you help me understand this issue and can i help solve this issue?

----------
nosy: +AVINASH MISHRA

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:15:00 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 10 Jan 2019 16:15:00 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547136900.82.0.27254617699.issue35707@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

time.sleep() is probably not the only function to have such a bug.

Maybe __int__() should default to:

    def __int__(self):
        return int(self.__float__())

when __float__ is defined and not __int__.

Nick Coghlan suggested something similar for __int__ and __index__.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:17:23 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 10 Jan 2019 16:17:23 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547137043.29.0.866266730159.issue35707@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:18:04 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 10 Jan 2019 16:18:04 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547137084.08.0.308177837779.issue35707@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

See #33039 for the proposed change to __int__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:29:18 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Thu, 10 Jan 2019 16:29:18 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547137758.19.0.546761094095.issue35698@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

Here's the essence of a patch.

Suppose the input is Python integers, and the output is a mathematical integer. In this case we can make the output a Python integer by using the helper function

>>> def wibble(p, q):
...     if type(p) == type(q) == int and p%q == 0:
...         return p // q
...     else:
...         return p / q
... 
>>> wibble(4, 2)
2
>>> wibble(3, 2)
1.5

This will also work for average.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:36:52 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 16:36:52 +0000
Subject: [issue35470] A deadly decref in _PyImport_FindExtensionObjectEx()
In-Reply-To: <1544618557.73.0.788709270274.issue35470@psf.upfronthosting.co.za>
Message-ID: <1547138212.78.0.34410837584.issue35470@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3e3d57d8490b729a80c8cd9e90475dec122dfe9e by Miss Islington (bot) in branch '3.7':
bpo-35470: Fix a reference counting bug in _PyImport_FindExtensionObjectEx(). (GH-11128)
https://github.com/python/cpython/commit/3e3d57d8490b729a80c8cd9e90475dec122dfe9e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35470>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:38:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Jan 2019 16:38:39 +0000
Subject: [issue35708] lib2to3 failed to convert as refactor's fixes not
 search.pyc files
In-Reply-To: <1547136482.81.0.227627171679.issue35708@roundup.psfhosted.org>
Message-ID: <1547138319.98.0.232618409137.issue35708@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35708>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:44:08 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 10 Jan 2019 16:44:08 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547138648.83.0.614736531368.issue35698@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

This does not do what you want:

    >>> class MyInt(int): pass
    >>> wibble(MyInt(4), MyInt(2))
    2.0

and a patch is only needed if something is broken.

I'm with vstinner of the opinion that nothing is broken and vote to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:44:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Jan 2019 16:44:08 +0000
Subject: [issue35470] A deadly decref in _PyImport_FindExtensionObjectEx()
In-Reply-To: <1544618557.73.0.788709270274.issue35470@psf.upfronthosting.co.za>
Message-ID: <1547138648.76.0.880762575035.issue35470@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35470>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:45:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:45:52 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547138752.64.0.136082277409.issue35707@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The problem comes from the private C function _PyTime_FromObject() of Python/pytime.c. This function must use the proper conversion to minimize the precision loss. Lib/test/test_time.py contains a lot of tests on conversions from different types and ensure that values are rounded correctly. See also my PEP 564 "Add new time functions with nanosecond resolution".

The correct code works for float and int (and maybe decimal.Decimal, I don't recall!), but it seems like it doesn't support types with __float__(). You have to explicitly cast such objects using float(value).

PyNumber_Float() can be used to convert arbitrary object to a float, but I'm not sure in which order the conversion should be tried to avoid/reduce precision loss during the conversion.

Example:

>>> x=2**53+1; x - int(float(x))
1

If we convert 'x' (int) to float, we introduce an error of 1.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:47:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:47:38 +0000
Subject: [issue35709] test_ssl fails on Fedora 29: test_min_max_version()
Message-ID: <1547138857.4.0.0864082014803.issue35709@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

test_ssl fails on Fedora 29:

vstinner at apu$ ./python -m test test_ssl -m test_min_max_version -v
== CPython 3.8.0a0 (heads/pytime_inf:aaea5b25d1, Jan 10 2019, 17:40:16) [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)]
== Linux-4.19.13-300.fc29.x86_64-x86_64-with-glibc2.28 little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_26069
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 2.33 [1/1] test_ssl
test_ssl: testing with 'OpenSSL 1.1.1 FIPS  11 Sep 2018' (1, 1, 1, 0, 15)
          under 'Linux-4.19.13-300.fc29.x86_64-x86_64-with-glibc2.28'
          HAS_SNI = True
          OP_ALL = 0x80000054
          OP_NO_TLSv1_1 = 0x10000000
test_min_max_version (test.test_ssl.ContextTests) ... FAIL
test_min_max_version (test.test_ssl.ThreadedTests) ...  server:  new connection from ('127.0.0.1', 35268)
 server: connection cipher is now ('ECDHE-RSA-AES256-GCM-SHA384', 'TLSv1.2', 256)
 server: selected protocol is now None
 server:  new connection from ('127.0.0.1', 40390)
 server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
 server: selected protocol is now None
 server:  new connection from ('127.0.0.1', 36674)

 server:  bad connection attempt from ('127.0.0.1', 36674):
Traceback (most recent call last):
   File "/home/vstinner/prog/python/master/Lib/test/test_ssl.py", line 2150, in wrap_conn
    self.sslconn = self.server.context.wrap_socket(
   File "/home/vstinner/prog/python/master/Lib/ssl.py", line 405, in wrap_socket
    return self.sslsocket_class._create(
   File "/home/vstinner/prog/python/master/Lib/ssl.py", line 853, in _create
    self.do_handshake()
   File "/home/vstinner/prog/python/master/Lib/ssl.py", line 1117, in do_handshake
    self._sslobj.do_handshake()
 ssl.SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:1055)
ok

======================================================================
FAIL: test_min_max_version (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_ssl.py", line 1069, in test_min_max_version
    self.assertEqual(
AssertionError: <TLSVersion.TLSv1: 769> != <TLSVersion.MINIMUM_SUPPORTED: -2>

----------------------------------------------------------------------

Ran 2 tests in 0.026s

FAILED (failures=1)
test test_ssl failed
test_ssl failed

== Tests result: FAILURE ==

1 test failed:
    test_ssl

Total duration: 269 ms
Tests result: FAILURE

vstinner at apu$ ./python -m test.pythoninfo|grep ^ssl
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1 FIPS  11 Sep 2018
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 0, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000

----------
components: Tests
messages: 333402
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_ssl fails on Fedora 29: test_min_max_version()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35709>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:49:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:49:24 +0000
Subject: [issue26669] time.localtime(float("NaN")) does not raise a ValueError
 on all platforms
In-Reply-To: <1459322243.53.0.921219428076.issue26669@psf.upfronthosting.co.za>
Message-ID: <1547138964.69.0.357412939826.issue26669@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11049
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26669>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:49:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:49:31 +0000
Subject: [issue26669] time.localtime(float("NaN")) does not raise a ValueError
 on all platforms
In-Reply-To: <1459322243.53.0.921219428076.issue26669@psf.upfronthosting.co.za>
Message-ID: <1547138971.55.0.934010678704.issue26669@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11049, 11050
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26669>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:49:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:49:31 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547138971.57.0.138360665976.issue35707@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +11053
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:49:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:49:38 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547138978.74.0.746597032708.issue35707@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +11053, 11054
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:49:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:49:38 +0000
Subject: [issue26669] time.localtime(float("NaN")) does not raise a ValueError
 on all platforms
In-Reply-To: <1459322243.53.0.921219428076.issue26669@psf.upfronthosting.co.za>
Message-ID: <1547138978.52.0.15014928695.issue26669@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11049, 11050, 11051
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26669>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:49:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:49:45 +0000
Subject: [issue26669] time.localtime(float("NaN")) does not raise a ValueError
 on all platforms
In-Reply-To: <1459322243.53.0.921219428076.issue26669@psf.upfronthosting.co.za>
Message-ID: <1547138985.83.0.822012765111.issue26669@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11049, 11050, 11051, 11052
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26669>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:53:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:53:59 +0000
Subject: [issue26669] time.localtime(float("NaN")) does not raise a ValueError
 on all platforms
In-Reply-To: <1459322243.53.0.921219428076.issue26669@psf.upfronthosting.co.za>
Message-ID: <1547139239.58.0.467260866615.issue26669@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 11507 to raise ValueError rather than OverflowError for -inf and +inf.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26669>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:54:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:54:43 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547139283.05.0.968316229563.issue35707@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

PR 11507 is not directly related to this issue, see bpo-26669. But I wrote this PR when trying to fix this issue :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:55:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Jan 2019 16:55:58 +0000
Subject: [issue35709] test_ssl fails on Fedora 29: test_min_max_version()
In-Reply-To: <1547138857.4.0.0864082014803.issue35709@roundup.psfhosted.org>
Message-ID: <1547139358.71.0.288355133929.issue35709@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems related https://bugs.python.org/issue35045

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35709>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:56:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:56:41 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547139401.63.0.268699404369.issue35702@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 572168a016ece1b7346695eb7289190c46f1ae55 by Victor Stinner (Joannah Nanjekye) in branch 'master':
bpo-35702: Add new identifier time.CLOCK_UPTIME_RAW for macOS 10.12 (GH-11503)
https://github.com/python/cpython/commit/572168a016ece1b7346695eb7289190c46f1ae55


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:58:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:58:35 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547106217.28.0.153121423636.issue35702@roundup.psfhosted.org>
Message-ID: <1547139515.68.0.371082411437.issue35702@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Joannah Nanjekye added time.CLOCK_UPTIME_RAW to the master branch (future Python 3.8). We don't add feature to stable versions (like 3.7), so I close the issue.

Thanks Ricardo Fraile for the report, I wasn't aware of this clock ;-)

Note: Until Python 3.8 is released, you can easily hardcode the constant in your application. Such constant rarely change.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 11:59:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 16:59:42 +0000
Subject: [issue35709] test_ssl fails on Fedora 29: test_min_max_version()
In-Reply-To: <1547138857.4.0.0864082014803.issue35709@roundup.psfhosted.org>
Message-ID: <1547139582.12.0.829727378214.issue35709@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh right, it's a duplicate of bpo-35045.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35709>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:05:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 17:05:44 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547139944.06.0.467861562753.issue35045@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:05:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 17:05:57 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547139957.87.0.904287681756.issue35045@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +11055
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:06:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 17:06:04 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547139964.45.0.760953185488.issue35045@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +11055, 11056
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:06:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 17:06:10 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547139970.93.0.292231318512.issue35045@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11055, 11056, 11057
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:11:12 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 10 Jan 2019 17:11:12 +0000
Subject: [issue35710] Make dataclasses.field() accept another name for
 __init__ field's name
Message-ID: <1547140271.38.0.846532339527.issue35710@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

When creating a class, I sometimes wish to get this behavior:


    def MyClass:
        def __init__(self, param):
            self._param = param

        def __repr__(self):
            return f"MyClass(param={self._param})"


Unless I'm making a mistaking, this behavior is not currently possible with dataclasses.

I propose to change:

    field(*, default=MISSING, default_factory=MISSING, repr=True, hash=None, init=True, compare=True, metadata=None)

to: 

    field(*, default=MISSING, default_factory=MISSING, repr=True, hash=None, init=True, compare=True, metadata=None, target=None)

with target being used as the init parameter name for this field and in the repr.

If this is accepted, I can post the patch to make this change.

----------
messages: 333409
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: Make dataclasses.field() accept another name for __init__ field's name
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35710>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:14:59 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Thu, 10 Jan 2019 17:14:59 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547140499.7.0.0541774359058.issue35698@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

It might be better in my sample code to write
    isinstance(p, int)
instead of
    type(p) == int
This would fix R?mi's example. (I wanted to avoid thinking about (False // True).)

For median([1, 1]), I am not claiming that 1.0 is wrong and 1 is right. I'm not saying the module is broken, only that it can be improved.

For median([1, 1]), I believe that 1 is a better answer, particularly for school students. In other words, that making this change would improve Python.

As a pure mathematician, to me 1.0 means a number that is close to 1. Whereas 1 means a number that is exactly 1..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:35:39 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 17:35:39 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547141739.79.0.906760664645.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11058

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:35:55 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 17:35:55 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547141755.69.0.866675371569.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11058, 11059

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:36:09 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 17:36:09 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547141769.9.0.573866221609.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11058, 11059, 11060

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:37:40 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Jan 2019 17:37:40 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547141860.61.0.711003175952.issue35045@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +11061

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:37:47 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Jan 2019 17:37:47 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547141867.59.0.901422189956.issue35045@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +11061, 11062

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:37:54 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 10 Jan 2019 17:37:54 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547141874.66.0.0491097401222.issue35045@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +11061, 11062, 11063

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:46:57 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 10 Jan 2019 17:46:57 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547142417.15.0.250457419114.issue32146@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm sorry about not seeing your PR before.  Would you like to update it against current git master?

(note I'm not thrilled by the use of the "ast" module; I hope we can change the command-line args so that this isn't needed)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:51:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 17:51:30 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547142690.54.0.00221104322167.issue32146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset bab4bbb4c9cd5d25ede21a1b8c99d56e3b8dae9d by Victor Stinner (Bo Bayles) in branch 'master':
bpo-32146: Add documentation about frozen executables on Unix (GH-5850)
https://github.com/python/cpython/commit/bab4bbb4c9cd5d25ede21a1b8c99d56e3b8dae9d


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:51:44 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 17:51:44 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547142704.96.0.499115708178.issue32146@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11064

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:51:53 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 17:51:53 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547142713.03.0.346860201343.issue32146@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11064, 11065

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:52:01 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 17:52:01 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547142721.65.0.948186005914.issue32146@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11064, 11065, 11066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:57:24 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Jan 2019 17:57:24 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547143044.74.0.147256692534.issue35701@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: 3.8 needlessly breaks weak references for UUIDs -> [uuid] 3.8 breaks weak references for UUIDs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:58:32 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Jan 2019 17:58:32 +0000
Subject: [issue35698] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547143112.41.0.360386173661.issue35698@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 12:58:55 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 10 Jan 2019 17:58:55 +0000
Subject: [issue35698] [statistics] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547143135.97.0.335501512504.issue35698@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Division by 2 in statistics.median -> [statistics] Division by 2 in statistics.median

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:01:48 2019
From: report at bugs.python.org (Ricardo Fraile)
Date: Thu, 10 Jan 2019 18:01:48 +0000
Subject: [issue35702] clock_gettime: Add new identifier CLOCK_UPTIME_RAW for
 Darwin
In-Reply-To: <1547139515.68.0.371082411437.issue35702@roundup.psfhosted.org>
Message-ID: <dcc7a0b1388028de51f95c4b4a16ba9a@rfraile.eu>


Ricardo Fraile <rfraile at rfraile.eu> added the comment:

Impressive response time, thanks team!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35702>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:05:05 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 18:05:05 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547143505.71.0.923896609736.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11067

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:05:16 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 18:05:16 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547143516.4.0.870990052082.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11067, 11068

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:05:26 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 18:05:26 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547143526.21.0.427226076982.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11067, 11068, 11070

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:05:35 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 18:05:35 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547143535.89.0.0859468000519.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +11067, 11068, 11069, 11070

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:13:16 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 18:13:16 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547143996.29.0.753524883366.issue24746@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:13:25 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Jan 2019 18:13:25 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547144005.54.0.762358333606.issue32146@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b9cd38f928f7eb4e18ad4b63e5c49c05c626c33e by Miss Islington (bot) in branch '3.7':
bpo-32146: Add documentation about frozen executables on Unix (GH-5850)
https://github.com/python/cpython/commit/b9cd38f928f7eb4e18ad4b63e5c49c05c626c33e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 13:56:13 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 10 Jan 2019 18:56:13 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547146573.01.0.0701885743447.issue24746@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset d09e8cecf214b1de457feae01860f5592f912a8e by Ned Deily (Senthil Kumaran) in branch '3.6':
Revert "bpo-24746: Avoid stripping trailing whitespace in doctest fancy diff (GH-10639) (GH-11477)" (GH-11509)
https://github.com/python/cpython/commit/d09e8cecf214b1de457feae01860f5592f912a8e


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:07:49 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 10 Jan 2019 20:07:49 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547150869.58.0.0653812102776.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I'm not sure in which order the conversion should be tried to avoid/reduce precision loss during the conversion.

I would suggest the order

1. __index__ to ensure exact conversion of exact integers
2. __float__ to ensure correct conversion of floating-point numbers
3. __int__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:42:54 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 10 Jan 2019 20:42:54 +0000
Subject: [issue35710] Make dataclasses.field() accept another name for
 __init__ field's name
In-Reply-To: <1547140271.38.0.846532339527.issue35710@roundup.psfhosted.org>
Message-ID: <1547152974.66.0.381539723263.issue35710@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith
nosy: +eric.smith
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35710>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:55:16 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 10 Jan 2019 20:55:16 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547153716.59.0.386215404575.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 0167c08163f44f4a033497102244bbb6150f606b by Senthil Kumaran in branch '2.7':
bpo-24746: Fix doctest failures when running the testsuite with -R (#11501) (#11512)
https://github.com/python/cpython/commit/0167c08163f44f4a033497102244bbb6150f606b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:58:01 2019
From: report at bugs.python.org (Samuel Freilich)
Date: Thu, 10 Jan 2019 20:58:01 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
Message-ID: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>


New submission from Samuel Freilich <sfreilich at google.com>:

_PyObject_FastCallDict and _PyObject_FastCallKeywords assert that there is no pending exception before calling functions that might otherwise clobber the exception state. However, that doesn't produce very clear output for debugging, since the assert failure doesn't say anything about what the pending exception actually was. It would be better to print the pending exception first.

----------
messages: 333418
nosy: Samuel Freilich
priority: normal
severity: normal
status: open
title: Print information about an unexpectedly pending error before crashing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:59:44 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 20:59:44 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547153984.31.0.579535357887.issue35711@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11071
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:59:47 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 20:59:47 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547153987.27.0.369537762385.issue35711@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11071, 11072
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Thu Jan 10 15:59:51 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Jan 2019 20:59:51 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547153991.05.0.408727826707.issue35711@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11071, 11072, 11073
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Thu Jan 10 16:18:29 2019
From: report at bugs.python.org (Piotr Dobrogost)
Date: Thu, 10 Jan 2019 21:18:29 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
 string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1547155109.72.0.826779945571.issue2517@roundup.psfhosted.org>


Piotr Dobrogost <bugs.python at p.dobrogost.net> added the comment:

Benjamin Peterson in comment https://bugs.python.org/issue2517#msg64771 wrote:

"That is because Python encodes it's error messages as ASCII by default?"

Could somebody please point where in the source code of Python 2 this happens?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2517>
_______________________________________

From report at bugs.python.org  Thu Jan 10 16:42:05 2019
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 10 Jan 2019 21:42:05 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1547156525.64.0.137790264428.issue35656@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

APPROXIMATE feels like it might lead to code smell to me, if I know roughly what the float should be why would I not want to test it for exactness? It could end up hiding inconsistencies the tests should be catching.

----------
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35656>
_______________________________________

From report at bugs.python.org  Thu Jan 10 16:55:07 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 10 Jan 2019 21:55:07 +0000
Subject: [issue35712] Make NotImplemented unusable in boolean context
Message-ID: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

I don't really expect this to go anywhere until Python 4 (*maybe* 3.9 after a deprecation period), but it seems like it would have been a good idea to make NotImplementedType's __bool__ explicitly raise a TypeError (rather than leaving it unset, so NotImplemented evaluates as truthy). Any correct use of NotImplemented per its documented intent would never evaluate it in a boolean context, but rather use identity testing, e.g. back in the Py2 days, the canonical __ne__ delegation to __eq__ for any class should be implemented as something like:

    def __ne__(self, other):
        equal = self.__eq__(other)
        return equal if equal is NotImplemented else not equal

Problem is, a lot of folks would make mistakes like doing:

    def __ne__(self, other):
        return not self.__eq__(other)

which silently returns False when __eq__ returns NotImplemented, rather than returning NotImplemented and allowing Python to check the mirrored operation. Similar issues arise when hand-writing the other rich comparison operators in terms of each other.

It seems like, given NotImplemented is a sentinel value that should never be evaluated in a boolean context, at some point it might be nice to explicitly prevent it, to avoid errors like this.

Main argument against it is that I don't know of any other type/object that explicitly makes itself unevaluable in a boolean context, so this could be surprising if someone uses NotImplemented as a sentinel unrelated to its intended purpose and suffers the problem.

----------
messages: 333421
nosy: josh.r
priority: normal
severity: normal
status: open
title: Make NotImplemented unusable in boolean context
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________

From report at bugs.python.org  Thu Jan 10 17:15:03 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 10 Jan 2019 22:15:03 +0000
Subject: [issue26239] distutils link-objects is not normalized
In-Reply-To: <1454104848.79.0.657615243425.issue26239@psf.upfronthosting.co.za>
Message-ID: <1547158503.73.0.940791494629.issue26239@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

This was fixed in issue 1703178.

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> link_objects in setup.cfg crashes build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26239>
_______________________________________

From report at bugs.python.org  Thu Jan 10 17:35:32 2019
From: report at bugs.python.org (Tasy)
Date: Thu, 10 Jan 2019 22:35:32 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
Message-ID: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>


New submission from Tasy <obiwan408 at mail.com>:

.
.
.
./python -E -S -m sysconfig --generate-posix-vars ;\
	if test $? -ne 0 ; then \
		echo "generate-posix-vars failed" ; \
		rm -f ./pybuilddir.txt ; \
		exit 1 ; \
	fi
Fatal Python error: _PySys_BeginInit: can't initialize sys module

Current thread 0x00002b4e5f9bf400 (most recent call first):
Aborted (core dumped)
generate-posix-vars failed
make[1]: *** [pybuilddir.txt] Error 1
make[1]: Leaving directory `/usr/local/mysoftware/Python-3.7.2/build'
make: *** [profile-opt] Error 2

----------
components: Build
messages: 333423
nosy: Tasy
priority: normal
severity: normal
status: open
title: Fatal Python error: _PySys_BeginInit: can't initialize sys module
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Thu Jan 10 17:42:12 2019
From: report at bugs.python.org (Dan Snider)
Date: Thu, 10 Jan 2019 22:42:12 +0000
Subject: [issue35714] Document that the null character '\0' terminates a
 struct format spec
Message-ID: <1547160130.27.0.885629506261.issue35714@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

ie.:
    >>> from struct import calcsize
    >>> calcsize('\144\u0064\000xf\U00000031000\60d\121\U00000051')
    16

I'm sure some people think it's obvious or even expect the null character to signal EOF but it probably isn't obvious at all to those without experience in lower level languages. It actually seems like Python goes out of its way to make sure everything treats the null character no more special than the letter "H", which is good.

At first glance I'd think something like this was just another trivial quirk of the language and not bring it up, but because the documentation doesn't mention it I actually got stuck on something related for half an hour when unit testing some dynamically generated format specs. 

Without going into unnecessary detail, what happened was that a typo in another tangentially related part of the test was enabling the generation of a rogue null byte. I'm bad at those "find face in the crowd" puzzles and this was hardly different, being literally camouflaged within a 300 character format spec containing a random mixture of escaped and non-escaped source characters in the forms: \Uffffffff, \uffff, \777, \xff, \x00, + latin/ascii.

If I'm not the only one who sees this as a slightly bigger deal than poor documentation, the fix is trivial with an extra call to PyBytes_GET_SIZE when null is found. But just because I can't think of a use case in allowing the null character to precede other characters in the format string doesn't mean there isn't one, which is why only documentation is currently selected.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 333424
nosy: bup, docs at python
priority: normal
severity: normal
status: open
title: Document that the null character '\0' terminates a struct format spec
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35714>
_______________________________________

From report at bugs.python.org  Thu Jan 10 17:48:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 22:48:50 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547160530.49.0.0918442347652.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> .
> .
> .

Hello. Can you elaborate this part?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Thu Jan 10 17:54:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Jan 2019 22:54:18 +0000
Subject: [issue35712] Make NotImplemented unusable in boolean context
In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org>
Message-ID: <1547160858.0.0.942118281988.issue35712@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems related issue22978

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________

From report at bugs.python.org  Thu Jan 10 18:38:41 2019
From: report at bugs.python.org (Tasy)
Date: Thu, 10 Jan 2019 23:38:41 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547163521.02.0.875994309905.issue35713@roundup.psfhosted.org>


Tasy <obiwan408 at mail.com> added the comment:

Sorry for the confusion. The three dots were for many lines of successful compilation output from make. The rest is the final few lines where the compilation fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Thu Jan 10 18:42:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Jan 2019 23:42:00 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547163720.43.0.369757997471.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Because it's late, I will say it shortly: if you don't elaborate how you get this error, I will simply close the issue. You have to describe what you are trying to do, your OS, etc.

(It works for me!)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Thu Jan 10 18:45:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 10 Jan 2019 23:45:02 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547163902.42.0.196231570332.issue35713@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Please attach the full build log too along with the command executed.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Thu Jan 10 20:03:27 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 11 Jan 2019 01:03:27 +0000
Subject: [issue35714] Document that the null character '\0' terminates a
 struct format spec
In-Reply-To: <1547160130.27.0.885629506261.issue35714@roundup.psfhosted.org>
Message-ID: <1547168607.96.0.245850146428.issue35714@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm not sure whether having NULLs terminate a struct format string is a feature or a bug.

Given that nearly every other string in Python treat NULLs as ordinary characters, I'm inclined to say this is a bug. Or at least an unnecessary restriction that ought to be lifted.

----------
nosy: +steven.daprano
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35714>
_______________________________________

From report at bugs.python.org  Thu Jan 10 20:18:33 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 11 Jan 2019 01:18:33 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547169513.45.0.316689309565.issue24746@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

All changes related to this issue are done.

Thanks for your contribution and engagement everyone!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Thu Jan 10 20:28:52 2019
From: report at bugs.python.org (bbayles)
Date: Fri, 11 Jan 2019 01:28:52 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547170132.22.0.10664100004.issue32146@roundup.psfhosted.org>


bbayles <bbayles at gmail.com> added the comment:

Thanks for the note. I've merged in master and fixed a conflict in the test file.

In an earlier rev I tried to do the argument parsing without ast.literal_eval, but found it awkward to support all the ways [1] can manifest. You might have a better idea?


[1] https://github.com/python/cpython/blob/3.7/Lib/multiprocessing/forkserver.py#L106-L107

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Thu Jan 10 20:44:01 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 11 Jan 2019 01:44:01 +0000
Subject: [issue35712] Make NotImplemented unusable in boolean context
In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org>
Message-ID: <1547171041.41.0.673000572335.issue35712@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> the canonical __ne__ delegation to __eq__ for any class should be implemented as something like

I disagree that your code snippet is the canonical way to write __ne__. I'd write it like this:

    def __ne__(self, other):
        return not (self == other)

Or just not write it at all. Python will automatically call __eq__ going back to Python 2.4 (and possibly older).

Delegating to __eq__ directly is the wrong way to do it.

> NotImplemented is a sentinel value that should never be evaluated in a boolean context

I don't see why not. I can't think of any use-cases where I would want to *specifically* use NotImplemented in a boolean context, but I see no good reason why I would want it to fail if one happened to do so.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________

From report at bugs.python.org  Thu Jan 10 21:02:58 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 11 Jan 2019 02:02:58 +0000
Subject: [issue34628] urllib.request.urlopen fails when userinfo is present in
 URL
In-Reply-To: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>
Message-ID: <1547172178.61.0.749592876129.issue34628@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I found that Requests library use urllib3 library which looks like ignore the user info part (in request_context https://github.com/urllib3/urllib3/blob/master/src/urllib3/poolmanager.py#L208). Did I miss something or we should also ignore it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34628>
_______________________________________

From report at bugs.python.org  Thu Jan 10 23:39:54 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Jan 2019 04:39:54 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1547181594.26.0.447414383097.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Your tests actually went the other way. This one puts a trailing space after the prompt and expected it to be there in the file, but also ensured that exactly one space was added at the start.

        self.assertEqual(context.prompt, '(My prompt) ')
        builder.create(self.env_dir)
        data = self.get_text_file_contents('pyvenv.cfg')
        self.assertIn('prompt = (My prompt) \n', data)

In the line "prompt = (My prompt) ", we need to define which of the spaces at either end of the value should be retained by tools trying to use the same prompt. The obvious assumption is to strip both ends, which would break your test. The next most obvious is to quote the string value (e.g. write repr(context.prompt) instead of the prompt directly).

Also, I'm pretty sure I saw some advice once to use multiple lines worth of prompt, which probably breaks many shells but presumably works okay in Bash. You'll need to handle that case as well - again, repr() will do it naturally by encoding newlines an "\n".

Anyone reading the string will have to do the equivalent of Python's literal_eval(), but that's pretty manageable in exchange for avoiding a whole lot of edge cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Thu Jan 10 23:59:48 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Jan 2019 04:59:48 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547182788.26.0.496624996406.issue35693@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Defining new training sets for PGO would be a new job (that you could volunteer to do if you like). The test suite is convenient because when you clone our GitHub repository, it's already there. Another training suite would have to be installed somehow as part of build (like we already do for extra tools).

The layouts are how Python looks when installed. Currently they are not documented, as they are subject to change (within reason - python.exe has to continue working from the root of any install), but the script in the PC/layout directory can produce them all with different options.

It sounds like these jobs may be more than you want to do. If you are just worried about failing tests during PGO training, then stop worrying because they are known and okay. Provided they pass when Python is installed properly (using our primary installer), there is no problem, and it sounds like this is the case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Fri Jan 11 00:56:12 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Fri, 11 Jan 2019 05:56:12 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547186172.85.0.71343089171.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

It is true that I worry about failing tests during PGO training because they stop me from compiling Python -with- PGO. I also got here to report my experience and problems back to you guys but, if the problems are known, well, there's nothing much I can do then. Also, I know this isn't a platform for asking howto questions so I will not bother you guys with that either. I *could* get back to topic and try to help sorting out the test_httpservers (because they do fail on 3.7, at least on my side) but it seems I don't have the necessary experience to give any meaningful aid. There's a saying in my hometown which goes something like this: "the one that does not hinder, helps", so that's what I'll do. happy coding!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Fri Jan 11 00:58:57 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Fri, 11 Jan 2019 05:58:57 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547186337.74.0.8157416156.issue35693@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Fri Jan 11 01:00:01 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Fri, 11 Jan 2019 06:00:01 +0000
Subject: [issue35399] Sysconfig bug
In-Reply-To: <1543901306.28.0.788709270274.issue35399@psf.upfronthosting.co.za>
Message-ID: <1547186401.28.0.824912398791.issue35399@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35399>
_______________________________________

From report at bugs.python.org  Fri Jan 11 01:00:48 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Fri, 11 Jan 2019 06:00:48 +0000
Subject: [issue35400] PGOMGR : warning PG0188:
In-Reply-To: <1543902242.92.0.788709270274.issue35400@psf.upfronthosting.co.za>
Message-ID: <1547186448.49.0.465253212192.issue35400@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35400>
_______________________________________

From report at bugs.python.org  Fri Jan 11 01:00:47 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 11 Jan 2019 06:00:47 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547186447.53.0.135549961222.issue35693@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Test failures during the PGO training (*not* those after the final PGO compilation) should be ignored; if they're not, that's an issue that should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Fri Jan 11 01:02:08 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Fri, 11 Jan 2019 06:02:08 +0000
Subject: [issue35156] Consider revising documentation on Python Builds from
 source
In-Reply-To: <1541288069.11.0.788709270274.issue35156@psf.upfronthosting.co.za>
Message-ID: <1547186528.08.0.398389945077.issue35156@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35156>
_______________________________________

From report at bugs.python.org  Fri Jan 11 01:02:34 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Fri, 11 Jan 2019 06:02:34 +0000
Subject: [issue35157] Missing pyconfig.h when building from source and pgo
 flag is enabled
In-Reply-To: <1541289168.57.0.788709270274.issue35157@psf.upfronthosting.co.za>
Message-ID: <1547186554.1.0.938415376602.issue35157@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35157>
_______________________________________

From report at bugs.python.org  Fri Jan 11 01:05:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Jan 2019 06:05:19 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547186719.19.0.748790481641.issue35693@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> It is true that I worry about failing tests during PGO training because they stop me from compiling Python -with- PGO.

They shouldn't prevent you from compiling with PGO... even if they cause Python to crash, you should be able to compile still. How is it failing? Do you not get binaries in the output folder at the end? What error messages do you see?

In any case, the httpservers failures seem to recur for you on 3.7, but not anyone else, which means we need your help diagnosing that issue. Could you start by getting the latest 3.7 sources, run "PCbuild/build.bat -p x64" and then your rt.bat command and post the complete output?

----------
stage: resolved -> test needed
status: closed -> open
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Fri Jan 11 02:24:07 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 07:24:07 +0000
Subject: [issue35712] Make NotImplemented unusable in boolean context
In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org>
Message-ID: <1547191447.4.0.544785737787.issue35712@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a common mistake. Even the default implementation of object.__ne__ had a bug, fixed only 4 years ago in issue21408. There were several errors in stdlib. I am sure there is a lot of occurrences of this errors in a third party code.

So I like this idea. This can help to fix hidden errors in existing code. But I share also Josh's concerns.

There is related common mistake. In C code, the result of PyObject_IsTrue() often is treated as just a boolean, without checking for errors. Fortunately, in the current CPython code it is handled properly, but I am sure this error still is occurred in third-party extensions.

When these two errors (using NotImplemented in the boolean context and ignoring the error in PyObject_IsTrue() in the C code) meet, this can lead to manifestation of more weird bugs than treating NotImplemented as true: from a crash in debug build to raising an exception in the following unrelated code.

I suggest to start emitting a DeprecationWarning or a FutureWarning in NotImplemented.__bool__.

----------
nosy: +gvanrossum, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________

From report at bugs.python.org  Fri Jan 11 02:28:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 07:28:15 +0000
Subject: [issue35714] Document that the null character '\0' terminates a
 struct format spec
In-Reply-To: <1547160130.27.0.885629506261.issue35714@roundup.psfhosted.org>
Message-ID: <1547191695.01.0.672572906735.issue35714@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I think the null character is illegal character in the format string, and struct functions should raise a struct.error for it.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35714>
_______________________________________

From report at bugs.python.org  Fri Jan 11 02:37:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 07:37:53 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547192273.26.0.862547835364.issue35711@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Calling PyErr_Occurred() on every function call adds some overhead. It should be called only in the debug build.

In addition to the traceback, it would be nice to output also some information about the callable.

Note also that PyErr_Print() calls sys.excepthook and exits the interpreter if SystemExit is raised. It is not a proper function for using here.

----------
components: +Interpreter Core
nosy: +serhiy.storchaka, vstinner
type:  -> enhancement
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Fri Jan 11 03:32:44 2019
From: report at bugs.python.org (Petter S)
Date: Fri, 11 Jan 2019 08:32:44 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1547195564.24.0.116430370553.issue35656@roundup.psfhosted.org>


Petter S <petter.strandmark at gmail.com> added the comment:

I am of the opposite opinion. :-) 

> if I know roughly what the float should be why would I not want to test it for exactness?

When testing algorithms, it is often the case that the answer should be mathematically exactly 2, but due to floating-point inexactness it becomes, say, 1.9999999997 in practice. If I then test for exactly 1.9999999997 the test becomes very brittle and sensitive for e.g. order of multiplications.

Testing floating point numbers with a relative error is essential in many application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35656>
_______________________________________

From report at bugs.python.org  Fri Jan 11 03:36:23 2019
From: report at bugs.python.org (David Chevell)
Date: Fri, 11 Jan 2019 08:36:23 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
Message-ID: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>


New submission from David Chevell <chevell at gmail.com>:

ProcessPoolExecutor workers will hold onto the return value of their last task in memory until the next task is received. Since the return value has already been propagated to the parent process's `Future` or else effectively discarded, this is holding onto objects unnecessarily.

Simple case to reproduce:

    import concurrent.futures
    import time

    executor = concurrent.futures.ProcessPoolExecutor(max_workers=1)

    def big_val():
        return [{1:1} for i in range(1, 1000000)]

    executor.submit(big_val)

    # Observe the memory usage of the process worker during the sleep interval
    time.sleep(10)


This should be easily fixed by having the worker explicitly `del r` after calling `_sendback_result` as it already does this for `call_item`

----------
components: Library (Lib)
messages: 333444
nosy: dchevell
priority: normal
severity: normal
status: open
title: ProcessPool workers hold onto return value of last task in memory
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Fri Jan 11 03:41:48 2019
From: report at bugs.python.org (David Chevell)
Date: Fri, 11 Jan 2019 08:41:48 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1547196108.46.0.23748124481.issue35715@roundup.psfhosted.org>


Change by David Chevell <chevell at gmail.com>:


----------
keywords: +patch
pull_requests: +11075
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Fri Jan 11 03:41:52 2019
From: report at bugs.python.org (David Chevell)
Date: Fri, 11 Jan 2019 08:41:52 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1547196112.55.0.843528051356.issue35715@roundup.psfhosted.org>


Change by David Chevell <chevell at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11075, 11076
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Fri Jan 11 03:41:56 2019
From: report at bugs.python.org (David Chevell)
Date: Fri, 11 Jan 2019 08:41:56 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1547196116.28.0.374796393392.issue35715@roundup.psfhosted.org>


Change by David Chevell <chevell at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11075, 11076, 11077
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Fri Jan 11 03:42:00 2019
From: report at bugs.python.org (David Chevell)
Date: Fri, 11 Jan 2019 08:42:00 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1547196120.06.0.185032657011.issue35715@roundup.psfhosted.org>


Change by David Chevell <chevell at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11075, 11076, 11077, 11078
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:19:55 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 09:19:55 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547198395.45.0.949446601212.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +11079
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:20:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 09:20:00 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547198400.55.0.0230505159276.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11079, 11080
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:20:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 09:20:05 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547198405.5.0.401766456775.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11079, 11080, 11081
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:20:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 09:20:26 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547198426.21.0.0173027765992.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11082

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:20:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 09:20:30 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547198430.6.0.882790628933.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11082, 11083

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:20:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 09:20:35 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547198435.51.0.0287241631084.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11082, 11083, 11084

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Fri Jan 11 04:32:49 2019
From: report at bugs.python.org (Ricardo Fraile)
Date: Fri, 11 Jan 2019 09:32:49 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
Message-ID: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>


New submission from Ricardo Fraile <rfraile at rfraile.eu>:

Add macOS to CLOCK_MONOTONIC_RAW description because it is already available since 10.12.

----------
assignee: docs at python
components: Documentation
files: 001.patch
keywords: patch
messages: 333445
nosy: docs at python, rfrail3, vstinner
priority: normal
severity: normal
status: open
title: CLOCK_MONOTONIC_RAW available on macOS
type: enhancement
Added file: https://bugs.python.org/file48041/001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:09:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 10:09:17 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547201357.3.0.7648307759.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Some examples:

$ ./python -m timeit "format('abc')"
Unpatched:  5000000 loops, best of 5: 65 nsec per loop
Patched:    5000000 loops, best of 5: 42.4 nsec per loop

$ ./python -m timeit "'abc'.replace('x', 'y')"
Unpatched:  5000000 loops, best of 5: 101 nsec per loop
Patched:    5000000 loops, best of 5: 63.8 nsec per loop

$ ./python -m timeit "'abc'.ljust(5)"
Unpatched:  2000000 loops, best of 5: 120 nsec per loop
Patched:    5000000 loops, best of 5: 94.4 nsec per loop

$ ./python -m timeit "(1, 2, 3).index(2)"
Unpatched:  2000000 loops, best of 5: 100 nsec per loop
Patched:    5000000 loops, best of 5: 62.4 nsec per loop

$ ./python -m timeit -s "a = [1, 2, 3]" "a.index(2)"
Unpatched:  2000000 loops, best of 5: 93.8 nsec per loop
Patched:    5000000 loops, best of 5: 70.1 nsec per loop

./python -m timeit -s "import math" "math.pow(0.5, 2.0)"
Unpatched:  2000000 loops, best of 5: 112 nsec per loop
Patched:    5000000 loops, best of 5: 82.3 nsec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:18:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 10:18:43 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547201923.64.0.0493958273908.issue35716@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:22:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 10:22:49 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547202169.47.0.596869163588.issue35716@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ronald, Ned: What is the macOS version used to build Python binaries distributed on python.org? Do we get the constant on macOS 10.12 if binaries are built on macOS 10.11 for example?

I guess that people building Python from source like hombrew will get the constant.

Joannah: Can you please convert attached patch into a pull request? Please mention Ricardo Fraile as co-author of the change (mention his name in the commit message). Such change doesn't need to be mentioned in the changelog (no NEWS entry needed).

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:31:46 2019
From: report at bugs.python.org (Sergey Shashkov)
Date: Fri, 11 Jan 2019 10:31:46 +0000
Subject: [issue25412] __floordiv__ in module fraction fails with TypeError
 instead of returning NotImplemented
In-Reply-To: <1444918194.04.0.71189202918.issue25412@psf.upfronthosting.co.za>
Message-ID: <1547202706.27.0.805945162412.issue25412@roundup.psfhosted.org>


Sergey Shashkov <sh57 at yandex.ru> added the comment:

This patch actually fixes the problem:

https://bugs.python.org/issue35588
https://github.com/python/cpython/commit/3a374e0c5abe805667b71ffaaa7614781101ff4c




from fractions import Fraction
import operator

class Goo:
    __radd__, __rdivmod__, __rfloordiv__, __rmod__, __rmul__, __rpow__, __rsub__, __rtruediv__ = [lambda a, b: 'ok'] * 8

for func in operator.add, operator.sub, operator.mul, operator.truediv, operator.pow, operator.mod, operator.floordiv, divmod:
    print(func.__name__, func(Fraction(1), Goo()))

----------
nosy:  -mark.dickinson, oscarbenjamin, vstinner
pull_requests: +11085
resolution:  -> fixed
stage:  -> patch review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25412>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:33:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 10:33:35 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547202815.65.0.254681647419.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

$ ./python -m timeit "format('abc')"
Unpatched:  5000000 loops, best of 5: 65 nsec per loop
Patched:    5000000 loops, best of 5: 42.4 nsec per loop

-23 ns on 65 ns: this is very significant! I spent like 6 months to implement "FASTCALL" to avoid a single tuple to pass positional arguments and it was only 20 ns faster per call. Additional 23 ns make the code way faster compared than Python without FASTCALL! I estimate something like 80 ns => 42 ns: 2x faster!

$ ./python -m timeit "'abc'.replace('x', 'y')"
Unpatched:  5000000 loops, best of 5: 101 nsec per loop
Patched:    5000000 loops, best of 5: 63.8 nsec per loop

-38 ns on 101 ns: that's even more significant! Wow, that's very impressive!

Please merge your PR, I want it now :-D

Can you maybe add a vague sentence in the Optimizations section of What's New in Python 3.8 ? Something like: "Parsing positional arguments in builtin functions has been made more efficient."? I'm not sure if "builtin" is the proper term here. Functions using Argument Clinic to parse their arguments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:38:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 10:38:07 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547203087.1.0.0374927851463.issue35711@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I added _Py_CheckFunctionResult() to every C calls. This function calls PyErr_Occurred() after a function call. This change has been made in Python 3.5: bpo-23571. I made this change because it was very difficult to identify bugs when an exception was raised but the bug was only spotted "later". Some exceptions were ignored by mistakes.

I also added a *lot* of assertions like the following one, but only when Python is built in debug mode:

#ifdef Py_DEBUG
    /* type_call() must not be called with an exception set,
       because it may clear it (directly or indirectly) and so the
       caller loses its exception */
    assert(!PyErr_Occurred());
#endif

commit 4a7cc8847276df27c8f52987cda619ca279687c2
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Fri Mar 6 23:35:27 2015 +0100

    Issue #23571: PyObject_Call(), PyCFunction_Call() and call_function() now
    raise a SystemError if a function returns a result and raises an exception.
    The SystemError is chained to the previous exception.
    
    Refactor also PyObject_Call() and PyCFunction_Call() to make them more readable.
    
    Remove some checks which became useless (duplicate checks).
    
    Change reviewed by Serhiy Storchaka.

commit efde146b0c42f2643f96d00896c99a90d501fb69
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Sat Mar 21 15:04:43 2015 +0100

    Issue #23571: _Py_CheckFunctionResult() now gives the name of the function
    which returned an invalid result (result+error or no result without error) in
    the exception message.
    
    Add also unit test to check that the exception contains the name of the
    function.
    
    Special case: the final _PyEval_EvalFrameEx() check doesn't mention the
    function since it didn't execute a single function but a whole frame.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:42:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 10:42:12 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547203332.41.0.527887569757.issue35711@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm a supporter to add *more* checks to the debug build but also provide a Python runtime compiled in debug mode which would be ABI compatible (no need to rebuild C extensions).

See my large project:

   https://pythoncapi.readthedocs.io/

Especially:

   https://pythoncapi.readthedocs.io/runtimes.html#debug-build

It would avoid any overhead at runtime for the regular runtime (compiled in release mode).

Only we would have such "debug runtime" available, I even plan to remove runtime checks from the release build :-)

https://pythoncapi.readthedocs.io/optimization_ideas.html#remove-debug-checks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:47:16 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 11 Jan 2019 10:47:16 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547203636.95.0.883375344716.issue35716@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11086
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:47:30 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 11 Jan 2019 10:47:30 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547203650.95.0.760523180969.issue35716@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11086, 11087
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:47:44 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 11 Jan 2019 10:47:44 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547203664.36.0.128205666619.issue35716@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11086, 11087, 11088
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:51:27 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 11 Jan 2019 10:51:27 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547203887.92.0.434271785136.issue35716@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@vstinner I have created the PR for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:52:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 10:52:17 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547203937.52.0.855985094561.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I suppose that my computer is a bit faster than your, so your 20 ns can be only 15 ns or 10 ns on my computer. Run microbenchmarks on your computer to get a scale.

It may be possible to save yet few nanoseconds if inline a fast path for _PyArg_CheckPositional(), but I'm going to try this later.

This change is a step in a sequence. I will add a What's New note after finishing so much steps as possible. The next large step is to optimize argument parsing for functions with keyword parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:52:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 10:52:42 +0000
Subject: [issue14614] PyTuple_SET_ITEM could check bounds in debug mode
In-Reply-To: <1334761414.21.0.756614621806.issue14614@psf.upfronthosting.co.za>
Message-ID: <1547203962.01.0.825733802958.issue14614@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Since bpo-35337 has been rejected, I also close this issue.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14614>
_______________________________________

From report at bugs.python.org  Fri Jan 11 05:57:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 11 Jan 2019 10:57:33 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547204253.23.0.147368552784.issue35582@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is it possible to run custom builds or benchmark of this once merged on speed.python.org ? I hope this give will be a noticeable dip in the benchmark graphs.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:01:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 11:01:10 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547204470.73.0.427682311059.issue35716@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

@Ricardo: Can you please give you email address? It's to credit you in the commit message. (You don't have to, it's up to you to share it or not :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:02:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 11:02:27 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547204547.16.0.439719985291.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I can trigger a benchmark run on speed.python.org once the change is merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:11:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 11:11:11 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547205071.59.0.981800379449.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Added Stefan because the new C API could be used in Cython after stabilizing. We should more cooperate with Cython team and provide a (semi-)official stable API for using in Cython.

I do not expect large affect on most tests, since this optimization affects only a part of functions, and can be noticeable only for very fast function calls.

----------
nosy: +scode

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:31:59 2019
From: report at bugs.python.org (Ricardo Fraile)
Date: Fri, 11 Jan 2019 11:31:59 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547206319.11.0.352078425574.issue35716@roundup.psfhosted.org>


Ricardo Fraile <rfraile at rfraile.eu> added the comment:

@vstinner here you have rfraile at rfraile.eu :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:37:08 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jan 2019 11:37:08 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547206628.34.0.879688335179.issue32146@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

The key here would be to replace function execution with module execution and command-line arguments.

So instead of:

  python -c 'from multiprocessing.forkserver import main; main(ARG1, ARG2...)'

you would do:

  python -m multiprocessing.forkserver ARG1 ARG2 ....

Then it should become easy to extract the concatenated command lines.

(and if that works, please do the same for semaphore_tracker ;-))

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Fri Jan 11 06:52:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 11:52:24 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1547207544.68.0.972257023414.issue34850@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If you are fine with this change Gregory, do you mind to withdraw your request and remove the DO-NOT-MERGE label on GitHub?

As for DeprecationWarning vs SyntaxWarning:

1. It looks as misuse of DeprecationWarning. We do not plan to remove this feature in future. Emitting it will send a false signal to users. And SyntaxWarning was added such kind of warning: syntactically valid code that for sure is an error.

2. Seems there is no differences between DeprecationWarning and SyntaxWarning if they are emitted at compile time. They will be shown by default in all cases, in the main script and in modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Fri Jan 11 07:14:24 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 11 Jan 2019 12:14:24 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547208864.41.0.0203617212132.issue35582@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +scoder -scode

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 07:15:37 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 11 Jan 2019 12:15:37 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547208937.21.0.399393187078.issue35716@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@Ricardo, Thanks, commit message updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 07:37:27 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 11 Jan 2019 12:37:27 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547210247.59.0.660182684775.issue35582@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

It might be worth inlining a fast path of "_PyArg_CheckPositional()" that only tests "nargs < min || nargs > max" (even via a macro), and then branches to the full error checking and reporting code only if that fails. Determining the concrete exception to raise is not time critical, but the good case is. Also, that would immediately collapse into "nargs != minmax" for the cases where "min == max", i.e. we expect an exact number of arguments.

And yes, a function that raises the expected exception with the expected error message for a hand full of common cases would be nice. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:19:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 13:19:59 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547212799.67.0.33362085158.issue35716@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fd7d539be3ce1cc098a4f104b7a7816ca00add16 by Victor Stinner (Joannah Nanjekye) in branch 'master':
bpo-35716: Update time.CLOCK_MONOTONIC_RAW doc (GH-11517)
https://github.com/python/cpython/commit/fd7d539be3ce1cc098a4f104b7a7816ca00add16


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:26:20 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:26:20 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547213180.62.0.535267910963.issue35716@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:26:28 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:26:28 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547213188.48.0.562717606807.issue35716@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11089, 11090

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:26:39 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:26:39 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547213199.45.0.857559439217.issue35716@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11089, 11090, 11091

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:32:14 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:32:14 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547213534.05.0.158175057443.issue35716@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8a5b1aa98f97923c39734b508aead152a5a1c911 by Miss Islington (bot) in branch '3.7':
bpo-35716: Update time.CLOCK_MONOTONIC_RAW doc (GH-11517)
https://github.com/python/cpython/commit/8a5b1aa98f97923c39734b508aead152a5a1c911


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:33:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 13:33:38 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547213618.67.0.282070551757.issue35716@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Joannah Nanjekye for the PR. I rewrote the commit message to format properly the co-authored-by tag. The doc has been updated in 3.7 and master.

Ricardo Fraile: *Please*. Don't use this clock :-) It must not be used except if you really understand well what you are doing :-)

https://www.python.org/dev/peps/pep-0418/#clock-monotonic-clock-monotonic-raw-clock-boottime

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:35:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 13:35:17 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547213717.05.0.494687708745.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5485085b324a45307c1ff4ec7d85b5998d7d5e0d by Victor Stinner in branch 'master':
bpo-32710: Fix _overlapped.Overlapped memory leaks (GH-11489)
https://github.com/python/cpython/commit/5485085b324a45307c1ff4ec7d85b5998d7d5e0d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:35:38 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:35:38 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547213738.82.0.87715748804.issue32710@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11092

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:35:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:35:47 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547213747.09.0.933007714884.issue32710@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11092, 11093

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:35:55 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 13:35:55 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547213755.5.0.175465168146.issue32710@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11092, 11093, 11094

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Fri Jan 11 08:58:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 13:58:34 +0000
Subject: [issue24746] doctest 'fancy diff' formats incorrectly strip trailing
 whitespace
In-Reply-To: <1438133212.76.0.56822320345.issue24746@psf.upfronthosting.co.za>
Message-ID: <1547215114.27.0.674050550756.issue24746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

All Refleaks buildots are back to green, thanks ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24746>
_______________________________________

From report at bugs.python.org  Fri Jan 11 09:01:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 14:01:18 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547215278.35.0.92918381805.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4fa9591025b6a098f3d6402e5413ee6740ede6c5 by Serhiy Storchaka in branch 'master':
bpo-35582: Argument Clinic: inline parsing code for positional parameters. (GH-11313)
https://github.com/python/cpython/commit/4fa9591025b6a098f3d6402e5413ee6740ede6c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 09:01:53 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Jan 2019 14:01:53 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547215313.5.0.576671929127.issue32710@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 059997d78ed1a1a5a364b1846ac972c98c704927 by Miss Islington (bot) in branch '3.7':
bpo-32710: Fix _overlapped.Overlapped memory leaks (GH-11489)
https://github.com/python/cpython/commit/059997d78ed1a1a5a364b1846ac972c98c704927


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Fri Jan 11 09:09:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 14:09:16 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1547215756.24.0.602765930467.issue34838@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 9659 is mostly superseded by issue35582. But it may contain other changes. Ammar, do you mind to create a new PR or merge the old PR with the current master?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Fri Jan 11 09:11:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 14:11:20 +0000
Subject: [issue32710] test_asyncio: ProactorEventLoopTests sendfile tests leak
 references on Windows
In-Reply-To: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>
Message-ID: <1547215880.88.0.174223420104.issue32710@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, _overlapped.Overlapped should now have a few less memory leaks :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Fri Jan 11 09:44:16 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Jan 2019 14:44:16 +0000
Subject: [issue35716] CLOCK_MONOTONIC_RAW available on macOS
In-Reply-To: <1547199168.5.0.0198252527214.issue35716@roundup.psfhosted.org>
Message-ID: <1547217856.1.0.653346087627.issue35716@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Victor, the binaries are build on the macOS version mentioned in the download. That is, the modern 64-bit installers are build on macOS 10.9 with the 10.9 SDK, the older 32/64-bit intel installers are build on macOS 10.6 with the 10.6 SDK.

With some work it should be possible to build the 64-bit installer on newer macOS releases, but that requires some work to ensure the code deals well with weakly linked symbols.  I've added such support in the past for older macOS releases, so this is definitely doable.  I'd love to work on this, but don't know when I'll have time to do so.

BTW. I'm pretty sure there's an issue about this, but cannot find it at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35716>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:08:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 15:08:15 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
Message-ID: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

sys._getframe(2) fails in the following example:

code = "from enum import Enum; Enum('Animal', 'ANT BEE CAT DOG')"
code = compile(code, "<string>", "exec")
global_ns = {}
local_ls = {}
exec(code, global_ns, local_ls)

Error with Python 3.7.2 (Fedora 29):

Traceback (most recent call last):
  File "x.py", line 5, in <module>
    exec(code, global_ns, local_ls)
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.7/enum.py", line 311, in __call__
    return cls._create_(value, names, module=module, qualname=qualname, type=type, start=start)
  File "/usr/lib64/python3.7/enum.py", line 429, in _create_
    module = sys._getframe(2).f_globals['__name__']
KeyError: '__name__'

----------
components: Library (Lib)
messages: 333474
nosy: barry, eli.bendersky, ethan.furman, vstinner
priority: normal
severity: normal
status: open
title: enum.Enum error on sys._getframe(2)
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:08:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 15:08:42 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547219322.34.0.298686579691.issue35717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug has been reported in my perf project:
https://github.com/vstinner/perf/issues/49

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:09:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 15:09:03 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547219343.06.0.454096977081.issue35582@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11095

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:09:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 15:09:13 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547219353.2.0.721964192855.issue35582@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11095, 11096

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:09:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 15:09:21 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547219361.44.0.670841863114.issue35582@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11095, 11096, 11097

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:12:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 15:12:07 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547219527.5.0.219646816475.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I converted msg333446 into attached bench.py using perf. Results on my laptop:

vstinner at apu$ ./python -m perf compare_to ref.json inlined.json --table -G
+-------------------------+---------+------------------------------+
| Benchmark               | ref     | inlined                      |
+=========================+=========+==============================+
| format('abc')           | 74.4 ns | 43.7 ns: 1.70x faster (-41%) |
+-------------------------+---------+------------------------------+
| 'abc'.replace('x', 'y') | 93.0 ns | 57.5 ns: 1.62x faster (-38%) |
+-------------------------+---------+------------------------------+
| (1, 2, 3).index(2)      | 92.5 ns | 59.2 ns: 1.56x faster (-36%) |
+-------------------------+---------+------------------------------+
| a.index(2)              | 93.6 ns | 59.9 ns: 1.56x faster (-36%) |
+-------------------------+---------+------------------------------+
| 'abc'.ljust(5)          | 124 ns  | 86.0 ns: 1.44x faster (-30%) |
+-------------------------+---------+------------------------------+
| math.pow(0.5, 2.0)      | 121 ns  | 88.1 ns: 1.37x faster (-27%) |
+-------------------------+---------+------------------------------+

The speedup on my laptop is between 30.7 and 38.0 ns per function call, on these specific functions.

1.7x faster on format() is very welcome, well done Serhiy!

Note: You need the just released perf 1.6.0 version to run this benchmark ;-)

----------
Added file: https://bugs.python.org/file48042/bench.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:19:35 2019
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Jan 2019 15:19:35 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547219975.91.0.457231464602.issue35717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Looks like the following code:

        if module is None:
            try:
                module = sys._getframe(2).f_globals['__name__']
            except (AttributeError, ValueError) as exc:
                pass

needs to have `KeyError` added to the `except` line.

----------
assignee:  -> ethan.furman
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:30:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 15:30:25 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547220625.91.0.332614922862.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I can trigger a benchmark run on speed.python.org once the change is merged.

Aha, it seems like Serhiy has more optimizations to come: PR #11520.

@Serhiy: tell me when you are done, so I can trigger a new benchmark run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:41:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 15:41:27 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547221287.01.0.952362021002.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 11520 additionally replaces PyArg_UnpackTuple() and _PyArg_UnpackStack() with _PyArg_CheckPositional() and inlined code in Argument Clinic.

Some examples for PR 11520:

$ ./python -m timeit "'abc'.strip()"
Unpatched:  5000000 loops, best of 5: 51.2 nsec per loop
Patched:    5000000 loops, best of 5: 45.8 nsec per loop

$ ./python -m timeit -s "d = {'a': 1}" "d.get('a')"
Unpatched:  5000000 loops, best of 5: 55 nsec per loop
Patched:    5000000 loops, best of 5: 51.1 nsec per loop

$ ./python -m timeit "divmod(5, 2)"
Unpatched:  5000000 loops, best of 5: 87 nsec per loop
Patched:    5000000 loops, best of 5: 80.6 nsec per loop

$ ./python -m timeit "hasattr(1, 'numerator')"
Unpatched:  5000000 loops, best of 5: 62.4 nsec per loop
Patched:    5000000 loops, best of 5: 54.8 nsec per loop

$ ./python -m timeit "isinstance(1, int)"
Unpatched:  5000000 loops, best of 5: 62.7 nsec per loop
Patched:    5000000 loops, best of 5: 54.1 nsec per loop

$ ./python -m timeit -s "from math import gcd" "gcd(6, 10)"
Unpatched:  2000000 loops, best of 5: 99.6 nsec per loop
Patched:    5000000 loops, best of 5: 89.9 nsec per loop

$ ./python -m timeit -s "from operator import add" "add(1, 2)"
Unpatched:  5000000 loops, best of 5: 40.7 nsec per loop
Patched:    10000000 loops, best of 5: 32.6 nsec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 10:47:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 15:47:51 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547221671.39.0.439071476432.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

$ ./python -m timeit -s "from operator import add" "add(1, 2)"
Unpatched:  5000000 loops, best of 5: 40.7 nsec per loop
Patched:    10000000 loops, best of 5: 32.6 nsec per loop

We should stop you, or the timing will become negative if you continue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:01:27 2019
From: report at bugs.python.org (Opher Shachar)
Date: Fri, 11 Jan 2019 16:01:27 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
Message-ID: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>


New submission from Opher Shachar <ophers at gmail.com>:

When creating a custom Command (or sub-classing one) we cannot initialize in "initialize_options()" the "force" option to 1, because Command.__init__ resets it to None after the call to self.initialize_options().

----------
components: Distutils
messages: 333481
nosy: Opher Shachar, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Cannot initialize the "force" command-option
type: behavior
versions: Python 2.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:01:55 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 16:01:55 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547222515.08.0.00906142860202.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2a39d251f07d4c620e3b9a1848e3d1eb3067be64 by Serhiy Storchaka in branch 'master':
bpo-35582: Argument Clinic: Optimize the "all boring objects" case. (GH-11520)
https://github.com/python/cpython/commit/2a39d251f07d4c620e3b9a1848e3d1eb3067be64


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:07:42 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Jan 2019 16:07:42 +0000
Subject: [issue35712] Make NotImplemented unusable in boolean context
In-Reply-To: <1547191447.4.0.544785737787.issue35712@roundup.psfhosted.org>
Message-ID: <CAP7+vJJBykV=qmrofzaAGD-t8riANayPabNH8USHTKMuE+_xpg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I agree.

On Thu, Jan 10, 2019 at 11:24 PM Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> This is a common mistake. Even the default implementation of object.__ne__
> had a bug, fixed only 4 years ago in issue21408. There were several errors
> in stdlib. I am sure there is a lot of occurrences of this errors in a
> third party code.
>
> So I like this idea. This can help to fix hidden errors in existing code.
> But I share also Josh's concerns.
>
> There is related common mistake. In C code, the result of
> PyObject_IsTrue() often is treated as just a boolean, without checking for
> errors. Fortunately, in the current CPython code it is handled properly,
> but I am sure this error still is occurred in third-party extensions.
>
> When these two errors (using NotImplemented in the boolean context and
> ignoring the error in PyObject_IsTrue() in the C code) meet, this can lead
> to manifestation of more weird bugs than treating NotImplemented as true:
> from a crash in debug build to raising an exception in the following
> unrelated code.
>
> I suggest to start emitting a DeprecationWarning or a FutureWarning in
> NotImplemented.__bool__.
>
> ----------
> nosy: +gvanrossum, serhiy.storchaka
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35712>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:13:38 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 16:13:38 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
In-Reply-To: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>
Message-ID: <1547223218.37.0.784586008664.issue31855@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

The off-by-one error in a test added for an unrelated issue (#17467) makes me think @michael.foord just made a mistake in the test.

> mock_open docs mentions about using a customized mock for complex cases
I think it's more for complex things like fetching data using a callback for example, this seems like a normal use case for mock_open(). Even more so, leaving the behavior as it is now may lead someone to think there is a bug in its code.

I opened a new PR to fix this issue: https://github.com/python/cpython/pull/11521

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:14:07 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 16:14:07 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
In-Reply-To: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>
Message-ID: <1547223247.85.0.307407553912.issue31855@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +11098
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:14:16 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 16:14:16 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
In-Reply-To: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>
Message-ID: <1547223256.14.0.881797858771.issue31855@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch
pull_requests: +11098, 11099
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:14:24 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 16:14:24 +0000
Subject: [issue31855] mock_open is not compatible with read(n) (and
 pickle.load)
In-Reply-To: <1508792590.83.0.213398074469.issue31855@psf.upfronthosting.co.za>
Message-ID: <1547223264.17.0.305103379578.issue31855@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch, patch
pull_requests: +11098, 11099, 11100
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31855>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:20:11 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 16:20:11 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1547223611.28.0.93391160867.issue27015@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:46:15 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 16:46:15 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547225175.71.0.0655708144656.issue35717@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 11:50:22 2019
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Jan 2019 16:50:22 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547225422.18.0.422657072014.issue35717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Marking this as "easy".  It needs a test showing the failing behavior, then the fix.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:00:41 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 17:00:41 +0000
Subject: [issue17467] Enhancement: give mock_open readline() and readlines()
 methods
In-Reply-To: <1363637353.75.0.10594649772.issue17467@psf.upfronthosting.co.za>
Message-ID: <1547226041.08.0.947301070676.issue17467@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
pull_requests: +11101

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17467>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:00:48 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 17:00:48 +0000
Subject: [issue17467] Enhancement: give mock_open readline() and readlines()
 methods
In-Reply-To: <1363637353.75.0.10594649772.issue17467@psf.upfronthosting.co.za>
Message-ID: <1547226048.67.0.145675933535.issue17467@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
pull_requests: +11101, 11102

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17467>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:00:56 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 17:00:56 +0000
Subject: [issue17467] Enhancement: give mock_open readline() and readlines()
 methods
In-Reply-To: <1363637353.75.0.10594649772.issue17467@psf.upfronthosting.co.za>
Message-ID: <1547226056.38.0.534982287367.issue17467@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
pull_requests: +11101, 11102, 11103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17467>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:04:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 17:04:08 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547226248.27.0.228066237151.issue35582@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11104

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:04:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 17:04:17 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547226257.46.0.600047368839.issue35582@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11104, 11105

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:04:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 17:04:27 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547226267.64.0.214429962097.issue35582@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11104, 11105, 11106

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:07:22 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 17:07:22 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547226442.33.0.595615883599.issue35717@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +11107
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:08:17 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 11 Jan 2019 17:08:17 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547226497.71.0.405560951481.issue35717@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi, PR https://github.com/python/cpython/pull/11521 should fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:09:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 17:09:39 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547226579.06.0.836314325498.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 11524 performs the same kind of changes as PR 11520, but for handwritten code (only if this causes noticeable speed up). Also iter() is now use the fast call convention.

$ ./python -m timeit "iter(())"
Unpatched:  5000000 loops, best of 5: 82.8 nsec per loop
Patched:    5000000 loops, best of 5: 56.3 nsec per loop

$ ./python -m timeit -s "it = iter([])" "next(it, None)"
Unpatched:  5000000 loops, best of 5: 54.1 nsec per loop
Patched:    5000000 loops, best of 5: 44.9 nsec per loop

$ ./python -m timeit "getattr(1, 'numerator')"
Unpatched:  5000000 loops, best of 5: 63.6 nsec per loop
Patched:    5000000 loops, best of 5: 57.5 nsec per loop

$ ./python -m timeit -s "from operator import attrgetter; f = attrgetter('numerator')" "f(1)"
Unpatched:  5000000 loops, best of 5: 64.1 nsec per loop
Patched:    5000000 loops, best of 5: 56.8 nsec per loop

$ ./python -m timeit -s "from operator import methodcaller; f = methodcaller('conjugate')" "f(1)"
Unpatched:  5000000 loops, best of 5: 79.5 nsec per loop
Patched:    5000000 loops, best of 5: 74.1 nsec per loop

It is possible to speed up also many math methods and maybe some contextvar and hamt methods, but this is for other issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:11:58 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 11 Jan 2019 17:11:58 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547226718.21.0.486436737439.issue35582@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Nice! Well done, Serhiy!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:16:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 17:16:08 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547226968.7.0.283188256379.issue35717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Hi, PR https://github.com/python/cpython/pull/11521 should fix the issue.

It's PR 11523.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:16:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 17:16:18 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547226968.7.0.283188256379.issue35717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Hi, PR https://github.com/python/cpython/pull/11521 should fix the issue.

It's PR 11523.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:16:20 2019
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Jan 2019 17:16:20 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547226980.68.0.995360545123.issue35717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

That PR does not go with this issue.  ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:16:53 2019
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Jan 2019 17:16:53 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547227013.56.0.589533301925.issue35717@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests:  -11107

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:19:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 17:19:15 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547227155.68.0.624370973578.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

$ ./python -m timeit "iter(())"
Unpatched:  5000000 loops, best of 5: 82.8 nsec per loop
Patched:    5000000 loops, best of 5: 56.3 nsec per loop

That's quite significant. Oh, it's because you converted builtin_iter() from METH_VARARGS to METH_FASTCALL at the same time. Interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:20:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jan 2019 17:20:33 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547227233.34.0.281355522129.issue35717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> That PR does not go with this issue.  ;)

It does. You removed the link to PR 11523 which is a fix for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:23:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 17:23:43 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547227423.56.0.534129229054.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Just inlining the arg tuple unpacking in iter() give only 10% speed up. I would not apply this optimization for such small difference. But with converting it to fast call it looks more interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:36:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 17:36:13 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547228173.47.0.263940440222.issue35717@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11108

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 12:45:27 2019
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 11 Jan 2019 17:45:27 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1547228727.4.0.655119268871.issue34838@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Sounds good, I'll take a look at the changes and update the PR accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:14:28 2019
From: report at bugs.python.org (Opher Shachar)
Date: Fri, 11 Jan 2019 18:14:28 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547230468.75.0.852341688339.issue35718@roundup.psfhosted.org>


Change by Opher Shachar <ophers at gmail.com>:


----------
keywords: +patch
pull_requests: +11109
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:14:35 2019
From: report at bugs.python.org (Opher Shachar)
Date: Fri, 11 Jan 2019 18:14:35 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547230475.49.0.645260927395.issue35718@roundup.psfhosted.org>


Change by Opher Shachar <ophers at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11109, 11110
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:14:40 2019
From: report at bugs.python.org (Opher Shachar)
Date: Fri, 11 Jan 2019 18:14:40 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547230480.86.0.0485291735102.issue35718@roundup.psfhosted.org>


Change by Opher Shachar <ophers at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11109, 11110, 11112
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:14:47 2019
From: report at bugs.python.org (Opher Shachar)
Date: Fri, 11 Jan 2019 18:14:47 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547230487.2.0.0298622744596.issue35718@roundup.psfhosted.org>


Change by Opher Shachar <ophers at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11109, 11110, 11111, 11112
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:16:26 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Jan 2019 18:16:26 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547230586.38.0.148271736899.issue35718@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Could you tell how you found the problem, i.e. what are you trying to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:17:12 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 18:17:12 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1547230632.99.0.786559414703.issue34569@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset a909460a09cca79bd051c45b02e650862a57dbd9 by Eric Snow (Michael Felt) in branch 'master':
bpo-34569: Fix subinterpreter 32-bit  ABI, pystate.c/_new_long_object() (gh-9127)
https://github.com/python/cpython/commit/a909460a09cca79bd051c45b02e650862a57dbd9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34569>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:17:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 18:17:26 +0000
Subject: [issue35719] Optimize multi-argument math functions
Message-ID: <1547230644.92.0.865651994946.issue35719@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR makes multi-argument functions in the math module atan2(), copysign(), remainder() and hypot() to use the fast call convention and inline arguments tuple unpacking.

Results:

$ ./python -m timeit -s "from math import atan2" "atan2(1.0, 1.0)"
Unpatched:  5000000 loops, best of 5: 79.5 nsec per loop
Patched:    5000000 loops, best of 5: 66.1 nsec per loop

$ ./python -m timeit -s "from math import copysign" "copysign(1.0, 1.0)"
Unpatched:  5000000 loops, best of 5: 90.3 nsec per loop
Patched:    10000000 loops, best of 5: 35.9 nsec per loop

$ ./python -m timeit -s "from math import remainder" "remainder(1.0, 1.0)"
Unpatched:  5000000 loops, best of 5: 69.5 nsec per loop
Patched:    5000000 loops, best of 5: 44.5 nsec per loop

$ ./python -m timeit -s "from math import hypot" "hypot(1.0, 1.0)"
Unpatched:  5000000 loops, best of 5: 63.6 nsec per loop
Patched:    5000000 loops, best of 5: 47.4 nsec per loop

----------
components: Extension Modules
messages: 333497
nosy: mark.dickinson, rhettinger, serhiy.storchaka, stutzbach, vstinner
priority: normal
severity: normal
status: open
title: Optimize multi-argument math functions
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35719>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:18:13 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 18:18:13 +0000
Subject: [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
In-Reply-To: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>
Message-ID: <1547230693.04.0.639715776633.issue34569@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, Michael.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34569>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:25:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 18:25:15 +0000
Subject: [issue35719] Optimize multi-argument math functions
In-Reply-To: <1547230644.92.0.865651994946.issue35719@roundup.psfhosted.org>
Message-ID: <1547231115.68.0.912229155758.issue35719@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +11113
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35719>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:25:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 18:25:24 +0000
Subject: [issue35719] Optimize multi-argument math functions
In-Reply-To: <1547230644.92.0.865651994946.issue35719@roundup.psfhosted.org>
Message-ID: <1547231124.53.0.664294792283.issue35719@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11113, 11114
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35719>
_______________________________________

From report at bugs.python.org  Fri Jan 11 13:25:32 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 11 Jan 2019 18:25:32 +0000
Subject: [issue35719] Optimize multi-argument math functions
In-Reply-To: <1547230644.92.0.865651994946.issue35719@roundup.psfhosted.org>
Message-ID: <1547231132.87.0.991726684631.issue35719@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11113, 11114, 11115
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35719>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:14:04 2019
From: report at bugs.python.org (Lucas Cimon)
Date: Fri, 11 Jan 2019 19:14:04 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
Message-ID: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>


New submission from Lucas Cimon <lucas.cimon at gmail.com>:

Hi.

I think I have found a minor memory leak in Modules/main.c:pymain_parse_cmdline_impl.

When the loop in the pymain_read_conf function in this same file
calls pymain_init_cmdline_argv a 2nd time, the pymain->command
buffer of wchar_t is overriden and the previously allocated memory
is never freed.

I haven't written any code test to reproduce this,
but it can be tested easily with gdb:
```
gdb -- bin/python3 -c pass
start
b Modules/main.c:587
b pymain_clear_pymain
c
c
```
You'll see that PyMem_RawMalloc is called twice without pymain->command ever being freed in pymain_clear_pymain.

I have a patch coming as PR on GitHub

I'd be glad to have your feedback on this issue and my proposal for a fix.

Regards.

----------
messages: 333499
nosy: Lucas Cimon
priority: normal
severity: normal
status: open
title: Memory leak in Modules/main.c:pymain_parse_cmdline_impl when using the CLI flag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:16:17 2019
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Jan 2019 19:16:17 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1547234177.73.0.12036027576.issue35720@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11116
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:16:20 2019
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Jan 2019 19:16:20 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1547234180.31.0.667563850934.issue35720@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11116, 11117
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:16:22 2019
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Jan 2019 19:16:22 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1547234182.37.0.633686945983.issue35720@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11116, 11117, 11118
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:19:13 2019
From: report at bugs.python.org (Opher Shachar)
Date: Fri, 11 Jan 2019 19:19:13 +0000
Subject: [issue35718] Cannot initialize the "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547234353.02.0.413056014326.issue35718@roundup.psfhosted.org>


Opher Shachar <ophers at gmail.com> added the comment:

(from the PR11526)
In this build_py subclass I initialize force to 1, but when reaching byte_compile() we find out it was reset to None.

from setuptools.command.build_py import build_py as _build_py

class build_py(_build_py):
    def initialize_options(self):
        _build_py.initialize_options(self)
        self.force = 1
        self.compile = 1

    def byte_compile(self, files):
        # self.compile == 1
        # self.force == None
        _build_py.byte_compile(self, files)
        # do stuff...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:24:53 2019
From: report at bugs.python.org (Niklas Fiekas)
Date: Fri, 11 Jan 2019 19:24:53 +0000
Subject: [issue35721] _UnixSubprocessTransport leaks socket pair if Popen fails
Message-ID: <1547234691.74.0.652164571217.issue35721@roundup.psfhosted.org>


New submission from Niklas Fiekas <niklas.fiekas at backscattering.de>:

Output of attached test case:

non-existing indeed
subprocess-exec-test.py:11: ResourceWarning: unclosed <socket.socket fd=6, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>
  print("non-existing indeed")
ResourceWarning: Enable tracemalloc to get the object allocation traceback
subprocess-exec-test.py:11: ResourceWarning: unclosed <socket.socket fd=7, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0>
  print("non-existing indeed")
ResourceWarning: Enable tracemalloc to get the object allocation traceback
.
----------------------------------------------------------------------
Ran 1 test in 0.007s

OK

----------
components: asyncio
files: subprocess-exec-test.py
messages: 333501
nosy: asvetlov, niklasf, yselivanov
priority: normal
severity: normal
status: open
title: _UnixSubprocessTransport leaks socket pair if Popen fails
type: resource usage
versions: Python 3.8
Added file: https://bugs.python.org/file48043/subprocess-exec-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35721>
_______________________________________

From report at bugs.python.org  Fri Jan 11 14:32:31 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 11 Jan 2019 19:32:31 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
Message-ID: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

In the logging package, the parameter disable_existing_loggers used in logging.config.dictConfig and logging.config.fileConfig does not apply to the root logger. More precisely, its disabled attribute remains unchanged (while it is set to True for non-root loggers). So it is either a bug or the documentation should be updated.

Illustration:

import logging.config

assert logging.getLogger().disabled is False
assert logging.getLogger("foo").disabled is False

logging.config.dictConfig({"version": 1})

assert logging.getLogger().disabled is False
assert logging.getLogger("foo").disabled is True

----------
components: Library (Lib)
messages: 333502
nosy: eric.araujo, ezio.melotti, maggyero, mdk, vinay.sajip, willingc
priority: normal
pull_requests: 11121
severity: normal
status: open
title: disable_existing_loggers does not apply to the root logger
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Fri Jan 11 15:34:18 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 11 Jan 2019 20:34:18 +0000
Subject: [issue35723] Add "time zone index" cache to datetime objects
Message-ID: <1547238857.17.0.663234077571.issue35723@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

When examining the performance characteristics of pytz, I realized that pytz's eager calculation of tzname, offset and DST gives it an implicit cache that makes it much faster for repeated queries to .utcoffset(), .dst() and/or .tzname()  though the eager calculation means that it's slower to create an aware datetime that never calculates those functions - see my blog post "pytz: The Fastest Footgun in the West" [1].

I do not think that datetime should move to eager calculations (for one thing it would be a pretty major change), but I did come up with a modest change that can make it possible to implement a pythonic time zone provider without taking the performance hit: introducing a small, optional, set-once cache for "time zone index" onto the datetime object. The idea takes advantage of the fact that essentially all time zones can be described by a very small number of (offset, tzname, dst) combinations plus a function to describe which one applies. Time zone implementations can store these offsets in one or more indexable containers and implement a `tzidx(self, dt)` method returning the relevant index as a function of the datetime. We would provide a per-datetime cache by implementing a datetime.tzidx(self) method, which would be a memoized call to `self.tzinfo.tzidx()`, like this (ignoring error handling - a more detailed implementation can be found in the PoC PR):

def tzidx(self):
    if self._tzidx != 0xff:
        return self._tzidx

    tzidx = self.tzinfo.tzidx(self)
    if isinstance(tzidx, int) and 0 <= tzidx < 255:
        self._tzidx = tzidx
    return tzidx

And then `utcoffset(self, dt)`, `dst(self, dt)` and `tzname(self, dt)` could be implemented in terms of `dt.tzidx()`! This interface would be completely opt-in, and `tzinfo.tzidx` would have no default implementation.

Note that I have used 0xff as the signal value here - this is because I propose that the `tzidx` cache be limited to *only* integers in the interval [0, 255), with 255 reserved as the "not set" value. It is exceedingly unlikely that a given time zone will have more than 255 distinct values in its index, and even if it does, this implementation gracefully falls back to "every call is a cache miss".

In my tests, using a single unsigned char for `tzidx` does not increase the size of the `PyDateTime` struct, because it's using a byte that is currently part of the alignment padding anyway. This same trick was used to minimize the impact of `fold`, and I figure it's better to be conservative and enforce 0 <= tzidx < 255, since we can only do it so many times.

The last thing I'd like to note is the problem of mutability - datetime objects are supposed to be immutable, and this cache value actually mutates the datetime struct! While it's true that the in-memory value of the datetime changes, the fundamental concept of immutability is retained, since this does not affect any of the qualities of the datetime observable via the public API.

In fact (and I hope this is not too much of a digression), it is already unfortunately true that datetimes are more mutable than they would seem, because nothing prevents `tzinfo` objects from returning different values on subsequent calls to the timezone-lookup functions. What's worse, datetime's hash implementation takes its UTC offset into account! In practice it's rare for a tzinfo to ever return a different value for utcoffset(dt), but one prominent example where this could be a problem is with something like `dateutil.tz.tzlocal`, which is a local timezone object written in terms of the `time` module's time zone information - which can change if the local timezone information changes over the course of a program's run.

This change does not necessarily fix that problem or start enforcing immutability of `utcoffset`, but it does encourage a design that is *less susceptible* to these problems, since even if the return value of `tzinfo.tzidx()` changes over time for some reason, that function would only be called once per datetime.

I have an initial PoC for this implemented, and I've tested it out with an accompanying implementation of `dateutil.tz` that makes use of it, it does indeed make things much faster. I look forward to your comments.

1. https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

----------
components: Library (Lib)
messages: 333503
nosy: p-ganssle
priority: normal
severity: normal
status: open
title: Add "time zone index" cache to datetime objects
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35723>
_______________________________________

From report at bugs.python.org  Fri Jan 11 15:37:38 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 11 Jan 2019 20:37:38 +0000
Subject: [issue35723] Add "time zone index" cache to datetime objects
In-Reply-To: <1547238857.17.0.663234077571.issue35723@roundup.psfhosted.org>
Message-ID: <1547239058.82.0.231947312818.issue35723@roundup.psfhosted.org>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
keywords: +patch
pull_requests: +11122
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35723>
_______________________________________

From report at bugs.python.org  Fri Jan 11 15:46:52 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 11 Jan 2019 20:46:52 +0000
Subject: [issue35723] Add "time zone index" cache to datetime objects
In-Reply-To: <1547238857.17.0.663234077571.issue35723@roundup.psfhosted.org>
Message-ID: <1547239612.91.0.545318322695.issue35723@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

One other thing I might mention here is that I did explore the idea of storing this cache on the tzinfo implementation itself, but it is problematic for a number of reasons:

1. It would either need to use some sort of expiring cache (lru, ttl) or require a great deal of memory, greatly reducing the utility - the proposed implementation requires no additional memory.
2. Because the implementation of datetime.__hash__ invokes utcoffset(), it is impossible to implement utcoffset in terms of a dictionary of tz-aware datetimes. This means that you need to construct a new, naive datetime, which is a fairly slow operation and really puts a damper in the utility of the cache.

If I were designing this from scratch, I would probably implement it differently, but I think this approach is pretty close to ideal given the constraints of backwards compatibility.

----------
nosy: +belopolsky, lemburg, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35723>
_______________________________________

From report at bugs.python.org  Fri Jan 11 15:58:18 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 11 Jan 2019 20:58:18 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547240298.35.0.666502502097.issue35582@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Are there any numbers on higher-level benchmarks?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:04:49 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 21:04:49 +0000
Subject: [issue35724] Check for main interpreter when checking for "main"
 thread (for signal handling)
Message-ID: <1547240687.08.0.242313450509.issue35724@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The code in Modules/signalsmodule.c (as well as a few other places in the code) has a concept of a "main" thread.  It's the OS thread where Py_Initialize() was called (and likely the process's original thread).  For various good reasons, we ensure that signal handling happens relative to that ("main") thread.

The problem is that we track the OS thread (by ID), which multiple interpreters can share.  What we really want is to track the original PyThreadState.  Otherwise signal-handling could happen (or handlers get added) in the wrong interpreter.

Options:
1. track the PyThreadState pointer instead of the OS thread ID
2. check that the current interpreter is the main one, in every place we check for the main thread

>From what I can tell, the simpler option is #2.

----------
components: Interpreter Core
messages: 333506
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Check for main interpreter when checking for "main" thread (for signal handling)
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35724>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:14:10 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 11 Jan 2019 21:14:10 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1547241250.52.0.0304163242321.issue35717@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:27:07 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 21:27:07 +0000
Subject: [issue35423] Signal handling machinery still relies on "pending
 calls".
In-Reply-To: <1544055159.6.0.788709270274.issue35423@psf.upfronthosting.co.za>
Message-ID: <1547242027.57.0.0554443360781.issue35423@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset fdf282d609fd172d52b59a6f1f062eb701494528 by Eric Snow in branch 'master':
bpo-35423: Stop using the "pending calls" machinery for signals. (gh-10972)
https://github.com/python/cpython/commit/fdf282d609fd172d52b59a6f1f062eb701494528


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35423>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:49:19 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 21:49:19 +0000
Subject: [issue35724] Check for main interpreter when checking for "main"
 thread (for signal handling)
In-Reply-To: <1547240687.08.0.242313450509.issue35724@roundup.psfhosted.org>
Message-ID: <1547243359.18.0.243702804733.issue35724@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +11123
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35724>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:49:21 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 21:49:21 +0000
Subject: [issue35724] Check for main interpreter when checking for "main"
 thread (for signal handling)
In-Reply-To: <1547240687.08.0.242313450509.issue35724@roundup.psfhosted.org>
Message-ID: <1547243361.72.0.551793892327.issue35724@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11123, 11124
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35724>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:49:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Jan 2019 21:49:59 +0000
Subject: [issue35712] Make NotImplemented unusable in boolean context
In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org>
Message-ID: <1547243399.0.0.0024617686523.issue35712@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I consider it a nice feature of Python that all builtin objects, and, AFAIK (and Josh, apparently), all stdlib class instances, have a boolean value.  (I am aware of numpy's element-wise behavior.)  I hate to give this up.  This is part of Python's general avoidance of singular exceptions and exceptions to exceptions.  This proposal would be the latter: "An object is truthy, unless its class makes it false, unless it is NotImplemented and a TypeError."

If this exception is made, I expect that there will be proposals to extend the exception to other objects, such as Ellipsis.

----------
nosy: +terry.reedy
stage:  -> test needed
type: behavior -> enhancement
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35712>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:50:36 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 11 Jan 2019 21:50:36 +0000
Subject: [issue35423] Signal handling machinery still relies on "pending
 calls".
In-Reply-To: <1544055159.6.0.788709270274.issue35423@psf.upfronthosting.co.za>
Message-ID: <1547243436.94.0.647478635881.issue35423@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35423>
_______________________________________

From report at bugs.python.org  Fri Jan 11 16:54:02 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Jan 2019 21:54:02 +0000
Subject: [issue35718] Cannot initialize the distutils  "force" command-option
In-Reply-To: <1547222486.48.0.811316963234.issue35718@roundup.psfhosted.org>
Message-ID: <1547243642.92.0.937844025367.issue35718@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Cannot initialize the "force" command-option -> Cannot initialize the distutils  "force" command-option

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35718>
_______________________________________

From report at bugs.python.org  Fri Jan 11 19:01:53 2019
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Sat, 12 Jan 2019 00:01:53 +0000
Subject: [issue35723] Add "time zone index" cache to datetime objects
In-Reply-To: <1547238857.17.0.663234077571.issue35723@roundup.psfhosted.org>
Message-ID: <1547251313.66.0.512547594527.issue35723@roundup.psfhosted.org>


Change by Eric N. Vander Weele <ericvw at gmail.com>:


----------
nosy: +ericvw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35723>
_______________________________________

From report at bugs.python.org  Fri Jan 11 21:52:38 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Jan 2019 02:52:38 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1547261558.2.0.717791600016.issue14802@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11125
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Fri Jan 11 21:52:50 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Jan 2019 02:52:50 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1547261570.82.0.682701946315.issue14802@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11125, 11126
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Fri Jan 11 21:53:01 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Jan 2019 02:53:01 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1547261581.13.0.977128553939.issue14802@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11125, 11126, 11128
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Fri Jan 11 21:53:10 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Jan 2019 02:53:10 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1547261590.15.0.405597291442.issue14802@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11125, 11126, 11127, 11128
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Fri Jan 11 22:18:04 2019
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 12 Jan 2019 03:18:04 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1547263084.53.0.242683881812.issue34838@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Great job Serhiy, your work on argument clinic has encompassed the previous PR very well. I've updated it for the changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Fri Jan 11 23:26:25 2019
From: report at bugs.python.org (Yoong Hor Meng)
Date: Sat, 12 Jan 2019 04:26:25 +0000
Subject: [issue35725] Using for...in.. generator-iterator
Message-ID: <1547267184.5.0.152784183529.issue35725@roundup.psfhosted.org>


New submission from Yoong Hor Meng <yoonghm at gmail.com>:

def f():
    print('-- Start --')
    yield 1
    print('-- Middle --')
    yield 2
    print('-- Finished --')
    yield 3

gen = f()
for x in gen:
    print('Another things ...')
    next(gen)


The output:

-- Start --
Another things ...
-- Middle --
-- Finished --
Another things ...

I noticed that the generator function will execute whenever it is in the for...in loop.  Is it expected? I do not see it documented anywhere. Thanks.

----------
components: Interpreter Core
messages: 333510
nosy: yoonghm
priority: normal
severity: normal
status: open
title: Using for...in.. generator-iterator
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35725>
_______________________________________

From report at bugs.python.org  Sat Jan 12 00:49:53 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 12 Jan 2019 05:49:53 +0000
Subject: [issue29734] os.stat handle leak
In-Reply-To: <1488799617.7.0.144245331277.issue29734@psf.upfronthosting.co.za>
Message-ID: <1547272193.28.0.144727168718.issue29734@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The os__getfinalpathname_impl handle leak and VOLUME_NAME_NT problems were fixed in another issue. However, PR 740 also includes fixes for handle leaks in os.stat, specifically in win32_xstat_impl and get_target_path.

----------
stage:  -> patch review
title: nt._getfinalpathname  handle leak -> os.stat handle leak
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29734>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:23:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 06:23:44 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1547274224.83.0.309335086935.issue34838@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cb08a71c5c534f33d9486677534dafb087c30e8c by Serhiy Storchaka (Ammar Askar) in branch 'master':
bpo-34838: Use subclass_of for math.dist. (GH-9659)
https://github.com/python/cpython/commit/cb08a71c5c534f33d9486677534dafb087c30e8c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:25:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 06:25:45 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547274345.14.0.693079249003.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 793426687509be24a42663a27e568cc92dcc07f6 by Serhiy Storchaka in branch 'master':
bpo-35582: Inline arguments tuple unpacking in handwritten code. (GH-11524)
https://github.com/python/cpython/commit/793426687509be24a42663a27e568cc92dcc07f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:26:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 06:26:37 +0000
Subject: [issue35719] Optimize multi-argument math functions
In-Reply-To: <1547230644.92.0.865651994946.issue35719@roundup.psfhosted.org>
Message-ID: <1547274397.16.0.0925534216869.issue35719@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d0d3e99120b19a4b800f0f381b2807c93aeecf0e by Serhiy Storchaka in branch 'master':
bpo-35719: Optimize multi-argument math functions. (GH-11527)
https://github.com/python/cpython/commit/d0d3e99120b19a4b800f0f381b2807c93aeecf0e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35719>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:27:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 06:27:16 +0000
Subject: [issue35719] Optimize multi-argument math functions
In-Reply-To: <1547230644.92.0.865651994946.issue35719@roundup.psfhosted.org>
Message-ID: <1547274436.34.0.166416332501.issue35719@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35719>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:28:27 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 12 Jan 2019 06:28:27 +0000
Subject: [issue35725] Using for...in.. generator-iterator
In-Reply-To: <1547267184.5.0.152784183529.issue35725@roundup.psfhosted.org>
Message-ID: <1547274507.23.0.744247659089.issue35725@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is not a bug, it is standard behaviour for all iterators, not just generators.

For loops work by calling next() on the iterator object, if you call next() on the same object inside the loop, that has the effect of advancing the for loop.

You say:

> I noticed that the generator function will execute whenever it is in the for...in loop.

but that's actually incorrect, as the generator FUNCTION f() is not inside the for loop. Each time you call the generator function f() you get a separate, independent generator object. In this case, you only call f() once, so you only have one generator object `gen`. Each time next(gen) is called, it advances to the next yield. It doesn't matter whether you call it manually, or the interpreter calls it for you using the for loop.

Try these two examples and compare their difference:

gen = f()
for x in gen:
    print(x, "outer loop")
    for y in gen:
        print(y, "inner loop")


versus:

for x in f():
    print(x, "outer loop")
    for y in f():
        print(y, "inner loop")

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35725>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:30:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 06:30:26 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547274626.51.0.297844290533.issue35582@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not expect significant changes in higher-level benchmarks. But if there are some, they can be shown on speed.python.org.

I this all work on this stage is finished.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:31:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 06:31:09 +0000
Subject: [issue34838] Improve arg clinic code generation for cases with type
 checking
In-Reply-To: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>
Message-ID: <1547274669.2.0.677260375291.issue34838@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34838>
_______________________________________

From report at bugs.python.org  Sat Jan 12 01:33:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 12 Jan 2019 06:33:22 +0000
Subject: [issue35725] Using for...in.. generator-iterator
In-Reply-To: <1547267184.5.0.152784183529.issue35725@roundup.psfhosted.org>
Message-ID: <1547274802.26.0.179324727562.issue35725@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I was also typing a similar reply and Steve explained it better :) Just to add there is a note on implicit next call on a for loop in the documentation.

https://docs.python.org/3/reference/expressions.html#generator.__next__

> Starts the execution of a generator function or resumes it at the last executed yield expression. When a generator function is resumed with a __next__() method, the current yield expression always evaluates to None. The execution then continues to the next yield expression, where the generator is suspended again, and the value of the expression_list is returned to __next__()?s caller. If the generator exits without yielding another value, a StopIteration exception is raised.

> This method is normally called implicitly, e.g. by a for loop, or by the built-in next() function.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35725>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:22:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 07:22:36 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547277756.33.0.719694459302.issue33817@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 44cc4822bb3799858201e61294c5863f93ec12e2 by Serhiy Storchaka in branch 'master':
bpo-33817: Fix _PyBytes_Resize() for empty bytes object. (GH-11516)
https://github.com/python/cpython/commit/44cc4822bb3799858201e61294c5863f93ec12e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:22:47 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 07:22:47 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547277767.16.0.260990096932.issue33817@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11129

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:22:51 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 07:22:51 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547277771.71.0.978698576811.issue33817@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11129, 11130

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:22:55 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 07:22:55 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547277775.94.0.0913749734498.issue33817@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 08a81df05004147ee174ece645679576ab867860 by Serhiy Storchaka in branch '2.7':
bpo-33817: Fix _PyString_Resize() and _PyUnicode_Resize() for empty strings. (GH-11515)
https://github.com/python/cpython/commit/08a81df05004147ee174ece645679576ab867860


----------
pull_requests: +11130

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:40:15 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 07:40:15 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547278815.34.0.0962781264019.issue33817@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d39c19255910b9dce08c595f511597e98b09e91f by Miss Islington (bot) in branch '3.7':
bpo-33817: Fix _PyBytes_Resize() for empty bytes object. (GH-11516)
https://github.com/python/cpython/commit/d39c19255910b9dce08c595f511597e98b09e91f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:46:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 07:46:52 +0000
Subject: [issue35494] Inaccurate error message for f-string
In-Reply-To: <1544794457.33.0.788709270274.issue35494@psf.upfronthosting.co.za>
Message-ID: <1547279212.63.0.936136938608.issue35494@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 58159ef856846d0235e0779aeb6013d70499570d by Serhiy Storchaka in branch 'master':
bpo-35494: Improve syntax error messages for unbalanced parentheses in f-string. (GH-11161)
https://github.com/python/cpython/commit/58159ef856846d0235e0779aeb6013d70499570d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35494>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:47:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 07:47:17 +0000
Subject: [issue35494] Inaccurate error message for f-string
In-Reply-To: <1544794457.33.0.788709270274.issue35494@psf.upfronthosting.co.za>
Message-ID: <1547279237.5.0.564559481909.issue35494@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35494>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:48:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 07:48:00 +0000
Subject: [issue33817] PyString_FromFormatV() fails to build empty strings
In-Reply-To: <1528576576.56.0.592728768989.issue33817@psf.upfronthosting.co.za>
Message-ID: <1547279280.22.0.720755137763.issue33817@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33817>
_______________________________________

From report at bugs.python.org  Sat Jan 12 02:59:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 07:59:51 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1547279991.93.0.637738094511.issue8765@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:12:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 08:12:26 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1547280746.17.0.236925503338.issue35634@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f1ec3cefad4639797c37eaa8c074830188fa0a44 by Serhiy Storchaka in branch 'master':
bpo-35634: Raise an error when first passed kwargs contains duplicated keys. (GH-11438)
https://github.com/python/cpython/commit/f1ec3cefad4639797c37eaa8c074830188fa0a44


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35634>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:13:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 08:13:21 +0000
Subject: [issue35634] kwargs regression when there are multiple entries with
 the same key
In-Reply-To: <1546391073.15.0.462051858565.issue35634@roundup.psfhosted.org>
Message-ID: <1547280801.2.0.73255439599.issue35634@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35634>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:30:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 08:30:37 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547281837.72.0.567209371271.issue35552@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d586ccb04f79863c819b212ec5b9d873964078e4 by Serhiy Storchaka in branch 'master':
bpo-35552: Fix reading past the end in PyUnicode_FromFormat() and PyBytes_FromFormat(). (GH-11276)
https://github.com/python/cpython/commit/d586ccb04f79863c819b212ec5b9d873964078e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:30:53 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 08:30:53 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547281853.25.0.613282871719.issue35552@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:30:56 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 08:30:56 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547281856.32.0.0574091649695.issue35552@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11131, 11132

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:49:14 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 08:49:14 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547282954.84.0.595737258967.issue35552@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11133

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 03:52:58 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 08:52:58 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547283178.3.0.80378766321.issue35552@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cbc7c2c791185ad44b4b3ede72309df5f252f4cb by Miss Islington (bot) in branch '3.7':
bpo-35552: Fix reading past the end in PyUnicode_FromFormat() and PyBytes_FromFormat(). (GH-11276)
https://github.com/python/cpython/commit/cbc7c2c791185ad44b4b3ede72309df5f252f4cb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 04:19:41 2019
From: report at bugs.python.org (kernc)
Date: Sat, 12 Jan 2019 09:19:41 +0000
Subject: [issue24119] Carry comments with the AST
In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za>
Message-ID: <1547284781.54.0.128513331171.issue24119@roundup.psfhosted.org>


Change by kernc <kerncece at gmail.com>:


----------
nosy: +kernc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24119>
_______________________________________

From report at bugs.python.org  Sat Jan 12 04:21:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 09:21:00 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547284860.09.0.68479786358.issue35552@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 555755ecff2669f4e020147d7d3a0aec71abb679 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-35552: Fix reading past the end in PyString_FromFormat(). (GH-11276) (GH-11534)
https://github.com/python/cpython/commit/555755ecff2669f4e020147d7d3a0aec71abb679


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 04:21:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Jan 2019 09:21:30 +0000
Subject: [issue35552] Do not read memory past the specified limit in
 PyUnicode_FromFormat() and PyBytes_FromFormat()
In-Reply-To: <1545390959.35.0.788709270274.issue35552@psf.upfronthosting.co.za>
Message-ID: <1547284890.98.0.0237840212349.issue35552@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35552>
_______________________________________

From report at bugs.python.org  Sat Jan 12 08:55:15 2019
From: report at bugs.python.org (David Ruggles)
Date: Sat, 12 Jan 2019 13:55:15 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
Message-ID: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>


New submission from David Ruggles <thedavidfactor at gmail.com>:

ISSUE: if you add a formatter to QueueHandler any subsequently added handlers will get the formatting added to QueueHandler

CAUSE: as best as I can tell, the code here:
https://github.com/python/cpython/blob/d586ccb04f79863c819b212ec5b9d873964078e4/Lib/logging/handlers.py#L1380
is modifying the record object so when it get passed to the next handler here:
https://github.com/python/cpython/blob/d586ccb04f79863c819b212ec5b9d873964078e4/Lib/logging/__init__.py#L1656
it includes the formatting applied by the QueueHandler's formatter.

I worked around this issue by moving my formatter from the QueueHandler to the QueueListener

I've attached a simple example of the issue

NOTE: I marked this as Python 3.7 because that's what I'm using, but I looked at github and the code is in master so I assume this affects 3.8 too.

----------
components: Library (Lib)
files: queuehandler_bug.py
messages: 333526
nosy: David Ruggles
priority: normal
severity: normal
status: open
title: QueueHandler formating affects other handlers
versions: Python 3.7
Added file: https://bugs.python.org/file48044/queuehandler_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 10:09:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 12 Jan 2019 15:09:12 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547305752.61.0.0319836992939.issue35726@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:21:57 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jan 2019 17:21:57 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313717.1.0.0619800896693.issue34512@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 1cffd0eed313011c0c2bb071c8affeb4a7ed05c7 by Tal Einat (Alexey Izbyshev) in branch 'master':
bpo-34512: Document platform-specific strftime() behavior for non-ASCII format strings (GH-8948)
https://github.com/python/cpython/commit/1cffd0eed313011c0c2bb071c8affeb4a7ed05c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:22:25 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:22:25 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313745.6.0.10598313464.issue34512@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11134

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:22:39 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:22:39 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313759.13.0.829261938536.issue34512@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11134, 11135

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:22:52 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:22:52 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313772.48.0.727597846028.issue34512@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11134, 11135, 11136

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:23:05 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:23:05 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313785.86.0.759336472256.issue34512@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11134, 11135, 11136, 11137

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:23:19 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:23:19 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313799.26.0.495075964902.issue34512@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11135, 11136, 11137, 11139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:23:30 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:23:30 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547313810.71.0.0298125474102.issue34512@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11135, 11136, 11137, 11138, 11139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:27:32 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:27:32 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547314052.6.0.508680920545.issue34512@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 678c5c07521caca809b1356d954975e6234c49ae by Miss Islington (bot) in branch '3.7':
bpo-34512: Document platform-specific strftime() behavior for non-ASCII format strings (GH-8948)
https://github.com/python/cpython/commit/678c5c07521caca809b1356d954975e6234c49ae


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:28:08 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 12 Jan 2019 17:28:08 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547314088.87.0.0180252490557.issue34512@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 77b80c956f39df34722bd8646cf5b83d149832c4 by Miss Islington (bot) in branch '2.7':
bpo-34512: Document platform-specific strftime() behavior for non-ASCII format strings (GH-8948)
https://github.com/python/cpython/commit/77b80c956f39df34722bd8646cf5b83d149832c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:37:12 2019
From: report at bugs.python.org (Manjusaka)
Date: Sat, 12 Jan 2019 17:37:12 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547314632.87.0.64760096836.issue35726@roundup.psfhosted.org>


Change by Manjusaka <lizheao940510 at gmail.com>:


----------
keywords: +patch
pull_requests: +11140
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:37:18 2019
From: report at bugs.python.org (Manjusaka)
Date: Sat, 12 Jan 2019 17:37:18 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547314638.5.0.836693989205.issue35726@roundup.psfhosted.org>


Change by Manjusaka <lizheao940510 at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11140, 11141
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:37:23 2019
From: report at bugs.python.org (Manjusaka)
Date: Sat, 12 Jan 2019 17:37:23 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547314643.42.0.348527874134.issue35726@roundup.psfhosted.org>


Change by Manjusaka <lizheao940510 at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11140, 11141, 11142
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:39:54 2019
From: report at bugs.python.org (Manjusaka)
Date: Sat, 12 Jan 2019 17:39:54 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547314794.33.0.343302900964.issue35726@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

I have already work on a PR for it

----------
nosy: +Manjusaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:46:50 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jan 2019 17:46:50 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547315210.34.0.468158852369.issue34512@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -11135

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:47:05 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jan 2019 17:47:05 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547315225.96.0.730928773599.issue34512@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -11135, 11137

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:47:19 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jan 2019 17:47:19 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547315239.8.0.818740550986.issue34512@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests:  -11135, 11137, 11139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 12:48:25 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 12 Jan 2019 17:48:25 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547315305.36.0.464439504825.issue34512@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Sat Jan 12 14:33:38 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Sat, 12 Jan 2019 19:33:38 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
Message-ID: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>


New submission from Christopher Hunt <chrahunt at gmail.com>:

When a function is executed by a multiprocessing.Process and uses sys.exit,
the actual exit code reported by multiprocessing is different than would be
expected given the Python interpreter behavior and documentation. For example,
given:

    from functools import partial
    from multiprocessing import get_context
    import sys
    
    
    def run(ctx, fn):
        p = ctx.Process(target=fn)
        p.start()
        p.join()
        return p.exitcode
    
    
    if __name__ == '__main__':
        ctx = get_context('fork')
        print(run(ctx, partial(sys.exit, 2)))
        print(run(ctx, partial(sys.exit, None)))
        print(run(ctx, sys.exit))
    
        ctx = get_context('spawn')
        print(run(ctx, partial(sys.exit, 2)))
        print(run(ctx, partial(sys.exit, None)))
        print(run(ctx, sys.exit))
    
        ctx = get_context('forkserver')
        print(run(ctx, partial(sys.exit, 2)))
        print(run(ctx, partial(sys.exit, None)))
        print(run(ctx, sys.exit))

when executed results in

    $ python exit.py
    2
    1
    1
    2
    1
    1
    2
    1
    1


but when Python itself is executed we see different behavior

    $ for arg in 2 None ''; do python -c "import sys; sys.exit($arg)"; echo $?; done
    2
    0
    0

The documentation states

> sys.exit([arg])
> ...
> The optional argument arg can be an integer giving the exit status
> (defaulting to zero), or another type of object.

The relevant line in multiprocessing (https://github.com/python/cpython/blame/1cffd0eed313011c0c2bb071c8affeb4a7ed05c7/Lib/multiprocessing/process.py#L307)
seems to be from the original pyprocessing module itself, and I could
not locate an active site that maintains the repository to see if there
was any justification for the behavior.

----------
components: Library (Lib)
files: multiprocessing-exitcode-3.7.1.patch
keywords: patch
messages: 333531
nosy: chrahunt
priority: normal
severity: normal
status: open
title: sys.exit() in a multiprocessing.Process does not align with Python behavior
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48045/multiprocessing-exitcode-3.7.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Sat Jan 12 15:08:41 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Sat, 12 Jan 2019 20:08:41 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1547323721.8.0.47292473291.issue35727@roundup.psfhosted.org>


Change by Christopher Hunt <chrahunt at gmail.com>:


----------
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Sat Jan 12 15:23:36 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Sat, 12 Jan 2019 20:23:36 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1547324616.87.0.161154343854.issue35727@roundup.psfhosted.org>


Change by Christopher Hunt <chrahunt at gmail.com>:


----------
pull_requests: +11143
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Sat Jan 12 15:23:40 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Sat, 12 Jan 2019 20:23:40 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1547324620.72.0.0211301577796.issue35727@roundup.psfhosted.org>


Change by Christopher Hunt <chrahunt at gmail.com>:


----------
pull_requests: +11143, 11144
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Sat Jan 12 15:23:43 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Sat, 12 Jan 2019 20:23:43 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1547324623.0.0.345558450935.issue35727@roundup.psfhosted.org>


Change by Christopher Hunt <chrahunt at gmail.com>:


----------
pull_requests: +11143, 11144, 11145
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Sat Jan 12 16:31:15 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 12 Jan 2019 21:31:15 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1547328675.6.0.764529752958.issue14802@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Sat Jan 12 16:33:33 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Jan 2019 21:33:33 +0000
Subject: [issue35728] Tkinter font nametofont requires default root
Message-ID: <1547328812.09.0.281453810047.issue35728@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

font.Font.__init__, font.families, and font.names have a 'root=None' argument and start with 
    if not root:
        root = tkinter._default_root
But font.nametofont does not, and so it calls Font without passing a root argument:
     return Font(name=name, exists=True)

Font fails if there is no default root.  There cannot be one if, as recommended, one disables it.

import tkinter as tk
from tkinter import font
tk.NoDefaultRoot()
root = tk.Tk()
font.nametofont('TkFixedFont')
# AttributeError: module 'tkinter' has no attribute '_default_root'

Proposed fix: add 'root=None' parameter to nametofont (at end, to not break code) and 'root=root' to Font call.

----------
components: Tkinter
messages: 333532
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Tkinter font nametofont requires default root
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35728>
_______________________________________

From report at bugs.python.org  Sat Jan 12 17:41:21 2019
From: report at bugs.python.org (bbayles)
Date: Sat, 12 Jan 2019 22:41:21 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547332881.67.0.427862151245.issue32146@roundup.psfhosted.org>


bbayles <bbayles at gmail.com> added the comment:

I'm currently having difficulty getting either cx_Freeze or PyInstaller to work with Python 3.8, which is hindering testing. I also no longer have easy access to a Windows environment.

If I change the implementation to use -m instead of -c would you be able to test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Sat Jan 12 18:32:40 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 12 Jan 2019 23:32:40 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547335960.32.0.607535552832.issue35726@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Any idea why the same PR appears three times in the PR list? Is it because for some reason you've added the issue link multiple times in the PR, when it's not needed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 18:39:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 12 Jan 2019 23:39:41 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547336381.82.0.793513532962.issue35726@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@vinay.sajip It's known issue discussed here https://github.com/python/bugs.python.org/issues/12

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 20:00:59 2019
From: report at bugs.python.org (Manjusaka)
Date: Sun, 13 Jan 2019 01:00:59 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547341259.24.0.394083788773.issue35726@roundup.psfhosted.org>


Change by Manjusaka <lizheao940510 at gmail.com>:


----------
pull_requests:  -11140

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 20:01:15 2019
From: report at bugs.python.org (Manjusaka)
Date: Sun, 13 Jan 2019 01:01:15 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1547341275.17.0.0967794425823.issue35726@roundup.psfhosted.org>


Change by Manjusaka <lizheao940510 at gmail.com>:


----------
pull_requests:  -11141

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Sat Jan 12 21:40:21 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 02:40:21 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547347221.55.0.330497036127.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To make a potentially viable concrete proposal here, I think a reasonable first step would be to change the ".pth" file processing code in site.py to emit PendingDeprecationWarning for the 'if line.startswith(("import ", "import\t")):' branch.

In addition to helping to determine the scope of the compatibility break being discussed here, such a warning would also be usable as a debugging tool.

I'd also suggest updating "python -m site" to list any pth files that it finds, and categorise them as simple sys.path additions (which are generally fine), and arbitrary code (which can be problematic).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:01:33 2019
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 13 Jan 2019 04:01:33 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1547352093.34.0.514366164633.issue16806@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16806>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:04:52 2019
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 13 Jan 2019 04:04:52 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1547352292.22.0.855507750126.issue16806@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

Should we backport this to 3.7?
AST changes including bugfix affects existing software unexpectedly.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16806>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:05:22 2019
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 13 Jan 2019 04:05:22 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1547352322.33.0.493253732356.issue16806@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 995d9b92979768125ced4da3a56f755bcdf80f6e by INADA Naoki (Anthony Sottile) in branch 'master':
bpo-16806: Fix `lineno` and `col_offset` for multi-line string tokens (GH-10021)
https://github.com/python/cpython/commit/995d9b92979768125ced4da3a56f755bcdf80f6e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16806>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:12:59 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Jan 2019 04:12:59 +0000
Subject: [issue35698] [statistics] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547352779.44.0.534160794141.issue35698@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> As a pure mathematician, to me 1.0 means a number that is 
> close to 1. Whereas 1 means a number that is exactly 1.

Descriptive statistics performed on a computer using actual measurements is pretty far from "pure mathematics" ;-)

Making this change is likely pointless for most users and likely confusing for others (i.e. why the type switch between median([1, 1]) and median([1, 3]).

I concur with Victor and recommend closing.

----------
assignee:  -> steven.daprano
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:18:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Jan 2019 04:18:40 +0000
Subject: [issue24119] Carry comments with the AST
In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za>
Message-ID: <1547353120.58.0.933576868405.issue24119@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Since the AST carries the module/lineno attributes isn't there already a way trace back into the token stream to recover comments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24119>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:19:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Jan 2019 04:19:17 +0000
Subject: [issue24119] Carry comments with the AST
In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za>
Message-ID: <1547353157.19.0.895545497112.issue24119@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Possible superceder:  https://bugs.python.org/issue33337

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24119>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:21:04 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Jan 2019 04:21:04 +0000
Subject: [issue35697] _decimal: Implement the previously rejected changes from
 #7442.
In-Reply-To: <1547033508.44.0.197270282125.issue35697@roundup.psfhosted.org>
Message-ID: <1547353264.97.0.45694537846.issue35697@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Sometimes not being dependent on API functions is a virtue if the code does not change very often.

That is a reasonable position to take.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35697>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:42:08 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Sun, 13 Jan 2019 04:42:08 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547354528.32.0.359511600519.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

the output is stored on the file run.txt above

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Sat Jan 12 23:50:03 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 13 Jan 2019 04:50:03 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1547355003.62.0.699915629698.issue16806@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I agree -- probably safer to not backport to 3.7 in case someone is relying on this behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16806>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:23:55 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 07:23:55 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547364235.05.0.0369551777588.issue35486@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch
pull_requests: +11147
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:24:05 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 07:24:05 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547364245.15.0.778103167798.issue35486@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11147, 11148
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:24:14 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 07:24:14 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547364254.66.0.178945244529.issue35486@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11147, 11148, 11149
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:30:47 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 07:30:47 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547364647.14.0.0460478900795.issue35486@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

dw: we routinely impose new requirements on folks modifying runtime internals in new feature releases, so the only aspect we missed for this changing is to explicitly call it out in the Porting section of the Python 3.6 What's New document as a potential forward compatibility risk for import system replacement authors that don't update their plugins accordingly.

For folks implementing PEP 302 finders and loaders, no change is required, as they indicate failure to find a module by returning None, not by raising ImportError.

It's only folks emulating the full import system by replacing `__import__` that should need to worry about this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:47:32 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 07:47:32 +0000
Subject: [issue33039] int() and math.trunc don't accept objects that only
 define __index__
In-Reply-To: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za>
Message-ID: <1547365652.5.0.498996648744.issue33039@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

@R?mi Aye, filling out derived slots is one of the things PyType_Ready does.

This would need a discussion on python-dev before going ahead and doing it though, as the closest equivalent we have to this right now is the "negative" derivation, where overriding __eq__ without overriding __hash__ implicitly marks the derived class as unhashable (look for "type->tp_hash = PyObject_HashNotImplemented;").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33039>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:50:30 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 07:50:30 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547365830.29.0.246668563549.issue35707@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Deriving __int__ from __float__ wouldn't be the right answer, as that can easily lead to unwanted OverflowError exceptions and other issues.

However, Jeroen's suggested order of checking __index__ then __float__ then __int__ in _PyTime_FromObject makes sense to me, as that addresses Victor's desire to use the most precise conversion available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Sun Jan 13 02:59:02 2019
From: report at bugs.python.org (kernc)
Date: Sun, 13 Jan 2019 07:59:02 +0000
Subject: [issue33337] Provide a supported Concrete Syntax Tree implementation
 in the standard library
In-Reply-To: <1524445447.99.0.682650639539.issue33337@psf.upfronthosting.co.za>
Message-ID: <1547366342.08.0.972062735133.issue33337@roundup.psfhosted.org>


Change by kernc <kerncece at gmail.com>:


----------
nosy: +kernc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33337>
_______________________________________

From report at bugs.python.org  Sun Jan 13 03:10:14 2019
From: report at bugs.python.org (Ma Lin)
Date: Sun, 13 Jan 2019 08:10:14 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1547367014.46.0.256239571684.issue34294@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Simplify the test-case, it seem the `state` is not reset properly.

Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47)
>>> import re
>>> re.findall(r"(?=(<\w+>)(<\w+>)?)", "<aaa><bbb>")
[('<aaa>', '<bbb>'), ('<bbb>', '')]

Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28)
>>> import re
>>> re.findall(r"(?=(<\w+>)(<\w+>)?)", "<aaa><bbb>")
[('<aaa>', '<bbb>'), ('<bbb>', '<bbb>')]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Sun Jan 13 03:17:57 2019
From: report at bugs.python.org (Igor Nowicki)
Date: Sun, 13 Jan 2019 08:17:57 +0000
Subject: [issue35729] XML.etree bug
Message-ID: <1547367475.69.0.228799716496.issue35729@roundup.psfhosted.org>


New submission from Igor Nowicki <thesmilingcatofcheshire at gmail.com>:

Consider we have big XML file and we can't load it all into memory. We use then `iterparse` function from XML.etree.ElementTree module to parse it element by element.

Problem is, XML doesn't allow to run this smoothly and starts outputing wrong data after loading 16 kb (16*1024, found it after looking into source code). Having large number of children, we get the information that we have just a few.

To reproduce the problem, I created this example program. It makes simple xml file with progressively bigger files and tracks how many children of main objects there are counted. For small objects we have actual number, 100 children. For bigger and bigger sizes we have smaller numbers, going down to just few.

----------
components: Library (Lib)
files: find_records.py
messages: 333549
nosy: Igor Nowicki
priority: normal
severity: normal
status: open
title: XML.etree bug
type: performance
versions: Python 3.6
Added file: https://bugs.python.org/file48046/find_records.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35729>
_______________________________________

From report at bugs.python.org  Sun Jan 13 03:43:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Jan 2019 08:43:39 +0000
Subject: [issue35729] XML.etree bug
In-Reply-To: <1547367475.69.0.228799716496.issue35729@roundup.psfhosted.org>
Message-ID: <1547369019.49.0.746100751174.issue35729@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +XML
nosy: +eli.bendersky, scoder, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35729>
_______________________________________

From report at bugs.python.org  Sun Jan 13 03:52:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Jan 2019 08:52:30 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547369550.82.0.297480466852.issue35707@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This can cause a loss of precision for Decimal.

If we want to support other numerical types with loss in double rounding, the most reliable way is to represent them as fractions (x.as_integer_ratio() or (x.numerator, x.denominator)) and use precise integer arithmetic.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Sun Jan 13 04:12:39 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 13 Jan 2019 09:12:39 +0000
Subject: [issue35729] XML.etree bug
In-Reply-To: <1547367475.69.0.228799716496.issue35729@roundup.psfhosted.org>
Message-ID: <1547370759.29.0.359671165844.issue35729@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

This is not a bug, it's normal, documented behaviour. The children are not guaranteed to be available during the "start" event. Only the tag itself is guaranteed to be there. The guarantee that the subtree is complete is only given for the "end" event.

See the big note in the documentation:
https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.iterparse

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35729>
_______________________________________

From report at bugs.python.org  Sun Jan 13 04:13:48 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 13 Jan 2019 09:13:48 +0000
Subject: [issue35729] iterparse does not return the full subtree on "start"
 events
In-Reply-To: <1547367475.69.0.228799716496.issue35729@roundup.psfhosted.org>
Message-ID: <1547370828.01.0.885107851624.issue35729@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
title: XML.etree bug -> iterparse does not return the full subtree on "start" events
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35729>
_______________________________________

From report at bugs.python.org  Sun Jan 13 05:50:06 2019
From: report at bugs.python.org (mattip)
Date: Sun, 13 Jan 2019 10:50:06 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windows Store
In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>
Message-ID: <1547376606.27.0.0345683894291.issue35688@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

The difference in search order between apps from the app store and desktop applications may be relevant

https://docs.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order#alternate-search-order-for-windows-store-apps

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Sun Jan 13 06:49:14 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 13 Jan 2019 11:49:14 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1547380154.82.0.0657558940302.issue35727@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

The same behavior on 3.8 and 3.5

----------
nosy: +eamanu
versions: +Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Sun Jan 13 07:39:24 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 13 Jan 2019 12:39:24 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547383164.75.0.931794701207.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> the most reliable way is to represent them as fractions (x.as_integer_ratio() or (x.numerator, x.denominator))

I don't think that we can rely on non-dunder names like that. They are not reserved names, so classes can give them any semantics that they like. This is not just hypothetical: SageMath for example uses numerator() and denominator() methods, not properties.

If you really want to go through with this, probably a special method like __as_integer_ratio__ should be defined.

Anyway, I personally consider the double rounding for time.sleep() a non-issue. We are not trying to write a precise math library here, nobody will complain about sleeping a femtosecond too long.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Sun Jan 13 07:53:44 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 13 Jan 2019 12:53:44 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547384024.3.0.0843122369438.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> The correct code works for float and int (and maybe decimal.Decimal, I don't recall!)

Not for Decimal! In fact sleep(Decimal("0.99")) is interpreted as sleep(0) because __int__ is used to convert.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Sun Jan 13 10:02:03 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 13 Jan 2019 15:02:03 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547391723.26.0.351565711061.issue35196@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 39a33e99270848d34628cdbb1fdb727f9ede502a by Tal Einat in branch 'master':
bpo-35196: Optimize Squeezer's write() interception (GH-10454)
https://github.com/python/cpython/commit/39a33e99270848d34628cdbb1fdb727f9ede502a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 10:02:26 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 15:02:26 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547391746.49.0.00942808643529.issue35196@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11150

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 10:02:34 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 15:02:34 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547391754.68.0.709541685451.issue35196@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11150, 11151

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 10:02:43 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 15:02:43 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547391763.27.0.751479078546.issue35196@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11150, 11151, 11152

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 11:43:10 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 16:43:10 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547397790.41.0.78546902313.issue35196@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 47bd7770229b5238a438703ee1d52da2e983ec9e by Miss Islington (bot) in branch '3.7':
bpo-35196: Optimize Squeezer's write() interception (GH-10454)
https://github.com/python/cpython/commit/47bd7770229b5238a438703ee1d52da2e983ec9e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 11:47:15 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 13 Jan 2019 16:47:15 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547398035.11.0.638539893427.issue35674@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
nosy: +izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Sun Jan 13 11:47:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 16:47:58 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547398078.89.0.649870645028.issue35196@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11152

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 11:48:16 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 16:48:16 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547398096.46.0.306748776965.issue35196@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11151

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Sun Jan 13 11:59:18 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Jan 2019 16:59:18 +0000
Subject: [issue35729] iterparse does not return the full subtree on "start"
 events
In-Reply-To: <1547367475.69.0.228799716496.issue35729@roundup.psfhosted.org>
Message-ID: <1547398758.15.0.00729958049235.issue35729@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35729>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:22:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:22:42 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
Message-ID: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

PR 10454 for #35196 added, among other things, more tests to test_squeezer.py.  SqueezerTest.test_reload initially worked on Mac and personal Windows machines. It failed on Cheryl Sabella's personal Ubuntu machine because doubling the nominal font size did not necessarily exactly double the reported pixel size of '0'.  This was easily fixed by testing only that the size increased.

self.assertGreater(squeezer.zero_char_width, orig_zero_char_width)

It failed on CI Linux and Windows machines because the pixel size did not increase at all. This was fixed for the CI machines by directly assigning a new font tuple to text['font'] instead of involving the idleConf machinery.  However, after merging, it failed with the same error that previously occurred on the CI machines.

AssertionError: 6 not greater than 6.

The initial fix will be to disable the assertion.

----------
assignee: terry.reedy
components: IDLE
messages: 333558
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Fix squeezer test_reload.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:25:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Jan 2019 17:25:19 +0000
Subject: [issue35428] xml.etree.ElementTree.tostring violates W3 standards
 allowing encoding='unicode' without error
In-Reply-To: <1544119722.12.0.788709270274.issue35428@psf.upfronthosting.co.za>
Message-ID: <1547400319.64.0.00546260385619.issue35428@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35428>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:30:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:30:23 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547400623.14.0.38240889832.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +11153
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:30:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:30:27 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547400627.62.0.712310516233.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch
pull_requests: +11153, 11154
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:30:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:30:32 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547400632.71.0.830343497084.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch, patch
pull_requests: +11153, 11154, 11155
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:31:16 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:31:16 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547400676.29.0.187834513165.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11154

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:31:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:31:30 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547400690.51.0.0476952373309.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11155

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:39:13 2019
From: report at bugs.python.org (timokau)
Date: Sun, 13 Jan 2019 17:39:13 +0000
Subject: [issue35383] lib2to3 raises ParseError on argument called "print"
In-Reply-To: <1543832407.47.0.788709270274.issue35383@psf.upfronthosting.co.za>
Message-ID: <1547401153.52.0.0234556794603.issue35383@roundup.psfhosted.org>


timokau <timokau at zoho.com> added the comment:

I disagree that this is "not a bug". While conversion from 2 to 3 is 2to3's main intention, the documentation advertises:

2to3 supporting library lib2to3 is, however, a flexible and generic library, so it is possible to write your own fixers for 2to3. lib2to3 could also be adapted to custom applications in which Python code needs to be edited automatically.
(https://docs.python.org/3.5/library/2to3.html#module-lib2to3)

And it is used for other purposes. See
- this sphinx bug: https://github.com/sphinx-doc/sphinx/issues/1641
- bower: https://pybowler.io/docs/basics-refactoring

----------
nosy: +timokau

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35383>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:40:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:40:49 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547401249.15.0.430971351909.issue35730@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Victor, a particular test assert fails only on Gentoo bots (see above).  Questions:

1. Can we disable the assert only on those machines?

2. I sometimes see what look like debug prints in buildbot test logs.  Correct?  If so, stdout or stderr?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:50:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 17:50:31 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547401831.36.0.855693572941.issue35730@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 5bb146aaea1484bcc117ab6cb38dda39ceb5df0f by Terry Jan Reedy in branch 'master':
bpo-35730: Disable IDLE test_reload assertion. (GH-11543)
https://github.com/python/cpython/commit/5bb146aaea1484bcc117ab6cb38dda39ceb5df0f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:50:42 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 17:50:42 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547401842.51.0.28478194617.issue35730@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11156

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 12:50:46 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 17:50:46 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547401846.86.0.109115162703.issue35730@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11156, 11157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 13:05:52 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Jan 2019 18:05:52 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547402752.41.0.0247270699413.issue35730@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 890d3fa10c68af6306cf6b989b2133978e6e7a12 by Miss Islington (bot) in branch '3.7':
bpo-35730: Disable IDLE test_reload assertion. (GH-11543)
https://github.com/python/cpython/commit/890d3fa10c68af6306cf6b989b2133978e6e7a12


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 13:14:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 18:14:27 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547403267.42.0.252051480404.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 13:25:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 13 Jan 2019 18:25:56 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1547403956.99.0.999296420677.issue35715@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Sun Jan 13 14:21:03 2019
From: report at bugs.python.org (Arlen)
Date: Sun, 13 Jan 2019 19:21:03 +0000
Subject: [issue35731] Modify to support multiple urls in webbrowser.open
Message-ID: <1547407261.77.0.914864319887.issue35731@roundup.psfhosted.org>


New submission from Arlen <arlen.yu6 at gmail.com>:

Note: new to python, please provide any feedback

Currently webbrowser.open supports one url, and there is no fn for url batching. I am proposing modifying webbrowser.open to support something along these lines:

```
def open(*urls, new=0, autoraise=True):
        ...
        browser = get(name)
        actions = [browser.open(url, new, autoraise) for url in urls]
        ...

# usage
open('http://example.com', 'http://example2.com')
```

----------
components: Library (Lib)
messages: 333563
nosy: arlenyu
priority: normal
severity: normal
status: open
title: Modify to support multiple urls in webbrowser.open
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35731>
_______________________________________

From report at bugs.python.org  Sun Jan 13 14:24:12 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jan 2019 19:24:12 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547407452.91.0.929927274032.issue35730@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I just realized that the Gentoo bots where this failed are, last I knew, the only *nix bots with X installed.  The non-Windows CI bots run the gui tests with an X simulator.  So Gentoo might not be the only distribution where this would fail.


Two debug prints that might help: the tk patch level (does Gentoo have something ancient?); the actual font and in particular the actual size resulting from ('Courier', 10/20).

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 14:38:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 13 Jan 2019 19:38:32 +0000
Subject: [issue35731] Modify to support multiple urls in webbrowser.open
In-Reply-To: <1547407261.77.0.914864319887.issue35731@roundup.psfhosted.org>
Message-ID: <1547408312.83.0.057596676679.issue35731@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Since you can do list comprehension over the URLs as in your example I don't see a good reason to change the current API to take multiple URLs.

[browser.open(url, new, autoraise) for url in urls]

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35731>
_______________________________________

From report at bugs.python.org  Sun Jan 13 14:49:02 2019
From: report at bugs.python.org (timokau)
Date: Sun, 13 Jan 2019 19:49:02 +0000
Subject: [issue35383] lib2to3 raises ParseError on argument called "print"
In-Reply-To: <1543832407.47.0.788709270274.issue35383@psf.upfronthosting.co.za>
Message-ID: <1547408942.11.0.522922851067.issue35383@roundup.psfhosted.org>


timokau <timokau at zoho.com> added the comment:

Also `print("a", file=sys.stderr)` *is* valid python2 provided that `print_function` is imported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35383>
_______________________________________

From report at bugs.python.org  Sun Jan 13 15:02:26 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 13 Jan 2019 20:02:26 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1547347221.55.0.330497036127.issue33944@roundup.psfhosted.org>
Message-ID: <7A324335-B8A5-446C-B5AB-4E9336069EC9@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

> To make a potentially viable concrete proposal here, I think a reasonable first step would be to change the ".pth" file processing code in site.py to emit PendingDeprecationWarning for the 'if line.startswith(("import ", "import\t")):' branch.

PendingDeprecationWarning because you don?t think we can remove this functionality in 3.9?

> In addition to helping to determine the scope of the compatibility break being discussed here, such a warning would also be usable as a debugging tool.
> 
> I'd also suggest updating "python -m site" to list any pth files that it finds, and categorise them as simple sys.path additions (which are generally fine), and arbitrary code (which can be problematic).

Great idea, +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sun Jan 13 15:42:16 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Jan 2019 20:42:16 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547412136.61.0.508208136078.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'm suggesting PendingDeprecationWarning because we can't *actually* deprecate anything until we provide a more transparent alternative that offers comparable functionality, and I haven't seen a credible proposal for a replacement yet.

So using PDW would truthfully indicate "We don't like this feature, and want to get rid of it as causing more problems than it solves, but also acknowledge that it is currently handling legitimate use cases that need to be addressed before we can remove it".

https://coverage.readthedocs.io/en/coverage-4.4.2/subprocess.html is one example I'm aware of that describes a legitimate use case for being able to run arbitrary code at software startup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sun Jan 13 15:49:58 2019
From: report at bugs.python.org (Chris Billington)
Date: Sun, 13 Jan 2019 20:49:58 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547412598.82.0.0462496329545.issue33944@roundup.psfhosted.org>


Chris Billington <chrisjbillington at gmail.com> added the comment:

coverage.py's documentation mentions:

> The sitecustomize.py technique is cleaner, but may involve modifying an existing sitecustomize.py, since there can be only one. If there is no sitecustomize.py already, you can create it in any directory on the Python path.

> The .pth technique seems like a hack, but works, and is documented behavior. On the plus side, you can create the file with any name you like so you don?t have to coordinate with other .pth files. On the minus side, you have to create the file in a system-defined directory, so you may need privileges to write it.

This brings to mind the transition of many programs from using a single config file or startup script to using a directory of config/startup files parsed/executed in alphabetical order. Would a sitecustomize.d/ directory (with files within it executed in alphabetical order) as a replacement for executable code in .pth files be an improvement on the status quo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:27:16 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Jan 2019 21:27:16 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547414836.02.0.572602444062.issue35674@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11158
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:27:26 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Jan 2019 21:27:26 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547414846.16.0.0509648800535.issue35674@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11158, 11159
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:27:36 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Jan 2019 21:27:36 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547414856.96.0.870411392394.issue35674@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11158, 11159, 11161
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:27:47 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Jan 2019 21:27:47 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547414867.83.0.184637710733.issue35674@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11158, 11159, 11160, 11161
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:48:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Jan 2019 21:48:49 +0000
Subject: [issue35679] pdb restart hooks
In-Reply-To: <1546869350.93.0.529177618496.issue35679@roundup.psfhosted.org>
Message-ID: <1547416129.38.0.87622017864.issue35679@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hi Hernot,

I think I understand what you are indicating but I still find it a bit confusing. Could you provide a reproducer and document a bit more the expected and actual behaviour, maybe with some code snippets?

Thanks

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35679>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:50:38 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 13 Jan 2019 21:50:38 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547416238.3.0.854926028932.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> * On FreeBSD, if setting posix_spawn() "attributes" or execute posix_spawn() "file actions" fails, posix_spawn() succeed but the child process exits immediately with exit code 127 without trying to call execv(). If execv() fails, posix_spawn() succeed, but the child process exit with exit code 127.
> * The worst seems to be: "In my test on Ubuntu 14.04, ./python -c "import subprocess; subprocess.call(['/xxx'], close_fds=False, restore_signals=False)" silently returns with zero exit code."

To clarify, in the Ubuntu example only the parent process returns with zero exit code. The child exits with 127, so the behavior is the same as on FreeBSD, as demonstrated by check_call():

$ ./python -c "import subprocess; subprocess.check_call(['/xxx'], close_fds=False, restore_signals=False)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/subprocess.py", line 348, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/xxx']' returned non-zero exit status 127.

> According to Alexey Izbyshev, musl should be safe as well, but I don't know how to test musl on my Fedora, nor how to check if Python is linked to musl, nor what is the minimum musl version which is safe.

musl doesn't have an equivalent of __GLIBC__ macro by design as explained in its FAQ [1], and the same FAQ suggests to use something like "#ifndef __GLIBC__ portable_code() #else glibc_code()". So far musl-related fixes followed this advice (see PR 9288, PR 9224), but in this case it doesn't seem like a good idea to me. POSIX allows asynchronous error notification, so "portable" code shouldn't make assumptions about that, and technically old glibc and FreeBSD are conforming implementations, but not suitable as a replacement for _posixsubprocess.

Maybe we could use configure-time musl detection instead? It seems like config.guess has some support for musl[2], but it uses "ldd" from PATH and hence appears to work out-of-the-box only on musl-based distros like Alpine. See also [3].

Regarding the minimum musl version, in this case it's not important since the relevant change was committed in 2013[4], and given that musl is relatively young, such old versions shouldn't have users now. 

[1] https://wiki.musl-libc.org/faq.html
[2] https://github.com/python/cpython/blob/5bb146aaea1484bcc117ab6cb38dda39ceb5df0f/config.guess#L154
[3] https://github.com/RcppCore/Rcpp/pull/449
[4] https://git.musl-libc.org/cgit/musl/commit/?id=fb6b159d9ec7cf1e037daa974eeeacf3c8b3b3f1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Sun Jan 13 16:53:24 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 13 Jan 2019 21:53:24 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1547412598.82.0.0462496329545.issue33944@roundup.psfhosted.org>
Message-ID: <bdf53809-f292-7864-07cc-d738518a968f@mail.ru>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

> This brings to mind the transition of many programs from using a single config file or startup script to using a directory of config/startup files parsed/executed in alphabetical order. Would a sitecustomize.d/ directory (with files within it executed in alphabetical order) as a replacement for executable code in .pth files be an improvement on the status quo?

No, because the required execution order is governed by package 
interdependencies rather than names. SysVInit went around this by 
hand-picking number prefixes to files in rcN.d/ but this proved 
unmaintainable in the long run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sun Jan 13 17:04:00 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Jan 2019 22:04:00 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1547417040.6.0.578825429671.issue35378@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have been playing with possible solutions for a while and the weak-reference solution seems not robust enough as there are too potential race conditions between the destruction of the weakreferences (the pool) and the handling code.

I would advocate again for using a strong reference. The reasons are:

* The rest of the stdlib is using this solution to link iterator objects and similar to their parents (lists, dicts, sets...etc all have strong references back to their parents).

* This solution is backwards compatible with the current behaviour.

* We have the new ResourceWarnigns to make clear that this behaviour is not supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Sun Jan 13 17:04:46 2019
From: report at bugs.python.org (Antony Lee)
Date: Sun, 13 Jan 2019 22:04:46 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547417086.58.0.720832808288.issue33944@roundup.psfhosted.org>


Change by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sun Jan 13 18:18:03 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Sun, 13 Jan 2019 23:18:03 +0000
Subject: [issue35732] Typo in library/warnings documentation
Message-ID: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>


New submission from Antoine Wecxsteen <antoine at wecxsteen.net>:

Hello,

I believe there's a mistake in the documentation of library/warnings.

https://docs.python.org/3.8/library/warnings.html#warnings.warn

"This function raises an exception if the particular warning issued is changed into an error by the warnings filter see above."

I think "see above" should be enclosed in brackets (or maybe completely removed as there is already a "(see above)" in the same text block).

Regards.

----------
assignee: docs at python
components: Documentation
messages: 333574
nosy: awecx, docs at python, eric.araujo, ezio.melotti, mdk, willingc
priority: normal
severity: normal
status: open
title: Typo in library/warnings documentation
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/issue35732>
_______________________________________

From report at bugs.python.org  Sun Jan 13 18:44:05 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 13 Jan 2019 23:44:05 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547423045.99.0.903716731078.issue33416@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

FYI, I started working on this. I will have PR ready end of next week.

Serhiy, I don't think we should keep both this and issue22616 open. Which one would you prefer to close?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Sun Jan 13 19:46:39 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 14 Jan 2019 00:46:39 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547426799.66.0.86036369396.issue35732@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

That looks like an error indeed. Are you interested on making a PR for fixing this?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Sun Jan 13 20:09:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Jan 2019 01:09:38 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547428178.05.0.786411606302.issue35730@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The corresponding 3.7 buildbots failed the same way, 6 not greater than 6, as the 3.8 buildbots.
https://buildbot.python.org/all/#/builders/108/builds/895/steps/5/logs/stdio
https://buildbot.python.org/all/#/builders/115/builds/888/steps/4/logs/stdio

One reason I am suspicious that something weird is going on is the width of 6.  On my system, the Courier 10 and Courier 20 0 widths are 10 and 20.  The Times New Roman 0 width, on CI machines that failed, was 8 (to be doubled to 16).  6 seems too small for Courier 10 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Sun Jan 13 20:20:47 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Mon, 14 Jan 2019 01:20:47 +0000
Subject: [issue35693] test_httpservers fails
In-Reply-To: <1547010094.25.0.275369600875.issue35693@roundup.psfhosted.org>
Message-ID: <1547428847.25.0.9055148574.issue35693@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

E:\RepoGiT\3.7>"E:\RepoGiT\3.7\PCbuild\amd64\python.exe"  -u -Wd -E -bb -m test  -v test_httpservers
== CPython 3.7.2+ (heads/3.7:e1259886ab, Jan 13 2019, 19:16:24) [MSC v.1916 64 bit (AMD64)]
== Windows-10-10.0.17763-SP0 little-endian
== cwd: E:\RepoGiT\3.7\build\test_python_21704
== CPU count: 8
== encodings: locale=cp1252, FS=utf-8
Run tests sequentially
0:00:00 [1/1] test_httpservers
test_err (test.test_httpservers.RequestHandlerLoggingTestCase) ... ok
test_get (test.test_httpservers.RequestHandlerLoggingTestCase) ... ok
test_close_connection (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_date_time_string (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_extra_space (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_error (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_header (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_buffering_of_send_response_only (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_length (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_header_unbuffered_when_continue (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_html_escape_on_error (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_0_9 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_1_0 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_http_1_1 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_request_length (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_too_many_headers (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_1_0 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_1_1 (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_with_continue_rejected (test.test_httpservers.BaseHTTPRequestHandlerTestCase) ... ok
test_command (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_error_content_length (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_handler (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_head_via_send_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_close (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_internal_key_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_latin1_header (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_request_line_trimming (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_custom_status (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_explain_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_return_header_keep_alive (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_blank (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_send_error (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_bogus (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_digits (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_invalid (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_version_none_get (test.test_httpservers.BaseHTTPServerTestCase) ... ok
test_browser_cache (test.test_httpservers.SimpleHTTPServerTestCase)
Check that when a request to /test is sent with the request header ... ok
test_browser_cache_file_changed (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_browser_cache_with_If_None_Match_header (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_get (test.test_httpservers.SimpleHTTPServerTestCase) ... FAIL
test_head (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_html_escape_filename (test.test_httpservers.SimpleHTTPServerTestCase) ... skipped 'Can not create file <test&>.txt on current file system'
test_invalid_requests (test.test_httpservers.SimpleHTTPServerTestCase) ... ok
test_last_modified (test.test_httpservers.SimpleHTTPServerTestCase)
Checks that the datetime returned in Last-Modified response header ... ok
test_path_without_leading_slash (test.test_httpservers.SimpleHTTPServerTestCase) ... E:\RepoGiT\3.7\lib\email\feedparser.py:89: ResourceWarning: unclosed <socket.socket [closed] fd=816, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  for ateof in reversed(self._eofstack):
ResourceWarning: Enable tracemalloc to get the object allocation traceback
FAIL
test_undecodable_filename (test.test_httpservers.SimpleHTTPServerTestCase) ... skipped 'undecodable name cannot be decoded on win32'
test_authorization (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_headers_and_content (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_invaliduri (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_issue19435 (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_nested_cgi_path_issue21323 (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_no_leading_slash (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_os_environ_is_not_altered (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_post (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_with_continuous_slashes (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_with_multiple_question_mark (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_url_collapse_path (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_urlquote_decoding_in_cgi_check (test.test_httpservers.CGIHTTPServerTestCase) ... ok
test_query_arguments (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_start_with_double_slash (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_windows_colon (test.test_httpservers.SimpleHTTPRequestHandlerTestCase) ... ok
test_all (test.test_httpservers.MiscTestCase) ... ok

======================================================================
FAIL: test_get (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\RepoGiT\3.7\lib\test\test_httpservers.py", line 422, in test_get
    self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
  File "E:\RepoGiT\3.7\lib\test\test_httpservers.py", line 374, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != <HTTPStatus.NOT_FOUND: 404>

======================================================================
FAIL: test_path_without_leading_slash (test.test_httpservers.SimpleHTTPServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\RepoGiT\3.7\lib\test\test_httpservers.py", line 523, in test_path_without_leading_slash
    self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
  File "E:\RepoGiT\3.7\lib\test\test_httpservers.py", line 374, in check_status_and_reason
    self.assertEqual(response.status, status)
AssertionError: 200 != <HTTPStatus.NOT_FOUND: 404>

----------------------------------------------------------------------

Ran 64 tests in 4.182s

FAILED (failures=2, skipped=2)
E:\RepoGiT\3.7\lib\test\support\__init__.py:1539: ResourceWarning: unclosed <socket.socket [closed] fd=732, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0>
  gc.collect()
ResourceWarning: Enable tracemalloc to get the object allocation traceback
test test_httpservers failed
test_httpservers failed

== Tests result: FAILURE ==

1 test failed:
    test_httpservers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35693>
_______________________________________

From report at bugs.python.org  Sun Jan 13 20:26:51 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 14 Jan 2019 01:26:51 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1547429211.39.0.825903763719.issue34294@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch
pull_requests: +11162
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Sun Jan 13 20:27:04 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 14 Jan 2019 01:27:04 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1547429224.89.0.812867263892.issue34294@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch, patch
pull_requests: +11162, 11163
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Sun Jan 13 20:27:14 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 14 Jan 2019 01:27:14 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1547429234.82.0.563967315929.issue34294@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11162, 11163, 11164
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Sun Jan 13 21:31:21 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 14 Jan 2019 02:31:21 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
Message-ID: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

Noticing this in pyflakes

https://github.com/PyCQA/pyflakes/pull/408

----------
messages: 333579
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: isinstance(ast.Constant(value=True), ast.Num) should be False
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Sun Jan 13 21:47:47 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 14 Jan 2019 02:47:47 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547434067.65.0.110613889123.issue35733@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +11165
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Sun Jan 13 21:47:51 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 14 Jan 2019 02:47:51 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547434071.36.0.481303874014.issue35733@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch
pull_requests: +11165, 11166
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Sun Jan 13 21:47:55 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 14 Jan 2019 02:47:55 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547434075.22.0.0983206514558.issue35733@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch, patch
pull_requests: +11165, 11166, 11167
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Sun Jan 13 22:08:06 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 14 Jan 2019 03:08:06 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1547435286.84.0.380738567753.issue34294@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

I tried to fix it, feel free to create a new PR if you don't want this one.

PR11546 has a small question, should `state->data_stack` be dealloced as well?

FYI, function `state_reset(SRE_STATE* state)` in file `_sre.c`:
https://github.com/python/cpython/blob/d4f9cf5545d6d8844e0726552ef2e366f5cc3abd/Modules/_sre.c#L340-L352

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Sun Jan 13 22:51:19 2019
From: report at bugs.python.org (ulin)
Date: Mon, 14 Jan 2019 03:51:19 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
Message-ID: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>


New submission from ulin <linlin152 at foxmail.com>:

valid netmask like 255.0.0.0 255.128.0.0, but 255.254.128.0 is not valid, but ipaddress._BaseV4._is_valid_netmask fails to detect the latter.

Tested in Python 3.6.7, as the code stays the same, affects all after Python 3.6.7.

----------
components: Library (Lib)
files: test_ipaddress.py
messages: 333581
nosy: ulindog
priority: normal
severity: normal
status: open
title: ipaddress's _BaseV4._is_valid_netmask fails to  detect invalid netmask like 255.254.128.0
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48047/test_ipaddress.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Sun Jan 13 23:55:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 04:55:20 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547441720.41.0.24628228543.issue35734@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Mon Jan 14 00:19:11 2019
From: report at bugs.python.org (tzickel)
Date: Mon, 14 Jan 2019 05:19:11 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1547443151.66.0.396206353274.issue35378@roundup.psfhosted.org>


tzickel <icebreak at yahoo.com> added the comment:

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Mon Jan 14 00:33:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jan 2019 05:33:17 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547443997.33.0.0224880145977.issue33416@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This idea seems reasonable.  Most of the AST nodes have a span and it would be nice to know what that is.  I'm sure we will find use cases though I doubt that many compiler syntax errors would benefit (since a syntax error means that we don't have a completely matched grammar rule).

BTW, does this information have to be added by the parser or could there be am AST module function that deduces the end locations from the start location of next sibling node or from the parent node?  If so, it may still be possible get the benefit without slowing down or complicating the parser logic.

Do we know what other languages do (carry the full span info in the AST or deduce the span after the fact)?  I don't know what the best practices are in this regard.

One other thought:  We should be careful not to impair existing AST capabilities that support code rewriting and movement (i.e. refactoring tools).  The copy_location() and fix_missing_locations() functions would need to be updated as well.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Mon Jan 14 00:34:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jan 2019 05:34:17 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1547444057.68.0.863217592162.issue35378@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:10:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 06:10:28 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547446228.6.0.668727122613.issue35734@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:13:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 06:13:57 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547446437.9.0.705038074054.issue35733@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:17:56 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 06:17:56 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547446676.86.0.366040191376.issue24780@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11168
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:18:15 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 06:18:15 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547446695.61.0.306238606301.issue24780@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11168, 11169
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:18:29 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 06:18:29 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547446709.73.0.472761162554.issue24780@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11168, 11169, 11170
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:21:25 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 06:21:25 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547446885.65.0.804966830618.issue24780@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I have opened a PR for this.

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:24:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 06:24:58 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547447098.34.0.610962032349.issue35733@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Added Serhiy since this seems to have been caused due to issue32892 and changes made in 6015cc50bc


?  cpython git:(6015cc50bc) ./python.exe -c 'import ast; print(isinstance(ast.Constant(False), ast.Num))'
True
?  cpython git:(6015cc50bc) git checkout 6015cc5~1
?  cpython git:(913876d824) make > /dev/null
?  cpython git:(913876d824) ./python.exe -c 'import ast; print(isinstance(ast.Constant(False), ast.Num))'
False

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:25:48 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jan 2019 06:25:48 +0000
Subject: [issue35710] Make dataclasses.field() accept another name for
 __init__ field's name
In-Reply-To: <1547140271.38.0.846532339527.issue35710@roundup.psfhosted.org>
Message-ID: <1547447148.43.0.337843936213.issue35710@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

"target" seems too general for the OP's use case.  "private=False" would be more focused.  General renaming occasionally has uses but is mostly an anti-pattern.  

Some thought also needs to be given to downstream effects of renaming (what shows up in help(), impact of renaming on type annotations, introspection challenges, what asdict() should do, whether the overall implementation would be made more complex, is the attribute now out of reach for __post_init__(), is this even within the scope of what dataclasses set out to do, etc).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35710>
_______________________________________

From report at bugs.python.org  Mon Jan 14 01:42:52 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Mon, 14 Jan 2019 06:42:52 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547448172.99.0.94583145886.issue35537@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Mon Jan 14 02:18:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 07:18:01 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547450281.56.0.94310441659.issue33416@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is up to you Ivan.

The end location can not be deduces from the start location of next sibling node or from the parent node. For example, the AST for the expression "foo.bar.baz" does not contain information for the end location of "foo.bar".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Mon Jan 14 02:25:44 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 14 Jan 2019 07:25:44 +0000
Subject: [issue35735] Current "make test" status for AIX
Message-ID: <1547450742.92.0.354703288853.issue35735@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Hi all,

as we get closer to having the current tests all patched I want to have a place to post new "failures" - since the BOT process is unable to report regressions before all tests are passing for a time.

Initially, the tests run normally, and report two unexpected failures. However, the second pass does not complete - it is giving a segmentation error (repeated twice, starting third run shortly).

i.e., the tests test_eintr and test_importlib have PR that are waitig to be merged. the failure of test_os and test_xml_etree_c are new.

Tested: heads/master-dirty:5bb146aaea

         ./python  ../git/python3-3.8/Tools/scripts/run_tests.py
/data/prj/python/python3-3.8/python -u -W default -bb -E -m test -r -w -j 0 -u all,-largefile,-audio,-gui
== CPython 3.8.0a0 (heads/master-dirty:5bb146aaea, Jan 13 2019, 21:30:27) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /data/prj/python/python3-3.8/build/test_python_9109548
== CPU count: 8
== encodings: locale=ISO8859-1, FS=iso8859-1
Using random seed 9105159
Run tests in parallel using 10 child processes
0:00:01 [  1/418] test_nis passed
0:00:01 [  2/418] test_zipfile64 skipped (resource denied)
test_zipfile64 skipped -- test requires loads of disk-space bytes and a long time to run
0:00:01 [  3/418] test_stringprep passed
...
0:10:23 [418/418/4] test_tools passed (4 min 31 sec)

== Tests result: FAILURE ==

390 tests OK.

4 tests failed:
    test_eintr test_importlib test_os test_xml_etree_c

24 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_idle
    test_kqueue test_msilib test_ossaudiodev test_readline test_spwd
    test_sqlite test_startfile test_tcl test_tix test_tk
    test_ttk_guionly test_ttk_textonly test_turtle test_unicode_file
    test_unicode_file_functions test_winconsoleio test_winreg
    test_winsound test_zipfile64

Re-running failed tests in verbose mode
...
Re-running test 'test_xml_etree_c' in verbose mode
test_bpo_31728 (test.test_xml_etree_c.MiscTests) ... ok
test_del_attribute (test.test_xml_etree_c.MiscTests) ... ok
test_iterparse_leaks (test.test_xml_etree_c.MiscTests) ... ok
test_length_overflow (test.test_xml_etree_c.MiscTests) ... skipped 'not enough memory: 2.0G minimum needed'
test_parser_ref_cycle (test.test_xml_etree_c.MiscTests) ... ok
test_setstate_leaks (test.test_xml_etree_c.MiscTests) ... ok
test_trashcan (test.test_xml_etree_c.MiscTests) ... ok
test_xmlpullparser_leaks (test.test_xml_etree_c.MiscTests) ... ok
test_alias_working (test.test_xml_etree_c.TestAliasWorking) ... ok
test_correct_import_cET (test.test_xml_etree_c.TestAcceleratorImported) ... ok
test_correct_import_cET_alias (test.test_xml_etree_c.TestAcceleratorImported) ... ok
test_parser_comes_from_C (test.test_xml_etree_c.TestAcceleratorImported) ... ok
test_element (test.test_xml_etree_c.SizeofTest) ... ok
test_element_with_attrib (test.test_xml_etree_c.SizeofTest) ... ok
test_element_with_children (test.test_xml_etree_c.SizeofTest) ... ok

----------------------------------------------------------------------

Ran 15 tests in 0.871s

OK (skipped=1)
test_all (test.test_xml_etree.ModuleTest) ... ok
test_sanity (test.test_xml_etree.ModuleTest) ... ok
test_delslice (test.test_xml_etree.ElementSlicingTest) ... ok
test_getslice_negative_steps (test.test_xml_etree.ElementSlicingTest) ... ok
test_getslice_range (test.test_xml_etree.ElementSlicingTest) ... ok
test_getslice_single_index (test.test_xml_etree.ElementSlicingTest) ... ok
test_getslice_steps (test.test_xml_etree.ElementSlicingTest) ... ok
test_setslice_negative_steps (test.test_xml_etree.ElementSlicingTest) ... ok
test_setslice_range (test.test_xml_etree.ElementSlicingTest) ... ok
test_setslice_single_index (test.test_xml_etree.ElementSlicingTest) ... ok
test_setslice_steps (test.test_xml_etree.ElementSlicingTest) ... ok
test_augmentation_type_errors (test.test_xml_etree.BasicElementTest) ... Fatal Python error: Segmentation fault

Current thread 0x00000001 (most recent call first):
  File "/data/prj/python/git/python3-3.8/Lib/unittest/case.py", line 197 in handle
  File "/data/prj/python/git/python3-3.8/Lib/unittest/case.py", line 782 in assertRaises
  File "/data/prj/python/git/python3-3.8/Lib/test/test_xml_etree.py", line 1811 in test_augmentation_type_errors
  File "/data/prj/python/git/python3-3.8/Lib/unittest/case.py", line 642 in run
  File "/data/prj/python/git/python3-3.8/Lib/unittest/case.py", line 702 in __call__
  File "/data/prj/python/git/python3-3.8/Lib/unittest/suite.py", line 122 in run
  File "/data/prj/python/git/python3-3.8/Lib/unittest/suite.py", line 84 in __call__
  File "/data/prj/python/git/python3-3.8/Lib/unittest/suite.py", line 122 in run
  File "/data/prj/python/git/python3-3.8/Lib/unittest/suite.py", line 84 in __call__
  File "/data/prj/python/git/python3-3.8/Lib/unittest/runner.py", line 176 in run
  File "/data/prj/python/git/python3-3.8/Lib/test/support/__init__.py", line 1935 in _run_suite
  File "/data/prj/python/git/python3-3.8/Lib/test/support/__init__.py", line 2031 in run_unittest
  File "/data/prj/python/git/python3-3.8/Lib/test/test_xml_etree.py", line 3213 in test_main
  File "/data/prj/python/git/python3-3.8/Lib/test/test_xml_etree_c.py", line 222 in test_main
  File "/data/prj/python/git/python3-3.8/Lib/test/libregrtest/runtest.py", line 182 in runtest_inner
  File "/data/prj/python/git/python3-3.8/Lib/test/libregrtest/runtest.py", line 137 in runtest
  File "/data/prj/python/git/python3-3.8/Lib/test/libregrtest/main.py", line 304 in rerun_failed_tests
  File "/data/prj/python/git/python3-3.8/Lib/test/libregrtest/main.py", line 619 in _main
  File "/data/prj/python/git/python3-3.8/Lib/test/libregrtest/main.py", line 582 in main
  File "/data/prj/python/git/python3-3.8/Lib/test/libregrtest/main.py", line 636 in main
  File "/data/prj/python/git/python3-3.8/Lib/test/__main__.py", line 2 in <module>
  File "/data/prj/python/git/python3-3.8/Lib/runpy.py", line 85 in _run_code
  File "/data/prj/python/git/python3-3.8/Lib/runpy.py", line 192 in _run_module_as_main
make: 1254-059 The signal code from the last command is 11.

----------
messages: 333588
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Current "make test" status for AIX
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35735>
_______________________________________

From report at bugs.python.org  Mon Jan 14 03:15:25 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Mon, 14 Jan 2019 08:15:25 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547453725.9.0.989764464104.issue35732@roundup.psfhosted.org>


Antoine Wecxsteen <antoine at wecxsteen.net> added the comment:

Hello Pablo,

Yes, I'll be happy to make a PR.

I don't think it should be removed after all as, actually, the two "see above" do not refer to the same paragraph ("Warning Categories" and "The Warnings Filter" respectively).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 03:23:26 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Mon, 14 Jan 2019 08:23:26 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547454206.32.0.27584799405.issue35732@roundup.psfhosted.org>


Change by Antoine Wecxsteen <antoine at wecxsteen.net>:


----------
keywords: +patch
pull_requests: +11171
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 03:23:37 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Mon, 14 Jan 2019 08:23:37 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547454217.64.0.518473011885.issue35732@roundup.psfhosted.org>


Change by Antoine Wecxsteen <antoine at wecxsteen.net>:


----------
keywords: +patch, patch
pull_requests: +11171, 11172
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 03:23:49 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Mon, 14 Jan 2019 08:23:49 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547454229.25.0.148493031081.issue35732@roundup.psfhosted.org>


Change by Antoine Wecxsteen <antoine at wecxsteen.net>:


----------
keywords: +patch, patch, patch
pull_requests: +11171, 11172, 11173
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 03:24:01 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Mon, 14 Jan 2019 08:24:01 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547454241.84.0.808404506276.issue35732@roundup.psfhosted.org>


Change by Antoine Wecxsteen <antoine at wecxsteen.net>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11171, 11172, 11173, 11174
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 03:28:39 2019
From: report at bugs.python.org (Antoine Wecxsteen)
Date: Mon, 14 Jan 2019 08:28:39 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547454519.03.0.286140522887.issue35732@roundup.psfhosted.org>


Antoine Wecxsteen <antoine at wecxsteen.net> added the comment:

https://github.com/python/cpython/pull/11549

Reading the dev guide, I see there is actually no need to open an issue for mere typos. I should have made a PR directly...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 04:01:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 09:01:58 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547456518.6.0.169335368433.issue33944@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I really hate .pth files because the slow down Python startup time for *all* applications whereas .pth files are usually specific to a very few applications using one or two specific modules.

They can also modify the behavior of Python for all applications, with no way to opt-out.

I would prefer to have an opt-in option, disabled by default.

I'm in favor of deprecating the feature in Python 3.8 and remove it from Python 3.9.

Python 3 already support namespaces which covers the most common use case of .pth files, no?

Another use case is to run code if a specific command line option is used or if an environment variable is set. For example, my faulthandler backport uses a .pth file to enable faulthandler if PYTHONFAULTHANDLER environment variable is set. I dislike this .pth file (I didn't write it ;-)). I'm fine with dropping this feature as a whole.

We can add a pending deprecation warning in Python 3.7 right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 04:14:03 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jan 2019 09:14:03 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547457243.99.0.352635334641.issue33944@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

As I said: editable installs (`pip install -e`) are an important use case of .pth files.

I don't see how namespace packages have anything to do with this, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 04:15:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 09:15:08 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547457308.68.0.484609986154.issue35730@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

https://buildbot.python.org/all/#/builders/108/builds/895/steps/5/logs/stdio
https://buildbot.python.org/all/#/builders/115/builds/888/steps/4/logs/stdio

======================================================================
FAIL: test_reload (idlelib.idle_test.test_squeezer.SqueezerTest)
Test the reload() class-method.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.7.ware-gentoo-x86.installed/build/target/lib/python3.7/idlelib/idle_test/test_squeezer.py", line 310, in test_reload
    self.assertGreater(squeezer.zero_char_width, orig_zero_char_width)
AssertionError: 6 not greater than 6


> Two debug prints that might help: the tk patch level (does Gentoo have something ancient?); the actual font and in particular the actual size resulting from ('Courier', 10/20).

The pythoninfo step of the buildbot says:

tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.8

--

The test pass (at revision 47bd7770229b5238a438703ee1d52da2e983ec9e, before you disabled the test) on my Fedora 29. I enabled all test resources using "-u all". I have the same Tkinter version:

$ ./python -m test -u all test_idle -m test_reload -v
== CPython 3.7.2+ (tags/v3.7.2-112-g47bd777022:47bd777022, Jan 14 2019, 10:12:33) [GCC 8.2.1 20181215 (Red Hat 8.2.1-6)]
== Linux-4.19.13-300.fc29.x86_64-x86_64-with-fedora-29-Twenty_Nine little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_3006
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.23 [1/1] test_idle
test_reload (idlelib.idle_test.test_codecontext.CodeContextTest) ... ok
test_reload (idlelib.idle_test.test_squeezer.SqueezerTest)
Test the reload() class-method. ... ok

----------------------------------------------------------------------

Ran 2 tests in 0.069s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 1 sec 344 ms
Tests result: SUCCESS

vstinner at apu$ make pythoninfo|grep ^tk
tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.8

--

The test rely on a specific font name and specific font size: maybe this specific font is not available. Instead of skipping the test, would it make same to accept that squeezer.zero_char_width does not change? I don't know IDLE nor the test.

diff --git a/Lib/idlelib/idle_test/test_squeezer.py b/Lib/idlelib/idle_test/test_squeezer.py
index 7c28a107a9..0d4467af0a 100644
--- a/Lib/idlelib/idle_test/test_squeezer.py
+++ b/Lib/idlelib/idle_test/test_squeezer.py
@@ -307,7 +307,7 @@ class SqueezerTest(unittest.TestCase):
             str(new_auto_squeeze_min_lines))
 
         Squeezer.reload()
-        self.assertGreater(squeezer.zero_char_width, orig_zero_char_width)
+        self.assertGreaterEqual(squeezer.zero_char_width, orig_zero_char_width)
         self.assertEqual(squeezer.auto_squeeze_min_lines,
                          new_auto_squeeze_min_lines)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 04:16:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 09:16:53 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1547457413.34.0.951385376388.issue35378@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

According to all previous discussions, I now agree with having a strong reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Mon Jan 14 04:30:37 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 14 Jan 2019 09:30:37 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547458237.33.0.182384998565.issue35730@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> The test rely on a specific font name and specific font size: maybe this specific font is not available.

Can you help by checking this? Is there another font known to be universally available?

> Instead of skipping the test, would it make same to accept that squeezer.zero_char_width does not change? I don't know IDLE nor the test.

Not really. This test, test_reload(), is specifically checking that the reload() function updates zero_char_width after font changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 04:56:28 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Mon, 14 Jan 2019 09:56:28 +0000
Subject: [issue30235] Validate shutil supports path-like objects,
 update docs accordingly
In-Reply-To: <1493745159.76.0.694023923588.issue30235@psf.upfronthosting.co.za>
Message-ID: <1547459788.76.0.390100760981.issue30235@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
nosy: +Tiger-222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30235>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:01:00 2019
From: report at bugs.python.org (SilentGhost)
Date: Mon, 14 Jan 2019 10:01:00 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547460060.36.0.154699565611.issue33944@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:02:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 10:02:56 +0000
Subject: [issue34384] os.readlink does not accept pathlib.Path on Windows
In-Reply-To: <1534045271.73.0.56676864532.issue34384@psf.upfronthosting.co.za>
Message-ID: <1547460176.81.0.109100941924.issue34384@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34384>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:05:04 2019
From: report at bugs.python.org (SilentGhost)
Date: Mon, 14 Jan 2019 10:05:04 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1547460304.22.0.401038409873.issue35720@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +vstinner
type:  -> resource usage
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:05:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 10:05:28 +0000
Subject: [issue33301] Add __contains__ to pathlib
In-Reply-To: <1524000201.84.0.682650639539.issue33301@psf.upfronthosting.co.za>
Message-ID: <1547460328.65.0.0846065824319.issue33301@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33301>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:11:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 10:11:35 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547460695.64.0.119800021286.issue35730@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Not really. This test, test_reload(), is specifically checking that the reload() function updates zero_char_width after font changes.

What if the old and the new font have the same width?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:17:21 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 14 Jan 2019 10:17:21 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547461041.31.0.843090550513.issue35730@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

> What if the old and the new font have the same width?

The font is set to Courier 10 in the test's setup, and it is then set to Courier 20 by the test before calling reload(). The zero character should certainly not have the same width in both cases.

ISTM that indeed the font must be missing, or something of that sort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:20:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 10:20:29 +0000
Subject: [issue34512] Document platform-specific strftime() behavior for
 non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1547461229.21.0.837336739002.issue34512@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

A solution to make time.strftime() more portable would be to split the format string, format each "%xxx" substring separately but don't pass substrings between "%xxx" to strftime(). There is a similar discussion about trailing "%": bpo-35066.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34512>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:21:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 10:21:14 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547461274.77.0.0317716312851.issue35066@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The behavior of strftime() with non-ASCII is not portable: bpo-34512.

A solution to make time.strftime() more portable would be to split the format string, format each "%xxx" substring separately but don't pass substrings between "%xxx" to strftime().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:23:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 10:23:48 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547461428.63.0.37043119167.issue35066@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 454b3d4ea246e8751534e105548d141ed7b0b032 by Victor Stinner (MichaelSaah) in branch 'master':
bpo-35066: _dateime.datetime.strftime copies trailing '%' (GH-10692)
https://github.com/python/cpython/commit/454b3d4ea246e8751534e105548d141ed7b0b032


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:24:17 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:24:17 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547461457.1.0.782752075315.issue35066@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11175

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:24:33 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:24:33 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547461473.69.0.258191341417.issue35066@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11175, 11176

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:24:51 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:24:51 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547461491.67.0.859900725899.issue35066@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11175, 11176, 11177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:40:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 10:40:32 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547462432.76.0.776949464438.issue35730@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The test still pass on my Fedora 29 with:

diff --git a/Lib/idlelib/idle_test/test_squeezer.py b/Lib/idlelib/idle_test/test_squeezer.py
index 71eccd3693..e026567789 100644
--- a/Lib/idlelib/idle_test/test_squeezer.py
+++ b/Lib/idlelib/idle_test/test_squeezer.py
@@ -114,7 +114,7 @@ class SqueezerTest(unittest.TestCase):
         if root is None:
             root = get_test_tk_root(self)
         text_widget = Text(root)
-        text_widget["font"] = ('Courier', 10)
+        text_widget["font"] = ('XXXX', 10)
         text_widget.mark_set("iomark", "1.0")
         return text_widget
 
@@ -300,7 +300,7 @@ class SqueezerTest(unittest.TestCase):
         orig_auto_squeeze_min_lines = squeezer.auto_squeeze_min_lines
 
         # Increase both font size and auto-squeeze-min-lines.
-        text_widget["font"] = ('Courier', 20)
+        text_widget["font"] = ('XXXX', 20)
         new_auto_squeeze_min_lines = orig_auto_squeeze_min_lines + 10
         self.set_idleconf_option_with_cleanup(
             'main', 'PyShell', 'auto-squeeze-min-lines',
@@ -309,7 +309,7 @@ class SqueezerTest(unittest.TestCase):
         Squeezer.reload()
         # The following failed on Gentoo buildbots.  Issue title will be
         # IDLE: Fix squeezer test_reload.
-        #self.assertGreater(squeezer.zero_char_width, orig_zero_char_width)
+        self.assertGreater(squeezer.zero_char_width, orig_zero_char_width)
         self.assertEqual(squeezer.auto_squeeze_min_lines,
                          new_auto_squeeze_min_lines)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:41:37 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:41:37 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547462497.44.0.354016073275.issue35066@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 26122de1a80d1618ee80862cf3b8f73f8ec7d9cf by Miss Islington (bot) in branch '3.7':
bpo-35066: _dateime.datetime.strftime copies trailing '%' (GH-10692)
https://github.com/python/cpython/commit/26122de1a80d1618ee80862cf3b8f73f8ec7d9cf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:41:59 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:41:59 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547462497.44.0.354016073275.issue35066@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 26122de1a80d1618ee80862cf3b8f73f8ec7d9cf by Miss Islington (bot) in branch '3.7':
bpo-35066: _dateime.datetime.strftime copies trailing '%' (GH-10692)
https://github.com/python/cpython/commit/26122de1a80d1618ee80862cf3b8f73f8ec7d9cf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:42:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 10:42:01 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1547462521.59.0.889067811927.issue35066@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I proposed two different implementations to make time.strftime() more portable, so it seems like it's more complex than what I expected. I merged the datetime change since this one is self-sufficient, so someone can work on a time change on top of it.

----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:49:19 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Mon, 14 Jan 2019 10:49:19 +0000
Subject: [issue30235] Validate shutil supports path-like objects,
 update docs accordingly
In-Reply-To: <1493745159.76.0.694023923588.issue30235@psf.upfronthosting.co.za>
Message-ID: <1547462959.49.0.769120864692.issue30235@roundup.psfhosted.org>


Micka?l Schoentgen <contact at tiger-222.fr> added the comment:

There is another place where the use of Path objects is not yet working: when move() is given a directory as argument. A patch is in review in issue32689.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30235>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:51:06 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Mon, 14 Jan 2019 10:51:06 +0000
Subject: [issue32689] shutil.move raises AttributeError if first argument is a
 pathlib.Path object and destination is a directory
In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>
Message-ID: <1547463066.01.0.960590769776.issue32689@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:52:49 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Mon, 14 Jan 2019 10:52:49 +0000
Subject: [issue30235] Validate shutil supports path-like objects,
 update docs accordingly
In-Reply-To: <1493745159.76.0.694023923588.issue30235@psf.upfronthosting.co.za>
Message-ID: <1547463169.53.0.236621812882.issue30235@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30235>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:58:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 10:58:41 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547463521.97.0.369223173449.issue34756@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6fe9c446f8302553952f63fc6d96be4dfa48ceba by Serhiy Storchaka in branch 'master':
bpo-34756: Silence only ImportError and AttributeError in sys.breakpointhook(). (GH-9457)
https://github.com/python/cpython/commit/6fe9c446f8302553952f63fc6d96be4dfa48ceba


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:59:10 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:59:10 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547463550.71.0.439801433992.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:59:16 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:59:16 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547463556.47.0.790448613451.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11178, 11179

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 05:59:22 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 10:59:22 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547463562.45.0.0120449276295.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11178, 11179, 11180

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:04:59 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 11:04:59 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547463899.32.0.923788752179.issue34756@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The part of the clean up was applied in PR 9519. And since _PyObject_GetBuiltin() was gone, the rest of the clean up no longer applicable. The only part that is left is to make unexpected exceptions no longer silenced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:17:10 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Jan 2019 11:17:10 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547464630.03.0.694054119931.issue34756@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6d0254bae4d739b487fcaa76705a2d309bce8e75 by Miss Islington (bot) in branch '3.7':
bpo-34756: Silence only ImportError and AttributeError in sys.breakpointhook(). (GH-9457)
https://github.com/python/cpython/commit/6d0254bae4d739b487fcaa76705a2d309bce8e75


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:18:39 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 14 Jan 2019 11:18:39 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547464719.54.0.893022516515.issue33416@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> I'm sure we will find use cases though I doubt that many compiler syntax errors would benefit (since a syntax error means that we don't have a completely matched grammar rule).

This is mostly useful for code analysis tools and IDEs.

> BTW, does this information have to be added by the parser or could there be am AST module function that deduces the end locations from the start location of next sibling node or from the parent node?

There may be some other ways to do it, but currently I am adding both `end_lineno` and `end_col_offset` to AST, and `n_end_lineno` and `n_end_col_offset` in CST. The latter are needed to easily take care of situations like `a + (b )`, and other corner cases. I could imagine it is possible to live with only end position information in AST to save some memory, but then the code will be much harder to maintain. We can discuss details in the PR.

> Do we know what other languages do (carry the full span info in the AST or deduce the span after the fact)?

I didn't do real research, but quick browsing shows carrying the end position info is quite common. But more importantly as Serhiy noted, deducing might be just not possible in some situations.

> It is up to you Ivan.

OK, I will close the other one as superseded by this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:24:06 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 14 Jan 2019 11:24:06 +0000
Subject: [issue22616] Allow connecting AST nodes with corresponding source
 ranges
In-Reply-To: <1413099307.65.0.261518195286.issue22616@psf.upfronthosting.co.za>
Message-ID: <1547465046.79.0.598144000214.issue22616@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22616>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:24:42 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 14 Jan 2019 11:24:42 +0000
Subject: [issue22616] Allow connecting AST nodes with corresponding source
 ranges
In-Reply-To: <1413099307.65.0.261518195286.issue22616@psf.upfronthosting.co.za>
Message-ID: <1547465082.91.0.489625197574.issue22616@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Closed as superseded by https://bugs.python.org/issue33416

----------
superseder:  -> Add endline and endcolumn to every AST node

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22616>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:25:44 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 14 Jan 2019 11:25:44 +0000
Subject: [issue28657] cmd.Cmd.get_help() implementation can't see do_*()
 methods added dynamically by setattr()
In-Reply-To: <1478776450.68.0.870801686772.issue28657@psf.upfronthosting.co.za>
Message-ID: <1547465144.16.0.176997291787.issue28657@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +catherinedevlin, tleonhardt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28657>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:27:57 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 14 Jan 2019 11:27:57 +0000
Subject: [issue28657] cmd.Cmd.get_help() implementation can't see do_*()
 methods added dynamically by setattr()
In-Reply-To: <1478776450.68.0.870801686772.issue28657@psf.upfronthosting.co.za>
Message-ID: <1547465277.87.0.700573788629.issue28657@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

CC-ing Catherine Devlin and Todd Leonhardt so we can close the issue by either accepting or refusing such feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28657>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:34:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 11:34:46 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547465686.99.0.289679360311.issue34756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:40:53 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 14 Jan 2019 11:40:53 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547466053.71.0.151180912327.issue35734@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I couldn't find any use of _is_valid_netmask() in the code, why should this netmask be invalid?

As far as I can tell this should be a valid one, is there a reason to refuse it?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Mon Jan 14 06:54:42 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 11:54:42 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547466882.91.0.69042552603.issue35734@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> I couldn't find any use of _is_valid_netmask() in the code, why should this netmask be invalid?

There is an open issue to remove this method which is unused and undocumented issue27860. 

I have less knowledge on the subnet masking area but on searching the web there seems to be an RFC that asks for contiguous ones without intermixing zeroes that I hope OP is referring to.

* https://superuser.com/questions/601252/is-225-225-225-128-a-valid-subnet-mask
* https://superuser.com/questions/1151908/non-contiguous-subnet-mask/1151942#1151942

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Mon Jan 14 07:17:17 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Jan 2019 12:17:17 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547468237.36.0.344883762423.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Namespace packages in general didn't rely on pth files - only the setuptools/pkg_resources implementation of them did.

I'll also reiterate that I am *completely* opposed to deprecating the "append entries to sys.path" usage model, as there is absolutely nothing wrong with that (if distros are ending up with an overly cluttered system that's making the standard path too long, then review the individual packages creating the clutter, don't remove the interpreter feature).

That "append to sys.path" aspect of the feature is all that's needed to make editable installs and virtual environment chaining work.

That means the aspect I'm in agreement with deprecating is the "arbitrary code execution on startup" case, but even for that, I don't think we should deprecate it until we have a comparable replacement that's more self-evidently a way of allowing arbitrary code execution, and also more obviously has the potential to make every interpreter startup in that Python installation slower.

I'm not really concerned about execution order issues between interdependent sitecustomize hooks, as there's already no ordering guarantee with .pth files, and if folks do need more control over the interdependencies for some reason then they can just rely on the regular import system rather than something sitecustomize specific.

So I think Chris Billington's proposed replacement is actually a reasonable idea:

1. In site.addsitedir, check for a __sitecustomize__ subdirectory after checking for .pth files
2. If any Python files are found in that directory, execute them
3. If "python -x importtime" has been specified, report the execution time of each of those files (this would allow both easy identification of any hooks that are being executed, as well as which ones are taking up a lot of time)

There could then be a "-Z" option that offered a more limited form of "-S": it would allow site.py itself to run, but disable the processing of `sitecustomize.py` and `__sitecustomize__` entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 07:19:22 2019
From: report at bugs.python.org (Edward K Ream)
Date: Mon, 14 Jan 2019 12:19:22 +0000
Subject: [issue22616] Allow connecting AST nodes with corresponding source
 ranges
In-Reply-To: <1547465048.07.0.0972564888883.issue22616@roundup.psfhosted.org>
Message-ID: <CAMF8tS3jGS+ZpOh_VNRjccmW+RnGDUMg2OFvyQZvHqB2ffdp=Q@mail.gmail.com>


Edward K Ream <edreamleo at gmail.com> added the comment:

On Mon, Jan 14, 2019 at 5:24 AM Ivan Levkivskyi <report at bugs.python.org>
wrote:

Adding endline and endcolumn to every ast node will be a big improvement.

Edward
------------------------------------------------------------------------------------------
Edward K. Ream: edreamleo at gmail.com Leo: http://leoeditor.com/
------------------------------------------------------------------------------------------

----------
nosy: +edreamleo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22616>
_______________________________________

From report at bugs.python.org  Mon Jan 14 07:34:24 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Jan 2019 12:34:24 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547469264.19.0.33677944828.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11181

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 07:34:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Jan 2019 12:34:34 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547469274.7.0.0655548013789.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11181, 11182

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 07:34:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Jan 2019 12:34:45 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547469285.37.0.81917918122.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11181, 11182, 11183

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Mon Jan 14 07:57:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 12:57:46 +0000
Subject: [issue35723] Add "time zone index" cache to datetime objects
In-Reply-To: <1547238857.17.0.663234077571.issue35723@roundup.psfhosted.org>
Message-ID: <1547470666.58.0.629322425525.issue35723@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I dislike adding a public API for an optimization. Would it be possible to make it private? Would it make sense? tzidx => _tzidx.

> One other thing I might mention here is that I did explore the idea of storing this cache on the tzinfo implementation itself, but it is problematic for a number of reasons:
>
> 1. It would either need to use some sort of expiring cache (lru, ttl) or require a great deal of memory, greatly reducing the utility - the proposed implementation requires no additional memory.

In test of your PR, tzinfo allocates memory for its cache: 

            offsets = [timedelta(hours=0), timedelta(hours=1)]
            names = ['+00:00', '+01:00']
            dsts = [timedelta(hours=0), timedelta(hours=1)]

This memory isn't free. I don't see how using an index completely prevents the need to allocate memory for a cache.

Somehow, we need a method to clear the cache and decide a caching policy. The simplest policy is to have no limit. The re.compile() uses a cache of 512 entries. functools.lru_cache uses a default limit of 128 entries.

Instead of adding a new API, would it be possible to reuse functools.lru_cache somehow?

> 2. Because the implementation of datetime.__hash__ invokes utcoffset(), it is impossible to implement utcoffset in terms of a dictionary of tz-aware datetimes. This means that you need to construct a new, naive datetime, which is a fairly slow operation and really puts a damper in the utility of the cache.

For special local timezones, would it be possible to explicitly exclude them, and restrict the cache the simple timespace (fixed offset)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35723>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:02:05 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 14 Jan 2019 13:02:05 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547470925.91.0.380154302261.issue35734@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Still 255.254.128.0 is a valid subnet.

If I understand correctly, rfc1519 relate to how public ip addresses should be attributed. It does not cover what private subnets you use and you still can such submask (as long as you own the whole /16 for example).

rfc950 explicitly allow for such subnets:

> Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address.

and I've heard of them being used (hence the complications and the need for rfc1519 for the public address space).

I'm in favor of closing this issue in favor of issue27860.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:06:40 2019
From: report at bugs.python.org (Aivar Annamaa)
Date: Mon, 14 Jan 2019 13:06:40 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547471200.21.0.914029018382.issue33416@roundup.psfhosted.org>


Aivar Annamaa <aivar.annamaa at gmail.com> added the comment:

I strongly support this feature, because my IDE (https://thonny.org) needs to highlight AST nodes in the source code.

There would be many interested parties if you count the stars of this project: https://github.com/gristlabs/asttokens

----------
nosy: +Aivar.Annamaa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:08:20 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 14 Jan 2019 13:08:20 +0000
Subject: [issue35698] [statistics] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547471300.44.0.269345521594.issue35698@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I agree that for numeric data, it isn't worth changing the behaviour of median to avoid the division in the case of two equal middle values.

Even if we did accept this feature request, it is not going to eliminate the change in type in all circumstances. median([1, 2]) will still return 1.5. And in practical terms, the conditions where this would apply are likely to be quite unusual for numeric data. (Ordinal data is likely to be a different story.)

One way or another, the caller has to expect that the median of an even number of ints may return a number which is a float. If the caller doesn't want that behaviour, they can use median_low or median_high, which never take the average and always return a value from the data set.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:20:16 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Mon, 14 Jan 2019 13:20:16 +0000
Subject: [issue35698] [statistics] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547472016.59.0.037403382136.issue35698@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

I'm still thinking about this.

I find Steve's closing of the issue premature, but I'm not going to reverse it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:26:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 13:26:42 +0000
Subject: [issue35698] [statistics] Division by 2 in statistics.median
In-Reply-To: <1547034372.58.0.0557058004142.issue35698@roundup.psfhosted.org>
Message-ID: <1547472402.92.0.77127493771.issue35698@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I find Steve's closing of the issue premature, but I'm not going to reverse it.

Steven D'Aprano is the maintainer of the module (he wrote 450 and implemented it), he has the last word.

Steven D'Aprano, Raymond Hettinger and me are 3 core developers and in favor of closing the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35698>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:28:09 2019
From: report at bugs.python.org (=?utf-8?q?Michael_Kr=C3=B6tlinger?=)
Date: Mon, 14 Jan 2019 13:28:09 +0000
Subject: [issue35736] Missing component in table after
 getElementsByTagName("nn")
Message-ID: <1547472488.22.0.593179518504.issue35736@roundup.psfhosted.org>


New submission from Michael Kr?tlinger <michael at way2help.at>:

After operations = xmltree.getElementsByTagName("operation") the table does not contain operations antragstypenErmitteln and mammographieIndikationenErmitteln

----------
files: EbsService.wsdl
messages: 333621
nosy: MiKr41
priority: normal
severity: normal
status: open
title: Missing component in table after getElementsByTagName("nn")
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48048/EbsService.wsdl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________

From report at bugs.python.org  Mon Jan 14 08:59:12 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 14 Jan 2019 13:59:12 +0000
Subject: [issue35723] Add "time zone index" cache to datetime objects
In-Reply-To: <1547238857.17.0.663234077571.issue35723@roundup.psfhosted.org>
Message-ID: <1547474352.69.0.609321290594.issue35723@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> I dislike adding a public API for an optimization. Would it be possible to make it private? Would it make sense? tzidx => _tzidx.

This also would have been my preference, but it is unfortunately not possible because of the way tzinfo works. tzinfo is an abstract base class, which means that any changes to how `tzinfo` subclasses work *must* be implemented by the third party time zone providers. The tzidx() method is intended to be called *only* from `tzinfo` an optional feature, as such it must be public.

Maybe a better option would be to make it a magic method, to indicate that it is public but not intended to be called directly by users? `__tzidx__` or `__tzcache__`?


> In test of your PR, tzinfo allocates memory for its cache: 

>            offsets = [timedelta(hours=0), timedelta(hours=1)]
>            names = ['+00:00', '+01:00']
>            dsts = [timedelta(hours=0), timedelta(hours=1)]

>This memory isn't free. I don't see how using an index completely prevents the need to allocate memory for a cache.

That part is not free, but that's also not a cache, it's the underlying data for the tzinfo and is not modified over the object's lifetime. Most `tzinfo` subclasses are *already* implemented like this in one way or another, for example `dateutil.tz.tzfile` reads one of the binary tzdata files and produces a list of `ttinfo` objects, then looks up which one applies for each datetime.

The cache part of this is that *that lookup* is expensive, but also super easy to cache. In pytz this cache comes for free, because instead of using a list of offsets and figuring out which one to apply when you call `utcoffset()`, pytz creates a list of `tzinfo` objects with *fixed* offsets and eagerly attaches one to a datetime when you call `pytz.timezone.localize()/normalize()`. It's using the `tzinfo` field as a cache, but at the cost of breaking time zone semantics (which unfortunately use `is` to determine whether two datetimes are in the same zone or not), plus the cost of requiring *eager* resolution to this question rather than lazy.

> Somehow, we need a method to clear the cache and decide a caching policy. The simplest policy is to have no limit. The re.compile() uses a cache of 512 entries. functools.lru_cache uses a default limit of 128 entries.

This is not necessary, actually, because of the way this cache works. This is a "write-once" cache *stored on the datetime itself*, and its cost is built in to the memory cost of the datetime itself. For CPython it will currently consume one of the alignment bytes, so there will be no additional memory use.

> Instead of adding a new API, would it be possible to reuse functools.lru_cache somehow?

If it were possible to use an LRU cache in this situation, it would not be necessary to make a change in CPython at all. The problem with LRU cache or any other cache implemented as a mapping between datetime -> offset are as I mentioned, large memory use and the performance cost of creating an appropriate hash would greatly reduce the utility of this function. The proposed tzidx lets tzinfo implementers opt in to nearly all the advantages of pytz without any of the disadvantages.

>> 2. Because the implementation of datetime.__hash__ invokes utcoffset(), it is impossible to implement utcoffset in terms of a dictionary of tz-aware datetimes. This means that you need to construct a new, naive datetime, which is a fairly slow operation and really puts a damper in the utility of the cache.

> For special local timezones, would it be possible to explicitly exclude them, and restrict the cache the simple timespace (fixed offset)?

I think there are many problems with this approach, but I'm going to hold off on answering this, because I think even if this were possible, an on-datetime cache makes much more sense than a mapping-based cache. If you still want this addressed given my other arguments let me know and I can give you a more thorough response.

Thank you for taking the time to review my proposal, Victor. I realize that it is a bit of a wall of text accompanying a pretty big PR, which is kinda the result of the fact that I had this idea 6+ months ago and I've been privately reworking and refining it (both in a code sandbox and in my head) for some time now, only to dump out the results of all my internal arguments all at once. I appreciate the feedback and I'm happy to do whatever possible to clarify my reasoning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35723>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:04:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 14:04:23 +0000
Subject: [issue35736] Missing component in table after
 getElementsByTagName("nn")
In-Reply-To: <1547472488.22.0.593179518504.issue35736@roundup.psfhosted.org>
Message-ID: <1547474663.29.0.909592562406.issue35736@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Please post a minimal code snippet with what you are expecting and the actual output of the program explaining the problem and how it's a bug in Python and not the actual code's logic.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:09:39 2019
From: report at bugs.python.org (Niklas Fiekas)
Date: Mon, 14 Jan 2019 14:09:39 +0000
Subject: [issue35721] _UnixSubprocessTransport leaks socket pair if Popen fails
In-Reply-To: <1547234691.74.0.652164571217.issue35721@roundup.psfhosted.org>
Message-ID: <1547474979.87.0.471488826675.issue35721@roundup.psfhosted.org>


Change by Niklas Fiekas <niklas.fiekas at backscattering.de>:


----------
keywords: +patch
pull_requests: +11184
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35721>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:09:47 2019
From: report at bugs.python.org (Niklas Fiekas)
Date: Mon, 14 Jan 2019 14:09:47 +0000
Subject: [issue35721] _UnixSubprocessTransport leaks socket pair if Popen fails
In-Reply-To: <1547234691.74.0.652164571217.issue35721@roundup.psfhosted.org>
Message-ID: <1547474987.68.0.735436179263.issue35721@roundup.psfhosted.org>


Change by Niklas Fiekas <niklas.fiekas at backscattering.de>:


----------
keywords: +patch, patch
pull_requests: +11184, 11185
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35721>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:09:55 2019
From: report at bugs.python.org (Niklas Fiekas)
Date: Mon, 14 Jan 2019 14:09:55 +0000
Subject: [issue35721] _UnixSubprocessTransport leaks socket pair if Popen fails
In-Reply-To: <1547234691.74.0.652164571217.issue35721@roundup.psfhosted.org>
Message-ID: <1547474995.38.0.160355441239.issue35721@roundup.psfhosted.org>


Change by Niklas Fiekas <niklas.fiekas at backscattering.de>:


----------
keywords: +patch, patch, patch
pull_requests: +11184, 11185, 11186
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35721>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:10:26 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 14:10:26 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547475026.4.0.0672165999253.issue35674@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11187

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:10:34 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 14:10:34 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547475034.54.0.0212256904824.issue35674@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11187, 11188

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:10:42 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 14 Jan 2019 14:10:42 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547475042.41.0.487977689215.issue35674@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11187, 11188, 11189

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:49:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 14:49:19 +0000
Subject: [issue35736] Missing component in table after
 getElementsByTagName("nn")
In-Reply-To: <1547472488.22.0.593179518504.issue35736@roundup.psfhosted.org>
Message-ID: <1547477359.0.0.606068737968.issue35736@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
Removed message: https://bugs.python.org/msg333624

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:51:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 14:51:17 +0000
Subject: [issue35736] Missing component in table after
 getElementsByTagName("nn")
In-Reply-To: <1547472488.22.0.593179518504.issue35736@roundup.psfhosted.org>
Message-ID: <1547477477.69.0.376308056437.issue35736@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please do not post a large amount of text as a message. This would make communication harder.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________

From report at bugs.python.org  Mon Jan 14 10:10:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 15:10:49 +0000
Subject: [issue35736] Missing component in table after
 getElementsByTagName("nn")
In-Reply-To: <1547472488.22.0.593179518504.issue35736@roundup.psfhosted.org>
Message-ID: <1547478649.78.0.917871291518.issue35736@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems you have added a reply with the program at https://bugs.python.org/file48049/unnamed but it's filled with escaped HTML I hope. I assume you have a problem that there are 34 items with 'operation name' under grep and in the program it causes IndexError on 30th item.

# Download the file

?  backups $ wget https://bugs.python.org/file48048/EbsService.wsdl

# Sample program 

?  backups $ cat bpo35736.py
from xml.dom import minidom
xmldoc = minidom.parse('EbsService.wsdl')
operations = xmldoc.getElementsByTagName("operation")

for s in operations:
    print(s.attributes['name'].value)

# The text reported in the original report
?  backups $ python3.7 bpo35736.py | grep mammographieIndikationenErmitteln
mammographieIndikationenErmitteln
mammographieIndikationenErmitteln

# Run the program and there are 34 items
?  backups $ python3.7 bpo35736.py | wc -l
      34
?  backups $ grep 'operation name' EbsService.wsdl | wc -l
      34


Please try attaching the program as a message or file complete with imports so that I can run on my computer. From my initial program above this doesn't seem to be a bug with xml.etree and more of a logic problem with the code.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________

From report at bugs.python.org  Mon Jan 14 10:30:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Jan 2019 15:30:04 +0000
Subject: [issue24780] unittest assertEqual difference output foiled by newlines
In-Reply-To: <1438534169.3.0.814109265012.issue24780@psf.upfronthosting.co.za>
Message-ID: <1547479804.4.0.431442159174.issue24780@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, I just stumbled upon issue2142 which is a similar report for unique_diff producing wrong output due to missing trailing newlines and could have been the original reason where the title was changed. But since there is a PR now towards adding a newline I think it's good to fix this on unittest side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24780>
_______________________________________

From report at bugs.python.org  Mon Jan 14 10:52:25 2019
From: report at bugs.python.org (Brett R)
Date: Mon, 14 Jan 2019 15:52:25 +0000
Subject: [issue35737] crypt AuthenticationError introduced with new Linux
 kernel
Message-ID: <1547481144.26.0.447593759473.issue35737@roundup.psfhosted.org>


New submission from Brett R <brett at cazena.com>:

We are seeing a crash apparently in crypt.py when invoked via SaltStack and have narrowed it down to some change in the Linux kernel introduced by this security update: https://access.redhat.com/errata/RHSA-2018:3083

Linux kernel 3.10.0-862.14.4.el7.x86_64 works fine
Linux kernel 3.10.0-957.el7.x86_64 and later show this error:

2018-11-28T16:35:13.302740+00:00 ip-10-128-152-49 cloud-init: [INFO    ] Executing state cmd.script for [setup-secondary-ips]
2018-11-28T16:35:13.494523+00:00 ip-10-128-152-49 cloud-init: [ERROR   ] An exception occurred in this state: Traceback (most recent call last):
2018-11-28T16:35:13.497189+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/state.py", line 1889, in call
2018-11-28T16:35:13.500053+00:00 ip-10-128-152-49 cloud-init: **cdata['kwargs'])
2018-11-28T16:35:13.502780+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/loader.py", line 1839, in wrapper
2018-11-28T16:35:13.505822+00:00 ip-10-128-152-49 cloud-init: return f(*args, **kwargs)
2018-11-28T16:35:13.508537+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/states/cmd.py", line 1118, in script
2018-11-28T16:35:13.511297+00:00 ip-10-128-152-49 cloud-init: cmd_all = __salt__['cmd.script'](source, python_shell=True, **cmd_kwargs)
2018-11-28T16:35:13.514308+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/modules/cmdmod.py", line 2114, in script
2018-11-28T16:35:13.517107+00:00 ip-10-128-152-49 cloud-init: fn_ = __salt__['cp.cache_file'](source, saltenv)
2018-11-28T16:35:13.520171+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/modules/cp.py", line 474, in cache_file
2018-11-28T16:35:13.523112+00:00 ip-10-128-152-49 cloud-init: result = _client().cache_file(path, saltenv)
2018-11-28T16:35:13.526199+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/fileclient.py", line 188, in cache_file
2018-11-28T16:35:13.529055+00:00 ip-10-128-152-49 cloud-init: return self.get_url(path, '', True, saltenv, cachedir=cachedir)
2018-11-28T16:35:13.532046+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/fileclient.py", line 494, in get_url
2018-11-28T16:35:13.535280+00:00 ip-10-128-152-49 cloud-init: result = self.get_file(url, dest, makedirs, saltenv, cachedir=cachedir)
2018-11-28T16:35:13.538335+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/fileclient.py", line 1145, in get_file
2018-11-28T16:35:13.541621+00:00 ip-10-128-152-49 cloud-init: data = self.channel.send(load, raw=True)
2018-11-28T16:35:13.544750+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/utils/async.py", line 65, in wrap
2018-11-28T16:35:13.548071+00:00 ip-10-128-152-49 cloud-init: ret = self._block_future(ret)
2018-11-28T16:35:13.551304+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/utils/async.py", line 75, in _block_future
2018-11-28T16:35:13.554546+00:00 ip-10-128-152-49 cloud-init: return future.result()
2018-11-28T16:35:13.557950+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 214, in result
2018-11-28T16:35:13.561205+00:00 ip-10-128-152-49 cloud-init: raise_exc_info(self._exc_info)
2018-11-28T16:35:13.564478+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 876, in run
2018-11-28T16:35:13.568139+00:00 ip-10-128-152-49 cloud-init: yielded = self.gen.throw(*exc_info)
2018-11-28T16:35:13.571683+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/transport/zeromq.py", line 312, in send
2018-11-28T16:35:13.575103+00:00 ip-10-128-152-49 cloud-init: ret = yield self._crypted_transfer(load, tries=tries, timeout=timeout, raw=raw)
2018-11-28T16:35:13.578736+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 870, in run
2018-11-28T16:35:13.582255+00:00 ip-10-128-152-49 cloud-init: value = future.result()
2018-11-28T16:35:13.585869+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 214, in result
2018-11-28T16:35:13.589636+00:00 ip-10-128-152-49 cloud-init: raise_exc_info(self._exc_info)
2018-11-28T16:35:13.593537+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 876, in run
2018-11-28T16:35:13.597250+00:00 ip-10-128-152-49 cloud-init: yielded = self.gen.throw(*exc_info)
2018-11-28T16:35:13.604695+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/transport/zeromq.py", line 284, in _crypted_transfer
2018-11-28T16:35:13.608535+00:00 ip-10-128-152-49 cloud-init: ret = yield _do_transfer()
2018-11-28T16:35:13.612022+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 870, in run
2018-11-28T16:35:13.615530+00:00 ip-10-128-152-49 cloud-init: value = future.result()
2018-11-28T16:35:13.619175+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/concurrent.py", line 214, in result
2018-11-28T16:35:13.622702+00:00 ip-10-128-152-49 cloud-init: raise_exc_info(self._exc_info)
2018-11-28T16:35:13.626336+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib64/python2.7/site-packages/tornado/gen.py", line 879, in run
2018-11-28T16:35:13.629839+00:00 ip-10-128-152-49 cloud-init: yielded = self.gen.send(value)
2018-11-28T16:35:13.633372+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/transport/zeromq.py", line 271, in _do_transfer
2018-11-28T16:35:13.636931+00:00 ip-10-128-152-49 cloud-init: data = self.auth.crypticle.loads(data, raw)
2018-11-28T16:35:13.640794+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/crypt.py", line 1316, in loads
2018-11-28T16:35:13.644318+00:00 ip-10-128-152-49 cloud-init: data = self.decrypt(data)
2018-11-28T16:35:13.647997+00:00 ip-10-128-152-49 cloud-init: File "/usr/lib/python2.7/site-packages/salt/crypt.py", line 1296, in decrypt
2018-11-28T16:35:13.651578+00:00 ip-10-128-152-49 cloud-init: raise AuthenticationError('message authentication failed')
2018-11-28T16:35:13.655231+00:00 ip-10-128-152-49 cloud-init: AuthenticationError: message authentication failed
2018-11-28T16:35:13.658805+00:00 ip-10-128-152-49 cloud-init: [INFO    ] Completed state [setup-secondary-ips] at time 16:35:13.491356 duration_in_ms=196.894


This is very reproducible and we originally reported it here: https://github.com/saltstack/salt/issues/50673 but it does not appear to be related to SaltStack so I am trying this as the next place to file. 

Please advise what additional info may be needed.

----------
messages: 333628
nosy: icycle
priority: normal
severity: normal
status: open
title: crypt AuthenticationError introduced with new Linux kernel
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35737>
_______________________________________

From report at bugs.python.org  Mon Jan 14 11:32:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 16:32:45 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547483565.86.0.193119190293.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11190

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Mon Jan 14 11:32:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 16:32:57 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547483577.72.0.00797599355765.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11190, 11191

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Mon Jan 14 11:33:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 16:33:08 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547483588.39.0.557060093427.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11190, 11191, 11192

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Mon Jan 14 11:50:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 16:50:54 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547484654.09.0.0805034441558.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> https://wiki.musl-libc.org/faq.html

"""
Q: Why is there no __MUSL__ macro?

It?s a bug to assume a certain implementation has particular properties rather than testing. So far, every time somebody?s asked for this with a particular usage case in mind, the usage case was badly wrong, and would have broken support for the next release of musl. The official explanation: http://openwall.com/lists/musl/2013/03/29/13
"""

IMHO that's wrong. A software like Python heavily rely on the *exact* implementation of a libc.

https://github.com/python/cpython/pull/9224/files looks like a coarse heuristic to detect musl for example.

Until muscl decides to provide an "#ifdef __MUSL__"-like or any way that it's musl, I propose to not support musl: don't use os.posix_spawn() but _posixsubprocess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:06:45 2019
From: report at bugs.python.org (David Heiberg)
Date: Mon, 14 Jan 2019 18:06:45 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547489205.63.0.579487467724.issue35701@roundup.psfhosted.org>


David Heiberg <dhdavvie at gmail.com> added the comment:

Since there has been no objection to this yet, would it be alright for me to take this as my first PR? 

On top of the change you mentioned to the __slots__ list, should there also be a test written so that a similar regression doesn't happen again?

----------
nosy: +dheiberg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:10:48 2019
From: report at bugs.python.org (Tal Einat)
Date: Mon, 14 Jan 2019 18:10:48 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547489205.63.0.579487467724.issue35701@roundup.psfhosted.org>
Message-ID: <CALWZvp5p6j4ZJjDDKcfGAHmpOctRBF15KbVQUbWP7AUGdNXBsw@mail.gmail.com>


Tal Einat <taleinat at gmail.com> added the comment:

Indeed, a PR for this should include a test that weakrefs work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:12:08 2019
From: report at bugs.python.org (wouter bolsterlee)
Date: Mon, 14 Jan 2019 18:12:08 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547489528.3.0.881948224684.issue35701@roundup.psfhosted.org>


wouter bolsterlee <uws at xs4all.nl> added the comment:

the test could be sth like

x = uuid.uuid4()
y = weakref.ref(x)
assert x is y()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:17:03 2019
From: report at bugs.python.org (David Heiberg)
Date: Mon, 14 Jan 2019 18:17:03 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547489823.7.0.426642135439.issue35701@roundup.psfhosted.org>


David Heiberg <dhdavvie at gmail.com> added the comment:

Ok thanks for your input, I will work on a PR and hopefully submit one tomorrow or Wednesday depending on schedule.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:38:07 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 14 Jan 2019 18:38:07 +0000
Subject: [issue35735] Current "make test" status for AIX
In-Reply-To: <1547450742.92.0.354703288853.issue35735@roundup.psfhosted.org>
Message-ID: <1547491087.7.0.833407313718.issue35735@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Well, I can close this again - whatever was wrong with test_xml_etree_c disappeared - and a cursory look at test_os reveals that the issue might be the time lag between the NFS server where the temp files are made and the "local" sense of time.

Most of the time I do not have an issue, so closing as false positives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35735>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:38:17 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 14 Jan 2019 18:38:17 +0000
Subject: [issue35735] Current "make test" status for AIX
In-Reply-To: <1547450742.92.0.354703288853.issue35735@roundup.psfhosted.org>
Message-ID: <1547491097.48.0.711920406821.issue35735@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35735>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:45:07 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Mon, 14 Jan 2019 18:45:07 +0000
Subject: [issue31658] xml.sax.parse won't accept path objects
In-Reply-To: <1506891071.57.0.213398074469.issue31658@psf.upfronthosting.co.za>
Message-ID: <1547491507.58.0.276428575545.issue31658@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31658>
_______________________________________

From report at bugs.python.org  Mon Jan 14 13:56:02 2019
From: report at bugs.python.org (Jayanth Raman)
Date: Mon, 14 Jan 2019 18:56:02 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 three
Message-ID: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>


New submission from Jayanth Raman <raman.jayanth at gmail.com>:

In the Examples section of the timeit documentation, repeat() returns a list of size three.  But the default is now five and the documentation should reflect that.
Thanks.

----------
assignee: docs at python
components: Documentation
messages: 333635
nosy: docs at python, jayanth
priority: normal
severity: normal
status: open
title: Update timeit documentation to reflect default repeat of three
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Mon Jan 14 14:07:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 14 Jan 2019 19:07:42 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547492862.26.0.137028757027.issue35732@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Doc: warnings.rst - add links to references

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 14:08:34 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 14 Jan 2019 19:08:34 +0000
Subject: [issue35732] Typo in library/warnings documentation
In-Reply-To: <1547421481.41.0.571803871053.issue35732@roundup.psfhosted.org>
Message-ID: <1547492914.8.0.374640534981.issue35732@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Closing as a duplicate of #35563, which converts the 'see above' to links.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35732>
_______________________________________

From report at bugs.python.org  Mon Jan 14 14:12:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Jan 2019 19:12:09 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 three
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547493129.89.0.896708113555.issue35738@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Mon Jan 14 14:20:04 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 14 Jan 2019 19:20:04 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547493604.93.0.897192831353.issue33944@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I like Nick's proposal. It has I believe the features that satisfy the use-cases of which I'm currently aware... with one edge case you may not have considered - support for multiple `__sitecustomize__` locations.

Consider, for example, the case where `__sitecustomize__` is in some system space unwritable by the user, but the package being installed is being installed in `--user` space.

Or consider the case where permissions aren't at play, but where you have a package installed in a different part of the PYTHONPATH. For example, [pip-run installs a sitecustomize module](https://github.com/jaraco/pip-run/blob/6203b1aa8cb52b5c181457054cf6ddaa40361437/pip_run/launch.py#L33-L44) in a temporary directory that it adds to sys.path. Ignoring for a moment the reason why it does this, I'd like to focus on the general need - that multiple paths on PYTHONPATH might expect `__sitecustomize__` support. You wouldn't want to have all of the `__sitecustomize__` hooks in one directory, because then they'll be decoupled from components that may or may not be in PYTHONPATH.

For these reasons, I think you'd want for `__sitecustomize__` to be supported to exist in multiple locations on PYTHONPATH and honor all of the files in all such directories, somewhat similar to how namespace packages are supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 14:55:22 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Jan 2019 19:55:22 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1547456518.6.0.169335368433.issue33944@roundup.psfhosted.org>
Message-ID: <2C557906-6A18-4A90-8439-A7F328D97F4D@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 14, 2019, at 04:02, STINNER Victor <report at bugs.python.org> wrote:
> 
> I really hate .pth files because the slow down Python startup time for *all* applications whereas .pth files are usually specific to a very few applications using one or two specific modules.
> 
> They can also modify the behavior of Python for all applications, with no way to opt-out.
> 
> I would prefer to have an opt-in option, disabled by default.

I completely agree.  The other problem is that .pth-caused problems are very difficult to diagnose and debug.  Essentially you have to hack site.py to break into the loading machinery.  I have to believe that we can come up with a better mechanism that doesn?t suffer from these problems.

Do we have a single place to capture a list of .pth use cases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 14:56:34 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Jan 2019 19:56:34 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1547457243.99.0.352635334641.issue33944@roundup.psfhosted.org>
Message-ID: <B27D721D-C570-472D-BBA1-6092EF44111B@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 14, 2019, at 04:14, Antoine Pitrou <report at bugs.python.org> wrote:
> 
> As I said: editable installs (`pip install -e`) are an important use case of .pth files.

Is that true outside of virtual environments?  I care less about .pth files inside venvs, since those are typically isolated to a single development environment, and don?t affect Python applications or libraries globally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 15:02:31 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Jan 2019 20:02:31 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1547468237.36.0.344883762423.issue33944@roundup.psfhosted.org>
Message-ID: <0A18C27B-F1B4-4073-82A1-E35DB2B654C7@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 14, 2019, at 07:17, Nick Coghlan <report at bugs.python.org> wrote:
> 
> I'll also reiterate that I am *completely* opposed to deprecating the "append entries to sys.path" usage model, as there is absolutely nothing wrong with that (if distros are ending up with an overly cluttered system that's making the standard path too long, then review the individual packages creating the clutter, don't remove the interpreter feature).

Yes, there is as Victor and others points out.  They do magical things that are difficult to debug and diagnose, and have global effects on the entire Python operating environment.

I?d be less opposed to a mechanism that is isolated to just those Python applications that need them.  I?d like to know about use cases outside of Python applications that can?t be done any other way.

> That "append to sys.path" aspect of the feature is all that's needed to make editable installs and virtual environment chaining work.
> 
> That means the aspect I'm in agreement with deprecating is the "arbitrary code execution on startup" case, but even for that, I don't think we should deprecate it until we have a comparable replacement that's more self-evidently a way of allowing arbitrary code execution, and also more obviously has the potential to make every interpreter startup in that Python installation slower.

I think we?re all in agreement about deprecating arbitrary code execution, so maybe this issue can concentrate on that, while we figure out what, if anything to do about the path extension use case.

I don?t care about slow start up of the interactive interpreter, but I do strongly care about the start up times for Python applications in general.  That?s why an opt-in mechanism is important.

> 1. In site.addsitedir, check for a __sitecustomize__ subdirectory after checking for .pth files
> 2. If any Python files are found in that directory, execute them
> 3. If "python -x importtime" has been specified, report the execution time of each of those files (this would allow both easy identification of any hooks that are being executed, as well as which ones are taking up a lot of time)
> 
> There could then be a "-Z" option that offered a more limited form of "-S": it would allow site.py itself to run, but disable the processing of `sitecustomize.py` and `__sitecustomize__` entries.

Is that a global __sitecustomize__ directory you?re talking about, or something specific to a Python application (or library?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 15:41:16 2019
From: report at bugs.python.org (Ori Avtalion)
Date: Mon, 14 Jan 2019 20:41:16 +0000
Subject: [issue32496] lib2to3 fails to parse a ** of a conditional expression
In-Reply-To: <1515108489.44.0.467229070634.issue32496@psf.upfronthosting.co.za>
Message-ID: <1547498476.14.0.0349556339918.issue32496@roundup.psfhosted.org>


Ori Avtalion <ori at avtalion.name> added the comment:

This can be circumvented by adding parenthesis:

  dummy(**(kwargs if kwargs else dict()))

----------
nosy: +salty-horse

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32496>
_______________________________________

From report at bugs.python.org  Mon Jan 14 16:04:47 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Jan 2019 21:04:47 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547499887.71.0.681595139975.issue33944@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is that true outside of virtual environments?

Not in my experience.  But I'm not sure special-casing virtual environments will make the situation easier to understand ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 16:35:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jan 2019 21:35:21 +0000
Subject: [issue28657] cmd.Cmd.get_help() implementation can't see do_*()
 methods added dynamically by setattr()
In-Reply-To: <1478776450.68.0.870801686772.issue28657@psf.upfronthosting.co.za>
Message-ID: <1547501721.62.0.0185575969114.issue28657@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Maybe the methods could all rely on `get_names` that
> return `dir(self.__class__)`,

Please read the previous posts on the subject.  The only reason to do this is if we want the module to explicitly support attaching methods directly to instances.  That practice has disadvantages (no access to self) and it is at odds with the design of the module (nothing we ever intended to explicitly support) and it is outside of usual Python norms (methods attached to classes).  AFAICT, the OP's need could be met using traditional (and supported) techniques such as class composition.  Accordingly, there isn't any need to go down this more unusual path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28657>
_______________________________________

From report at bugs.python.org  Mon Jan 14 17:30:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Jan 2019 22:30:17 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1547499887.71.0.681595139975.issue33944@roundup.psfhosted.org>
Message-ID: <CA+3bQGHaHxdrJE4vyQJvt57eNb2uSR8D8Mt3nKEg-39d3uJRGw@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't think that you will like it, but I feel that a PEP will be needed
here to list use cases and explain what replace .pth files for each use
case. Maybe no replacement for some use cases is fine. The PEP doesn't have
to be long.

I also expect that it's going to be a large backward incompatible change. A
PEP can summerize the rationale, schedule deprecation, etc.

Any volunteer around? Barry, Nick, someone else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 17:42:18 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 14 Jan 2019 22:42:18 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <CA+3bQGHaHxdrJE4vyQJvt57eNb2uSR8D8Mt3nKEg-39d3uJRGw@mail.gmail.com>
Message-ID: <26D38932-E046-477D-8626-DB9C03A528AE@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 14, 2019, at 17:30, STINNER Victor <report at bugs.python.org> wrote:
> 
> I don't think that you will like it, but I feel that a PEP will be needed
> here to list use cases and explain what replace .pth files for each use
> case. Maybe no replacement for some use cases is fine. The PEP doesn't have
> to be long.
> 
> I also expect that it's going to be a large backward incompatible change. A
> PEP can summerize the rationale, schedule deprecation, etc.

+1

> Any volunteer around? Barry, Nick, someone else?

I will volunteer to co-author.  I would definitely like at least Nick and/or Jason to help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Mon Jan 14 17:43:02 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 14 Jan 2019 22:43:02 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547505782.91.0.0125526138831.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Until muscl decides to provide an "#ifdef __MUSL__"-like or any way that it's musl, I propose to not support musl: don't use os.posix_spawn() but _posixsubprocess.

FYI, I'm researching how to use vfork(), focusing on Linux, but I'll need more time to study the current state of affairs of libcs. Both musl and glibc don't use "pure" vfork() now because of perceived danger of miscompilation due to sharing of the stack between the parent and the child. They switched to clone(CLONE_VM|CLONE_VFORK), which is basically the same but allows the caller to provide a separate stack for the child. There are also additional subtle issues related to signal handling (and pthread cancellation in particular) which I need to study.
 
If I find vfork()-like approach feasible, I'll open a separate issue. The bonus of this approach is that it doesn't depend on a particular libc, so both glibc (including older versions) and musl could be supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Mon Jan 14 18:10:16 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 14 Jan 2019 23:10:16 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1547507416.77.0.999091346584.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Steve, thanks for explaining that.  I understand what you're saying now.  It's funny but because the context prompt has the space added at the end when it's created (`context.prompt = '(%s) ' % prompt`), I added it to the test, but completely forgot about it.  I was thinking about just getting back what was inside the parentheses without considering at all what the whole line looked like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Mon Jan 14 20:21:35 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 15 Jan 2019 01:21:35 +0000
Subject: [issue26410] "incompatible pointer type" while compiling Python3.5.1
In-Reply-To: <1456154116.48.0.737124559195.issue26410@psf.upfronthosting.co.za>
Message-ID: <1547515295.05.0.872666220022.issue26410@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26410>
_______________________________________

From report at bugs.python.org  Mon Jan 14 20:21:57 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 15 Jan 2019 01:21:57 +0000
Subject: [issue26410] "incompatible pointer type" while compiling Python3.5.1
In-Reply-To: <1456154116.48.0.737124559195.issue26410@psf.upfronthosting.co.za>
Message-ID: <1547515317.09.0.489942660597.issue26410@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
status: open -> closed
superseder:  -> Use Py_uintptr_t instead of void* for atomic pointers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26410>
_______________________________________

From report at bugs.python.org  Tue Jan 15 00:26:49 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Tue, 15 Jan 2019 05:26:49 +0000
Subject: [issue35739] Enable verbose of tests during PGO build on amd64
 platforms
Message-ID: <1547530007.74.0.355457877892.issue35739@roundup.psfhosted.org>


New submission from Jorge Ramos <neyuru at gmail.com>:

It would be interesting to allow regrtests to output to command line during testing with PGO enabled. The default behavior is to not display output unless some fatal error occurs ("quiet" mode).

Making this issue to create a pull request.

----------
components: Build, Windows
messages: 333648
nosy: neyuru, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Enable verbose of tests during PGO build on amd64 platforms
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35739>
_______________________________________

From report at bugs.python.org  Tue Jan 15 00:33:57 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Tue, 15 Jan 2019 05:33:57 +0000
Subject: [issue35739] Enable verbose of tests during PGO build on amd64
 platforms
In-Reply-To: <1547530007.74.0.355457877892.issue35739@roundup.psfhosted.org>
Message-ID: <1547530437.76.0.698919014007.issue35739@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
keywords: +patch
pull_requests: +11193
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35739>
_______________________________________

From report at bugs.python.org  Tue Jan 15 00:34:07 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Tue, 15 Jan 2019 05:34:07 +0000
Subject: [issue35739] Enable verbose of tests during PGO build on amd64
 platforms
In-Reply-To: <1547530007.74.0.355457877892.issue35739@roundup.psfhosted.org>
Message-ID: <1547530447.28.0.505999443312.issue35739@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11193, 11194
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35739>
_______________________________________

From report at bugs.python.org  Tue Jan 15 00:34:18 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Tue, 15 Jan 2019 05:34:18 +0000
Subject: [issue35739] Enable verbose of tests during PGO build on amd64
 platforms
In-Reply-To: <1547530007.74.0.355457877892.issue35739@roundup.psfhosted.org>
Message-ID: <1547530458.16.0.784870629213.issue35739@roundup.psfhosted.org>


Change by Jorge Ramos <neyuru at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11193, 11194, 11195
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35739>
_______________________________________

From report at bugs.python.org  Tue Jan 15 01:18:22 2019
From: report at bugs.python.org (Henry Chen)
Date: Tue, 15 Jan 2019 06:18:22 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 three
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547533102.6.0.135749520634.issue35738@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


----------
keywords: +patch
pull_requests: +11196
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 01:18:28 2019
From: report at bugs.python.org (Henry Chen)
Date: Tue, 15 Jan 2019 06:18:28 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 three
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547533108.8.0.783352576514.issue35738@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11196, 11197
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 01:18:35 2019
From: report at bugs.python.org (Henry Chen)
Date: Tue, 15 Jan 2019 06:18:35 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 three
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547533115.65.0.2961748925.issue35738@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11196, 11197, 11198
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 01:23:15 2019
From: report at bugs.python.org (Henry Chen)
Date: Tue, 15 Jan 2019 06:23:15 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 five
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547533395.43.0.809446951809.issue35738@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


----------
title: Update timeit documentation to reflect default repeat of three -> Update timeit documentation to reflect default repeat of five

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 02:41:20 2019
From: report at bugs.python.org (ossdev)
Date: Tue, 15 Jan 2019 07:41:20 +0000
Subject: [issue35740] ssl version 1.1.1 need to be there in
 cpython-source-deps for windows ARM64
Message-ID: <1547538078.35.0.434984866585.issue35740@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
assignee: christian.heimes
components: SSL
nosy: christian.heimes, ossdev07
priority: normal
severity: normal
status: open
title: ssl version 1.1.1 need to be there in cpython-source-deps for windows ARM64
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35740>
_______________________________________

From report at bugs.python.org  Tue Jan 15 02:41:43 2019
From: report at bugs.python.org (ossdev)
Date: Tue, 15 Jan 2019 07:41:43 +0000
Subject: [issue35740] openssl version 1.1.1 need to be there in
 cpython-source-deps for windows ARM64
Message-ID: <1547538103.66.0.363812378649.issue35740@roundup.psfhosted.org>


Change by ossdev <ossdev at puresoftware.com>:


----------
title: ssl version 1.1.1 need to be there in cpython-source-deps for windows ARM64 -> openssl version 1.1.1 need to be there in cpython-source-deps for windows ARM64

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35740>
_______________________________________

From report at bugs.python.org  Tue Jan 15 02:45:24 2019
From: report at bugs.python.org (ossdev)
Date: Tue, 15 Jan 2019 07:45:24 +0000
Subject: [issue35740] openssl version 1.1.1 need to be there in
 cpython-source-deps for windows ARM64
Message-ID: <1547538324.61.0.844550645044.issue35740@roundup.psfhosted.org>


New submission from ossdev <ossdev at puresoftware.com>:

as per in https://github.com/openssl/openssl/issues/6856 , for windows on ARM64 we need to switch to Openssl 1.1.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35740>
_______________________________________

From report at bugs.python.org  Tue Jan 15 02:49:11 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 07:49:11 +0000
Subject: [issue35740] openssl version 1.1.1 need to be there in
 cpython-source-deps for windows ARM64
In-Reply-To: <1547538324.61.0.844550645044.issue35740@roundup.psfhosted.org>
Message-ID: <1547538551.88.0.910389645559.issue35740@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

3.7 uses OpenSSL 1.1.0. OpenSSL 1.1.1 adds TLS 1.3 and behaves differently than 1.1.0. We cannot update 3.7 to 1.1.1 because it would break backwards compatibility. For 3.8, we can move to 1.1.1.

You either have to compile your own Python and OpenSSL 1.1.1 on Windows, convince OpenSSL upstream to fix 1.1.0, or wait until 3.8 comes out by the end of the year.

----------
assignee: christian.heimes -> 
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35740>
_______________________________________

From report at bugs.python.org  Tue Jan 15 03:53:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 08:53:21 +0000
Subject: [issue35619] Support custom data descriptors in pydoc
In-Reply-To: <1546192124.51.0.0883005560054.issue35619@roundup.psfhosted.org>
Message-ID: <1547542401.81.0.0062706593401.issue35619@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset efcf82f94572abcdbd70336e0b2c3d0f4df280bc by Serhiy Storchaka in branch 'master':
bpo-35619: Improve support of custom data descriptors in help() and pydoc. (GH-11366)
https://github.com/python/cpython/commit/efcf82f94572abcdbd70336e0b2c3d0f4df280bc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35619>
_______________________________________

From report at bugs.python.org  Tue Jan 15 03:55:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 08:55:45 +0000
Subject: [issue29707] os.path.ismount() always returns false for mount --bind
 on same filesystem
In-Reply-To: <1488524974.65.0.103028894103.issue29707@psf.upfronthosting.co.za>
Message-ID: <1547542545.28.0.852668111437.issue29707@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 32ebd8508d4807a7c85d2ed8e9c3b44ecd6de591 by Serhiy Storchaka in branch 'master':
bpo-29707: Document that os.path.ismount() is not able to reliable detect bind mounts. (GH-11238)
https://github.com/python/cpython/commit/32ebd8508d4807a7c85d2ed8e9c3b44ecd6de591


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29707>
_______________________________________

From report at bugs.python.org  Tue Jan 15 03:56:04 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 08:56:04 +0000
Subject: [issue29707] os.path.ismount() always returns false for mount --bind
 on same filesystem
In-Reply-To: <1488524974.65.0.103028894103.issue29707@psf.upfronthosting.co.za>
Message-ID: <1547542564.49.0.093157190193.issue29707@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11199

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29707>
_______________________________________

From report at bugs.python.org  Tue Jan 15 03:56:13 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 08:56:13 +0000
Subject: [issue29707] os.path.ismount() always returns false for mount --bind
 on same filesystem
In-Reply-To: <1488524974.65.0.103028894103.issue29707@psf.upfronthosting.co.za>
Message-ID: <1547542573.89.0.416232089609.issue29707@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11199, 11200

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29707>
_______________________________________

From report at bugs.python.org  Tue Jan 15 03:56:21 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 08:56:21 +0000
Subject: [issue29707] os.path.ismount() always returns false for mount --bind
 on same filesystem
In-Reply-To: <1488524974.65.0.103028894103.issue29707@psf.upfronthosting.co.za>
Message-ID: <1547542581.22.0.780033778252.issue29707@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11199, 11200, 11201

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29707>
_______________________________________

From report at bugs.python.org  Tue Jan 15 03:59:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 08:59:54 +0000
Subject: [issue35619] Support custom data descriptors in pydoc
In-Reply-To: <1546192124.51.0.0883005560054.issue35619@roundup.psfhosted.org>
Message-ID: <1547542794.09.0.770191241564.issue35619@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35619>
_______________________________________

From report at bugs.python.org  Tue Jan 15 04:01:18 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 09:01:18 +0000
Subject: [issue29707] os.path.ismount() always returns false for mount --bind
 on same filesystem
In-Reply-To: <1488524974.65.0.103028894103.issue29707@psf.upfronthosting.co.za>
Message-ID: <1547542878.44.0.229938224964.issue29707@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a4aade2cf82dfa889c2bdad9fa0aa874f43c0bf8 by Miss Islington (bot) in branch '3.7':
bpo-29707: Document that os.path.ismount() is not able to reliable detect bind mounts. (GH-11238)
https://github.com/python/cpython/commit/a4aade2cf82dfa889c2bdad9fa0aa874f43c0bf8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29707>
_______________________________________

From report at bugs.python.org  Tue Jan 15 04:15:49 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 15 Jan 2019 09:15:49 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1547543749.78.0.748556025774.issue32146@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Tue Jan 15 04:32:08 2019
From: report at bugs.python.org (jianxu3)
Date: Tue, 15 Jan 2019 09:32:08 +0000
Subject: [issue35741] unittest.skipUnless(time._STRUCT_TM_ITEMS == 11,
 "needs tm_zone support") doesn't work
Message-ID: <1547544727.75.0.967204925198.issue35741@roundup.psfhosted.org>


New submission from jianxu3 <sunshone0711 at 163.com>:

Whether or not the HAVE_STRUCT_TM_TM_ZONE is defined, _STRUCT_TM_ITEMS always equal to 11. It is initialized at PyInit_time(void).
PyModule_AddIntConstant(m, "_STRUCT_TM_ITEMS", 11);

If I modify it like this:
#ifdef HAVE_STRUCT_TM_TM_ZONE
PyModule_AddIntConstant(m, "_STRUCT_TM_ITEMS", 11)
#else
PyModule_AddIntConstant(m, "_STRUCT_TM_ITEMS", 9)
#endif

Then test_fields at test_structseq.py will fail.

def test_fields(self):
self.assertEqual(t.n_fields, time._STRUCT_TM_ITEMS)

What I hope is that if HAVE_STRUCT_TM_TM_ZONE is not defined, test_localtime_timezone will be skipped.

----------
components: Tests
messages: 333654
nosy: jianxu3
priority: normal
severity: normal
status: open
title: unittest.skipUnless(time._STRUCT_TM_ITEMS == 11, "needs tm_zone support") doesn't work
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35741>
_______________________________________

From report at bugs.python.org  Tue Jan 15 04:43:59 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 15 Jan 2019 09:43:59 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
Message-ID: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>


New submission from Chih-Hsuan Yen <yen at chyen.cc>:

On git-master (32ebd8508d4807a7c85d2ed8e9c3b44ecd6de591) of CPython, 3 tests of test_builtin fails:

======================================================================
ERROR: test_envar_unimportable (test.test_builtin.TestBreakpoint) (envar='.')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/yen/Projects/cpython/Lib/test/test_builtin.py", line 1618, in test_envar_unimportable
    breakpoint()
ValueError: Empty module name

======================================================================
ERROR: test_envar_unimportable (test.test_builtin.TestBreakpoint) (envar='.foo')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/yen/Projects/cpython/Lib/test/test_builtin.py", line 1618, in test_envar_unimportable
    breakpoint()
ValueError: Empty module name

======================================================================
ERROR: test_envar_unimportable (test.test_builtin.TestBreakpoint) (envar='.int')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/yen/Projects/cpython/Lib/test/test_builtin.py", line 1618, in test_envar_unimportable
    breakpoint()
ValueError: Empty module name

----------------------------------------------------------------------

If I revert 6fe9c446f8302553952f63fc6d96be4dfa48ceba, tests pass. This commit is from issue34756, so I add the author of that patch to the nosy list.

Environment: Arch Linux x86_64

Steps to reproduce:
$ ./configure
$ make
$ ./python -m test -v test_builtin

----------
components: Tests
messages: 333655
nosy: serhiy.storchaka, yan12125
priority: normal
severity: normal
status: open
title: test_builtin fails after merging the fix for bpo-34756
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 04:54:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 09:54:16 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547546056.74.0.489361032021.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> FYI, I'm researching how to use vfork(), focusing on Linux, but I'll need more time to study the current state of affairs of libcs.

Using os.posix_spawn() in pure Python is a first step forward :-)


> (...) There are also additional subtle issues related to signal handling (and pthread cancellation in particular) which I need to study.

That's why vfork was an opt-in option in the first glibc implementation, whereas glibc is now able to detect when using vfork is safe or not.


> If I find vfork()-like approach feasible, I'll open a separate issue. The bonus of this approach is that it doesn't depend on a particular libc, so both glibc (including older versions) and musl could be supported.

I like it, but it seems to be *very* tricky to implement!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:04:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:04:06 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547546646.93.0.99566067649.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

If someone wants to implement a runtime check for musl, here is an heuristic based on ldd output and libc filenames:

https://github.com/lovell/detect-libc/blob/master/lib/detect-libc.js

var GLIBC = 'glibc';
var MUSL = 'musl';

    // Try ldd
    var ldd = spawnSync('ldd', ['--version'], spawnOptions);
    if (ldd.status === 0 && ldd.stdout.indexOf(MUSL) !== -1) {
      family = MUSL;
      version = versionFromMuslLdd(ldd.stdout);
      method = 'ldd';
    } else if (ldd.status === 1 && ldd.stderr.indexOf(MUSL) !== -1) {
      family = MUSL;
      version = versionFromMuslLdd(ldd.stderr);
      method = 'ldd';
    } else {
      // Try filesystem (family only)
      var lib = safeReaddirSync('/lib');
      if (lib.some(contains('-linux-gnu'))) {
        family = GLIBC;
        method = 'filesystem';
      } else if (lib.some(contains('libc.musl-'))) {
        family = MUSL;
        method = 'filesystem';
      } else if (lib.some(contains('ld-musl-'))) {
        family = MUSL;
        method = 'filesystem';
      } else {
        var usrSbin = safeReaddirSync('/usr/sbin');
        if (usrSbin.some(contains('glibc'))) {
          family = GLIBC;
          method = 'filesystem';
        }
      }
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:07:38 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 15 Jan 2019 10:07:38 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546872413.86.0.767569575645.issue35633@roundup.psfhosted.org>
Message-ID: <7c146aed-9571-c825-4004-04fca56c89a6@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 07/01/2019 15:46, STINNER Victor wrote:
> STINNER Victor <vstinner at redhat.com> added the comment:
>
> Since you are getting indentation error, I'm not sure about your test. Can you please apply the patch below and run again test_eintr? Does it still fail with PermissionError?
Answer - Yes. Still get PermissionError
>
> diff --git a/Lib/test/eintrdata/eintr_tester.py b/Lib/test/eintrdata/eintr_tester.py
> index 25c169bde5..4db5dc9045 100644
> --- a/Lib/test/eintrdata/eintr_tester.py
> +++ b/Lib/test/eintrdata/eintr_tester.py
> @@ -492,13 +492,13 @@ class FNTLEINTRTest(EINTRBaseTest):
>          self.addCleanup(support.unlink, support.TESTFN)
>          code = '\n'.join((
>              "import fcntl, time",
> -            "with open('%s', 'wb') as f:" % support.TESTFN,
> +            "with open('%s', 'w+b') as f:" % support.TESTFN,
>              "   fcntl.%s(f, fcntl.LOCK_EX)" % lock_name,
>              "   time.sleep(%s)" % self.sleep_time))
>          start_time = time.monotonic()
>          proc = self.subprocess(code)
>          with kill_on_error(proc):
> -            with open(support.TESTFN, 'wb') as f:
> +            with open(support.TESTFN, 'w+b') as f:
>                  while True:  # synchronize the subprocess
>                      dt = time.monotonic() - start_time
>                      if dt > 60.0:
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35633>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35633>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:15:16 2019
From: report at bugs.python.org (Jack)
Date: Tue, 15 Jan 2019 10:15:16 +0000
Subject: [issue26226] Test failures with non-ascii character in hostname on
 Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1547547316.07.0.291987968656.issue26226@roundup.psfhosted.org>


Jack <jack.watson7890 at gmail.com> added the comment:

Python not working..

----------
nosy: +Jack01

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26226>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:17:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:17:06 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547547426.14.0.473214737951.issue34756@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I reopen the issue. This change broke test_builtin: see bpo-35742.

I can reproduce the test failure on my Fedoea 29 using:

./python -m test -v test_builtin -m TestBreakpoint

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:18:37 2019
From: report at bugs.python.org (Ori Avtalion)
Date: Tue, 15 Jan 2019 10:18:37 +0000
Subject: [issue35743] Broken "Exception ignored in:" message on OSError's
Message-ID: <1547547515.11.0.919853628992.issue35743@roundup.psfhosted.org>


New submission from Ori Avtalion <ori at avtalion.name>:

When an OSError exception is raised in __del__, both Python 2 and 3 print the "Exception ignored" message, but Python 3 also prints a traceback.

This is similar to issue 22836, with dealt with errors in __repr__ while inside __del__.

Test script:

import os

class Obj(object):
    def __init__(self):
        self.f = open('/dev/null')
        os.close(self.f.fileno())

    def __del__(self):
        self.f.close()

f = Obj()
del f

Output with Python 3.7.2:

Exception ignored in: <function Obj.__del__ at 0x7fb18789be18>
Traceback (most recent call last):
  File "/tmp/test.py", line 9, in __del__
    self.f.close()
OSError: [Errno 9] Bad file descriptor

----------
components: Interpreter Core
messages: 333661
nosy: salty-horse
priority: normal
severity: normal
status: open
title: Broken "Exception ignored in:" message on OSError's
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35743>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:23:12 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547547792.44.0.793653852347.issue35742@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +11202
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:23:14 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1547547794.3.0.264188583687.issue35633@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> On AIX the test for flock() passes, but the test for lockf() fails: (...)

I would prefer to simply skip the lockf() test rather than ignoring PermissionError for flock() and lockf() on all platforms. Can you please write a PR for that?

There is no need to add a NEWS entry, I will add "skip news". If you want to add a NEWS entry, mention at least the fixed test and AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35633>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:23:18 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547547798.19.0.904002229225.issue35742@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11202, 11203
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:23:18 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547547798.2.0.0808923294477.issue34756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11206
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:23:24 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547547804.19.0.749048991905.issue35742@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11202, 11203, 11204
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:23:27 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547547807.73.0.199605169368.issue34756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +11206, 11207
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:23:29 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547547809.98.0.784678370821.issue35742@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11202, 11203, 11204, 11205
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:23:48 2019
From: report at bugs.python.org (Ori Avtalion)
Date: Tue, 15 Jan 2019 10:23:48 +0000
Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in
 __repr__
In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za>
Message-ID: <1547547828.97.0.894167071868.issue22836@roundup.psfhosted.org>


Ori Avtalion <ori at avtalion.name> added the comment:

I encountered a similar bug and reported it as issue 35743.

----------
nosy: +salty-horse

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22836>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:24:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:24:45 +0000
Subject: [issue27423] Failed assertions when running test.test_os on Windows
In-Reply-To: <1467305238.88.0.613411427666.issue27423@psf.upfronthosting.co.za>
Message-ID: <1547547885.86.0.57836823069.issue27423@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This bug has been fixed in test_os or libregrtest, I don't recall, but it's now fixed ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27423>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:26:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:26:14 +0000
Subject: [issue27426] Encoding mismatch causes some tests to fail on Windows
In-Reply-To: <1467307595.9.0.252955875696.issue27426@psf.upfronthosting.co.za>
Message-ID: <1547547974.43.0.930459178216.issue27426@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm quite sure that this bug has been fixed in the meanwhile. If it still fails, please give more information about your configuration: ANSI code page, regional configuration, Windows version, etc.

----------
nosy: +vstinner
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27426>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:27:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:27:40 +0000
Subject: [issue26226] Test failures with non-ascii character in hostname on
 Windows
In-Reply-To: <1453940751.65.0.882732529995.issue26226@psf.upfronthosting.co.za>
Message-ID: <1547548060.78.0.0776225960659.issue26226@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm not sure that all issues have been fixed, but almost all of them are. I prefer to close this issue which has a long history and mentions very different bugs. If someone wants to continue the effort for better Unicode support on Windows with non-ASCII hostname, please open a new specific issues.

Thanks Emanuel Barry for your bug report!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26226>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:29:23 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 10:29:23 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 five
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547548163.88.0.220139027028.issue35738@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 06f8b57212b2e2cd2e63af36cecdfa3075b324a2 by Serhiy Storchaka (Henry Chen) in branch 'master':
bpo-35738: Update the example for timer.Timer.repeat(). (GH-11559)
https://github.com/python/cpython/commit/06f8b57212b2e2cd2e63af36cecdfa3075b324a2


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:29:40 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 10:29:40 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 five
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547548180.75.0.799407325832.issue35738@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11208

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:29:41 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 15 Jan 2019 10:29:41 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547548181.55.0.371898742615.issue35742@roundup.psfhosted.org>


Chih-Hsuan Yen <yen at chyen.cc> added the comment:

Wow that's super fast! I can confirm the patch fixes the issue on my machine. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:29:47 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 10:29:47 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 five
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547548187.2.0.263284113502.issue35738@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11208, 11209

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:35:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:35:09 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547548509.61.0.18076819225.issue35742@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't understand why buildbots didn't scream and why the test didn't fail on Travis CI nor AppVeyor on https://github.com/python/cpython/pull/9457

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:41:13 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 15 Jan 2019 10:41:13 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547548873.7.0.280897823461.issue35742@roundup.psfhosted.org>


Chih-Hsuan Yen <yen at chyen.cc> added the comment:

Found a test_builtin failure in the job for the relevant commit on Travis CI - https://travis-ci.org/python/cpython/jobs/479642964#L1491. I guess it's not noticed as it's listed in allow_failures in .travis.yml. However, I'm not sure if it's the same issue or not as there are no failure details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:46:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:46:08 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547549168.19.0.0803077533905.issue35742@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Found a test_builtin failure in the job for the relevant commit on Travis CI - https://travis-ci.org/python/cpython/jobs/479642964#L1491.

This job is for code coverage. I confirm that failures are allowed. This job runs the full test suite in sequence, whereas the main Travis CI job runs tests in parallel... I tested running tests in sequence and in parallel: test_builtin fail in both cases. It's a mystery. Anyway, it's going to be fixed soon ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:47:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:47:42 +0000
Subject: [issue35743] Broken "Exception ignored in:" message on OSError's
In-Reply-To: <1547547515.11.0.919853628992.issue35743@roundup.psfhosted.org>
Message-ID: <1547549262.62.0.206731048251.issue35743@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python works as expected, I don't understand why you opened a bug report? What looks wrong to you?

Closing a closed file descriptor is your fault, not a bug in Python.

Python logs an error as expected.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35743>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:48:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:48:02 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547549282.41.0.400417241138.issue34323@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b1e45739d832e1e402a563c6727defda92e193b7 by Victor Stinner in branch 'master':
bpo-34323: Enhance IocpProactor.close() log (GH-11555)
https://github.com/python/cpython/commit/b1e45739d832e1e402a563c6727defda92e193b7


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:49:19 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 10:49:19 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 five
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547549359.24.0.722196228371.issue35738@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0bb6b891154b5718c2d7604fc4aa7a51a2f9fe70 by Miss Islington (bot) in branch '3.7':
bpo-35738: Update the example for timer.Timer.repeat(). (GH-11559)
https://github.com/python/cpython/commit/0bb6b891154b5718c2d7604fc4aa7a51a2f9fe70


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:52:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:52:40 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547549560.6.0.447535939622.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11210

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:52:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:52:46 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547549566.6.0.221545459443.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11210, 11211

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:52:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:52:51 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547549571.89.0.927307126615.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11210, 11211, 11212

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 05:54:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 10:54:04 +0000
Subject: [issue35738] Update timeit documentation to reflect default repeat of
 five
In-Reply-To: <1547492160.57.0.532136359252.issue35738@roundup.psfhosted.org>
Message-ID: <1547549644.37.0.897537304369.issue35738@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35738>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:13:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:13:51 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547550831.11.0.974120088304.issue11555@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b91140fdb17472d03a7b7971f143c08a40fde923 by Victor Stinner in branch 'master':
bpo-11555: Enhance IocpProactor.close() log again (GH-11563)
https://github.com/python/cpython/commit/b91140fdb17472d03a7b7971f143c08a40fde923


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:26:19 2019
From: report at bugs.python.org (Ori Avtalion)
Date: Tue, 15 Jan 2019 11:26:19 +0000
Subject: [issue35743] Broken "Exception ignored in:" message on OSError's
In-Reply-To: <1547547515.11.0.919853628992.issue35743@roundup.psfhosted.org>
Message-ID: <1547551579.49.0.984774933521.issue35743@roundup.psfhosted.org>


Ori Avtalion <ori at avtalion.name> added the comment:

Sorry, I was confused by how Python 3 prints the traceback of ignored exceptions, and Python 2 does not.

(This happens on on any exception and not just OSError)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35743>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:26:50 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:26:50 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547551610.29.0.151045038104.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a by Serhiy Storchaka in branch 'master':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:26:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:26:57 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547551617.61.0.516969445329.issue34756@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a by Serhiy Storchaka in branch 'master':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:26:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:26:58 +0000
Subject: [issue35743] Broken "Exception ignored in:" message on OSError's
In-Reply-To: <1547547515.11.0.919853628992.issue35743@roundup.psfhosted.org>
Message-ID: <1547551618.19.0.802379973547.issue35743@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Sorry, I was confused by how Python 3 prints the traceback of ignored exceptions, and Python 2 does not.

It's not a bug but a nice feature which helps you to debug your code!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35743>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:27:05 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547551610.29.0.151045038104.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a by Serhiy Storchaka in branch 'master':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a


----------
pull_requests: +11213

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:07 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 11:27:07 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547551627.65.0.549728407167.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11217

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:07 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:27:07 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547551610.29.0.151045038104.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a by Serhiy Storchaka in branch 'master':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a


----------
pull_requests: +11213, 11214

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:27:09 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547551610.29.0.151045038104.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a by Serhiy Storchaka in branch 'master':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a


----------
pull_requests: +11213, 11214, 11215

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:10 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:27:10 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547551610.29.0.151045038104.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a by Serhiy Storchaka in branch 'master':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/3607ef43c4a1a24d44f39ff54a77fc0af5bfa09a


----------
pull_requests: +11213, 11214, 11215, 11216

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:14 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 11:27:14 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547551634.75.0.051946027757.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11217, 11218

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:21 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 11:27:21 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547551641.21.0.105530533498.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11217, 11218, 11220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:27:28 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 11:27:28 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547551648.36.0.187380859464.issue34756@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11217, 11218, 11219, 11220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:38:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:38:58 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547552338.97.0.908613325693.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11221

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:39:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:39:05 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547552345.64.0.470364908101.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11221, 11222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:39:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:39:05 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547552345.67.0.834990225321.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:39:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:39:12 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547552352.25.0.57388680478.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11221, 11222, 11224

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:39:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:39:16 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547552356.03.0.964610013702.issue34323@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11225, 11226

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:39:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:39:19 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547552359.6.0.640006674205.issue11555@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11221, 11222, 11223, 11224

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:39:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:39:41 +0000
Subject: [issue11555] email.Message.as_string no longer mangles "From " (doc
 fix)
In-Reply-To: <1300202143.89.0.407309500097.issue11555@psf.upfronthosting.co.za>
Message-ID: <1547552381.84.0.311898132513.issue11555@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> New changeset b91140fdb17472d03a7b7971f143c08a40fde923 by Victor Stinner in branch 'master':
> bpo-11555: Enhance IocpProactor.close() log again (GH-11563)
> https://github.com/python/cpython/commit/b91140fdb17472d03a7b7971f143c08a40fde923

Sorry, this change is for bpo-34323.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11555>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:41:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:41:05 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547552465.44.0.26403830752.issue34323@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oops, I used the wrong bpo number for my second change in master:

New changeset b91140fdb17472d03a7b7971f143c08a40fde923 by Victor Stinner in branch 'master':
bpo-11555: Enhance IocpProactor.close() log again (GH-11563)
https://github.com/python/cpython/commit/b91140fdb17472d03a7b7971f143c08a40fde923

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:46:01 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 11:46:01 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547552761.35.0.00146729487193.issue35742@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 97d6a56d9d169f35cf2a24d62bf15adfc42fc672 by Miss Islington (bot) in branch '3.7':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/97d6a56d9d169f35cf2a24d62bf15adfc42fc672


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:46:07 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 11:46:07 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547552767.67.0.923077293492.issue34756@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 97d6a56d9d169f35cf2a24d62bf15adfc42fc672 by Miss Islington (bot) in branch '3.7':
bpo-35742: Fix test_envar_unimportable in test_builtin. (GH-11561)
https://github.com/python/cpython/commit/97d6a56d9d169f35cf2a24d62bf15adfc42fc672


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:50:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:50:12 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547553012.11.0.654747135811.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I was surprised too. Maybe it is because that was very old PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:50:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 11:50:35 +0000
Subject: [issue34756] Few changes in sys.breakpointhook()
In-Reply-To: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>
Message-ID: <1547553035.22.0.945142958967.issue34756@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34756>
_______________________________________

From report at bugs.python.org  Tue Jan 15 06:51:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 11:51:34 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547553094.67.0.0883185141641.issue35742@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I was surprised too. Maybe it is because that was very old PR.

Yeah, that's the most likely explanation. Maybe the CI ran tests before the final merge, or something like that? It doesn't explain why buildbots didn't complain, but it doesn't matter if such hiccup is very rare ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:02:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 12:02:39 +0000
Subject: [issue35742] test_builtin fails after merging the fix for bpo-34756
In-Reply-To: <1547545437.79.0.55588181748.issue35742@roundup.psfhosted.org>
Message-ID: <1547553759.18.0.833119565146.issue35742@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe CI updates only files touched by the PR and the failed test was added after the initial creation of the PR? Or there is something wrong with timestamps, so outdated pyc files were used for tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35742>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:04:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:04:55 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547553895.56.0.407772759703.issue35711@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I close the issue, see:

https://github.com/python/cpython/pull/11513#issuecomment-454369637

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:05:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:05:34 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547553934.12.0.0551595909669.issue34323@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d5a6adf6285ec8892b977a32c22143ebd1025b50 by Victor Stinner in branch '3.7':
[3.7] bpo-34323: Enhance IocpProactor.close() log (GH-11565)
https://github.com/python/cpython/commit/d5a6adf6285ec8892b977a32c22143ebd1025b50


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:06:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:06:28 +0000
Subject: [issue34323] False timeout log message on proactor close
In-Reply-To: <1533250213.71.0.56676864532.issue34323@psf.upfronthosting.co.za>
Message-ID: <1547553988.1.0.314722036128.issue34323@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, the bug is now fixed. Thanks for your bug report John Nelson!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34323>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:09:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:09:20 +0000
Subject: [issue35599] asyncio windows_events.py IocpProactor bug
In-Reply-To: <1545960124.09.0.284140631848.issue35599@roundup.psfhosted.org>
Message-ID: <1547554160.67.0.10356000936.issue35599@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I confirm that it's a duplicate of bpo-34323 that I just fixed ;-)

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> False timeout log message on proactor close

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35599>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:13:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:13:50 +0000
Subject: [issue27500] ProactorEventLoop cannot open connection to ::1
In-Reply-To: <1468346135.06.0.410333112523.issue27500@psf.upfronthosting.co.za>
Message-ID: <1547554430.18.0.85407802322.issue27500@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27500>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:15:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:15:04 +0000
Subject: [issue33837] Closing asyncio.Server on asyncio.ProactorEventLoop
 causes all active servers to stop listening
In-Reply-To: <1528732780.1.0.592728768989.issue33837@psf.upfronthosting.co.za>
Message-ID: <1547554504.18.0.108132350134.issue33837@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Duplicate of bpo-29711 and already fixed.

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> When you use stop_serving in proactor loop it's kill all listening servers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33837>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:24:02 2019
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Tue, 15 Jan 2019 12:24:02 +0000
Subject: [issue27500] ProactorEventLoop cannot open connection to ::1
In-Reply-To: <1468346135.06.0.410333112523.issue27500@psf.upfronthosting.co.za>
Message-ID: <1547555042.74.0.884009846298.issue27500@roundup.psfhosted.org>


Sebastien Bourdeauducq <sb at m-labs.hk> added the comment:

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27500>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:24:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:24:11 +0000
Subject: [issue32661] ProactorEventLoop locks up on close call
In-Reply-To: <1516850655.32.0.467229070634.issue32661@psf.upfronthosting.co.za>
Message-ID: <1547555051.18.0.534263213712.issue32661@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

bug.py calls loop.run_forever() but nothing calls stops the loop. If you add loop.stop() to handle_incoming_connection(), the script exits properly as soon as a client connects and sends some data.

> 3. I press Ctrl-C in the DOS window.  Nothing happens.

This issue has been fixed by bpo-23057. So I qualify this issue as a duplicate of bpo-23057.

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] asyncio: support signal handlers on Windows (feature request)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32661>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:26:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:26:24 +0000
Subject: [issue31048] ResourceWarning in
 test_asyncio.test_events.ProactorEventLoopTests.test_create_server_ssl_verify_failed
In-Reply-To: <1501091072.67.0.693498013368.issue31048@psf.upfronthosting.co.za>
Message-ID: <1547555184.84.0.424140868035.issue31048@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't know how, but this issue has been fixed in the meanwhile.

----------
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31048>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:32:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:32:25 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547555545.98.0.462748727524.issue23846@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +11227
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:32:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:32:33 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547555553.07.0.703747446564.issue23846@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +11227, 11228
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:32:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:32:42 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547555562.11.0.698890695343.issue23846@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11227, 11228, 11229
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:34:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:34:29 +0000
Subject: [issue35580] Windows IocpProactor: CreateIoCompletionPort 4th arg
 0xffffffff -- why is this value the default?
In-Reply-To: <1545694904.74.0.712150888896.issue35580@roundup.psfhosted.org>
Message-ID: <1547555669.18.0.482600381475.issue35580@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Am I correct that only one thread calls `GetQueuedCompletionStatus` on a given `iocp` object in asyncio under Windows `IocpProactor`?

An asyncio event loop must only run in a single thread at the same time. It doesn't make sense to run the same event loop multiple times in parallel and it is not supported (most asyncio classes are not thread-safe, there is no need to be thread-safe).

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35580>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:34:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 12:34:51 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1547555691.06.0.417058195501.issue8765@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1462234baf7398a6b00c0f51905e26caa17d3c60 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-8765: Deprecate writing unicode to binary streams in Py3k mode. (GH-11127)
https://github.com/python/cpython/commit/1462234baf7398a6b00c0f51905e26caa17d3c60


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:35:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Jan 2019 12:35:38 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1547555738.37.0.38894131569.issue8765@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8765>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:41:12 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Jan 2019 12:41:12 +0000
Subject: [issue35580] Windows IocpProactor: CreateIoCompletionPort 4th arg
 0xffffffff -- why is this value the default?
In-Reply-To: <1545694904.74.0.712150888896.issue35580@roundup.psfhosted.org>
Message-ID: <1547556072.75.0.0380140957277.issue35580@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

>From my understanding the question is: replace 0xffffffff with 0 or 1?

I don't know much about IOCP, 0 sounds safer for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35580>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:53:04 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Jan 2019 12:53:04 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547556784.39.0.0948636956195.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

`site.addsitedir` is called for every site-packages directory (whether global, within a venv, or at the user level), so my proposal above covers appending multiple segments.

Linux distros approach to handling this is terrible because they dump all their system packages into a single global site-packages, leading to the every growing sys.path problem that Barry is concerned about.

However, that's entirely the fault of distro packaging policies, and can be remedied in a far superior way by switching distros to a model where they create a venv per application, and then use .pth files to link in the system packages that they actually want visible to that application.

"Some users don't want to use virtual environments appropriately" is an incredibly poor reason for breaking a perfectly valid feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:55:32 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Jan 2019 12:55:32 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547556932.92.0.771138460926.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that any PEP I contributed to writing would need to be restricted to eliminating arbitrary code execution, as I don't think there's anything wrong with the path extension feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:58:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 12:58:43 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547557123.05.0.91183712784.issue23846@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c9f872b0bdce5888f1879fa74e098bf4a05430c5 by Victor Stinner in branch 'master':
bpo-23846: Fix ProactorEventLoop._write_to_self() (GH-11566)
https://github.com/python/cpython/commit/c9f872b0bdce5888f1879fa74e098bf4a05430c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:59:03 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 12:59:03 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547557143.51.0.234858164553.issue23846@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11230

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:59:15 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 12:59:15 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547557155.11.0.887233688056.issue23846@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11230, 11231

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 07:59:26 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 12:59:26 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547557166.63.0.760076769343.issue23846@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11230, 11231, 11232

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 08:12:13 2019
From: report at bugs.python.org (Jay)
Date: Tue, 15 Jan 2019 13:12:13 +0000
Subject: [issue35744] Problem in the documentation of numpy.random.randint in
 python 2.7
Message-ID: <1547557932.37.0.905069096511.issue35744@roundup.psfhosted.org>


New submission from Jay <jay.pokarna10 at gmail.com>:

Official Documentation of python 2.7 mentions that numpy.random.randint(a,b) will return a random integer from N such that a<=N<=b. But I have run the code and I have found that it never returns equal to b. So, what I did was I ran numpy.random.randint(0,1) for 50 milion times and finally printed the sum. 

The output was 0. 

I don't know if this a documentation or an implementation issue, but this is an issue which needs to be looked at. I am attaching the code that I ran.

----------
assignee: docs at python
components: Documentation
files: sample.py
messages: 333701
nosy: Jay, docs at python
priority: normal
severity: normal
status: open
title: Problem in the documentation of numpy.random.randint in python 2.7
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48051/sample.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35744>
_______________________________________

From report at bugs.python.org  Tue Jan 15 08:13:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 13:13:49 +0000
Subject: [issue35744] Problem in the documentation of numpy.random.randint in
 python 2.7
In-Reply-To: <1547557932.37.0.905069096511.issue35744@roundup.psfhosted.org>
Message-ID: <1547558029.45.0.0763324580341.issue35744@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Sorry but this is the bug tracker of Python, not of numpy. Please use https://github.com/numpy/numpy/issues instead.

----------
nosy: +vstinner
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35744>
_______________________________________

From report at bugs.python.org  Tue Jan 15 08:17:13 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 13:17:13 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547558233.14.0.0471352266025.issue23846@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c9f26714d511a338ba2fdd926e3dc62636f31815 by Miss Islington (bot) in branch '3.7':
bpo-23846: Fix ProactorEventLoop._write_to_self() (GH-11566)
https://github.com/python/cpython/commit/c9f26714d511a338ba2fdd926e3dc62636f31815


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 08:59:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 13:59:09 +0000
Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when
 ThreadPoolExecutor has many workers
In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za>
Message-ID: <1547560749.78.0.874980484956.issue23846@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> In any case it looks like self-pipe sock's buffer was overflown because call_soon_threadsafe was called too many times, and loop._read_from_self couldn't empty the buffer promptly.  Then, at some point, _write_to_self failed with an IOError.

I fixed the issue. Thanks for your bug report ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23846>
_______________________________________

From report at bugs.python.org  Tue Jan 15 09:01:31 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 15 Jan 2019 14:01:31 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547560891.05.0.0500106769041.issue33944@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> `site.addsitedir` is called for every site-packages directory (whether global, within a venv, or at the user level), so my proposal above covers appending multiple segments.

Good point. I think you're assuming that only site dirs are appropriate for packages that require arbitrary code execution. I think I'd like to break that assumption and allow any location where packages can be installed (PYTHONPATH) to install hooks. Consider this use-case:

draft $ mkdir pkgs                                                                                                                           draft $ python3.5 -m pip download -d pkgs future_fstrings                                                                              Collecting future_fstrings
  Using cached https://files.pythonhosted.org/packages/36/25/070c2dc1fe1e51901df5875c495d6efbbf945a93a2ca40f47e5225302fb8/future_fstrings-0.4.5-py2.py3-none-any.whl
  Saved ./pkgs/future_fstrings-0.4.5-py2.py3-none-any.whl
Collecting tokenize-rt; python_version < "3.6" (from future_fstrings)
  Using cached https://files.pythonhosted.org/packages/76/82/0e6a9dda45dd76be22d74211443e199a330ac7e428b8dbbc5d116651be03/tokenize_rt-2.1.0-py2.py3-none-any.whl
  Saved ./pkgs/tokenize_rt-2.1.0-py2.py3-none-any.whl
Successfully downloaded future-fstrings tokenize-rt
draft $ cat > hello-fstrings.py                                                                                                             # coding: future_fstrings
print(f'hello world')                                             
draft $ PYTHONPATH=pkgs/future_fstrings-0.4.5-py2.py3-none-any.whl:pkgs/tokenize_rt-2.1.0-py2.py3-none-any.whl python3.5 hello-fstrings.py                                               
xonsh: subprocess mode: command not found: PYTHONPATH=pkgs/future_fstrings-0.4.5-py2.py3-none-any.whl:pkgs/tokenize_rt-2.1.0-py2.py3-none-any.whl
draft $ env PYTHONPATH=pkgs/future_fstrings-0.4.5-py2.py3-none-any.whl:pkgs/tokenize_rt-2.1.0-py2.py3-none-any.whl python3.5 hello-fstrings.py                                           
  File "hello-fstrings.py", line 1
SyntaxError: encoding problem: future_fstrings


If future-fstrings were properly installed, its runtime hook is called and the script can run:

draft $ python3.5 -m pip-run -q future-fstrings -- hello-fstrings.py                                                                                                                     
hello world


I'd like for a package like future-fstrings to be able to supply a hook that can be executed on startup that can be honored even if the package isn't installed in one of the site paths.

> Let's make a PEP.

I'd be delighted to help with the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Tue Jan 15 09:04:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 14:04:56 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547561096.43.0.839341864691.issue33944@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> SyntaxError: encoding problem: future_fstrings

IMHO that's the expected behavior. I would prefer to have to explicitly install this special encoding *before* loading a script using it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Tue Jan 15 09:32:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 15 Jan 2019 14:32:46 +0000
Subject: [issue35741] unittest.skipUnless(time._STRUCT_TM_ITEMS == 11,
 "needs tm_zone support") doesn't work
In-Reply-To: <1547544727.75.0.967204925198.issue35741@roundup.psfhosted.org>
Message-ID: <1547562766.97.0.695142415619.issue35741@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35741>
_______________________________________

From report at bugs.python.org  Tue Jan 15 10:33:13 2019
From: report at bugs.python.org (Windson Yang)
Date: Tue, 15 Jan 2019 15:33:13 +0000
Subject: [issue35745] Add import statement in dataclass code snippet
Message-ID: <1547566391.87.0.956827047672.issue35745@roundup.psfhosted.org>


New submission from Windson Yang <wiwindson at outlook.com>:

Most of the example in https://docs.python.org/3/library/dataclasses.html miss code like

from dataclasses import dataclass, field
from typing import List

I think we should add this statement in the code snippet.

----------
assignee: docs at python
components: Documentation
messages: 333707
nosy: Windson Yang, docs at python
priority: normal
severity: normal
status: open
title: Add import statement in dataclass code snippet
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35745>
_______________________________________

From report at bugs.python.org  Tue Jan 15 10:36:52 2019
From: report at bugs.python.org (Windson Yang)
Date: Tue, 15 Jan 2019 15:36:52 +0000
Subject: [issue35745] Add import statement in dataclass code snippet
In-Reply-To: <1547566391.87.0.956827047672.issue35745@roundup.psfhosted.org>
Message-ID: <1547566612.21.0.8406398449.issue35745@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I'm not sure if we should put 

from dataclasses import dataclass

everywhere or we should put it just in the first example as I did in the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35745>
_______________________________________

From report at bugs.python.org  Tue Jan 15 11:24:31 2019
From: report at bugs.python.org (Cisco Talos)
Date: Tue, 15 Jan 2019 16:24:31 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
Message-ID: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>


New submission from Cisco Talos <vulndev at cisco.com>:

An exploitable denial-of-service vulnerability exists in the X509 certificate parser of Python.org Python 2.7.11 / 3.6.6. A specially crafted X509 certificate can cause a NULL pointer dereference, resulting in a denial of service. An attacker can initiate or accept TLS connections using crafted certificates to trigger this vulnerability.

----------
files: TALOS-2019-0758.txt
messages: 333709
nosy: Talos
priority: normal
severity: normal
status: open
title: TALOS-2018-0758 Denial of Service
type: security
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48052/TALOS-2019-0758.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 11:25:53 2019
From: report at bugs.python.org (Cisco Talos)
Date: Tue, 15 Jan 2019 16:25:53 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547569553.78.0.12101027796.issue35746@roundup.psfhosted.org>


Change by Cisco Talos <vulndev at cisco.com>:


----------
versions:  -Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48053/TALOS-2019-0758 - POC.pem

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 11:30:21 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 16:30:21 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547569821.42.0.887841080489.issue35746@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Thanks for the report!

----------
assignee:  -> christian.heimes
components: +SSL
nosy: +christian.heimes
stage:  -> needs patch
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/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 11:38:19 2019
From: report at bugs.python.org (Cisco Talos)
Date: Tue, 15 Jan 2019 16:38:19 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569821.42.0.887841080489.issue35746@roundup.psfhosted.org>
Message-ID: <68A8E267-5CAD-4F0F-B487-D75EB1B86FE3@cisco.com>


Cisco Talos <vulndev at cisco.com> added the comment:

Thanks for acknowledging.  We look forward to any updates/developments on the issue reported.

For further information about the Cisco Vendor Vulnerability Reporting and Disclosure Policy please refer to this document which also links to our public PGP key. https://tools.cisco.com/security/center/resources/vendor_vulnerability_policy.html

Kind Regards,

Regina Wilson
Analyst.Business Operations
regiwils at cisco.com<mailto:regiwils at cisco.com>

[cid:CFA14CB5-B7B2-4FF7-8313-22D495F607D5 at vrt.sourcefire.com]

On Jan 15, 2019, at 11:30 AM, Christian Heimes <report at bugs.python.org<mailto:report at bugs.python.org>> wrote:

Christian Heimes <lists at cheimes.de<mailto:lists at cheimes.de>> added the comment:

Thanks for the report!

----------
assignee:  -> christian.heimes
components: +SSL
nosy: +christian.heimes
stage:  -> needs patch
versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org<mailto:report at bugs.python.org>>
<https://bugs.python.org/issue35746>
_______________________________________

----------
Added file: https://bugs.python.org/file48054/image001.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8573 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20190115/4a54f432/attachment-0001.png>

From report at bugs.python.org  Tue Jan 15 11:54:46 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 16:54:46 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547571286.09.0.893585467865.issue35746@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I can confirm that CPython is affected.

By the way PyCA cryptography handles the CRL DB just fine.

>>> from cryptography import x509
>>> from cryptography.hazmat.backends import default_backend
>>> with open("Lib/test/talos-2019-0758.pem", "rb") as f:
...     pem_data = f.read()
... 
>>> cert = x509.load_pem_x509_certificate(pem_data, default_backend())
>>> cert.extensions[-1]
<Extension(oid=<ObjectIdentifier(oid=2.5.29.31, name=cRLDistributionPoints)>, critical=False, value=<CRLDistributionPoints([<DistributionPoint(full_name=None, relative_name=None, reasons=None, crl_issuer=None)>])>)>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:11:05 2019
From: report at bugs.python.org (Cisco Talos)
Date: Tue, 15 Jan 2019 17:11:05 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572265.48.0.820119288028.issue35746@roundup.psfhosted.org>


Change by Cisco Talos <vulndev at cisco.com>:


Removed file: https://bugs.python.org/file48053/TALOS-2019-0758 - POC.pem

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:11:26 2019
From: report at bugs.python.org (Cisco Talos)
Date: Tue, 15 Jan 2019 17:11:26 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572286.1.0.371373775526.issue35746@roundup.psfhosted.org>


Change by Cisco Talos <vulndev at cisco.com>:


Removed file: https://bugs.python.org/file48052/TALOS-2019-0758.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:15:26 2019
From: report at bugs.python.org (Cisco Talos)
Date: Tue, 15 Jan 2019 17:15:26 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547572287.32.0.989594622469.issue35746@roundup.psfhosted.org>
Message-ID: <D038AE18-047D-4CB7-964F-E653A6D42755@cisco.com>


Cisco Talos <vulndev at cisco.com> added the comment:

The files are removed and will be reissued to PSIRT.

Regina Wilson
Analyst.Business Operations
regiwils at cisco.com<mailto:regiwils at cisco.com>

[cid:CFA14CB5-B7B2-4FF7-8313-22D495F607D5 at vrt.sourcefire.com]

On Jan 15, 2019, at 12:11 PM, Cisco Talos <report at bugs.python.org<mailto:report at bugs.python.org>> wrote:

Change by Cisco Talos <vulndev at cisco.com<mailto:vulndev at cisco.com>>:

Removed file: https://bugs.python.org/file48052/TALOS-2019-0758.txt

_______________________________________
Python tracker <report at bugs.python.org<mailto:report at bugs.python.org>>
<https://bugs.python.org/issue35746>
_______________________________________

----------
Added file: https://bugs.python.org/file48055/image001.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8573 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20190115/d5904385/attachment.png>

From report at bugs.python.org  Tue Jan 15 12:17:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 17:17:37 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572657.53.0.0555111383952.issue35746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I close the bug just to hide it from the home page and default search result, to have more time to fix it (make the issue less visible).

----------
nosy: +vstinner
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:20:33 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 17:20:33 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572833.57.0.939412384596.issue35746@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Please leave the bug open and don't remove files. It's too late. The bug report has been sent to mailing lists and RSS feeds already.

Also you cannot remove any files from the bug tracker. Only admins are can do that.

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:21:39 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 17:21:39 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572899.51.0.824633019662.issue35746@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
pull_requests: +11233

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:21:45 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 17:21:45 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572905.6.0.166347920078.issue35746@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch, patch
pull_requests: +11233, 11234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:21:52 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 17:21:52 +0000
Subject: [issue35746] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547572912.47.0.374571868663.issue35746@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch, patch, patch
pull_requests: +11233, 11234, 11235

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:25:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 17:25:41 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547573141.43.0.491496916228.issue35746@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: TALOS-2018-0758 Denial of Service -> [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Mon Jan 14 09:43:53 2019
From: report at bugs.python.org (=?utf-8?q?Michael_Kr=C3=B6tlinger?=)
Date: Mon, 14 Jan 2019 14:43:53 +0000
Subject: [issue35736] Missing component in table after
 getElementsByTagName("nn")
In-Reply-To: <1547474663.29.0.909592562406.issue35736@roundup.psfhosted.org>
Message-ID: <20190114144350.82C3442C2AAA@dd15524.kasserver.com>


Michael Kr?tlinger <michael at way2help.at> added the comment:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://soap.ebs.client.chipkarte.at" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://soap.ebs.client.chipkarte.at" name="EbsService">
  <types>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://exceptions.soap.base.client.chipkarte.at" elementFormDefault="qualified" targetNamespace="http://exceptions.soap.base.client.chipkarte.at" version="1.0">
      <xs:element name="AccessException" type="tns:accessExceptionContent" />
      <xs:element name="CardException" type="tns:cardExceptionContent" />
      <xs:element name="DialogException" type="tns:dialogExceptionContent" />
      <xs:element name="ServiceException" type="tns:serviceExceptionContent" />
      <xs:complexType name="accessExceptionContent">
        <xs:complexContent>
          <xs:extension base="tns:baseExceptionContent">
            <xs:sequence />
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
      <xs:complexType name="baseExceptionContent">
        <xs:sequence>
          <xs:element name="code" type="xs:string" minOccurs="0" />
          <xs:element name="errorCode" type="xs:int" minOccurs="0" />
          <xs:element name="message" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="cardExceptionContent">
        <xs:complexContent>
          <xs:extension base="tns:baseExceptionContent">
            <xs:sequence />
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
      <xs:complexType name="dialogExceptionContent">
        <xs:complexContent>
          <xs:extension base="tns:baseExceptionContent">
            <xs:sequence />
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
      <xs:complexType name="serviceExceptionContent">
        <xs:complexContent>
          <xs:extension base="tns:baseExceptionContent">
            <xs:sequence />
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
    </xs:schema>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:baseexc="http://exceptions.soap.base.client.chipkarte.at" xmlns:tns="http://exceptions.soap.ebs.client.chipkarte.at" elementFormDefault="qualified" targetNamespace="http://exceptions.soap.ebs.client.chipkarte.at" version="1.0">
      <xs:import namespace="http://exceptions.soap.base.client.chipkarte.at" />
      <xs:element name="EbsException" type="tns:ebsExceptionContent" />
      <xs:element name="EbsInvalidParameterException" type="tns:ebsInvalidParameterExceptionContent" />
      <xs:complexType name="ebsExceptionContent">
        <xs:complexContent>
          <xs:extension base="baseexc:baseExceptionContent">
            <xs:sequence>
              <xs:element name="svtCodes" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
            </xs:sequence>
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
      <xs:complexType name="ebsInvalidParameterExceptionContent">
        <xs:complexContent>
          <xs:extension base="baseexc:baseExceptionContent">
            <xs:sequence />
          </xs:extension>
        </xs:complexContent>
      </xs:complexType>
    </xs:schema>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:baseexc="http://exceptions.soap.base.client.chipkarte.at" elementFormDefault="qualified" targetNamespace="http://soap.base.client.chipkarte.at" version="1.0">
      <xs:complexType name="baseProperty">
        <xs:sequence>
          <xs:element name="code" type="xs:string" minOccurs="0" />
          <xs:element name="nurAnzeige" type="xs:boolean" minOccurs="0" />
          <xs:element name="text" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="property">
        <xs:sequence>
          <xs:element name="key" type="xs:string" minOccurs="0" />
          <xs:element name="value" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="svPersonV2">
        <xs:sequence>
          <xs:element name="druckNachname" type="xs:string" minOccurs="0" />
          <xs:element name="druckTitelHinten" type="xs:string" minOccurs="0" />
          <xs:element name="druckTitelVorne" type="xs:string" minOccurs="0" />
          <xs:element name="druckVorname" type="xs:string" minOccurs="0" />
          <xs:element name="geburtsdatum" type="xs:string" minOccurs="0" />
          <xs:element name="geschlecht" type="xs:string" minOccurs="0" />
          <xs:element name="nachname" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="titelHinten" type="xs:string" minOccurs="0" />
          <xs:element name="titelVorne" type="xs:string" minOccurs="0" />
          <xs:element name="vorname" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
    </xs:schema>
    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:base="http://soap.base.client.chipkarte.at" xmlns:ebsexc="http://exceptions.soap.ebs.client.chipkarte.at" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" elementFormDefault="qualified" targetNamespace="http://soap.ebs.client.chipkarte.at" version="1.0">
      <xs:import namespace="http://soap.base.client.chipkarte.at" />
      <xs:import namespace="http://www.w3.org/2005/05/xmlmime" schemaLocation="http://www.w3.org/2005/05/xmlmime" />
      <xs:element name="abfragenAntragMitCode" type="tns:abfragenAntragMitCode" />
      <xs:element name="abfragenAntragMitCodeResponse" type="tns:abfragenAntragMitCodeResponse" />
      <xs:element name="abfragenEbsRelevanteTraeger" type="tns:abfragenEbsRelevanteTraeger" />
      <xs:element name="abfragenEbsRelevanteTraegerResponse" type="tns:abfragenEbsRelevanteTraegerResponse" />
      <xs:element name="abfragenEigeneAntraege" type="tns:abfragenEigeneAntraege" />
      <xs:element name="abfragenEigeneAntraegeResponse" type="tns:abfragenEigeneAntraegeResponse" />
      <xs:element name="antragstypenErmitteln" type="tns:antragstypenErmitteln" />
      <xs:element name="antragstypenErmittelnResponse" type="tns:antragstypenErmittelnResponse" />
      <xs:element name="beantwortenEvidenzmeldung" type="tns:beantwortenEvidenzmeldung" />
      <xs:element name="beantwortenEvidenzmeldungResponse" type="tns:beantwortenEvidenzmeldungResponse" />
      <xs:element name="bekanntgebenTerminvereinbarung" type="tns:bekanntgebenTerminvereinbarung" />
      <xs:element name="bekanntgebenTerminvereinbarungResponse" type="tns:bekanntgebenTerminvereinbarungResponse" />
      <xs:element name="checkStatus" type="tns:checkStatus" />
      <xs:element name="checkStatusResponse" type="tns:checkStatusResponse" />
      <xs:element name="erfassenVerordnerAntrag" type="tns:erfassenVerordnerAntrag" />
      <xs:element name="erfassenVerordnerAntragResponse" type="tns:erfassenVerordnerAntragResponse" />
      <xs:element name="herunterladenAttachments" type="tns:herunterladenAttachments" />
      <xs:element name="herunterladenAttachmentsResponse" type="tns:herunterladenAttachmentsResponse" />
      <xs:element name="mammographieIndikationenErmitteln" type="tns:mammographieIndikationenErmitteln" />
      <xs:element name="mammographieIndikationenErmittelnResponse" type="tns:mammographieIndikationenErmittelnResponse" />
      <xs:element name="nacherfassenAntrag" type="tns:nacherfassenAntrag" />
      <xs:element name="nacherfassenAntragResponse" type="tns:nacherfassenAntragResponse" />
      <xs:element name="pruefenAdministrativeAntragsdaten" type="tns:pruefenAdministrativeAntragsdaten" />
      <xs:element name="pruefenAdministrativeAntragsdatenResponse" type="tns:pruefenAdministrativeAntragsdatenResponse" />
      <xs:element name="pruefenOriginalverordnerVpnr" type="tns:pruefenOriginalverordnerVpnr" />
      <xs:element name="pruefenOriginalverordnerVpnrResponse" type="tns:pruefenOriginalverordnerVpnrResponse" />
      <xs:element name="stornierenAntrag" type="tns:stornierenAntrag" />
      <xs:element name="stornierenAntragResponse" type="tns:stornierenAntragResponse" />
      <xs:element name="uebernehmenAntragsleistungen" type="tns:uebernehmenAntragsleistungen" />
      <xs:element name="uebernehmenAntragsleistungenResponse" type="tns:uebernehmenAntragsleistungenResponse" />
      <xs:element name="widerrufenTerminvereinbarung" type="tns:widerrufenTerminvereinbarung" />
      <xs:element name="widerrufenTerminvereinbarungResponse" type="tns:widerrufenTerminvereinbarungResponse" />
      <xs:element name="widerrufenUebernahme" type="tns:widerrufenUebernahme" />
      <xs:element name="widerrufenUebernahmeResponse" type="tns:widerrufenUebernahmeResponse" />
      <xs:complexType name="abfragenAntragMitCode">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="karteKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="abfragenAntragMitCodeErgebnis">
        <xs:sequence>
          <xs:element name="attachmentOriginalverordnung" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" />
          <xs:element name="bewilligungsakt" type="tns:bewilligungsakt" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="abfragenAntragMitCodeResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:abfragenAntragMitCodeErgebnis" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="abfragenEbsRelevanteTraeger">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="abfragenEbsRelevanteTraegerResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:kvtAntragstypen" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="abfragenEigeneAntraege">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="karteKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
          <xs:element name="vorname" type="xs:string" minOccurs="0" />
          <xs:element name="zuname" type="xs:string" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="antragsstatus" type="xs:string" minOccurs="0" />
          <xs:element name="aggregierterLeistungsstatus" type="xs:string" minOccurs="0" />
          <xs:element name="eigeneRolle" type="xs:string" minOccurs="0" />
          <xs:element name="vonDatum" type="xs:string" minOccurs="0" />
          <xs:element name="bisDatum" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="abfragenEigeneAntraegeResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsaktReferenz" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="adressdaten">
        <xs:sequence>
          <xs:element name="ort" type="xs:string" minOccurs="0" />
          <xs:element name="postleitzahl" type="xs:string" minOccurs="0" />
          <xs:element name="staat" type="xs:string" minOccurs="0" />
          <xs:element name="strasse" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="antragstypDetail">
        <xs:sequence>
          <xs:element name="baseProperty" type="base:baseProperty" minOccurs="0" />
          <xs:element name="benoetigtesRecht" type="xs:string" minOccurs="0" />
          <xs:element name="kurztext" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="antragstypenErmitteln">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="antragstypenErmittelnResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:antragstypDetail" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="attachmentInfo">
        <xs:sequence>
          <xs:element name="dateiinfos" type="tns:dateiInfo" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="gesamtgroesse" type="xs:int" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="beantragteLeistung">
        <xs:sequence>
          <xs:element name="beantragungsposition" type="xs:string" minOccurs="0" />
          <xs:element name="katalogleistung" type="tns:katalogleistung" minOccurs="0" />
          <xs:element name="koerperregion" type="xs:string" minOccurs="0" />
          <xs:element name="kontrastmittel" type="xs:string" minOccurs="0" />
          <xs:element name="leistungfreitext" type="xs:string" minOccurs="0" />
          <xs:element name="leistungfreitextgrund" type="xs:string" minOccurs="0" />
          <xs:element name="seite" type="xs:string" minOccurs="0" />
          <xs:element name="weitereMedizinischeDaten" type="tns:medizinischeDatenerweiterung" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="beantwortenEvidenzmeldung">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="karteKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
          <xs:element name="evidenzantwort" type="xs:string" minOccurs="0" />
          <xs:element name="attachmentInfo" type="tns:attachmentInfo" minOccurs="0" />
          <xs:element name="evidenzAttachments" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="beantwortenEvidenzmeldungResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsaktReferenz" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="bekanntgebenTerminvereinbarung">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="antragsreferenz" type="xs:string" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="fachgebiet" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="bekanntgebenTerminvereinbarungResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsaktReferenz" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="bewilligungsakt">
        <xs:sequence>
          <xs:element name="ansprechpersonNacherfasser" type="xs:string" minOccurs="0" />
          <xs:element name="antragZusatzinformation" type="xs:string" minOccurs="0" />
          <xs:element name="antragsAttachmentinfo" type="tns:attachmentInfo" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
          <xs:element name="antragsReferenz" type="xs:string" minOccurs="0" />
          <xs:element name="antragsdatum" type="xs:string" minOccurs="0" />
          <xs:element name="antragsstatus" type="xs:string" minOccurs="0" />
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="beantragteLeistungen" type="tns:beantragteLeistung" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="ctAntragsdaten" type="tns:ctAntragsdaten" minOccurs="0" />
          <xs:element name="druckaufbereitung" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" />
          <xs:element name="entschiedeneLeistungen" type="tns:entschiedeneLeistung" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="erfasserkennung" type="xs:string" minOccurs="0" />
          <xs:element name="evidenzdaten" type="tns:evidenzDaten" minOccurs="0" />
          <xs:element name="generelleMedizinischeAntragsdaten" type="tns:generelleMedizinischeAntragsdaten" minOccurs="0" />
          <xs:element name="gueltigkeitsdatum" type="xs:string" minOccurs="0" />
          <xs:element name="humAntragsdaten" type="tns:humAntragsdaten" minOccurs="0" />
          <xs:element name="kdmAntragsdaten" type="tns:kdmAntragsdaten" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="leistungsbezieher" type="tns:leistungsbezieher" minOccurs="0" />
          <xs:element name="mrAntragsdaten" type="tns:mrAntragsdaten" minOccurs="0" />
          <xs:element name="nukAntragsdaten" type="tns:nukAntragsdaten" minOccurs="0" />
          <xs:element name="roetAntragsdaten" type="tns:roetAntragsdaten" minOccurs="0" />
          <xs:element name="roeuAntragsdaten" type="tns:roeuAntragsdaten" minOccurs="0" />
          <xs:element name="rolleErsteller" type="xs:boolean" minOccurs="0" />
          <xs:element name="rolleLeistungserbringer" type="xs:boolean" minOccurs="0" />
          <xs:element name="rolleStornierung" type="xs:boolean" minOccurs="0" />
          <xs:element name="rolleVerordner" type="xs:boolean" minOccurs="0" />
          <xs:element name="sonoAntragsdaten" type="tns:sonoAntragsdaten" minOccurs="0" />
          <xs:element name="statusBegruendung" type="xs:string" minOccurs="0" />
          <xs:element name="stornokennung" type="xs:string" minOccurs="0" />
          <xs:element name="terminvereinbarungDurch" type="xs:string" minOccurs="0" />
          <xs:element name="terminvereinbarungErfolgt" type="xs:string" minOccurs="0" />
          <xs:element name="verordnerDaten" type="tns:leistungsverordner" minOccurs="0" />
          <xs:element name="verordnungsdatum" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="bewilligungsaktReferenz">
        <xs:sequence>
          <xs:element name="aggregierterLeistungsstatus" type="xs:string" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
          <xs:element name="antragsReferenz" type="xs:string" minOccurs="0" />
          <xs:element name="antragsdatum" type="xs:string" minOccurs="0" />
          <xs:element name="antragsstatus" type="xs:string" minOccurs="0" />
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="ekvkPatient" type="tns:ekvkPatient" minOccurs="0" />
          <xs:element name="gueltigkeitsdatum" type="xs:string" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="svPatient" type="base:svPersonV2" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="checkStatus">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="checkStatusResponse">
        <xs:sequence>
          <xs:element name="return" type="base:property" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="ctAntragsdaten">
        <xs:sequence>
          <xs:element name="bisherigeTherapie" type="xs:string" minOccurs="0" />
          <xs:element name="empfohlen" type="xs:string" minOccurs="0" />
          <xs:element name="fachgebietsbezogen" type="xs:string" minOccurs="0" />
          <xs:element name="klinik" type="xs:string" minOccurs="0" />
          <xs:element name="kreatinin" type="xs:string" minOccurs="0" />
          <xs:element name="tsh" type="xs:string" minOccurs="0" />
          <xs:element name="unfall" type="xs:string" minOccurs="0" />
          <xs:element name="unfalldatum" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="dateiInfo">
        <xs:sequence>
          <xs:element name="dateiInhaltstyp" type="xs:string" minOccurs="0" />
          <xs:element name="dateiformat" type="xs:string" minOccurs="0" />
          <xs:element name="dateigroesse" type="xs:int" minOccurs="0" />
          <xs:element name="dateiname" type="xs:string" minOccurs="0" />
          <xs:element name="dateinummer" type="xs:long" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="ekvkPatient">
        <xs:sequence>
          <xs:element name="geburtsdatum" type="xs:string" minOccurs="0" />
          <xs:element name="geschlecht" type="xs:string" minOccurs="0" />
          <xs:element name="karteAblaufdatum" type="xs:string" minOccurs="0" />
          <xs:element name="karteKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="karteninhaberKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="staat" type="xs:string" minOccurs="0" />
          <xs:element name="traegerKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="vorname" type="xs:string" minOccurs="0" />
          <xs:element name="zuname" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="entschiedeneLeistung">
        <xs:sequence>
          <xs:element name="begruendung" type="xs:string" minOccurs="0" />
          <xs:element name="entscheidungsposition" type="xs:string" minOccurs="0" />
          <xs:element name="katalogleistung" type="tns:katalogleistung" minOccurs="0" />
          <xs:element name="koerperregion" type="xs:string" minOccurs="0" />
          <xs:element name="kontrastmittel" type="xs:string" minOccurs="0" />
          <xs:element name="leistungfreitext" type="xs:string" minOccurs="0" />
          <xs:element name="leistungsstatus" type="xs:string" minOccurs="0" />
          <xs:element name="seite" type="xs:string" minOccurs="0" />
          <xs:element name="weitereMedizinischeDaten" type="tns:medizinischeDatenerweiterung" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="erfassenVerordnerAntrag">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="cardReaderId" type="xs:string" minOccurs="0" />
          <xs:element name="leistungsantragAktuell" type="tns:leistungsantragAktuell" minOccurs="0" />
          <xs:element name="antragsAttachments" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="erfassenVerordnerAntragResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsakt" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="evidenzBeantwortung">
        <xs:sequence>
          <xs:element name="antwortdatum" type="xs:string" minOccurs="0" />
          <xs:element name="beantworterkennung" type="xs:string" minOccurs="0" />
          <xs:element name="evidenzAttachmentInfo" type="tns:attachmentInfo" minOccurs="0" />
          <xs:element name="evidenzantwort" type="xs:string" minOccurs="0" />
          <xs:element name="selbsterstellt" type="xs:boolean" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="evidenzDaten">
        <xs:sequence>
          <xs:element name="meldungen" type="tns:evidenzMeldung" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="evidenzMeldung">
        <xs:sequence>
          <xs:element name="beantwortungen" type="tns:evidenzBeantwortung" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="fragestellung" type="xs:string" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="meldungsdatum" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="generelleMedizinischeAntragsdaten">
        <xs:sequence>
          <xs:element name="anamnese" type="xs:string" minOccurs="0" />
          <xs:element name="diagnose" type="xs:string" minOccurs="0" />
          <xs:element name="diagnosecodierung" type="xs:string" minOccurs="0" />
          <xs:element name="erstellungsgrund" type="xs:string" minOccurs="0" />
          <xs:element name="weitereMedizinischeDaten" type="tns:medizinischeDatenerweiterung" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="gewuenschteLeistung">
        <xs:sequence>
          <xs:element name="koerperregion" type="xs:string" minOccurs="0" />
          <xs:element name="kontrastmittel" type="xs:string" minOccurs="0" />
          <xs:element name="leistungfreitext" type="xs:string" minOccurs="0" />
          <xs:element name="leistungfreitextgrund" type="xs:string" minOccurs="0" />
          <xs:element name="leistungsposition" type="xs:string" minOccurs="0" />
          <xs:element name="seite" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="herunterladenAttachments">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="karteKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
          <xs:element name="dateiNummern" type="xs:long" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="herunterladenAttachmentsResponse">
        <xs:sequence>
          <xs:element name="return" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="humAntragsdaten">
        <xs:sequence>
          <xs:element name="dnaArrayanalyse" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="indikationMammographie">
        <xs:sequence>
          <xs:element name="begruendung" type="xs:string" minOccurs="0" />
          <xs:element name="indikation" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="katalogleistung">
        <xs:sequence>
          <xs:element name="anzeigetext" type="xs:string" minOccurs="0" />
          <xs:element name="appc" type="xs:string" minOccurs="0" />
          <xs:element name="indikationsangabe" type="xs:string" minOccurs="0" />
          <xs:element name="kategorienummer" type="xs:string" minOccurs="0" />
          <xs:element name="leistungsposition" type="xs:string" minOccurs="0" />
          <xs:element name="seitenangabe" type="xs:boolean" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="kategorie">
        <xs:sequence>
          <xs:element name="anzeigetext" type="xs:string" minOccurs="0" />
          <xs:element name="kategorienummer" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="kdmAntragsdaten">
        <xs:sequence>
          <xs:element name="fragilitaetsfraktur" type="xs:string" minOccurs="0" />
          <xs:element name="kreatinin" type="xs:string" minOccurs="0" />
          <xs:element name="methode" type="xs:string" minOccurs="0" />
          <xs:element name="tsh" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="kontaktdatenVerordner">
        <xs:sequence>
          <xs:element name="ansprechperson" type="xs:string" minOccurs="0" />
          <xs:element name="email" type="xs:string" minOccurs="0" />
          <xs:element name="telefon" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="kvtAntragstypen">
        <xs:sequence>
          <xs:element name="antragstypen" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="leistungsantragAktuell">
        <xs:sequence>
          <xs:element name="adressePatient" type="tns:adressdaten" minOccurs="0" />
          <xs:element name="ansprechpersonPatient" type="xs:string" minOccurs="0" />
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="attachmentInfo" type="tns:attachmentInfo" minOccurs="0" />
          <xs:element name="ctAntragsdaten" type="tns:ctAntragsdaten" minOccurs="0" />
          <xs:element name="ekvkPatient" type="tns:ekvkPatient" minOccurs="0" />
          <xs:element name="fachgebiet" type="xs:string" minOccurs="0" />
          <xs:element name="generelleMedizinischeAntragsdaten" type="tns:generelleMedizinischeAntragsdaten" minOccurs="0" />
          <xs:element name="gewuenschteLeistungen" type="tns:gewuenschteLeistung" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="kdmAntragsdaten" type="tns:kdmAntragsdaten" minOccurs="0" />
          <xs:element name="kontaktdatenVerordner" type="tns:kontaktdatenVerordner" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="mrAntragsdaten" type="tns:mrAntragsdaten" minOccurs="0" />
          <xs:element name="nukAntragsdaten" type="tns:nukAntragsdaten" minOccurs="0" />
          <xs:element name="patientenverstaendigung" type="tns:verstaendigung" minOccurs="0" />
          <xs:element name="roetAntragsdaten" type="tns:roetAntragsdaten" minOccurs="0" />
          <xs:element name="roeuAntragsdaten" type="tns:roeuAntragsdaten" minOccurs="0" />
          <xs:element name="sonoAntragsdaten" type="tns:sonoAntragsdaten" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="leistungsantragNacherfassen">
        <xs:sequence>
          <xs:element name="adressePatient" type="tns:adressdaten" minOccurs="0" />
          <xs:element name="ansprechpersonNacherfasser" type="xs:string" minOccurs="0" />
          <xs:element name="ansprechpersonPatient" type="xs:string" minOccurs="0" />
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="attachmentInfo" type="tns:attachmentInfo" minOccurs="0" />
          <xs:element name="ctAntragsdaten" type="tns:ctAntragsdaten" minOccurs="0" />
          <xs:element name="ekvkPatient" type="tns:ekvkPatient" minOccurs="0" />
          <xs:element name="generelleMedizinischeAntragsdaten" type="tns:generelleMedizinischeAntragsdaten" minOccurs="0" />
          <xs:element name="gewuenschteLeistungen" type="tns:gewuenschteLeistung" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="humAntragsdaten" type="tns:humAntragsdaten" minOccurs="0" />
          <xs:element name="kdmAntragsdaten" type="tns:kdmAntragsdaten" minOccurs="0" />
          <xs:element name="kontaktdatenVerordner" type="tns:kontaktdatenVerordner" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="mrAntragsdaten" type="tns:mrAntragsdaten" minOccurs="0" />
          <xs:element name="nukAntragsdaten" type="tns:nukAntragsdaten" minOccurs="0" />
          <xs:element name="patientenverstaendigung" type="tns:verstaendigung" minOccurs="0" />
          <xs:element name="roetAntragsdaten" type="tns:roetAntragsdaten" minOccurs="0" />
          <xs:element name="roeuAntragsdaten" type="tns:roeuAntragsdaten" minOccurs="0" />
          <xs:element name="sonoAntragsdaten" type="tns:sonoAntragsdaten" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="verordnerFreitextangabe" type="tns:verordnerInformation" minOccurs="0" />
          <xs:element name="verordnerVpnr" type="xs:string" minOccurs="0" />
          <xs:element name="verordnungsdatum" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="leistungsbezieher">
        <xs:sequence>
          <xs:element name="adresse" type="tns:adressdaten" minOccurs="0" />
          <xs:element name="ansprechpersonPatient" type="xs:string" minOccurs="0" />
          <xs:element name="ekvkPatient" type="tns:ekvkPatient" minOccurs="0" />
          <xs:element name="patientenverstaendigung" type="tns:verstaendigung" minOccurs="0" />
          <xs:element name="svPatient" type="base:svPersonV2" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="leistungskatalog">
        <xs:sequence>
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="katalogleistungen" type="tns:katalogleistung" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="kategorien" type="tns:kategorie" maxOccurs="unbounded" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="leistungsverordner">
        <xs:sequence>
          <xs:element name="fachgebiet" type="xs:string" minOccurs="0" />
          <xs:element name="kontaktdatenVerordner" type="tns:kontaktdatenVerordner" minOccurs="0" />
          <xs:element name="partnerdaten" type="tns:partnerdaten" minOccurs="0" />
          <xs:element name="verordnerinformation" type="tns:verordnerInformation" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="mammographieIndikationenErmitteln">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="mammographieIndikationenErmittelnResponse">
        <xs:sequence>
          <xs:element name="return" type="base:baseProperty" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="medizinischeDatenerweiterung">
        <xs:sequence>
          <xs:element name="datenbezeichner" type="xs:string" minOccurs="0" />
          <xs:element name="dateninhalt" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="mrAntragsdaten">
        <xs:sequence>
          <xs:element name="bisherigeTherapie" type="xs:string" minOccurs="0" />
          <xs:element name="empfohlen" type="xs:string" minOccurs="0" />
          <xs:element name="fachgebietsbezogen" type="xs:string" minOccurs="0" />
          <xs:element name="klinik" type="xs:string" minOccurs="0" />
          <xs:element name="kreatinin" type="xs:string" minOccurs="0" />
          <xs:element name="tsh" type="xs:string" minOccurs="0" />
          <xs:element name="unfall" type="xs:string" minOccurs="0" />
          <xs:element name="unfalldatum" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="nacherfassenAntrag">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="cardReaderId" type="xs:string" minOccurs="0" />
          <xs:element name="leistungsantragNacherfassen" type="tns:leistungsantragNacherfassen" minOccurs="0" />
          <xs:element name="antragsAttachments" type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="nacherfassenAntragResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsakt" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="nukAntragsdaten">
        <xs:sequence>
          <xs:element name="bisherigeTherapie" type="xs:string" minOccurs="0" />
          <xs:element name="klinik" type="xs:string" minOccurs="0" />
          <xs:element name="kreatinin" type="xs:string" minOccurs="0" />
          <xs:element name="radiopharmakon" type="xs:string" minOccurs="0" />
          <xs:element name="tsh" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="partnerdaten">
        <xs:sequence>
          <xs:element name="titelHinten" type="xs:string" minOccurs="0" />
          <xs:element name="titelVorne" type="xs:string" minOccurs="0" />
          <xs:element name="vorname" type="xs:string" minOccurs="0" />
          <xs:element name="vpnr" type="xs:string" minOccurs="0" />
          <xs:element name="zuname" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="pruefenAdministrativeAntragsdaten">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="cardReaderId" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="ekvkPatient" type="tns:ekvkPatient" minOccurs="0" />
          <xs:element name="aktuell" type="xs:boolean" minOccurs="0" />
          <xs:element name="antragstyp" type="xs:string" minOccurs="0" />
          <xs:element name="fachgebiet" type="xs:string" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="verordnerVpnr" type="xs:string" minOccurs="0" />
          <xs:element name="verordnerFreitext" type="tns:verordnerInformation" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="pruefenAdministrativeAntragsdatenErgebnis">
        <xs:sequence>
          <xs:element name="ekvkPatient" type="tns:ekvkPatient" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="leistungskatalog" type="tns:leistungskatalog" minOccurs="0" />
          <xs:element name="svPatient" type="base:svPersonV2" minOccurs="0" />
          <xs:element name="verordnerPartnerdaten" type="tns:partnerdaten" minOccurs="0" />
          <xs:element name="verordnerPartnerstatus" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="pruefenAdministrativeAntragsdatenResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:pruefenAdministrativeAntragsdatenErgebnis" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="pruefenOriginalverordnerVpnr">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="vpnr" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="pruefenOriginalverordnerVpnrResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:partnerdaten" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="roetAntragsdaten">
        <xs:sequence>
          <xs:element name="bisherigeTherapie" type="xs:string" minOccurs="0" />
          <xs:element name="methode" type="xs:string" minOccurs="0" />
          <xs:element name="methodeBehandlung" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="roeuAntragsdaten">
        <xs:sequence>
          <xs:element name="bisherigeTherapie" type="xs:string" minOccurs="0" />
          <xs:element name="indikationMammographie" type="tns:indikationMammographie" minOccurs="0" />
          <xs:element name="indikationstext" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="sonoAntragsdaten">
        <xs:sequence>
          <xs:element name="bisherigeTherapie" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="stornierenAntrag">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="svNummer" type="xs:string" minOccurs="0" />
          <xs:element name="karteKennnummer" type="xs:string" minOccurs="0" />
          <xs:element name="antragsCode" type="xs:string" minOccurs="0" />
          <xs:element name="stornogrund" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="stornierenAntragResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsaktReferenz" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="uebernehmenAntragsleistungen">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="antragsreferenz" type="xs:string" minOccurs="0" />
          <xs:element name="kvt" type="xs:string" minOccurs="0" />
          <xs:element name="fachgebiet" type="xs:string" minOccurs="0" />
          <xs:element name="alleUebernehmen" type="xs:string" minOccurs="0" />
          <xs:element name="leistungen" type="xs:string" maxOccurs="unbounded" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="uebernehmenAntragsleistungenResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsakt" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="verordnerInformation">
        <xs:sequence>
          <xs:element name="verordneradresse" type="tns:adressdaten" minOccurs="0" />
          <xs:element name="vorname" type="xs:string" minOccurs="0" />
          <xs:element name="zuname" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="verstaendigung">
        <xs:sequence>
          <xs:element name="email" type="xs:string" minOccurs="0" />
          <xs:element name="patientverstaendigung" type="xs:string" minOccurs="0" />
          <xs:element name="telefon" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="widerrufenTerminvereinbarung">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="antragsreferenz" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="widerrufenTerminvereinbarungResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsaktReferenz" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="widerrufenUebernahme">
        <xs:sequence>
          <xs:element name="dialogId" type="xs:string" minOccurs="0" />
          <xs:element name="antragsreferenz" type="xs:string" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="widerrufenUebernahmeResponse">
        <xs:sequence>
          <xs:element name="return" type="tns:bewilligungsakt" minOccurs="0" />
        </xs:sequence>
      </xs:complexType>
    </xs:schema>
  </types>
  <message name="AccessException">
    <part xmlns:baseexc="http://exceptions.soap.base.client.chipkarte.at" name="fault" element="baseexc:AccessException" />
  </message>
  <message name="CardException">
    <part xmlns:baseexc="http://exceptions.soap.base.client.chipkarte.at" name="fault" element="baseexc:CardException" />
  </message>
  <message name="DialogException">
    <part xmlns:baseexc="http://exceptions.soap.base.client.chipkarte.at" name="fault" element="baseexc:DialogException" />
  </message>
  <message name="EbsException">
    <part xmlns:ebsexc="http://exceptions.soap.ebs.client.chipkarte.at" name="fault" element="ebsexc:EbsException" />
  </message>
  <message name="EbsInvalidParameterException">
    <part xmlns:ebsexc="http://exceptions.soap.ebs.client.chipkarte.at" name="fault" element="ebsexc:EbsInvalidParameterException" />
  </message>
  <message name="ServiceException">
    <part xmlns:baseexc="http://exceptions.soap.base.client.chipkarte.at" name="fault" element="baseexc:ServiceException" />
  </message>
  <message name="abfragenAntragMitCode">
    <part name="parameters" element="tns:abfragenAntragMitCode" />
  </message>
  <message name="abfragenAntragMitCodeResponse">
    <part name="parameters" element="tns:abfragenAntragMitCodeResponse" />
  </message>
  <message name="abfragenEbsRelevanteTraeger">
    <part name="parameters" element="tns:abfragenEbsRelevanteTraeger" />
  </message>
  <message name="abfragenEbsRelevanteTraegerResponse">
    <part name="parameters" element="tns:abfragenEbsRelevanteTraegerResponse" />
  </message>
  <message name="abfragenEigeneAntraege">
    <part name="parameters" element="tns:abfragenEigeneAntraege" />
  </message>
  <message name="abfragenEigeneAntraegeResponse">
    <part name="parameters" element="tns:abfragenEigeneAntraegeResponse" />
  </message>
  <message name="antragstypenErmitteln">
    <part name="parameters" element="tns:antragstypenErmitteln" />
  </message>
  <message name="antragstypenErmittelnResponse">
    <part name="parameters" element="tns:antragstypenErmittelnResponse" />
  </message>
  <message name="beantwortenEvidenzmeldung">
    <part name="parameters" element="tns:beantwortenEvidenzmeldung" />
  </message>
  <message name="beantwortenEvidenzmeldungResponse">
    <part name="parameters" element="tns:beantwortenEvidenzmeldungResponse" />
  </message>
  <message name="bekanntgebenTerminvereinbarung">
    <part name="parameters" element="tns:bekanntgebenTerminvereinbarung" />
  </message>
  <message name="bekanntgebenTerminvereinbarungResponse">
    <part name="parameters" element="tns:bekanntgebenTerminvereinbarungResponse" />
  </message>
  <message name="checkStatus">
    <part name="parameters" element="tns:checkStatus" />
  </message>
  <message name="checkStatusResponse">
    <part name="parameters" element="tns:checkStatusResponse" />
  </message>
  <message name="erfassenVerordnerAntrag">
    <part name="parameters" element="tns:erfassenVerordnerAntrag" />
  </message>
  <message name="erfassenVerordnerAntragResponse">
    <part name="parameters" element="tns:erfassenVerordnerAntragResponse" />
  </message>
  <message name="herunterladenAttachments">
    <part name="parameters" element="tns:herunterladenAttachments" />
  </message>
  <message name="herunterladenAttachmentsResponse">
    <part name="parameters" element="tns:herunterladenAttachmentsResponse" />
  </message>
  <message name="mammographieIndikationenErmitteln">
    <part name="parameters" element="tns:mammographieIndikationenErmitteln" />
  </message>
  <message name="mammographieIndikationenErmittelnResponse">
    <part name="parameters" element="tns:mammographieIndikationenErmittelnResponse" />
  </message>
  <message name="nacherfassenAntrag">
    <part name="parameters" element="tns:nacherfassenAntrag" />
  </message>
  <message name="nacherfassenAntragResponse">
    <part name="parameters" element="tns:nacherfassenAntragResponse" />
  </message>
  <message name="pruefenAdministrativeAntragsdaten">
    <part name="parameters" element="tns:pruefenAdministrativeAntragsdaten" />
  </message>
  <message name="pruefenAdministrativeAntragsdatenResponse">
    <part name="parameters" element="tns:pruefenAdministrativeAntragsdatenResponse" />
  </message>
  <message name="pruefenOriginalverordnerVpnr">
    <part name="parameters" element="tns:pruefenOriginalverordnerVpnr" />
  </message>
  <message name="pruefenOriginalverordnerVpnrResponse">
    <part name="parameters" element="tns:pruefenOriginalverordnerVpnrResponse" />
  </message>
  <message name="stornierenAntrag">
    <part name="parameters" element="tns:stornierenAntrag" />
  </message>
  <message name="stornierenAntragResponse">
    <part name="parameters" element="tns:stornierenAntragResponse" />
  </message>
  <message name="uebernehmenAntragsleistungen">
    <part name="parameters" element="tns:uebernehmenAntragsleistungen" />
  </message>
  <message name="uebernehmenAntragsleistungenResponse">
    <part name="parameters" element="tns:uebernehmenAntragsleistungenResponse" />
  </message>
  <message name="widerrufenTerminvereinbarung">
    <part name="parameters" element="tns:widerrufenTerminvereinbarung" />
  </message>
  <message name="widerrufenTerminvereinbarungResponse">
    <part name="parameters" element="tns:widerrufenTerminvereinbarungResponse" />
  </message>
  <message name="widerrufenUebernahme">
    <part name="parameters" element="tns:widerrufenUebernahme" />
  </message>
  <message name="widerrufenUebernahmeResponse">
    <part name="parameters" element="tns:widerrufenUebernahmeResponse" />
  </message>
  <portType name="IEbsService">
    <operation name="abfragenAntragMitCode">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCodeRequest" message="tns:abfragenAntragMitCode" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCodeResponse" message="tns:abfragenAntragMitCodeResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCode/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCode/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCode/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCode/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenAntragMitCode/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="abfragenEbsRelevanteTraeger">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEbsRelevanteTraegerRequest" message="tns:abfragenEbsRelevanteTraeger" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEbsRelevanteTraegerResponse" message="tns:abfragenEbsRelevanteTraegerResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEbsRelevanteTraeger/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEbsRelevanteTraeger/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEbsRelevanteTraeger/Fault/EbsException" message="tns:EbsException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEbsRelevanteTraeger/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="abfragenEigeneAntraege">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraegeRequest" message="tns:abfragenEigeneAntraege" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraegeResponse" message="tns:abfragenEigeneAntraegeResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraege/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraege/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraege/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraege/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/abfragenEigeneAntraege/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="antragstypenErmitteln">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/antragstypenErmittelnRequest" message="tns:antragstypenErmitteln" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/antragstypenErmittelnResponse" message="tns:antragstypenErmittelnResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/antragstypenErmitteln/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/antragstypenErmitteln/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/antragstypenErmitteln/Fault/EbsException" message="tns:EbsException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/antragstypenErmitteln/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="beantwortenEvidenzmeldung">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldungRequest" message="tns:beantwortenEvidenzmeldung" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldungResponse" message="tns:beantwortenEvidenzmeldungResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldung/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldung/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldung/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldung/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/beantwortenEvidenzmeldung/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="bekanntgebenTerminvereinbarung">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarungRequest" message="tns:bekanntgebenTerminvereinbarung" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarungResponse" message="tns:bekanntgebenTerminvereinbarungResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarung/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarung/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarung/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarung/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/bekanntgebenTerminvereinbarung/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="checkStatus">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/checkStatusRequest" message="tns:checkStatus" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/checkStatusResponse" message="tns:checkStatusResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/checkStatus/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/checkStatus/Fault/DialogException" message="tns:DialogException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/checkStatus/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="erfassenVerordnerAntrag">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntragRequest" message="tns:erfassenVerordnerAntrag" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntragResponse" message="tns:erfassenVerordnerAntragResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntrag/Fault/AccessException" message="tns:AccessException" />
      <fault name="CardException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntrag/Fault/CardException" message="tns:CardException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntrag/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntrag/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntrag/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/erfassenVerordnerAntrag/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="herunterladenAttachments">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachmentsRequest" message="tns:herunterladenAttachments" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachmentsResponse" message="tns:herunterladenAttachmentsResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachments/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachments/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachments/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachments/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/herunterladenAttachments/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="mammographieIndikationenErmitteln">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/mammographieIndikationenErmittelnRequest" message="tns:mammographieIndikationenErmitteln" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/mammographieIndikationenErmittelnResponse" message="tns:mammographieIndikationenErmittelnResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/mammographieIndikationenErmitteln/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/mammographieIndikationenErmitteln/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/mammographieIndikationenErmitteln/Fault/EbsException" message="tns:EbsException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/mammographieIndikationenErmitteln/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="nacherfassenAntrag">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntragRequest" message="tns:nacherfassenAntrag" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntragResponse" message="tns:nacherfassenAntragResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntrag/Fault/AccessException" message="tns:AccessException" />
      <fault name="CardException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntrag/Fault/CardException" message="tns:CardException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntrag/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntrag/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntrag/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/nacherfassenAntrag/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="pruefenAdministrativeAntragsdaten">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdatenRequest" message="tns:pruefenAdministrativeAntragsdaten" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdatenResponse" message="tns:pruefenAdministrativeAntragsdatenResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdaten/Fault/AccessException" message="tns:AccessException" />
      <fault name="CardException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdaten/Fault/CardException" message="tns:CardException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdaten/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdaten/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdaten/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenAdministrativeAntragsdaten/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="pruefenOriginalverordnerVpnr">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnrRequest" message="tns:pruefenOriginalverordnerVpnr" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnrResponse" message="tns:pruefenOriginalverordnerVpnrResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnr/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnr/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnr/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnr/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/pruefenOriginalverordnerVpnr/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="stornierenAntrag">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntragRequest" message="tns:stornierenAntrag" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntragResponse" message="tns:stornierenAntragResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntrag/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntrag/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntrag/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntrag/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/stornierenAntrag/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="uebernehmenAntragsleistungen">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungenRequest" message="tns:uebernehmenAntragsleistungen" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungenResponse" message="tns:uebernehmenAntragsleistungenResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungen/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungen/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungen/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungen/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/uebernehmenAntragsleistungen/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="widerrufenTerminvereinbarung">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarungRequest" message="tns:widerrufenTerminvereinbarung" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarungResponse" message="tns:widerrufenTerminvereinbarungResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarung/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarung/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarung/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarung/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenTerminvereinbarung/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
    <operation name="widerrufenUebernahme">
      <input wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahmeRequest" message="tns:widerrufenUebernahme" />
      <output wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahmeResponse" message="tns:widerrufenUebernahmeResponse" />
      <fault name="AccessException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahme/Fault/AccessException" message="tns:AccessException" />
      <fault name="DialogException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahme/Fault/DialogException" message="tns:DialogException" />
      <fault name="EbsException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahme/Fault/EbsException" message="tns:EbsException" />
      <fault name="EbsInvalidParameterException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahme/Fault/EbsInvalidParameterException" message="tns:EbsInvalidParameterException" />
      <fault name="ServiceException" wsam:Action="http://soap.ebs.client.chipkarte.at/IEbsService/widerrufenUebernahme/Fault/ServiceException" message="tns:ServiceException" />
    </operation>
  </portType>
  <binding name="ebs_5Binding" type="tns:IEbsService">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
    <operation name="abfragenAntragMitCode">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="abfragenEbsRelevanteTraeger">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="abfragenEigeneAntraege">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="antragstypenErmitteln">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="beantwortenEvidenzmeldung">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="bekanntgebenTerminvereinbarung">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="checkStatus">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="erfassenVerordnerAntrag">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="CardException">
        <soap:fault name="CardException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="herunterladenAttachments">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="mammographieIndikationenErmitteln">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="nacherfassenAntrag">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="CardException">
        <soap:fault name="CardException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="pruefenAdministrativeAntragsdaten">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="CardException">
        <soap:fault name="CardException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="pruefenOriginalverordnerVpnr">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="stornierenAntrag">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="uebernehmenAntragsleistungen">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="widerrufenTerminvereinbarung">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
    <operation name="widerrufenUebernahme">
      <soap:operation soapAction="" />
      <input>
        <soap:body use="literal" />
      </input>
      <output>
        <soap:body use="literal" />
      </output>
      <fault name="AccessException">
        <soap:fault name="AccessException" use="literal" />
      </fault>
      <fault name="DialogException">
        <soap:fault name="DialogException" use="literal" />
      </fault>
      <fault name="EbsException">
        <soap:fault name="EbsException" use="literal" />
      </fault>
      <fault name="EbsInvalidParameterException">
        <soap:fault name="EbsInvalidParameterException" use="literal" />
      </fault>
      <fault name="ServiceException">
        <soap:fault name="ServiceException" use="literal" />
      </fault>
    </operation>
  </binding>
  <service name="EbsService">
    <port name="ebs_5" binding="tns:ebs_5Binding">
      <soap:address location="http://localhost/ebs/5" />
    </port>
  </service>
</definitions>

----------
Added file: https://bugs.python.org/file48049/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________
-------------- next part --------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="de" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /><title></title><style type="text/css">html,body{background-color:#fff;color:#333;line-height:1.4;font-family:sans-serif,Arial,Verdana,Trebuchet MS;}</style></head><body><p>Dear Mr. Singaralevan</p>

<p>Thank you very much for your prompt reaction! This is a shot snippet:</p>

<p>def execute(self,ip,function,params):<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; global xmltree<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; global envelope<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; operations = xmltree.getElementsByTagName("operation")</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passOn = False</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for operation in operations:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if operation.getAttribute("name") == function:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passOn = True</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (passOn == False):</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (function == 'getStaatenISO3166alpha2'):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # another wsdl File where this function is not found<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passOn = True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (function == 'mammographieIndikationenErmitteln'):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # the reported wsdl file (see attachment)<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passOn = True<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (function == 'antragstypenErmitteln'):<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; import pdb; pdb.set_trace()<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; passOn = True</p>

<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if passOn: .........</p>

<p>Setting a breakpoint after if (passOn == False): the result is</p>

<p>(Pdb) print(operations[0].getAttribute("name"))<br>
abfragenAntragMitCode&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &lt;operation name="abfragenAntragMitCode"&gt;<br>
(Pdb) print(operations[1].getAttribute("name"))<br>
abfragenEbsRelevanteTraeger&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="abfragenEbsRelevanteTraeger"&gt;<br>
(Pdb) print(operations[2].getAttribute("name"))<br>
abfragenEigeneAntraege&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="abfragenEigeneAntraege"&gt;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; <span style="color:#FF0000;">missing</span>: &lt;operation name="antragstypenErmitteln"&gt;<br>
(Pdb) print(operations[3].getAttribute("name"))<br>
beantwortenEvidenzmeldung&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="beantwortenEvidenzmeldung"&gt;<br>
(Pdb) print(operations[4].getAttribute("name"))<br>
bekanntgebenTerminvereinbarung&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="bekanntgebenTerminvereinbarung"&gt;<br>
(Pdb) print(operations[5].getAttribute("name"))<br>
checkStatus&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="checkStatus"&gt;<br>
(Pdb) print(operations[6].getAttribute("name"))<br>
erfassenVerordnerAntrag&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="erfassenVerordnerAntrag"&gt;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<br>
(Pdb) print(operations[7].getAttribute("name"))<br>
herunterladenAttachments&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="herunterladenAttachments"&gt;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;<span style="color:#FF0000;">missing</span>: &lt;operation name="mammographieIndikationenErmitteln"&gt;<br>
(Pdb) print(operations[8].getAttribute("name"))<br>
nacherfassenAntrag&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="nacherfassenAntrag"&gt;<br>
(Pdb) print(operations[9].getAttribute("name"))<br>
pruefenAdministrativeAntragsdaten&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="pruefenAdministrativeAntragsdaten"&gt;<br>
(Pdb) print(operations[10].getAttribute("name"))<br>
pruefenOriginalverordnerVpnr&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="pruefenOriginalverordnerVpnr"&gt;<br>
(Pdb) print(operations[11].getAttribute("name"))<br>
stornierenAntrag&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="stornierenAntrag"&gt;<br>
(Pdb) print(operations[12].getAttribute("name"))<br>
uebernehmenAntragsleistungen&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="uebernehmenAntragsleistungen"&gt;<br>
(Pdb) print(operations[13].getAttribute("name"))<br>
widerrufenTerminvereinbarung&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="widerrufenTerminvereinbarung"&gt;<br>
(Pdb) print(operations[14].getAttribute("name"))<br>
widerrufenUebernahme&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&lt;operation name="widerrufenUebernahme"&gt;<br>
(Pdb) print(operations[15].getAttribute("name"))<br>
abfragenAntragMitCode<br>
(Pdb) print(operations[16].getAttribute("name"))<br>
abfragenEbsRelevanteTraeger<br>
(Pdb) print(operations[17].getAttribute("name"))<br>
abfragenEigeneAntraege<br>
(Pdb) print(operations[18].getAttribute("name"))<br>
beantwortenEvidenzmeldung<br>
(Pdb) print(operations[19].getAttribute("name"))<br>
bekanntgebenTerminvereinbarung<br>
(Pdb) print(operations[20].getAttribute("name"))<br>
checkStatus<br>
(Pdb) print(operations[21].getAttribute("name"))<br>
erfassenVerordnerAntrag<br>
(Pdb) print(operations[22].getAttribute("name"))<br>
herunterladenAttachments<br>
(Pdb) print(operations[23].getAttribute("name"))<br>
nacherfassenAntrag<br>
(Pdb) print(operations[24].getAttribute("name"))<br>
pruefenAdministrativeAntragsdaten<br>
(Pdb) print(operations[25].getAttribute("name"))<br>
pruefenOriginalverordnerVpnr<br>
(Pdb) print(operations[26].getAttribute("name"))<br>
stornierenAntrag<br>
(Pdb) print(operations[27].getAttribute("name"))<br>
uebernehmenAntragsleistungen<br>
(Pdb) print(operations[28].getAttribute("name"))<br>
widerrufenTerminvereinbarung<br>
(Pdb) print(operations[29].getAttribute("name"))<br>
widerrufenUebernahme<br>
(Pdb) print(operations[30].getAttribute("name"))<br>
*** IndexError: list index out of range<br>
(Pdb)<br>
34 times found '&lt;operations name=' in EbsService.wsdl using notepad++ - see attached File. I think loading the wsdl file to the xmltree it should be easily possible to reproduce this problem</p>

<div>Kind regards<br>
<br>
Michael Kr??tlinger<br>
Dr. Ferschitzstr. 2<br>
3160 Traisen</div>

<p>Karthikeyan Singaravelan schrieb am 14.01.2019 15:04:</p>

<blockquote cite="mid:1547474663.29.0.909592562406.issue35736 at roundup.psfhosted.org" type="cite">
<pre>Karthikeyan Singaravelan &lt;tir.karthi at gmail.com&gt; added the comment:

Thanks for the report. Please post a minimal code snippet with what you are
expecting and the actual output of the program explaining the problem and how
it's a bug in Python and not the actual code's logic.

----------
nosy: +xtreak

_______________________________________
Python tracker &lt;report at bugs.python.org&gt;
&lt;<a href="https://bugs.python.org/issue35736" target="_blank" title="https://bugs.python.org/issue35736">https://bugs.python.org/issue35736</a>&gt;
_______________________________________

</pre>
</blockquote></body></html>

From report at bugs.python.org  Tue Jan 15 12:34:08 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 17:34:08 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547573648.82.0.031368782886.issue35746@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


Added file: https://bugs.python.org/file48052/TALOS-2019-0758.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:34:19 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 15 Jan 2019 17:34:19 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547573659.93.0.0245379249114.issue35746@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


Added file: https://bugs.python.org/file48053/TALOS-2019-0758 - POC.pem

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:35:32 2019
From: report at bugs.python.org (Chris Billington)
Date: Tue, 15 Jan 2019 17:35:32 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547573732.1.0.00134784894815.issue33944@roundup.psfhosted.org>


Chris Billington <chrisjbillington at gmail.com> added the comment:

> Linux distros approach to handling this is terrible because they dump all their system packages into a single global site-packages, leading to the every growing sys.path problem that Barry is concerned about.

> However, that's entirely the fault of distro packaging policies, and can be remedied in a far superior way by switching distros to a model where they create a venv per application, and then use .pth files to link in the system packages that they actually want visible to that application.

I'm curious about this since it doesn't make sense to me. Dumping all packages at the top level in /usr/lib/pythonX.Y/site-packages means exactly zero .pth files. Wouldn't putting each module in its own directory, with all the directories necessary for a given app added to the path of a venv for that app mean strictly more .pth files, and a sys.path as long as the list of dependencies for that app? Whilst this would certainly be more flexible for keeping multiple versions of packages around as required by different apps, I don't see that it would decrease startup time at all - more folders need to be searched for each import, not less, and a recursive hierarchy of .pth files would need to be parsed at startup as each package pulled in the directories of its own dependencies. A flat structure like most linux distros use would seem like it would be as efficient as you could get, unless you think that searching through a larger list of strings for the right one is slower than opening a tree of .pth files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:42:22 2019
From: report at bugs.python.org (David Heiberg)
Date: Tue, 15 Jan 2019 17:42:22 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547574142.83.0.960921870616.issue35701@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
keywords: +patch
pull_requests: +11236
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:42:35 2019
From: report at bugs.python.org (David Heiberg)
Date: Tue, 15 Jan 2019 17:42:35 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547574155.1.0.180241005541.issue35701@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11236, 11237
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:42:47 2019
From: report at bugs.python.org (David Heiberg)
Date: Tue, 15 Jan 2019 17:42:47 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547574167.5.0.472785388519.issue35701@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11236, 11237, 11238
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:44:28 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jan 2019 17:44:28 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1547574268.83.0.100728001769.issue35661@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

First, Cheryl, thanks for taking this on!

I think one way to potentially simplify this whole situation about the whitespace for the prompt is to actually store the raw value that gets passed into EnvBuilder instead of the prompt as formatted for the activation scripts. I personally only want that initial value anyway and not the formatted version for the prompt for us in VS Code. Plus if we document that the value that we save in the pyvenv.cfg will be stripped then that should help with this.

Otherwise I say go with the repr as Steve suggested, but I would still like to have access to the unformatted value (and probably not bother setting it if a custom value isn't provided to facilitate relocating venvs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:46:43 2019
From: report at bugs.python.org (BTaskaya)
Date: Tue, 15 Jan 2019 17:46:43 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547574403.69.0.660034250797.issue34782@roundup.psfhosted.org>


Change by BTaskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +11239
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:46:47 2019
From: report at bugs.python.org (BTaskaya)
Date: Tue, 15 Jan 2019 17:46:47 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547574407.07.0.939263961659.issue34782@roundup.psfhosted.org>


Change by BTaskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11239, 11240
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:47:38 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 15 Jan 2019 17:47:38 +0000
Subject: [issue35736] [xml.minidom] Missing component in table after
 getElementsByTagName("nn")
In-Reply-To: <1547472488.22.0.593179518504.issue35736@roundup.psfhosted.org>
Message-ID: <1547574458.9.0.0757019604671.issue35736@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Missing component in table after getElementsByTagName("nn") -> [xml.minidom] Missing component in table after getElementsByTagName("nn")

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35736>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:54:34 2019
From: report at bugs.python.org (ido k)
Date: Tue, 15 Jan 2019 17:54:34 +0000
Subject: [issue35747] Python threading event wait influenced by date change
Message-ID: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>


New submission from ido k <ido.koren.git at gmail.com>:

Happen on ubuntu 

Opening two threads - one thread alternate system date
The seconds waits for 60 seconds. joining both threads.

The execution should take at least 60 seconds. Takes less then 15 seconds.

Any work around?

----------
components: Library (Lib)
files: wrong_wait_behaviour.py
messages: 333718
nosy: ido k
priority: normal
severity: normal
status: open
title: Python threading event wait influenced by date change
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48056/wrong_wait_behaviour.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Tue Jan 15 12:57:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 17:57:17 +0000
Subject: [issue35747] Python threading event wait influenced by date change
In-Reply-To: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>
Message-ID: <1547575037.6.0.263592553576.issue35747@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 3 uses a monotonic clock to implement timeouts, such clock is not affected by system clock changes *on purpose*. See time.monotonic() and PEP 418:
https://docs.python.org/dev/library/time.html#time.monotonic
https://www.python.org/dev/peps/pep-0418/

Relying on the system clock can cause severe bugs.

I suggest to close this issue as "not a bug".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:03:52 2019
From: report at bugs.python.org (ido k)
Date: Tue, 15 Jan 2019 18:03:52 +0000
Subject: [issue35747] Python threading event wait influenced by date change
In-Reply-To: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>
Message-ID: <1547575432.03.0.847914372319.issue35747@roundup.psfhosted.org>


ido k <ido.koren.git at gmail.com> added the comment:

thanks for the comment

please look at the code.
i use wait on event for 60 seconds.
the wait timed out in less than 60 seconds... 

why this is not a bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:04:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:04:27 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1547575467.43.0.378292034162.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

One other aspect of this may be the confusion that ensues when changing the setting doesn't change the prompt when you activate it.

It would be possible (though not necessarily trivial) to update the activate scripts to read the prompt from the file, though I don't think it's necessary. But we'll get a bug report sooner or later anyway.

Maybe if the setting is called "provided-custom-prompt" that will imply enough that it's a optional record of the prompt rather than an active configuration setting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:10:06 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:10:06 +0000
Subject: [issue35739] Enable verbose of tests during PGO build on amd64
 platforms
In-Reply-To: <1547530007.74.0.355457877892.issue35739@roundup.psfhosted.org>
Message-ID: <1547575806.96.0.989385043831.issue35739@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You can provide this new default as a command line option when invoking the script (--pgo-job, IIRC), which should satisfy the occasional need to do this.

I would rather keep the default quieter so that the build does not take as long (though I guess there is the possibility that enabling more output produces a better profile, but I doubt it's significant).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35739>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:18:41 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:18:41 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windows Store
In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>
Message-ID: <1547576321.58.0.858561002793.issue35688@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I posted on the numpy thread: Most likely the DLL is failing to load, which the importer returns as "not found" (as it falls back on other search mechanisms and doesn't retain the error). I suggested loading it directly with ctypes to see if there's a better error indicator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:25:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:25:27 +0000
Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises
 WinError instead of returning False
In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org>
Message-ID: <1547576727.76.0.61104957954.issue35692@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

In issue 22759 there was some logic applied for which errors to forward rather than hide.

I'm inclined to agree that this one should be hidden, but it may have to be done by checking the winerror field rather than the exception type, since other PermissionErrors may mean the file is guaranteed to exist (but you can't touch it) or that the path exists up to the point where you are not allowed to see.

I'd happily argue that since these permissions indicate that the file does not exist *for the current user* and so they should be swallowed more broadly, but I'll let Antoine make the call.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35692>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:31:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:31:20 +0000
Subject: [issue35662] Windows #define _PY_EMULATED_WIN_CV 0 bug
In-Reply-To: <1546658725.61.0.827924851828.issue35662@roundup.psfhosted.org>
Message-ID: <1547577080.52.0.00216490603616.issue35662@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's broken, but unused. And the entire section needs fixing before it can be used, which necessitates fixing this function. So issue 29871 covers this sufficiently (though I'll post a link back to this one for the added context on this particular issue).

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Enable optimized locks on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35662>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:33:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:33:26 +0000
Subject: [issue29871] Enable optimized locks on Windows
In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za>
Message-ID: <1547577206.31.0.526787767817.issue29871@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

On issue 35562 Jeff posted a deeper analysis of the issue in TIMEDWAIT. That will need fixing along with the other regressions before we can enable these.

----------
nosy: +jeffr at livedata.com

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29871>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:37:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:37:36 +0000
Subject: [issue29515] socket module missing IPPROTO_IPV6,
 IPPROTO_IPV4 on Windows
In-Reply-To: <1486664862.54.0.729311605676.issue29515@psf.upfronthosting.co.za>
Message-ID: <1547577456.93.0.709402216169.issue29515@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

No progress, but I like the extra defines idea best (directly in socketmodule.c, not in a public header file). That's the easiest way to close the gap between (apparently) real constants used on Windows and the preprocessor defines (apparently) used elsewhere.

----------
keywords: +easy (C)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29515>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:40:28 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 18:40:28 +0000
Subject: [issue35306] OSError [WinError 123] when testing if pathlib.Path('*')
 (asterisks) exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1547577628.92.0.0218658031809.issue35306@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Pathlib doesn't necessarily directly follow os on its error handling - adding Antoine for comment.

Passing strict=False to resolve() should be able to handle an invalid name like that. If not, I propose that we change it so that it does.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35306>
_______________________________________

From report at bugs.python.org  Tue Jan 15 13:52:55 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jan 2019 18:52:55 +0000
Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises
 WinError instead of returning False
In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org>
Message-ID: <1547578375.94.0.7248501635.issue35692@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think exists() should simply return False here.  There's no reason a non-existing drive should fail differently than a non-existing parent directory.

----------
stage:  -> needs patch
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35692>
_______________________________________

From report at bugs.python.org  Tue Jan 15 14:02:30 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jan 2019 19:02:30 +0000
Subject: [issue35306] OSError [WinError 123] when testing if pathlib.Path('*')
 (asterisks) exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1547578950.74.0.311565100699.issue35306@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm fine with swallowing the error in both exists() and resolve(). We should be careful not to swallow errors too broadly, though.  The code paths should be audited to check that EINVAL can't mean something else.

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35306>
_______________________________________

From report at bugs.python.org  Tue Jan 15 14:27:52 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 15 Jan 2019 19:27:52 +0000
Subject: [issue29871] Enable optimized locks on Windows
In-Reply-To: <1490146396.76.0.76409234296.issue29871@psf.upfronthosting.co.za>
Message-ID: <1547580472.75.0.310109996984.issue29871@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

I assume you meant #35662 (based on the superseder note in the history).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29871>
_______________________________________

From report at bugs.python.org  Tue Jan 15 15:17:18 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 15 Jan 2019 20:17:18 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547583438.83.0.477597579285.issue35746@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


Removed file: https://bugs.python.org/file48054/image001.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 15:17:35 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 15 Jan 2019 20:17:35 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547583455.82.0.235477397101.issue35746@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


Removed file: https://bugs.python.org/file48055/image001.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 16:44:42 2019
From: report at bugs.python.org (mattip)
Date: Tue, 15 Jan 2019 21:44:42 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windows Store
In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>
Message-ID: <1547588682.76.0.813242762065.issue35688@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

It seems changing os.environ['PATH'] is a security risk and is not allowed for Windows Store apps. The suggestion in the NumPy issue is to:

- use AddDllDirectory, (which is as accessable as os.environ['PATH'] but is not considered a security risk so far), but this requires using SetDefaultDllDirectories which breaks other things

- put any dlls required for the c-extension pyd in the same directory which means scipy and numpy will be using duplicate and potentially different OpenBLAS dlls, and whoever imports first wins

- load all the required dlls via LoadLibrary, meaning NumPy will have to export a windows-only API to SciPy so the latter can know where the DLL is.

I am glad NumPy only has one DLL, and not a dozen like QT or wxPython. 

Is there a PEP that describes the overall design of windows directory layout or a design guide for package authors with best practices for additional dll dependencies?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:03:41 2019
From: report at bugs.python.org (Tasy)
Date: Tue, 15 Jan 2019 22:03:41 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547589821.56.0.707139752346.issue35713@roundup.psfhosted.org>


Tasy <obiwan408 at mail.com> added the comment:

Configuration Options: 

 ../configure --prefix=$HOME --enable-shared --enable-optimizations --with-system-expat --with-system-ffi --with-ensurepip=yes



Make throws the following warning:


*** WARNING: renaming "_curses_panel" since importing it failed: No module named '_curses'

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_ssl                  _uuid                                    
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                                                           


Failed to build these modules:
_curses                                                        


Following modules built successfully but were removed because they could not be imported:
_curses_panel                                                  


Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().
LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381

There ther is a following error...

0:06:18 load avg: 0.55 [171/416] test_hashlib
*** Error in `./python': corrupted size vs. prev_size: 0x000000000276b7a0 ***
Fatal Python error: Aborted

Current thread 0x00002ba4468c7bc0 (most recent call first):
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/test_hashlib.py", line 904 in _test_pbkdf2_hmac
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/test_hashlib.py", line 935 in test_pbkdf2_hmac_c
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/case.py", line 615 in run
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/case.py", line 663 in __call__
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/support/testresult.py", line 162 in run
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/support/__init__.py", line 1895 in _run_suite
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/support/__init__.py", line 1991 in run_unittest
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/runtest.py", line 178 in test_runner
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/runtest.py", line 182 in runtest_inner
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/runtest.py", line 137 in runtest
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/main.py", line 407 in run_tests_sequential
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/main.py", line 514 in run_tests
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/main.py", line 615 in _main
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/main.py", line 582 in main
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/libregrtest/main.py", line 636 in main
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/regrtest.py", line 46 in _main
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/regrtest.py", line 50 in <module>
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/runpy.py", line 85 in _run_code
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/runpy.py", line 193 in _run_module_as_main
Aborted (core dumped)
make[1]: Leaving directory `/usr/local/data/mySoftware/Python-3.7.2/build'
make build_all_merge_profile
make[1]: Entering directory `/usr/local/data/mySoftware/Python-3.7.2/build'
true
make[1]: Leaving directory `/usr/local/data/mySoftware/Python-3.7.2/build'
# Remove profile generation binary since we are done with it.
make clean
make[1]: Entering directory `/usr/local/data/mySoftware/Python-3.7.2/build'
find .. -depth -name '__pycache__' -exec rm -rf {} ';'
find .. -name '*.py[co]' -exec rm -f {} ';'
find . -name '*.[oa]' -exec rm -f {} ';'
find . -name '*.s[ol]' -exec rm -f {} ';'
find . -name '*.so.[0-9]*.[0-9]*' -exec rm -f {} ';'
find build -name 'fficonfig.h' -exec rm -f {} ';' || true
find build -name '*.py' -exec rm -f {} ';' || true
find build -name '*.py[co]' -exec rm -f {} ';' || true
rm -f pybuilddir.txt
rm -f Lib/lib2to3/*Grammar*.pickle
rm -f Programs/_testembed Programs/_freeze_importlib
find build -type f -a ! -name '*.gc??' -exec rm -f {} ';'
rm -f Include/pydtrace_probes.h
rm -f profile-gen-stamp
make[1]: Leaving directory `/usr/local/data/mySoftware/Python-3.7.2/build'
# This is an expensive target to build and it does not have proper
# makefile dependency information.  So, we create a "stamp" file
# to record its completion and avoid re-running it.
touch profile-run-stamp
Rebuilding with profile guided optimizations:
rm -f profile-clean-stamp
make build_all CFLAGS_NODIST=" -fprofile-use -fprofile-correction" LDFLAGS_NODIST=""
make[1]: Entering directory `/usr/local/data/mySoftware/Python-3.7.2/build'

And then finally : 

 Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/_tracemalloc.o Modules/hashtable.o  Modules/symtablemodule.o  Modules/xxsubtype.o Python/frozen.o
gcc -pthread -shared     -Wl,--no-as-needed -o libpython3.so -Wl,-hlibpython3.so libpython3.7m.so
gcc -pthread     -Xlinker -export-dynamic -o python Programs/python.o -L. -lpython3.7m -lpthread -ldl  -lutil   -lm  
gcc -pthread     -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o -L. -lpython3.7m -lpthread -ldl  -lutil   -lm  
LD_LIBRARY_PATH=/usr/local/data/mySoftware/Python-3.7.2/build:$HOME/lib:/usr/local/cuda/lib64:$HOME/lib/cuda/lib64:$HOME/lib/cuda/extras/CUPTI/lib64:/usr/local/data/lib:/usr/local/lib/:/usr/lib/ ./python -E -S -m sysconfig --generate-posix-vars ;\
	if test $? -ne 0 ; then \
		echo "generate-posix-vars failed" ; \
		rm -f ./pybuilddir.txt ; \
		exit 1 ; \
	fi
Fatal Python error: _PySys_BeginInit: can't initialize sys module

Current thread 0x00002adc936069c0 (most recent call first):
Aborted (core dumped)
generate-posix-vars failed
make[1]: *** [pybuilddir.txt] Error 1
make[1]: Leaving directory `/usr/local/data/mySoftware/Python-3.7.2/build'
make: *** [profile-opt] Error 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:10:44 2019
From: report at bugs.python.org (John Parejko)
Date: Tue, 15 Jan 2019 22:10:44 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1547590244.14.0.918213190703.issue23078@roundup.psfhosted.org>


John Parejko <parejkoj at gmail.com> added the comment:

Were you able to make any progress on this? Do you need any help?

----------
nosy: +parejkoj-3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:37:35 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 15 Jan 2019 22:37:35 +0000
Subject: [issue35688] "pip install --user numpy" fails on Python from the
 Windows Store
In-Reply-To: <1546987520.17.0.731862977401.issue35688@roundup.psfhosted.org>
Message-ID: <1547591855.17.0.933189868708.issue35688@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> use AddDllDirectory, (which is as accessable as os.environ['PATH'] but is not considered a security risk so far)

The parenthical is incorrect. The user-specified DLL search directory is separate from PATH, and both appear in the default DLL search order when resolving relative paths. In more secure configurations, PATH is not used for DLL resolution.

> but this requires using SetDefaultDllDirectories which breaks other things

Specifically, it breaks any extension relying on the implicit default search order by enabling one of the more secure configurations.

> put any dlls required for the c-extension pyd in the same directory which means scipy and numpy will be using duplicate and potentially different OpenBLAS dlls, and whoever imports first wins

Doesn't scipy import numpy? Which means numpy wins every time. Or alternatively, put "-numpy" in the name of numpy's one and "-scipy" in the name of scipy's one, and you can have both.

> load all the required dlls via LoadLibrary, meaning NumPy will have to export a windows-only API to SciPy so the latter can know where the DLL is.

Perhaps that API could be exported via normal module import as is currently is? That way scipy can just "import numpy" to locate numpy?

Alternatively, if you do indeed need to have shared state with scipy, then you should come up with an API that they can depend on. This is how shared state normally works.

> Is there a PEP that describes the overall design of windows directory layout or a design guide for package authors with best practices for additional dll dependencies?

No, but there is a doc page that deserves an update: https://docs.python.org/3/extending/windows.html

If we make a dramatic change to CPython here, then there may be a PEP, but it should still defer to the documentation as that is what gets updated over time.

Currently, the best info comes from https://docs.microsoft.com/windows/desktop/Dlls/dynamic-link-library-search-order and awareness that only the LOAD_WITH_ALTERED_SEARCH_PATH flag is used when loading extension modules (see https://github.com/python/cpython/blob/master/Python/dynload_win.c#L221)


Since I just saw the confirmation at https://docs.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order#search-order-using-load_library_search-flags, I don't think we can safely change the LoadLibraryEx option in CPython until we drop support for Windows 7 completely, as the update containing the new flags may not be installed. If/when we do that, it will break any extension relying on unsafe DLL search semantics (that is, anything appearing in the earlier section but not in this section).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35688>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:46:53 2019
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 15 Jan 2019 22:46:53 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592413.94.0.462510093304.issue35746@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I can confirm this crashes a freshly-built interpreter from the current 3.5 and 3.4 branches.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:47:50 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:47:50 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592470.01.0.137703856225.issue35746@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a37f52436f9aa4b9292878b72f3ff1480e2606c3 by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-35746: Fix segfault in ssl's cert parser (GH-11569)
https://github.com/python/cpython/commit/a37f52436f9aa4b9292878b72f3ff1480e2606c3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:48:03 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:48:03 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592483.6.0.881339550967.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:48:13 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:48:13 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592493.38.0.424412998464.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11241, 11242

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:48:24 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:48:24 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592504.95.0.890880558891.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11241, 11242, 11243

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:48:35 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:48:35 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592515.3.0.62354908344.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11242, 11243, 11244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:48:43 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:48:43 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592523.52.0.885539519701.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11242, 11243, 11244, 11245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:48:52 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:48:52 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592532.43.0.127018554568.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11242, 11243, 11244, 11245, 11247

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:49:01 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 22:49:01 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547592541.48.0.686693766324.issue35746@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11242, 11243, 11244, 11245, 11246, 11247

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:50:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 22:50:16 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547592616.82.0.986167277551.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Serhiy Storchaka:
> I mean that after writing tests they can be tested manually by disabling conditions for posix_spawn one by one. I.e. some tests should fail if remove "stdout is None" and some tests should fail if remove "not close_fds", etc.

I made some manual tests on my PR 11452. I changed close_fds default value from True to False. I also modified my change to use posix_spawnp using Joannah's PR 11554 of bpo-35674.

The following tests fail *as expected*:

* test_close_fds_when_max_fd_is_lowered
* test_exception_errpipe_normal
* test_exception_errpipe_bad_data

The 2 errpipe tests mock subprocess to inject errors in the error pipe... but posix_spawn() doesn't expose its private "error pipe", so the test is not relevant for posix_spawn().

test_close_fds_when_max_fd_is_lowered() tests close_fds=True behavior. It's expected that it fails.

At least, I didn't notice any bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:53:13 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 15 Jan 2019 22:53:13 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547592793.26.0.118099690724.issue35537@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 17:54:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 22:54:23 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547592863.67.0.00962837973551.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Gregory P. Smith:
"""
Thanks for all your research and reference links on this!  As a _posixsubprocess maintainer, I am not against either posix_spawn or vfork being used directly in the future when feasible.

A challenge, especially with platform specific vfork, is making sure we understand exactly which platforms it can work properly on and checking for those both at compile time _and_ runtime (running kernel version and potentially the runtime libc version?) so that we can only use it in situations we are sure it is supposed to behave as desired in.  My guiding philosophy: Be conservative on choosing when such a thing is safe to use.
"""

About "My guiding philosophy: Be conservative on choosing when such a thing is safe to use.", I modified my PR 11452 to only use posix_spawn() on a very small subset of platforms where we know that the implementation is safe. It's different than early implementations which tried to use it as soon as it's available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 18:02:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 23:02:38 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547593358.78.0.484318951391.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 9daecf37a571e98aaf43a387bcc9e41a7132f477 by Victor Stinner in branch 'master':
bpo-35537: subprocess uses os.posix_spawn in some cases (GH-11452)
https://github.com/python/cpython/commit/9daecf37a571e98aaf43a387bcc9e41a7132f477


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 18:03:38 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 23:03:38 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547593418.64.0.975126883162.issue35746@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset be5de958e9052e322b0087c6dba81cdad0c3e031 by Miss Islington (bot) in branch '3.7':
bpo-35746: Fix segfault in ssl's cert parser (GH-11569)
https://github.com/python/cpython/commit/be5de958e9052e322b0087c6dba81cdad0c3e031


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 18:08:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 23:08:07 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547593687.47.0.701627507518.issue35746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

TALOS-2019-0758.txt: "Credit: Discovered by Colin Read and Nicolas Edet of Cisco."

Can we credit them somewhere? Maybe edit the NEWS entry to mention their name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 18:11:55 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Jan 2019 23:11:55 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547593915.01.0.798620228378.issue35746@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 06b15424b0dcacb1c551b2a36e739fffa8d0c595 by Miss Islington (bot) in branch '2.7':
bpo-35746: Fix segfault in ssl's cert parser (GH-11569)
https://github.com/python/cpython/commit/06b15424b0dcacb1c551b2a36e739fffa8d0c595


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 18:28:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Jan 2019 23:28:30 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547594910.44.0.165167247722.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

More benchmarks.

I modified subprocess_bench.py to use:
ARGS = ["/usr/bin/python3", "-S", "-E", "-c", "pass"]
=> Mean +- std dev: [fork_exec] 34.1 ms +- 0.4 ms -> [posix_spawn] 6.85 ms +- 0.08 ms: 4.97x faster (-80%)

Benchmark using:
ARGS = ["/usr/bin/python3", "-c", "pass"]
=> Mean +- std dev: [fork_exec] 44.5 ms +- 0.6 ms -> [posix_spawn] 17.2 ms +- 0.2 ms: 2.58x faster (-61%)

Copy of the previous benchmark using /usr/bin/true:
Mean +- std dev: [fork_exec] 27.1 ms +- 0.4 ms -> [posix_spawn] 447 us +- 163 us: 60.55x faster (-98%)

The benchmark is less impressive with Python which has a longer startup time (7 to 17 ms depending on the -S option).

The speedup is between 2.6x (default) and 5.0x (-S option) faster for Python... to execute "pass" (do nothing).

In short, I understand that vfork removes a fixed cost of 27 ms which is the cost of duplicating the 2 GiB of memory pages.

The speedup depends on the memory footprint of the parent process and the execution time of the child process. The best speedup is when the parent is the largest and the child is the fastest.

--

Another benchmark, I modified subprocess_bench.py with:

BIG_ALLOC = b'x' * (10 * 1024 * 1024 * 1024)   # 10 GiB
ARGS = ["/bin/true"]

Mean +- std dev: [fork_exec] 139 ms +- 9 ms -> [posix_spawn] 420 us +- 208 us: 331.40x faster (-100%)

Here the cost of copying 10 GiB of memory pages is around 138 ms. It's 331x faster ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 19:20:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 00:20:20 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547598020.59.0.837909614938.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11248

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 19:20:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 00:20:36 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547598036.0.0.176993450816.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11248, 11249

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 19:20:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 00:20:51 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547598051.5.0.426410316574.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11248, 11249, 11250

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 19:49:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 00:49:00 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547599740.21.0.258106917033.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

subprocess_bench_stdout.py: benchmark for PR 11575 using stdout=subprocess.PIPE, /usr/bin/pwd, and allocate 2 GiB of memory in the parent process. Result on my laptop:

Mean +- std dev: [fork_exec] 28.2 ms +- 0.3 ms -> [posix_spawn] 561 us +- 209 us: 50.25x faster (-98%)

----------
Added file: https://bugs.python.org/file48057/subprocess_bench_stdout.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Tue Jan 15 20:14:21 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 16 Jan 2019 01:14:21 +0000
Subject: [issue35306] OSError [WinError 123] when testing if pathlib.Path('*')
 (asterisks) exists
In-Reply-To: <1543038959.25.0.788709270274.issue35306@psf.upfronthosting.co.za>
Message-ID: <1547601261.47.0.944143440165.issue35306@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> (sidenote: what os.path operation does Path.resolve() match? 
> Path('nonexistent').resolve() returns a relative path on Python 
> 3.7.1, whereas Path().resolve() returns an absolute path.)

pathlib should resolve 'nonexistent' in Windows. It works as expected in Unix:

    >>> os.getcwd()
    '/etc'
    >>> os.fspath(Path('nonexistent').resolve())
    '/etc/nonexistent'

A PR to implement ntpath.realpath is in development for issue 14094. The proposed implementation calls ntpath.abspath at the start, unless it's an extended path (i.e. prefixed by \\?\). Unlike Unix, Windows normalizes a path in user mode as a text operation before passing it to the kernel and file system. This means there's no problem if abspath removes a reparse point (e.g. symlink or mountpoint) when it resolves a ".." component.

> The code paths should be audited to check that EINVAL can't mean something else.

We'd have to use the Windows error code (e.g. ERROR_INVALID_NAME) if it has to be specific. EINVAL is the default errno value. In particular, EINVAL includes some low-level device failures such as ERROR_IO_DEVICE and errors for operations that a device doesn't implement, which are commonly ERROR_INVALID_PARAMETER, ERROR_INVALID_FUNCTION, and ERROR_NOT_SUPPORTED. 

Also, a few device and files-system errors are mapped to EACCES (e.g. ERROR_NOT_READY and ERROR_SECTOR_NOT_FOUND). If we include EACCES, then files that exist but are inaccessible (e.g. the user isn't allowed to list the parent  directory) will be reported as not existing instead of raising an error. It's what os.path.exists does, but I guess pathlib wants to be more nuanced.

When using C runtime I/O (e.g. open, read, write), it can help to get the last Windows error code, _doserrno [1]. Its value gets set when errno is set by mapping an OS error. The last NT status value may also help in some cases. It gets set whenever an NT status code is mapped to a Windows error via RtlNtStatusToDosError (usually followed immediately by RtlSetLastWin32Error). It would be nice if OSError always included these two values, maybe as "last_winerror" (differentiated from "winerror") and "last_ntstatus".

For example, here's a case of trying to open a file on a CD drive that has no disk in it.

    import ctypes

    doserrno = ctypes.WinDLL('ucrtbase').__doserrno
    doserrno.restype = ctypes.POINTER(ctypes.c_ulong)
    doserrno.errcheck = lambda r, f, a: r[0]

    get_last_nt_status = ctypes.WinDLL('ntdll').RtlGetLastNtStatus
    get_last_nt_status.restype = ctypes.c_ulong

    def test():
        try:
            open('D:\\test.txt')
        except:
            winerror, ntstatus = doserrno(), get_last_nt_status()
            print('Windows error:', winerror)
            print('NT status:', format(ntstatus, '#010x'))
            raise

    >>> test()
    Windows error: 21
    NT status: 0xc0000013
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 3, in test
    PermissionError: [Errno 13] Permission denied: 'D:\\test.txt'

Windows error 21 is ERROR_NOT_READY, so we're already much better informed than EACCES (13). NT status 0xC0000013 is STATUS_NO_MEDIA_IN_DEVICE.

[1]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-doserrno-sys-errlist-and-sys-nerr?view=vs-2017

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35306>
_______________________________________

From report at bugs.python.org  Tue Jan 15 20:16:40 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Jan 2019 01:16:40 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547601400.35.0.221723449136.issue35746@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 216a4d83c3b72f4fdcd81b588dc3f42cc461739a by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-35746: Fix segfault in ssl's cert parser (GH-11569) (GH-11573)
https://github.com/python/cpython/commit/216a4d83c3b72f4fdcd81b588dc3f42cc461739a


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Jan 15 20:36:13 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 16 Jan 2019 01:36:13 +0000
Subject: [issue35692] pathlib.Path.exists() on non-existent drive raises
 WinError instead of returning False
In-Reply-To: <1547002815.07.0.33405132487.issue35692@roundup.psfhosted.org>
Message-ID: <1547602573.92.0.52509733813.issue35692@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> There's no reason a non-existing drive should fail differently than 
> a non-existing parent directory.

The drive exists (or should) if we're getting ERROR_NOT_READY (21). It's likely a removable media device, such as an optical disc or card reader, and there's no media in the device. 

If a logical drive isn't defined at all, we should get ERROR_PATH_NOT_FOUND (from the NT status value STATUS_OBJECT_PATH_NOT_FOUND). This gets mapped to the errno value ENOENT, which is already handled. For example:

    >>> os.stat('Q:/')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    FileNotFoundError: [WinError 3] The system cannot find the path specified: 'Q:/'

    >>> pathlib.Path('Q:/whatever/blah.txt').exists()
    False

Similarly if a UNC 'drive' doesn't exist, we should get ERROR_BAD_NET_NAME (from NT STATUS_BAD_NETWORK_NAME), which is also mapped to ENOENT:

    >>> os.stat('//some/where')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    FileNotFoundError: [WinError 67] The network name cannot be found: '//some/where'

    >>> pathlib.Path('//some/where/whatever/blah.txt').exists()
    False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35692>
_______________________________________

From report at bugs.python.org  Tue Jan 15 22:21:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Jan 2019 03:21:45 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547608905.86.0.760696764287.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11183

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Tue Jan 15 22:22:04 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Jan 2019 03:22:04 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547608924.41.0.118899066026.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11182

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Tue Jan 15 22:59:59 2019
From: report at bugs.python.org (Henry Chen)
Date: Wed, 16 Jan 2019 03:59:59 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547611199.5.0.0842445724507.issue34782@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


----------
nosy: +scotchka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Tue Jan 15 23:15:59 2019
From: report at bugs.python.org (Kyle Evans)
Date: Wed, 16 Jan 2019 04:15:59 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547612159.68.0.927563044068.issue35537@roundup.psfhosted.org>


Kyle Evans <kevans at FreeBSD.org> added the comment:

> * On FreeBSD, if setting posix_spawn() "attributes" or execute posix_spawn() "file actions" fails, posix_spawn() succeed but the child process exits immediately with exit code 127 without trying to call execv(). If execv() fails, posix_spawn() succeed, but the child process exit with exit code 127.

Hi,

As a disclaimer, I'm a FreeBSD developer interested in making sure we're doing the right thing here. =)

May I ask what the above assessment is based on, and specifically what we need to address?

As far as I can tell, our implementation is as POSIX describes -- errors processing the file actions or attrs triggers a 127 exit [1][2] which get bubbled up via the return value to posix_spawn [3]. exec failures capture errno at [4] and bubble the error up to the return value of posix_spawn as well via [3]. POSIX explicitly does not require an implementation to use errno for this, only return values, and we seem to have gone the route of not using errno to match OpenSolaris behavior.

What do I need to do to reproduce the results for deriving the results seen in the above quote, so that I can fix us and we can also see this improvement?

I threw together a minimal C reproducer for posix-spawn on -current (this particular bit being unchanged since FreeBSD 11.x times) and was returned ENOENT for a bad exec and otherwise given a pid for successful exec with a return of 0.

[1] https://svnweb.freebsd.org/base/head/lib/libc/gen/posix_spawn.c?view=markup#l214
[2] https://svnweb.freebsd.org/base/head/lib/libc/gen/posix_spawn.c?view=markup#l219
[3] https://svnweb.freebsd.org/base/head/lib/libc/gen/posix_spawn.c?view=markup#l232
[4] https://svnweb.freebsd.org/base/head/lib/libc/gen/posix_spawn.c?view=markup#l225

----------
nosy: +kevans

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 02:45:27 2019
From: report at bugs.python.org (Neeraj Sonaniya)
Date: Wed, 16 Jan 2019 07:45:27 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
Message-ID: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>


New submission from Neeraj Sonaniya <nsonaniya2010 at gmail.com>:

Summary:
It have been identified that `urlparse` under `urllib.parse` module is detecting wrong hostname which could leads to a security issue known as Open redirect vulnerability.

Steps to reproduce the issue:

Following code will help you in reproducing the issue:

```
from urllib.parse import urlparse
x= 'http://www.google.com\@xxx.com'
y = urlparse(x)
print(y.hostname)
```

Output:
xxx.com

The hostname from above URL which is actually rendered by browser is : 'https://www.google.com'.

In following browsers tested: (hostname detected as: https://www.google.com)

```
1. Chromium - Version 72.0.3626.7  - Developer Build
2. Firefox - 60.4.0esr (64-bit)
3. Internet Explorer - 11.0.9600.17843
4. Safari - Version 12.0.2 (14606.3.4)
```

----------
components: Library (Lib)
files: Screenshot from 2019-01-16 12-47-22.png
messages: 333750
nosy: nsonaniya2010, orsenthil
priority: normal
severity: normal
status: open
title: urlparse library detecting wrong hostname leads to open redirect vulnerability
type: security
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48058/Screenshot from 2019-01-16 12-47-22.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 03:03:16 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 08:03:16 +0000
Subject: [issue34148] Fatal error on SSL transport
In-Reply-To: <1531923784.93.0.56676864532.issue34148@psf.upfronthosting.co.za>
Message-ID: <1547625796.82.0.989062677688.issue34148@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +11251
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34148>
_______________________________________

From report at bugs.python.org  Wed Jan 16 03:03:20 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 08:03:20 +0000
Subject: [issue34148] Fatal error on SSL transport
In-Reply-To: <1531923784.93.0.56676864532.issue34148@psf.upfronthosting.co.za>
Message-ID: <1547625800.86.0.9510583378.issue34148@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11251, 11252
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34148>
_______________________________________

From report at bugs.python.org  Wed Jan 16 03:03:23 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 08:03:23 +0000
Subject: [issue34148] Fatal error on SSL transport
In-Reply-To: <1531923784.93.0.56676864532.issue34148@psf.upfronthosting.co.za>
Message-ID: <1547625803.92.0.799377203642.issue34148@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11251, 11252, 11253
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34148>
_______________________________________

From report at bugs.python.org  Wed Jan 16 03:17:27 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 08:17:27 +0000
Subject: [issue35749] Ignore exception if event loop wakeup pipe is full
Message-ID: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Asyncio uses a pipe to wakeup event loop in cases of
1. Signal handlers (set_wakeup_fd)
2. Calling asyncio code from another thread

In both cases, it sends b'\0' to the pipe to wake up a loop.
If the pipe is full OSError is raised.
asyncio logs these exceptions in debug mode.
The logging can be omitted because if the pipe is full the loop wakes up and drains the pipe anyway.

----------
messages: 333751
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Ignore exception if event loop wakeup pipe is full

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 03:18:10 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 08:18:10 +0000
Subject: [issue35749] Ignore exception if event loop wakeup pipe is full
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547626690.09.0.230179912009.issue35749@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: +asyncio
nosy: +yselivanov
type:  -> enhancement
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 03:18:24 2019
From: report at bugs.python.org (Anil kunduru)
Date: Wed, 16 Jan 2019 08:18:24 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
Message-ID: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>


New submission from Anil kunduru <kunduruanilwork at gmail.com>:

function contains of long loop each iteration it will do get data from different website using request.get and do analysis, loop will take one minute for 10 iteration.
after completed some 100 to 400 iteration it will exit with process finished with exit code -1073740940 (0xc0000374) do no what is this unexpected behavior!

----------
messages: 333752
nosy: kunduruanil
priority: normal
severity: normal
status: open
title: process finished with exit code -1073740940 (0xc0000374)
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Wed Jan 16 04:07:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 16 Jan 2019 09:07:46 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547629666.63.0.367743029568.issue35750@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Please include a minimal code snippet without external dependencies to reproduce the issue. Describe what you have done (script, traceback, operating system environment etc) and what you are expecting. Without these information it's unclear to debug a crash and especially if it's a bug in Python or the logic in the code.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Wed Jan 16 04:18:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 16 Jan 2019 09:18:29 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547630309.18.0.5343692427.issue35748@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 04:43:18 2019
From: report at bugs.python.org (Anil kunduru)
Date: Wed, 16 Jan 2019 09:43:18 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547631798.0.0.39590057869.issue35750@roundup.psfhosted.org>


Anil kunduru <kunduruanilwork at gmail.com> added the comment:

i am figuring out as heap memory issue because i am using multiple data frames and online web scrap data as well , may be memory is overloaded and it cause this issue .
please correct me it may not be changes or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Wed Jan 16 04:46:23 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 09:46:23 +0000
Subject: [issue35749] Ignore exception if event loop wakeup pipe is full
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547631983.49.0.321819243133.issue35749@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +11254
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 04:46:28 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 09:46:28 +0000
Subject: [issue35749] Ignore exception if event loop wakeup pipe is full
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547631988.54.0.295166920486.issue35749@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11254, 11255
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 04:46:33 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 09:46:33 +0000
Subject: [issue35749] Ignore exception if event loop wakeup pipe is full
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547631993.74.0.429690725973.issue35749@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11254, 11255, 11256
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 05:01:37 2019
From: report at bugs.python.org (Martin Panter)
Date: Wed, 16 Jan 2019 10:01:37 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547632897.49.0.33726596936.issue35748@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

FWIW I understand the backslash should be percent-encoded in URLs, otherwise the URL is not valid.

This reminds me of a few other bugs:

* Issue 30500: Made the behaviour of fragment (#. . .) versus userinfo (. . .@) consistent, e.g. in //www.google.com#@xxx.com
* Issue 18140: Also about the ambiguity of fragment (#. . .) and query (?. . .) versus userinfo (. . .@)
* Issue 23328: Precedence of path segment (/. . .) versus userinfo (. . .@); e.g. //user/name:pass/word at www.google.com

I think people some times come up with these invalid URLs because they are trying to make a URL that includes a password with unusual characters (e.g. for the ?http_proxy? environment variable). So raising an exception or otherwise changing the parsing behaviour could break those cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 05:04:35 2019
From: report at bugs.python.org (Neeraj Sonaniya)
Date: Wed, 16 Jan 2019 10:04:35 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547633075.52.0.551830126654.issue35748@roundup.psfhosted.org>


Neeraj Sonaniya <nsonaniya2010 at gmail.com> added the comment:

Hi,

I know that \ (backslash)  should be encoded to url encoding (%5c) but if the same url (without urlencoded form) typed into URL bar of browser we are getting hostname to 'https://www.google.com'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 05:17:40 2019
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 16 Jan 2019 10:17:40 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547633860.8.0.218887684421.issue35748@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

You cannot compare a low level library like Python's urllib module with a user interface like a modern browser. Browsers do a lot of extra work to make sense of user input. For example Firefox and Chrome mangle your example URL and replace \ with /. Firefox even shows a warning when the URL contains user and password:

---
You are about to log in to the site ?python.org? with the username ?user?, but the website does not require authentication. This may be an attempt to trick you.

Is ?python.org? the site you want to visit?
---

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 05:32:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 16 Jan 2019 10:32:03 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547634723.37.0.302554574427.issue35748@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I just tested other implementations in Ruby and Go and they too return host as "evil.com" for "http://www.google.com at evil.com" along with the user info component.

$ ruby -e 'require "uri"; puts URI("http://www.google.com at evil.com").hostname'
evil.com
$ cat /tmp/foo.go
package main

import (
	"fmt"
	"net/url"
)

func main() {
	u, _ := url.Parse(`http://www.google.com at evil.com`)
	fmt.Println(u.Host);
	fmt.Println(u.User);
}
$ go run /tmp/foo.go
evil.com
www.google.com

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 05:34:08 2019
From: report at bugs.python.org (=?utf-8?b?0KLQsNGA0LDRgSDQktC+0LnQvdCw0YDQvtCy0YHRjNC60LjQuQ==?=)
Date: Wed, 16 Jan 2019 10:34:08 +0000
Subject: [issue35751] traceback.clear_frames manages to deadlock a background
 task
Message-ID: <1547634847.81.0.0050263541371.issue35751@roundup.psfhosted.org>


New submission from ????? ????????????? <voyn1991 at gmail.com>:

My use case:
I have a background task, say called "coordination". In that task, I want to catch any errors and push those to the user waiting in the main task and only continue running the background coroutine after the user manually resolves the exception. 

Issue:
When testing the behaviour with ``unittest.Case`` and using ``assertRaises`` to catch the exception, the background coroutine manages to just freeze. I have narrowed it down to ``traceback.clear_frames`` in ``assertRaises`` that causes a GeneratorExit in the background coroutine.

I believe this issue is a duplicate to https://bugs.python.org/issue29211, but wanted to provide another actual use case where it can pop up. Also even if the generator raises a GeneratorExit, why did the background thread freeze is still a mystery to me.

Script to reproduce in my case is attached.

----------
components: asyncio
files: test_async_deadlock.py
messages: 333759
nosy: asvetlov, yselivanov, ????? ?????????????
priority: normal
severity: normal
status: open
title: traceback.clear_frames manages to deadlock a background task
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48059/test_async_deadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35751>
_______________________________________

From report at bugs.python.org  Wed Jan 16 06:32:51 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 16 Jan 2019 11:32:51 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547638371.27.0.975058967314.issue35750@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I assume this is on Windows? 0xc0000374 is a heap corruption error on Windows.

I agree that without a way to reproduce this it will be impossible to track down any error.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Wed Jan 16 06:38:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 11:38:57 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547638737.01.0.339158285934.issue35750@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

You can enable faulthandler to get the Python traceback where the bug occurs. It might help a little bit. Either write the traceback into a file (file argument of faulthandler.enable()) or run your program in a terminal to see the traceback on the terminal.

http://docs.python.org/dev/library/faulthandler.html

I also suggest you to try to run your program using "python -X dev program.py" to enable more debug checks:
https://pythondev.readthedocs.io/debug_tools.html

PYTHONMALLOC=debug environment variable may help.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Wed Jan 16 06:40:01 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 16 Jan 2019 11:40:01 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547638801.38.0.324980901949.issue35750@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

A crash with the code STATUS_HEAP_CORRUPTION (0xC0000374) is due to a bug, not memory exhaustion. The bug may not be the fault of the interpreter or standard library if you're working with extension modules or ctypes. It's easy to corrupt the internal structures of a heap. For example:

    >>> import ctypes
    >>> b = (ctypes.c_char * 100000)()
    >>> ctypes.POINTER(ctypes.c_int)(b)[-1] = 0
    >>> del b

[crashed]

    C:\>echo %errorlevel%
    -1073740940

Heap corruption is best examined with a debugger (e.g. windbg or cdb) attached to the faulting process, with full page heap checking enabled for the executable in the registry (usually set via gflags). This reserves a page before and after each heap allocation to ensure that writes that would otherwise corrupt the heap will instead immediately raise an access violation.

----------
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Wed Jan 16 07:14:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Jan 2019 12:14:36 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547640876.85.0.485845113606.issue34782@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is no a crash. There is just an exception raised when you pass an inappropriate object as locals. This is an expected behavior, and I do not think that anything need to be changed.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Wed Jan 16 07:42:11 2019
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 16 Jan 2019 12:42:11 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1547642531.22.0.465762655357.issue35746@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The bug is less critical and harder to exploit than I initially thought. td;dr if you have cert validation enabled and only trust public root CAs from CA/B forum, then you are not affected.

The bug is only exploitable under two conditions:
1) The user has disabled TLS/SSL certificate validation *and* calls getpeercert() in 3rd party code.
2) Or the user trusts a CA that does not properly validate end-entity certificates.

When cert validation is enabled, the ssl module will refuse any untrusted certificate during the handshake. The SSLSocket.getpeercert() and SSLObject.getpeercert() methods raise an exception, when the handshake was not successful. Python 2.7 - 3.6 hostname verification code only calls getpeercert() after the cert chain was validated successfully. Python 3.7+ no longer calls getpeercert() for hostname verification. Further more hostname verification can't be enabled when cert validation is disabled.

For publicly trusted CAs governed by CA/B baseline requirements, CRL DPs must by valid URI general names with HTTP links. From CA/Browser Forum Baseline Requirements Version 1.6.2, December 10, 2018, section 7.1.2.3. Subscriber Certificate:

b. cRLDistributionPoints
This extension MAY be present. If present, it MUST NOT be marked critical, and it MUST contain the HTTP URL of the CA?s CRL service.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Wed Jan 16 08:00:50 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 16 Jan 2019 13:00:50 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1547643650.04.0.327216212872.issue13285@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> In Jeroen's API, I can see what the Python-level signal handler is, but there's no way to find out whether that signal handler is actually in use or not.

I added support for that in the latest cysignals release. Now you can do

>>> import signal
>>> from cysignals.pysignals import getossignal, python_os_handler
>>> _ = signal.signal(signal.SIGINT, signal.default_int_handler)
>>> getossignal(signal.SIGINT) == python_os_handler
True

Note that cysignals is POSIX-only for now (it assumes sigaction), but the code could easily be ported to other systems. Ideally it would become part of CPython's signal module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Wed Jan 16 08:04:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 16 Jan 2019 13:04:32 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547643872.44.0.605743974232.issue35748@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There are also some notes at https://tools.ietf.org/html/rfc3986#section-7.6

Because the userinfo subcomponent is rarely used and appears before
the host in the authority component, it can be used to construct a
URI intended to mislead a human user by appearing to identify one
(trusted) naming authority while actually identifying a different
authority hidden behind the noise.  For example

ftp://cnn.example.com&story=breaking_news at 10.0.0.1/top_story.htm

might lead a human user to assume that the host is 'cnn.example.com',
whereas it is actually '10.0.0.1'.  Note that a misleading userinfo
subcomponent could be much longer than the example above.

A misleading URI, such as that above, is an attack on the user's
preconceived notions about the meaning of a URI rather than an attack
on the software itself.  User agents may be able to reduce the impact
of such attacks by distinguishing the various components of the URI
when they are rendered, such as by using a different color or tone to
render userinfo if any is present, though there is no panacea.  More
information on URI-based semantic attacks can be found in [Siedzik]

In Firefox nightly and latest chrome pasting the above URL makes a request to 10.0.0.1/top_story.htm where in Chrome the URL in the address bar is changed to 10.0.0.1/top_story.htm and Firefox has the same URL in the address bar. Python also returns '10.0.0.1' as the hostname for the above example using urlparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Wed Jan 16 08:29:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 13:29:30 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547645370.64.0.52357870492.issue35674@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 92b8322e7ea04b239cb1cb87b78d952f13ddfebb by Victor Stinner (Joannah Nanjekye) in branch 'master':
bpo-35674: Add os.posix_spawnp() (GH-11554)
https://github.com/python/cpython/commit/92b8322e7ea04b239cb1cb87b78d952f13ddfebb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:07:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:07:49 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547647669.38.0.598556310994.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11257, 11258, 11259

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:07:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:07:31 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547647651.77.0.558207312054.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11257, 11258

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:07:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:07:14 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547647634.38.0.254250106779.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11257

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:14:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:14:16 +0000
Subject: [issue35749] Rewrite asyncio signal handler
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547648056.41.0.0894588769305.issue35749@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

In short, attached PR reverts the following commit:

commit fe5649c7b7bf52147480d6b1124a3d8e3597aee3
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Thu Jul 17 22:43:40 2014 +0200

    Python issue #21645, Tulip issue 192: Rewrite signal handling
    
    Since Python 3.3, the C signal handler writes the signal number into the wakeup
    file descriptor and then schedules the Python call using Py_AddPendingCall().
    
    asyncio uses the wakeup file descriptor to wake up the event loop, and relies
    on Py_AddPendingCall() to schedule the final callback with call_soon().
    
    If the C signal handler is called in a thread different than the thread of the
    event loop, the loop is awaken but Py_AddPendingCall() was not called yet. In
    this case, the event loop has nothing to do and go to sleep again.
    Py_AddPendingCall() is called while the event loop is sleeping again and so the
    final callback is not scheduled immediatly.
    
    This patch changes how asyncio handles signals. Instead of relying on
    Py_AddPendingCall() and the wakeup file descriptor, asyncio now only relies on
    the wakeup file descriptor. asyncio reads signal numbers from the wakeup file
    descriptor to call its signal handler.

=> https://github.com/python/asyncio/issues/192


Since this change, the C signal handler of Python has been reworked in bpo-30038 by:

commit 4ae01496971624c75080431806ed1c08e00f22c7
Author: Nathaniel J. Smith <njs at pobox.com>
Date:   Tue May 16 14:12:11 2017 -0700

    bpo-30038: fix race condition in signal delivery + wakeup fd (#1082)
    
    Before, it was possible to get the following sequence of
    events (especially on Windows, where the C-level signal handler for
    SIGINT is run in a separate thread):
    
    - SIGINT arrives
    - trip_signal is called
    - trip_signal writes to the wakeup fd
    - the main thread wakes up from select()-or-equivalent
    - the main thread checks for pending signals, but doesn't see any
    - the main thread drains the wakeup fd
    - the main thread goes back to sleep
    - trip_signal sets is_tripped=1 and calls Py_AddPendingCall to notify
      the main thread the it should run the Python-level signal handler
    - the main thread doesn't notice because it's asleep
    
    This has been causing repeated failures in the Trio test suite:
      https://github.com/python-trio/trio/issues/119


I am very scared by signals. These things are very complex and it's hard to handle them proplery on all platforms :-( So I'm not excited by changing the code.


> If the pipe is full OSError is raised.

Are you able to reproduce this issue, or is it a theorical issue?

What is the pipe buffer size on Linux? See bpo-33733.

----------
nosy: +njs, vstinner
title: Ignore exception if event loop wakeup pipe is full -> Rewrite asyncio signal handler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:16:55 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 16 Jan 2019 14:16:55 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1547648215.25.0.916656004341.issue27015@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +11260
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:17:05 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 16 Jan 2019 14:17:05 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1547648225.6.0.678578709969.issue27015@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch
pull_requests: +11260, 11261
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:17:14 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 16 Jan 2019 14:17:14 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1547648234.82.0.311414954529.issue27015@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch, patch
pull_requests: +11260, 11261, 11262
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:19:09 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 16 Jan 2019 14:19:09 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1547648349.39.0.584056852786.issue27015@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I tried to fix the issue, the attached PR solves the issue of saving the kwargs and unpickling the exception but I was not able to fix a regression I caused in test_memory_error_in_PyErr_PrintEx.

----------
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:25:48 2019
From: report at bugs.python.org (Taras Voinarovskyi)
Date: Wed, 16 Jan 2019 14:25:48 +0000
Subject: [issue35751] traceback.clear_frames manages to deadlock a background
 task
In-Reply-To: <1547634847.81.0.0050263541371.issue35751@roundup.psfhosted.org>
Message-ID: <1547648748.64.0.794019129938.issue35751@roundup.psfhosted.org>


Taras Voinarovskyi <voyn1991 at gmail.com> added the comment:

So yes, the `clear_frames` function will force a running generator to close. See https://github.com/python/cpython/blob/3.7/Objects/frameobject.c#L566, it explicitly does a Finalize. Would that be the desired behaviour for assertRaises is not clear. I find it strange that catching an exception is closing my running coroutine.

The reproduce example can be lowered to something like::

    import asyncio


    async def background(error_future):
        try:
            raise ValueError
        except Exception as exc:
            error_future.set_exception(exc)

        await asyncio.sleep(1)


    async def main():
        loop = asyncio.get_event_loop()
        error_future = loop.create_future()
        task = asyncio.create_task(background(error_future))

        await asyncio.wait([error_future])
        exc = error_future.exception()
        import traceback
        traceback.clear_frames(exc.__traceback__)

        # Will block forever, as task will never be waken up
        await task


    if __name__ == "__main__":
        asyncio.run(main())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35751>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:26:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:26:25 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547648785.64.0.682814459623.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 07858894689047c77f9c12ddc061d30681368d19 by Victor Stinner in branch 'master':
bpo-35537: subprocess can now use os.posix_spawnp (GH-11579)
https://github.com/python/cpython/commit/07858894689047c77f9c12ddc061d30681368d19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:33:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:33:10 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547649190.15.0.377738972701.issue35674@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Well done Joannah Nanjekye :-) Thanks to Joannah for this nice enhancemenet and to all reviewers.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Wed Jan 16 09:34:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 14:34:00 +0000
Subject: [issue35674] Expose os.posix_spawnp()
In-Reply-To: <1546821968.26.0.975322975658.issue35674@roundup.psfhosted.org>
Message-ID: <1547649240.81.0.00527714923846.issue35674@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

FYI I modified subprocess to use os.posix_spawnp() when it's available:

New changeset 07858894689047c77f9c12ddc061d30681368d19 by Victor Stinner in branch 'master':
bpo-35537: subprocess can now use os.posix_spawnp (GH-11579)
https://github.com/python/cpython/commit/07858894689047c77f9c12ddc061d30681368d19

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35674>
_______________________________________

From report at bugs.python.org  Wed Jan 16 11:51:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 16:51:19 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
Message-ID: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The bug was first reported on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1540995

======================================================================
FAIL: test_memoryview_struct_module (test.test_buffer.TestBufferProtocol)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.6.4/Lib/test/test_buffer.py", line 2540, in test_memoryview_struct_module
    self.assertEqual(m[1], nd[1])
AssertionError: -21.099998474121094 != -21.100000381469727

The problem is the conversion from C double (64-bit float) and C float (32-bit float). There are 2 implementations:

* Objects/memoryobject.c: pack_single() and unpack_single()
* Modules/_struct.c: nu_float() and np_float()

Attached ppc64_float32_bug.py is the simplified test case to trigger the bug.

The result depends on the compiler optimization level:

* gcc -O0: -21.100000381469727 == -21.100000381469727, OK
* gcc -O1: -21.099998474121094 != -21.100000381469727, ERROR
* (I guess that higher optimization level also trigger the bug)

The problem is that the pack_single() function is "miscompiled" (or "too optimized").

Adding "volatile" to PACK_SINGLE() prevents the unsafe compiler optimization and fix the issue for me: try attached pack_single_volatile.patch.


=== -O1 assembler code with the bug ===

PACK_SINGLE(ptr, d, float);


r30 = ptr
(gdb) p $vs63.v2_double
$17 = {0, -21.100000000000001}

=> 0x00000000100a1178 <pack_single+1988>:       stxsspx vs63,0,r30

(gdb) p /x (*ptr)@4
$10 = {0xcc, 0xcc, 0xa8, 0xc1}

The first byte is 0xcc: WRONG.


=== -O1 assembler code without the bug (volatile) ===

r30 = ptr

(gdb) p $f31
$1 = -21.100000000000001

=> 0x00000000100a11e4 <pack_single+2096>:       frsp    f31,f31

(gdb) p $f31
$2 = -21.100000381469727

   0x00000000100a11e8 <pack_single+2100>:       stfs    f31,152(r1)
   0x00000000100a11ec <pack_single+2104>:       lwz     r9,152(r1)

(gdb) p /x $r9
$8 = 0xc1a8cccd

   0x00000000100a11f0 <pack_single+2108>:       stw     r9,0(r30)

(gdb) p /x (*ptr)@4
$9 = {0xcd, 0xcc, 0xa8, 0xc1}

   0x00000000100a11f4 <pack_single+2112>:       li      r3,0
   0x00000000100a11f8 <pack_single+2116>:       lfd     f31,216(r1)
   0x00000000100a11fc <pack_single+2120>:       ld      r30,200(r1)

The first byte is 0xcd: GOOD.

----------
components: Library (Lib)
files: ppc64_float32_bug.py
messages: 333774
nosy: mark.dickinson, skrah, vstinner
priority: normal
severity: normal
status: open
title: test_buffer fails on ppc64le: memoryview pack_single() is miscompiled
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48060/ppc64_float32_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 11:51:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 16:51:34 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547657494.2.0.00464569048798.issue35752@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file48061/pack_single.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:02:24 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 16 Jan 2019 17:02:24 +0000
Subject: [issue35751] traceback.clear_frames manages to deadlock a background
 task
In-Reply-To: <1547634847.81.0.0050263541371.issue35751@roundup.psfhosted.org>
Message-ID: <1547658144.83.0.6546701648.issue35751@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Very interesting. Thanks for reporting this issue. I'll definitely take a look at this before 3.8 is released.  For 3.7 you'll likely have to find a workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35751>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:06:30 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 16 Jan 2019 17:06:30 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547658390.23.0.850792607618.issue35752@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:11:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 17:11:25 +0000
Subject: [issue35582] Argument Clinic: inline parsing code for functions with
 only positional parameters
In-Reply-To: <1545748852.85.0.712150888896.issue35582@roundup.psfhosted.org>
Message-ID: <1547658685.93.0.51455605192.issue35582@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I ran benchmarks on speed.python.org, it's the 5bb146aaea1484bcc117ab6cb38dda39ceb5df0f dot (Jan 13, 2019). I didn't look at results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35582>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:12:19 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 16 Jan 2019 17:12:19 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547658739.69.0.144752411304.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

This is a performance sensitive function, so I prefer not to add
volatile. MSVC also had a bug with that function, but only in PGO
mode. Microsoft has fixed the issue long ago.

Do newer gcc versions have this issue?

I'm fine with wrapping the entire macro in an #ifdef for __ppc64__.

Who is using this platform? IBM Power9?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:18:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 17:18:12 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547659092.74.0.299565745948.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This is a performance sensitive function, so I prefer not to add
volatile.

I don't suggest to use volatile. I'm just pointing to the function causing the bug and I said that volatile worked for me :-)

I made my tests on:

* Red Hat Enterprise Linux release 8.0 Beta (Ootpa)
* gcc (GCC) 8.2.1 20180905 (Red Hat 8.2.1-3)
* Linux kernel 4.18.0-56.el8.ppc64le
* uname -p: ppc64le

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:36:33 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 16 Jan 2019 17:36:33 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547660193.58.0.0355322346085.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Does it also work with -fno-inline, just for ppc64? There are other
places in the sources where an inlined memcpy() could be miscompiled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:43:44 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 16 Jan 2019 17:43:44 +0000
Subject: [issue13285] signal module ignores external signal changes
In-Reply-To: <1319801278.56.0.946220269602.issue13285@psf.upfronthosting.co.za>
Message-ID: <1547660624.21.0.0743441043461.issue13285@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

For reference, the sources for my implementation: https://github.com/sagemath/cysignals/blob/master/src/cysignals/pysignals.pyx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13285>
_______________________________________

From report at bugs.python.org  Wed Jan 16 12:48:36 2019
From: report at bugs.python.org (Henry Chen)
Date: Wed, 16 Jan 2019 17:48:36 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547660916.06.0.012353655969.issue34782@roundup.psfhosted.org>


Henry Chen <tahafut at gmail.com> added the comment:

I agree that this behavior is normal, unless there is a use case for passing a partially implemented mapping object to pdb.run. However I cannot think of such a use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Wed Jan 16 13:33:58 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 16 Jan 2019 18:33:58 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547663638.45.0.367037118552.issue35752@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Possibly relevant:

https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition#Detailed_Description

But the work is not complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 16 14:06:29 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 19:06:29 +0000
Subject: [issue35749] Rewrite asyncio signal handler
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547665589.39.0.0833100696874.issue35749@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Victor, thanks for the message.
I forgot mentioned changes.
You are right, the issue is "theoretical", I didn't see problems with current implementation.
The self-pipe buffer is pretty big, a chance to reach its limit is relatively low.
But a change to break asyncio on some OS with the patch is much higher.
Moreover, the patch assumes that python signal handler will be called *before* reading from self-pipe. 
Otherwise, a signal callback will be postponed up to next writing to the pipe, which looks like a hidden bug.

Let's close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 14:06:55 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Jan 2019 19:06:55 +0000
Subject: [issue35749] Rewrite asyncio signal handler
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547665615.71.0.324196424615.issue35749@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 14:25:10 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 16 Jan 2019 19:25:10 +0000
Subject: [issue35749] Rewrite asyncio signal handler
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547666710.09.0.695961517441.issue35749@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> You are right, the issue is "theoretical", I didn't see problems with current implementation.
> The self-pipe buffer is pretty big, a chance to reach its limit is relatively low.

Actually, I disagree.  The problem manifests itself easily when you orchestrate a big number of subprocesses (think 1000s).

I've implemented a different strategy for signals handling in uvloop [1] and I think we can easily employ similar approach in asyncio.

Please keep this open. 

[1] https://github.com/MagicStack/uvloop/commit/6e03e513625eb544a5f60c9bf9922019fc3a0b29

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 14:25:24 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 16 Jan 2019 19:25:24 +0000
Subject: [issue35749] Rewrite asyncio signal handler
In-Reply-To: <1547626646.01.0.761930434303.issue35749@roundup.psfhosted.org>
Message-ID: <1547666724.66.0.538731792272.issue35749@roundup.psfhosted.org>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
stage: resolved -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________

From report at bugs.python.org  Wed Jan 16 15:05:51 2019
From: report at bugs.python.org (ppperry)
Date: Wed, 16 Jan 2019 20:05:51 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547669151.52.0.0701349370774.issue34782@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

The thing is, though, that the same error occurs if a larger code being debugged calls `exec` or `eval` with such a mapping (`pdb.run("eval('1+1',{},FakeContainer())" also crashes with the same error), and the test suite contains code that evals other code in an incomplete mapping (test_var_annot_custom_maps in test_grammar)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Wed Jan 16 15:17:26 2019
From: report at bugs.python.org (David Antonini)
Date: Wed, 16 Jan 2019 20:17:26 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
Message-ID: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>


New submission from David Antonini <davidantonini at hotmail.com>:

Ok so that's a pretty odd bug. I already had from unittest.mock import patch, mock_open so I simply modified that to from  instead of doing mock.call in my test. Changing this to from unittest import mock and then mock.call fixed the error.

from unittest.mock import patch, mock_open, call

mocked_print.assert_has_calls([
    call("first print"),
    call("second print"),
    ])

I get: 

C:\Program Files (x86)\Python37-64\lib\doctest.py:932: in find
    self._find(tests, obj, name, module, source_lines, globs, {})
C:\Program Files (x86)\Python37-64\lib\doctest.py:991: in _find
    if ((inspect.isroutine(inspect.unwrap(val))
C:\Program Files (x86)\Python37-64\lib\inspect.py:515: in unwrap
    raise ValueError('wrapper loop when unwrapping {!r}'.format(f))
E   ValueError: wrapper loop when unwrapping call
collected 1 item / 1 errors

But when I don't import call directly my test runs as expected:

from unittest.mock import patch, mock_open

import unittest.mock

mocked_print.assert_has_calls([
    mock.call(),
    mock.call(),
    ])

I have the same issue when using:

assert mocked_print.call_args_list == [call("first print"), call("second print")] <- ValueError
assert mocked_print.call_args_list == [mock.call("first print"), mock.call("second print")] <- Works as expected.

----------
components: Tests
messages: 333786
nosy: toonarmycaptain
priority: normal
severity: normal
status: open
title: Importing call from unittest.mock directly causes ValueError
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 15:19:08 2019
From: report at bugs.python.org (David Antonini)
Date: Wed, 16 Jan 2019 20:19:08 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1547669948.02.0.595479199536.issue35753@roundup.psfhosted.org>


David Antonini <davidantonini at hotmail.com> added the comment:

I'm having a problem with mock.call when I import it directly from unittest.mock.

When I do:

from unittest.mock import patch, mock_open, call

mocked_print.assert_has_calls([
    call("first print"),
    call("second print"),
    ])

I get: 

C:\Program Files (x86)\Python37-64\lib\doctest.py:932: in find
    self._find(tests, obj, name, module, source_lines, globs, {})
C:\Program Files (x86)\Python37-64\lib\doctest.py:991: in _find
    if ((inspect.isroutine(inspect.unwrap(val))
C:\Program Files (x86)\Python37-64\lib\inspect.py:515: in unwrap
    raise ValueError('wrapper loop when unwrapping {!r}'.format(f))
E   ValueError: wrapper loop when unwrapping call
collected 1 item / 1 errors

But when I don't import call directly my test runs as expected:

from unittest.mock import patch, mock_open

import unittest.mock

mocked_print.assert_has_calls([
    mock.call(),
    mock.call(),
    ])

I have the same issue when using:

assert mocked_print.call_args_list == [call("first print"), call("second print")] <- ValueError
assert mocked_print.call_args_list == [mock.call("first print"), mock.call("second print")] <- Works as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 15:21:29 2019
From: report at bugs.python.org (David Antonini)
Date: Wed, 16 Jan 2019 20:21:29 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1547670089.97.0.114029448172.issue35753@roundup.psfhosted.org>


David Antonini <davidantonini at hotmail.com> added the comment:

Apologies for initial malformed message, I hit submit prematurely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 15:32:54 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Jan 2019 20:32:54 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1547670774.77.0.489334702458.issue35753@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hi David,

Can you provide a full reproducer? In your example, mocked_print is undefined. Please, provide a self-contained script that can be executed to test the behaviour.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 15:48:34 2019
From: report at bugs.python.org (ppperry)
Date: Wed, 16 Jan 2019 20:48:34 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1547671714.5.0.25312371236.issue35753@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

According to the error message, this is a duplicate of https://bugs.python.org/issue25532

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 16:27:39 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Jan 2019 21:27:39 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1547674059.84.0.220783588155.issue35753@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Indeed, closed as duplicate of https://bugs.python.org/issue25532

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 16:33:10 2019
From: report at bugs.python.org (jimbo1qaz_ via Gmail)
Date: Wed, 16 Jan 2019 21:33:10 +0000
Subject: [issue35754] When writing/closing a closed Popen.stdin,
 I get OSError vs. BrokenPipeError randomly or depending on bufsize
Message-ID: <1547674388.65.0.744708229654.issue35754@roundup.psfhosted.org>


New submission from jimbo1qaz_ via Gmail <jimbo1qaz at gmail.com>:

Windows 10 1709 x64, Python 3.7.1.

Minimal example and stack traces at https://gist.github.com/jimbo1qaz/75d7a40cac307f8239ce011fd90c86bf

Essentially I create a subprocess.Popen, using a process (msys2 head.exe) which closes its stdin after some amount of input, then write nothing but b"\n"*1000 bytes to its stdin.

If the bufsize is small (1000 bytes), I always get OSError: [Errno 22] Invalid argument

If the bufsize is large (1 million bytes), I always get BrokenPipeError: [Errno 32] Broken pipe. (This happens whether I write 1 million newlines or 1000 at a time).

Originally I created a ffmpeg->ffplay pipeline with a massive bufsize (around 1280*720*3 * 2 frames), then wrote 1280*720*3 bytes of video frames at a time. Closing ffplay's window usually created BrokenPipeError, but occasionally OSError. This was actually random.


------------

It seems that this is known to some extent, although I couldn't find any relevant issues on the bug tracker, and "having to catch 2 separate errors" isn't explained on the documentation. (Is it intended though undocumented behavior?)

Popen._communicate() calls Popen._stdin_write(), but specifically ignores BrokenPipeError and OSError where exc.errno == errno.EINVAL == 22 (the 2 cases I encountered).

But I don't call Popen.communicate() but instead write directly to stdin, since I have a loop that outputs 1 video frame at a time, and rely on pipe blocking to stop my application from running too far ahead of ffmpeg/ffplay.

------------

popen.stdin is a <_io.BufferedWriter name=3>.

https://docs.python.org/3/library/io.html#io.BufferedIOBase.write

>Write the given bytes-like object, b, and return the number of bytes written (always equal to the length of b in bytes, since if the write fails an OSError will be raised). Depending on the actual implementation, these bytes may be readily written to the underlying stream, or held in a buffer for performance and latency reasons.

The page doesn't mention BrokenPipeError at all (Ctrl+F). So why do I *sometimes* get a BrokenPipeError (subclasses ConnectionError subclasses OSError) instead?

----------
messages: 333792
nosy: jimbo1qaz_
priority: normal
severity: normal
status: open
title: When writing/closing a closed Popen.stdin, I get OSError vs. BrokenPipeError randomly or depending on bufsize
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35754>
_______________________________________

From report at bugs.python.org  Wed Jan 16 16:41:54 2019
From: report at bugs.python.org (jimbo1qaz_ via Gmail)
Date: Wed, 16 Jan 2019 21:41:54 +0000
Subject: [issue35754] When writing/closing a closed Popen.stdin,
 I get OSError vs. BrokenPipeError randomly or depending on bufsize
In-Reply-To: <1547674388.65.0.744708229654.issue35754@roundup.psfhosted.org>
Message-ID: <1547674914.3.0.166654838023.issue35754@roundup.psfhosted.org>


jimbo1qaz_ via Gmail <jimbo1qaz at gmail.com> added the comment:

Popen._stdin_write() has comments linking to https://bugs.python.org/issue19612 and https://bugs.python.org/issue30418 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35754>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:02:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:02:41 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547676161.64.0.771456008154.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11263

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:02:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:02:54 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547676174.83.0.319272335321.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11263, 11264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:03:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:03:11 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547676191.5.0.82542596665.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11263, 11264, 11265

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:08:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:08:24 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547676504.96.0.352520152704.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh... Using directly posix_spawnp() in subprocess to locate the executable in the PATH introduces subtle behavior changes...
https://github.com/python/cpython/pull/11579/#pullrequestreview-193261299

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:14:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:14:51 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547676891.27.0.648182512149.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

One of the issue that I have with using posix_spawn() is that the *exact* behavior of subprocess is not properly defined by test_subprocess. Should we more more tests, or document that the exact behavior is "an implementation detail"? I guess that the best for users is get the same behavior on all platforms, but can we really warranty that? Python rely on the operating system and the libc, but each platform has subtle behavior differneces. Handling time and date is a good example: strptime() and strftime() have big differences between platforms. posix_spawn() is another example where the implementation is very different depending on the platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:15:33 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Jan 2019 22:15:33 +0000
Subject: [issue35747] Python threading event wait influenced by date change
In-Reply-To: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>
Message-ID: <1547676933.73.0.413545194298.issue35747@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think this is becase at the end, the threading code calls

sem_timedwait(thelock, &ts) where &ts is the timespect structure. The manpage of sem_timedwait says:

...

The timeout shall expire when the absolute time specified by abs_timeout passes, as measured by the clock on which timeouts are based (that is, when the value of that clock equals or exceeds abs_timeout), or if the absolute time specified by abs_timeout has already been passed at the time of the call.

If the Timers option is supported, the timeout shall be based on the CLOCK_REALTIME clock. If the Timers option is not supported, the timeout shall be based on the system clock as returned by the time() function. The resolution of the timeout shall be the resolution of the clock on which it is based. The timespec data type is defined as a structure in the <time.h> header.

So I assume this is using the system clock, so is affected by the date.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:18:14 2019
From: report at bugs.python.org (ppperry)
Date: Wed, 16 Jan 2019 22:18:14 +0000
Subject: [issue35753] Importing call from unittest.mock directly causes
 ValueError
In-Reply-To: <1547669844.88.0.953853980523.issue35753@roundup.psfhosted.org>
Message-ID: <1547677094.38.0.185078232349.issue35753@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

Sorry, looks like I was wrong about it being a duplicate. The actual bug appears to be "doctest can't run on a module that contains un-unwrappable objects", which there probably is an issue for but I don't know what it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35753>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:26:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:26:11 +0000
Subject: [issue31267] threading.Timer object is affected by changes to system
 time: Python locks should use a monotonic clock if available
In-Reply-To: <1503521255.96.0.0977006158294.issue31267@psf.upfronthosting.co.za>
Message-ID: <1547677571.12.0.620405717909.issue31267@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm sorrry, I read the issue too quickly and misunderstood it. I guess that it's a duplicate of bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms". This issue is blocked the libc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31267>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:35:31 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Jan 2019 22:35:31 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547678131.13.0.104394416366.issue35537@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> One of the issue that I have with using posix_spawn() is that the *exact* behavior of subprocess is not properly defined by test_subprocess. Should we more more tests, or document that the exact behavior is "an implementation detail"? I guess that the best for users is get the same behavior on all platforms, but can we really warranty that? Python rely on the operating system and the libc, but each platform has subtle behavior differneces. Handling time and date is a good example: strptime() and strftime() have big differences between platforms. posix_spawn() is another example where the implementation is very different depending on the platform.

I don't think we can get the same behaviour in all platforms, but I would want to know what Gregory P. Smith thinks about this potential divergence in behaviour and what are the guarantees that posix_subprocess should maintain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 17:38:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 22:38:11 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547678291.66.0.673919776201.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8c349565e8a442e17f1a954d1a9996847749d778 by Victor Stinner in branch 'master':
Revert "bpo-35537: subprocess can now use os.posix_spawnp (GH-11579)" (GH-11582)
https://github.com/python/cpython/commit/8c349565e8a442e17f1a954d1a9996847749d778


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 18:41:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 23:41:48 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
Message-ID: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Currently, posixpath.defpath is equal to:

defpath = ':/bin:/usr/bin'

It gives 3 directories:

>>> posixpath.defpath.split(posixpath.pathsep)
['', '/bin', '/usr/bin']

where the empty string means "the current directory". Trying to locate an executable from the current directory can be security issue when an attacker tries to execute arbitrary command.

The Linux exec(3) manual page contains an interesting note about the removal of the empty string from glibc 2.24 by accident:

http://man7.org/linux/man-pages/man3/execvp.3.html

NOTES

       The default search path (used when the environment does not contain
       the variable PATH) shows some variation across systems.  It generally
       includes /bin and /usr/bin (in that order) and may also include the
       current working directory.  On some other systems, the current
       working is included after /bin and /usr/bin, as an anti-Trojan-horse
       measure.  The glibc implementation long followed the traditional
       default where the current working directory is included at the start
       of the search path.  However, some code refactoring during the
       development of glibc 2.24 caused the current working directory to be
       dropped altogether from the default search path.  This accidental
       behavior change is considered mildly beneficial, and won't be
       reverted.

       (...)

Context of this issue: This discussion started from my PR 11579 which modifies the subprocess module to use posix_spawnp():
https://github.com/python/cpython/pull/11579#pullrequestreview-193261299


So I propose to replace defpath = ':/bin:/usr/bin' with defpath = '/bin:/usr/bin' which gives 2 directories:

>>> '/bin:/usr/bin'.split(posixpath.pathsep)
['/bin', '/usr/bin']

This change would only affect os.get_exec_path(), and so indirectly the subprocess module (when the executable contains no directory), *when the PATH environmant variable is not set*.

----------
components: Library (Lib)
messages: 333801
nosy: christian.heimes, giampaolo.rodola, gregory.p.smith, vstinner
priority: normal
severity: normal
status: open
title: Remove current directory from posixpath.defpath to enhance security
type: security
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Wed Jan 16 18:42:11 2019
From: report at bugs.python.org (Bryan Koch)
Date: Wed, 16 Jan 2019 23:42:11 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
Message-ID: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>


New submission from Bryan Koch <bbkoch94 at gmail.com>:

Using the new "`return value` is semantically equivalent to `raise StopIteration(value)`" syntax created in PEP-380 (https://legacy.python.org/dev/peps/pep-0380/#formal-semantics) causes the returned value to be skipped by standard methods of iteration.

The PEP reads as if returning a value via StopIteration was meant to signal that the generator was finished and that StopIteration.value was the final value.  If StopIteration.value is meant to represent the final value, then the built-in for-loop should not skip it and the current implementation in 3.3, 3.4, 3.5, and 3.6 should be considered an oversight of the PEP and a bug (I don't have a version of 3.7 or 3.8 to test newer versions).

Reproduction code is attached with comments/annotations.

----------
files: ex1.py
messages: 333802
nosy: Bryan Koch
priority: normal
severity: normal
status: open
title: Using `return value` in a generator function skips the returned value on for-loop iteration
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file48062/ex1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Wed Jan 16 18:47:27 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 16 Jan 2019 23:47:27 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547682447.66.0.417294184657.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Hi,

> As a disclaimer, I'm a FreeBSD developer interested in making sure we're doing the right thing here. =)

> May I ask what the above assessment is based on, and specifically what we need to address?

Hello, Kyle! That assessment is based on my quick and incorrect reading of posix_spawn source code. I didn't notice that "error" is visible in the parent due to address space sharing. Sorry for that, and thank you for the correction. A proper error notification is required for posix_spawn to be used in subprocess as a replacement for fork/exec, and FreeBSD does it right.

While we're here, would you be kind to answer several questions about posix_spawn on FreeBSD?

1) On Linux, without taking additional precautions, signals may be delivered to a child process created via vfork(). If a signal handler runs in such a child, it can leave traces of its work in the (shared) memory, potentially surprising the parent process. To avoid this, glibc[1] and musl[2] disable all signals (even signals used internally for thread cancellation) before creating a child, but FreeBSD calls vfork() right away. Is this not considered a problem, or is something hidden in vfork() implementation?

2) Another problem with vfork() is potential sharing of address space between processes with different privileges (see Rich Felker's post[3] about this and the previous problem). Is this a valid concern on FreeBSD?

3) Does FreeBSD kernel guarantee that when waitpid(WNOHANG) is called at [4], the child is ready for reaping? On Linux, it's not always the case[5].

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c;h=353bcf5b333457d191320e358d35775a2e9b319b;hb=HEAD#l372
[2] http://git.musl-libc.org/cgit/musl/tree/src/process/posix_spawn.c?id=5ce3737931bb411a8d167356d4d0287b53b0cbdc#n171
[3] https://ewontfix.com/7
[4] https://svnweb.freebsd.org/base/head/lib/libc/gen/posix_spawn.c?view=markup#l229
[5] https://sourceware.org/git/?p=glibc.git;a=commit;h=aa95a2414e4f664ca740ad5f4a72d9145abbd426

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 18:54:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 23:54:57 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547682897.4.0.817753351066.issue35755@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote attached execv_curdir.py to check if os.execv() tries to find the executable in the current directory if it doesn't contain a directory: yes, it does.

$ python3 execv_curdir.py 
execv() searchs in the current directory

I also wrote attached subprocess_curdir.py which confirms that subprocess runs a program from the current directory if it exists.

$ python3 subprocess_curdir.py 
defpath = :/bin:/usr/bin
subprocess searchs in the current directory

Moreover, the current directory has the priority over /bin and /usr/bin.

----------
Added file: https://bugs.python.org/file48063/execv_curdir.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Wed Jan 16 18:55:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Jan 2019 23:55:16 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547682916.12.0.469797582564.issue35755@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


Added file: https://bugs.python.org/file48064/subprocess_curdir.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:35:51 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 00:35:51 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547685351.75.0.976946747852.issue17005@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +11266
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:36:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 00:36:07 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547685367.3.0.934819914738.issue17005@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11266, 11267
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:36:22 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 00:36:22 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547685382.94.0.34521228791.issue17005@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11266, 11267, 11268
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:38:47 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 17 Jan 2019 00:38:47 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547685527.73.0.658746608699.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> One of the issue that I have with using posix_spawn() is that the *exact* behavior of subprocess is not properly defined by test_subprocess. Should we more more tests, or document that the exact behavior is "an implementation detail"?

Regarding using PATH from "env" instead of parent's environment, it may be considered documented because subprocess docs refer to os.execvp(), where it's explicitly documented:

"""
The variants which include a ?p? near the end (execlp(), execlpe(), execvp(), and execvpe()) will use the PATH environment variable to locate the program file. When the environment is being replaced (using one of the exec*e variants, discussed in the next paragraph), the new environment is used as the source of the PATH variable.
"""

The problem is that it differs from execvp() in libc (and POSIX), so I would consider such behavior a bug if it wasn't so old to become a feature. Thanks to Victor for noticing that, I missed it.

So, if we can't change os.execvp() and/or current subprocess behavior, posix_spawnp seems to be ruled out. (I don't consider temporarily changing the parent environment as a solution). A naive emulation of posix_spawnp would be repeatedly calling posix_spawn for each PATH entry, but that's prohibitively expensive. Could we use a following hybrid approach instead?

Iterate over PATH entries and perform a quick check for common exec errors (ENOENT, ENOTDIR, EACCES) manually (e.g. by stat()). If the check fails, exec would also fail so just skip the entry. (It's important not to get false negatives here, but the child process would have the same privileges as the parent since we don't use POSIX_SPAWN_RESETIDS, so I can't think of one). Otherwise, call posix_spawn with the absolute path. If it fails, skip the entry.

Looks ugly, but are there other problems? This would seem to work just as well as posix_spawnp in the common case, but in the worst (contrived) case it would be equivalent to calling posix_spawn for each PATH entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:43:56 2019
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Jan 2019 00:43:56 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547685836.53.0.0918508657671.issue17005@roundup.psfhosted.org>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Here is an implementation that I've used for years. It is somewhat shorter than the one in PR 11583:

class CycleError(LogicalError, ValueError):
    """dependencies cycle detected

    """


def tsort(pairs):
    """topological sort

    Just like unix tsort(1)

    >>> tsort([(1, 2), (7, 8), (8, 10), (7, 4), (2, 3), (4, 10)])
    [1, 7, 2, 8, 4, 3, 10]
    >>> try:
    ...     tsort([(1,2), (2,1)])
    ... except CycleError as e:
    ...     print(e)
    ([], Counter({1: 1, 2: 1}), {1: [2], 2: [1]})
    """
    # inspired by http://mail.python.org/pipermail/python-list/1999-July/002831.html
    successors = {}
    predecessor_counts = collections.Counter()
    for x, y in pairs:
        successors.setdefault(x, []).append(y)
        predecessor_counts.setdefault(x, 0)
        predecessor_counts[y] += 1
    ordered = [x for x in predecessor_counts
               if predecessor_counts[x] == 0]
    for x in ordered:
        del predecessor_counts[x]
        for y in successors.get(x, ()):
            predecessor_counts[y] -= 1
            if predecessor_counts[y] == 0:
                ordered.append(y)
    if predecessor_counts:
        raise CycleError(ordered, predecessor_counts, successors)
    return ordered

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:48:49 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 17 Jan 2019 00:48:49 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547686129.42.0.273349810817.issue35755@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Would it make sense to use os.confstr('CS_PATH') instead of a hardcoded path, or is identical behavior on all POSIX platforms preferred to that?

----------
nosy: +izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:50:59 2019
From: report at bugs.python.org (Taras Voinarovskyi)
Date: Thu, 17 Jan 2019 00:50:59 +0000
Subject: [issue35751] traceback.clear_frames manages to deadlock a background
 task
In-Reply-To: <1547634847.81.0.0050263541371.issue35751@roundup.psfhosted.org>
Message-ID: <1547686259.46.0.62061911322.issue35751@roundup.psfhosted.org>


Taras Voinarovskyi <voyn1991 at gmail.com> added the comment:

For now, it seems like ``copy.copy(exception)`` before raising seems to prevent this behaviour. So for all exceptions originating from background tasks I raise a copy to the user, rather than the original exception. It prints correct stack, so no real impact on the library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35751>
_______________________________________

From report at bugs.python.org  Wed Jan 16 19:53:13 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 17 Jan 2019 00:53:13 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1547686393.49.0.64198929004.issue35756@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You say:

> The PEP reads as if returning a value via StopIteration was meant to signal that the generator was finished and that StopIteration.value was the final value.

To me, the PEP is clear that `return expr` is equivalent to `raise StopIteration(expr)` which is *not* used as an iteration value. Can you point to the passage in the PEP that suggests something different to you?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:08:42 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 01:08:42 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547687322.45.0.50613444458.issue17005@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests:  -11268

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:08:53 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 01:08:53 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547687333.64.0.954469982609.issue17005@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests:  -11267, 11268

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:31:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Jan 2019 01:31:50 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547688710.03.0.481689066994.issue17005@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks. I have some API nits to work to make this more broadly useful.  I'll all those on the PR comments soonish :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:33:39 2019
From: report at bugs.python.org (ido k)
Date: Thu, 17 Jan 2019 01:33:39 +0000
Subject: [issue35747] Python threading event wait influenced by date change
In-Reply-To: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>
Message-ID: <1547688819.69.0.990676359991.issue35747@roundup.psfhosted.org>


ido k <ido.koren.git at gmail.com> added the comment:

thanks @pablogsal.

looks like duplicate of bugs.python.org/issue23428 

It seems like i cant trust the threading wait function and need to use busy waiting.

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:38:00 2019
From: report at bugs.python.org (Henry Chen)
Date: Thu, 17 Jan 2019 01:38:00 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547689080.03.0.039314374108.issue34782@roundup.psfhosted.org>


Henry Chen <tahafut at gmail.com> added the comment:

Hmm, the example works for me (Python 3.6.5):

>>> import pdb
>>> class FakeContainer:
...     def __getitem__(self, key):
...             raise KeyError(key)
...
>>> pdb.run("eval('1+1',{},FakeContainer())")
> <string>(1)<module>()
(Pdb) c
>>>

As for exec/eval accepting an incomplete mapping, that strikes me as a less than thorough checking on the part of exec/eval, perhaps for performance reasons(?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:40:03 2019
From: report at bugs.python.org (ppperry)
Date: Thu, 17 Jan 2019 01:40:03 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547689203.5.0.541096006807.issue34782@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

You have to step into the eval for the error to be raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Wed Jan 16 20:57:18 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 17 Jan 2019 01:57:18 +0000
Subject: [issue35754] When writing/closing a closed Popen.stdin,
 I get OSError vs. BrokenPipeError randomly or depending on bufsize
In-Reply-To: <1547674388.65.0.744708229654.issue35754@roundup.psfhosted.org>
Message-ID: <1547690238.43.0.491477605043.issue35754@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

If I'm right, we can reduce your example down as follows:

    import os
    import subprocess
    import time
    import ctypes

    RtlGetLastNtStatus = ctypes.WinDLL('ntdll').RtlGetLastNtStatus
    RtlGetLastNtStatus.restype = ctypes.c_ulong

    msys = os.path.normpath("C:/msys64/usr/bin")
    head = os.path.join(msys, "head.exe")

    p = subprocess.Popen(head, stdin=subprocess.PIPE,
            stdout=subprocess.PIPE, bufsize=0)

    # head.exe reads 1 KiB. It closes stdin if it finds 10 lines.
    p.stdin.write(b'\n' * 1024)

    # If we immediately fill up the pipe again plus 1 extra byte, 
    # i.e. 4097 bytes for the default queue size, then NPFS will 
    # internally queue a pending IRP. We're synchronous, so the 
    # I/O manager will wait for I/O completion. Meanwhile the child
    # has requested to close its end of the pipe. In this case,
    # NPFS will complete the pending IRP with STATUS_PIPE_BROKEN,
    # which maps to WinAPI ERROR_PIPE_BROKEN and C errno EPIPE.
    #
    # On the other hand, if we wait to give the child's close request
    # time to complete, then NPFS will fail our 4097 byte write 
    # immediately with STATUS_PIPE_CLOSING, which maps to WinAPI
    # ERROR_NO_DATA and C errno EINVAL.

    time.sleep(0.0) # STATUS_PIPE_BROKEN / ERROR_PIPE_BROKEN / EPIPE
    #time.sleep(0.5) # STATUS_PIPE_CLOSING / ERROR_NO_DATA / EINVAL

    try:
        p.stdin.write(b'\n' * 4097)
    except OSError:
        ntstatus = RtlGetLastNtStatus()
        if ntstatus == 0xC000_00B1:
           print('NT Status: STATUS_PIPE_CLOSING\n')
        elif ntstatus == 0xC000_014B:
            print('NT Status: STATUS_PIPE_BROKEN\n')
        else:
            print('NT Status: {}\n'.format(ntstatus, '#010x'))
        raise

This could be addressed by improving our exception handling to look at the C runtime's _doserrno [1] value for EINVAL errors, in order to map ERROR_NO_DATA to EPIPE instead of EINVAL. Only two NT status codes are mapped to ERROR_NO_DATA, and both are pipe related (STATUS_PIPE_CLOSING and STATUS_PIPE_EMPTY), so using EPIPE should be fine.

[1]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-doserrno-sys-errlist-and-sys-nerr?view=vs-2017

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35754>
_______________________________________

From report at bugs.python.org  Wed Jan 16 21:11:33 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 17 Jan 2019 02:11:33 +0000
Subject: [issue35754] When writing/closing a closed Popen.stdin,
 I get OSError vs. BrokenPipeError randomly or depending on bufsize
In-Reply-To: <1547674388.65.0.744708229654.issue35754@roundup.psfhosted.org>
Message-ID: <1547691093.37.0.500545745192.issue35754@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +IO, Interpreter Core, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type:  -> behavior
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35754>
_______________________________________

From report at bugs.python.org  Wed Jan 16 21:12:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 02:12:11 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547691131.14.0.933184333115.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The one in PR 11583 is twice as faster:

>timeit for -> topsort([(2,11),(9,11),(9,8),(9,10),(10,11),(10,3),(11,7),(11,5),(8,7),(8,3)])
12.4 ?s ? 59.1 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

>timeit for -> tsort([(2,11),(9,11),(9,8),(9,10),(10,11),(10,3),(11,7),(11,5),(8,7),(8,3)])
29.1 ?s ? 147 ns per loop (mean ? std. dev. of 7 runs, 10000 loops each)

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 21:13:52 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 02:13:52 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547691232.16.0.0118445951211.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The one in PR 11583 is twice as fast:

>timeit for -> topsort([(2,11),(9,11),(9,8),(9,10),(10,11),(10,3),(11,7),(11,5),(8,7),(8,3)])
12.4 ?s ? 59.1 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

>timeit for -> tsort([(2,11),(9,11),(9,8),(9,10),(10,11),(10,3),(11,7),(11,5),(8,7),(8,3)])
29.1 ?s ? 147 ns per loop (mean ? std. dev. of 7 runs, 10000 loops each)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 21:14:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 02:14:07 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547691232.16.0.0118445951211.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The one in PR 11583 is twice as fast:

>timeit for -> topsort([(2,11),(9,11),(9,8),(9,10),(10,11),(10,3),(11,7),(11,5),(8,7),(8,3)])
12.4 ?s ? 59.1 ns per loop (mean ? std. dev. of 7 runs, 100000 loops each)

>timeit for -> tsort([(2,11),(9,11),(9,8),(9,10),(10,11),(10,3),(11,7),(11,5),(8,7),(8,3)])
29.1 ?s ? 147 ns per loop (mean ? std. dev. of 7 runs, 10000 loops each)

----------
Removed message: https://bugs.python.org/msg333815

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Wed Jan 16 21:59:39 2019
From: report at bugs.python.org (bryan.koch)
Date: Thu, 17 Jan 2019 02:59:39 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1547693979.62.0.927229132748.issue35756@roundup.psfhosted.org>


bryan.koch <bbkoch94 at gmail.com> added the comment:

I understood the PEP to include `return expr` in the iteration values as per the first bullet of the proposal.

> Any values that the iterator yields are passed directly to the caller.

This bullet doesn't have any additional formatting on the word "yields" so I consider it as not directly referring to the "yield" keyword.

With the current implementation, I have to concern myself if a generator function was created with the intention of being called using `last_ret = yield from function(); yield last_ret` or as `for ret in function(): yield ret`.  The first also yields the return value but would also yield an additional `None` if a `return` was not the terminal cause; the second will miss the last value if the generator uses `return`.

Essentially, allowing `return expr` in generator functions without invoking the generator using `yield from generator` will lose the last value.

I support either of the below resolutions:
* `return expr` being invoked from a generator that is not being iterated using `yield from generator` is a SyntaxError
* `return expr` being invoked from a generator that is not being iterated using `yield from generator` includes the final return value in the iterated set

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Wed Jan 16 23:15:15 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 17 Jan 2019 04:15:15 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547698515.56.0.293133436344.issue35701@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

David, the What's New note about weak references no longer being possible should be removed as part of this change. I'm not sure the note on arbitrary attributes no longer being addable is needed either (__setattr__ blocked that beforehand, it's just even more impossible now).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Wed Jan 16 23:29:02 2019
From: report at bugs.python.org (Kirill Kolyshkin)
Date: Thu, 17 Jan 2019 04:29:02 +0000
Subject: [issue35757] slow subprocess.Popen(..., close_fds=True)
Message-ID: <1547699341.03.0.843639889929.issue35757@roundup.psfhosted.org>


New submission from Kirill Kolyshkin <kolyshkin at gmail.com>:

In case close_fds=True is passed to subprocess.Popen()
or its users (subprocess.call() etc), it might spend
some considerable time closing non-opened file descriptors,
as demonstrated by the following snippet from strace:

    close(3)                    = -1 EBADF (Bad file descriptor)
    close(5)                    = -1 EBADF (Bad file descriptor)
    close(6)                    = -1 EBADF (Bad file descriptor)
    close(7)                    = -1 EBADF (Bad file descriptor)
    ...
    close(1021)                 = -1 EBADF (Bad file descriptor)
    close(1022)                 = -1 EBADF (Bad file descriptor)
    close(1023)                 = -1 EBADF (Bad file descriptor)

This happens because the code in _close_fds() iterates from 3 up to
MAX_FDS = os.sysconf("SC_OPEN_MAX").

Now, syscalls are cheap, but SC_OPEN_MAX (also known as RLIMIT_NOFILE
or ulimit -n) can be quite high, for example:

    $ docker run --rm python python3 -c \
            $'import os\nprint(os.sysconf("SC_OPEN_MAX"))'
    1048576

This means a million syscalls before spawning a child process, which
can result in a major delay, like 0.1s as measured on my fast and mostly
idling laptop. Here is the comparison with python3 (which does not have this problem):

    $ docker run --rm python python3 -c $'import subprocess\nimport time\ns = time.time()\nsubprocess.check_call([\'/bin/true\'], close_fds=True)\nprint(time.time() - s)\n'
    0.0009245872497558594

    $ docker run --rm python python2 -c $'import subprocess\nimport time\ns = time.time()\nsubprocess.check_call([\'/bin/true\'], close_fds=True)\nprint(time.time() - s)\n'
    0.0964419841766

----------
components: Library (Lib)
messages: 333819
nosy: Kirill Kolyshkin
priority: normal
pull_requests: 11269
severity: normal
status: open
title: slow subprocess.Popen(..., close_fds=True)
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35757>
_______________________________________

From report at bugs.python.org  Wed Jan 16 23:54:30 2019
From: report at bugs.python.org (Kyle Evans)
Date: Thu, 17 Jan 2019 04:54:30 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547700870.28.0.0288028603435.issue35537@roundup.psfhosted.org>


Kyle Evans <kevans at FreeBSD.org> added the comment:

On Wed, Jan 16, 2019 at 5:47 PM Alexey Izbyshev <report at bugs.python.org> wrote:
> > Hi,
>
> > As a disclaimer, I'm a FreeBSD developer interested in making sure we're doing the right thing here. =)
>
> > May I ask what the above assessment is based on, and specifically what we need to address?
>
> Hello, Kyle! That assessment is based on my quick and incorrect reading of posix_spawn source code. I didn't notice that "error" is visible in the parent due to address space sharing. Sorry for that, and thank you for the correction. A proper error notification is required for posix_spawn to be used in subprocess as a replacement for fork/exec, and FreeBSD does it right.

Oh, good to hear. =) koobs had pointed this thread out in hopes that we can try to reconcile and figure out what work needs to be done here. =)

> While we're here, would you be kind to answer several questions about posix_spawn on FreeBSD?

Most definitely, if I can!

> 1) On Linux, without taking additional precautions, signals may be delivered to a child process created via vfork(). If a signal handler runs in such a child, it can leave traces of its work in the (shared) memory, potentially surprising the parent process. To avoid this, glibc[1] and musl[2] disable all signals (even signals used internally for thread cancellation) before creating a child, but FreeBSD calls vfork() right away. Is this not considered a problem, or is something hidden in vfork() implementation?
>

Right, after glancing over our implementation details- this is indeed a problem here. Our manpage indicates that we only block SIGTTOU for SIGTTIN for children in vfork(), and some light testing seems to indicate that's the case. Signal handlers are inherited from the parent, so that's less than stellar.

> 2) Another problem with vfork() is potential sharing of address space between processes with different privileges (see Rich Felker's post[3] about this and the previous problem). Is this a valid concern on FreeBSD?

My initial read-through of the relevant bits seem to indicate that image activation will cause the child process to be allocated a new process space, so it's looking kind of like a 'no' -- I'm outsourcing the answer to this one to someone more familiar with those bits, though, so I'll get back to you.


> 3) Does FreeBSD kernel guarantee that when waitpid(WNOHANG) is called at [4], the child is ready for reaping? On Linux, it's not always the case[5].

I want to say vfork semantics guarantee it- we got to this point, so the child hit an error and _exit(127). I'm double-checking this one, though, to verify the child's properly marked a zombie before we could possibly reschedule the parent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 17 00:16:03 2019
From: report at bugs.python.org (Minmin Gong)
Date: Thu, 17 Jan 2019 05:16:03 +0000
Subject: [issue35758] Disable x87 control word for MSVC ARM compiler
Message-ID: <1547702162.77.0.571505556494.issue35758@roundup.psfhosted.org>


New submission from Minmin Gong <minmin.gong at gmail.com>:

Msvc defines _M_ARM for arm target, but it doesn't have x87 control word. Need to disable it to prevent some compiling problems.

----------
messages: 333821
nosy: Minmin.Gong
priority: normal
pull_requests: 11270
severity: normal
status: open
title: Disable x87 control word for MSVC ARM compiler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35758>
_______________________________________

From report at bugs.python.org  Thu Jan 17 00:49:04 2019
From: report at bugs.python.org (ossdev)
Date: Thu, 17 Jan 2019 05:49:04 +0000
Subject: [issue34691] _contextvars missing in xmaster branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1547704144.9.0.0126314580657.issue34691@roundup.psfhosted.org>


ossdev <ossdev at puresoftware.com> added the comment:

I am building python for windows on ARM64,
I am getting "No module named '_contextvars'" when trying to import contextvars:
>>> import contextvars
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\ps-emb\Downloads\cpython-master\cpython-master\lib\contextvars.py", line 1, in <module>
    from _contextvars import Context, ContextVar, Token, copy_context
ModuleNotFoundError: No module named '_contextvars'

thanks

----------
nosy: +ossdev07
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Thu Jan 17 00:57:15 2019
From: report at bugs.python.org (Tim Peters)
Date: Thu, 17 Jan 2019 05:57:15 +0000
Subject: [issue34691] _contextvars missing in xmaster branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1547704634.99.0.868056411859.issue34691@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Precisely _how_ are you building it?  As noted above, if you're using Visual Studio, try using build.bat instead for the first time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Thu Jan 17 01:05:43 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 17 Jan 2019 06:05:43 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547693979.62.0.927229132748.issue35756@roundup.psfhosted.org>
Message-ID: <20190117060536.GE13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> I understood the PEP to include `return expr` in the iteration values 
> as per the first bullet of the proposal.
> 
> > Any values that the iterator yields are passed directly to the caller.
> 
> This bullet doesn't have any additional formatting on the word 
> "yields" so I consider it as not directly referring to the "yield" 
> keyword.

I read it as "yields", not "yields or returns". Lack of formatting is 
irrelevant -- we shouldn't expect every use of a word with a technical 
meaning to necessarily be formatted specifically.

Read the Proposal section:

    The following new expression syntax will be allowed in the body 
    of a generator 
    [...]
    FURTHERMORE, when the iterator is another generator, the 
    subgenerator is allowed to execute a return statement with a 
    value, AND THAT VALUE BECOMES THE VALUE OF THE YIELD FROM 
    EXPRESSION. [emphasis added]

https://legacy.python.org/dev/peps/pep-0380/#id11

It does not say "that value is yielded and then becomes the value of the 
yiueld from expression".

To me, it is clear that the intention here is that the return value is 
not yielded.

The Abstract also says:

    Additionally, the subgenerator is allowed to return with a
    value, and the value IS MADE AVAILABLE to the delegating
    generator. [emphasis added]

The use of "is made available" suggests that the return value is treated 
differently from a yield. Values yielded from the subgenerator are 
automatically yielded from the calling generator, without any additional 
effort. The value returned is merely *made available*, for the calling 
generator to do with whatever it wishes.

And if there is still any doubt, there is specification of the behaviour 
of "result = yield from expression" which makes it clear that the return 
value carried by the StopIteration exception is not yielded, but used as 
the value of the expression (i.e. assigned to `result`).

The motivation of yield from returning a value is to allow a side- 
channel independent of the iterable values. It isn't intended as a "one 
last yield and then bail out". I don't think that your interpretation 
can be justified by reading the PEP.

> Essentially, allowing `return expr` in generator functions without 
> invoking the generator using `yield from generator` will lose the last 
> value.

No, because the return value is not intended to be used as one of the 
iteration values. Quoting one of Greg Ewing's examples:

    I hope it is also clear why returning values via yield,
    or having 'yield from' return any of the yielded values,
    would be the wrong thing to do. The send/yield channel and
    the return channel are being used for completely different
    purposes, and conflating them would be disastrous.

http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Parser/parser.txt

That example is indirectly linked to from the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Thu Jan 17 01:42:39 2019
From: report at bugs.python.org (Kyle Evans)
Date: Thu, 17 Jan 2019 06:42:39 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547707359.49.0.040165382943.issue35537@roundup.psfhosted.org>


Kyle Evans <kevans at FreeBSD.org> added the comment:

I'll be preparing a patch for our posix_spawn's signal handling.

My mistake in my setuid assessment was pointed out to me- it doesn't seem like a highly likely attack vector, but it is indeed possible.

If the child errored out, they will indeed be properly reapable at that point due to how vfork is implemented -- any observation to the contrary is to be considered a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:30:46 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Jan 2019 07:30:46 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547710246.97.0.640796336892.issue35755@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

ntpath and macpath appear to have the same potential issue.
They've basically had this defpath value forever.

keep following it and you find a commit from 1994 https://github.com/python/cpython/commit/2979b01ff88ac4c5b316d9bf98edbaaaffac8e24

Changing them only alters behavior of users of os.defpath or in the (odd?) situation when the PATH environment variable is unset, anything using of shutil.which() or distutils.spawn.find_executabnle(), the only stdlib users of os.defpath.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:33:14 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 17 Jan 2019 07:33:14 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547710394.08.0.194025122707.issue35755@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I'm not arguing against this change, just trying to figure out where it came from in the first place.  We should fix the value on all OSes.

It would be a behavior change so probably only good for 3.8+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:38:08 2019
From: report at bugs.python.org (Anil kunduru)
Date: Thu, 17 Jan 2019 07:38:08 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547710688.91.0.458661836624.issue35750@roundup.psfhosted.org>


Anil kunduru <kunduruanilwork at gmail.com> added the comment:

thanks Eryk Sun i am able to solve the problem, it was extension modules problem. it was helpful great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:40:04 2019
From: report at bugs.python.org (Anil kunduru)
Date: Thu, 17 Jan 2019 07:40:04 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547710804.93.0.977488574737.issue35750@roundup.psfhosted.org>


Anil kunduru <kunduruanilwork at gmail.com> added the comment:

Thanks guys for quick responses.  Eryk Sun  comment wa very help full.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:41:13 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 17 Jan 2019 07:41:13 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547710873.04.0.515216636778.issue35755@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

+1, /usr/bin:/bin sounds good to me.

My /usr/include/paths.h has #define _PATH_DEFPATH "/usr/bin:/bin" and #define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin". The file is pretty old and has copyright from 89 and 93, https://code.woboq.org/gcc/include/paths.h.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:46:07 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jan 2019 07:46:07 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547711167.3.0.850373930519.issue35730@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +11272

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:46:22 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jan 2019 07:46:22 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547711182.21.0.105322786765.issue35730@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +11272, 11273, 11274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 02:46:14 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jan 2019 07:46:14 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547711174.88.0.540828031783.issue35730@roundup.psfhosted.org>


Change by Tal Einat <taleinat at gmail.com>:


----------
pull_requests: +11272, 11273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 03:08:22 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 17 Jan 2019 08:08:22 +0000
Subject: [issue35750] process finished with exit code -1073740940 (0xc0000374)
In-Reply-To: <1547626702.61.0.971998033647.issue35750@roundup.psfhosted.org>
Message-ID: <1547712502.98.0.131074163702.issue35750@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution: fixed -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35750>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:01:08 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 09:01:08 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547715668.07.0.908811929171.issue17005@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

As the name been already discussed ? 


I fear that topsort might only be clear to people already knowing what it does. topoligical_sort would be more discoverable and explicit and one can always do

    from functools import topological_sort as tsort

if he wants to save some typing later.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:22:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 09:22:28 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547716948.7.0.62413959313.issue35755@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm working on PR but I found an issue.

shutil.which() behaves differently than subprocess, distutils.spawn.find_executable() and os.execv() when PATH is set but set to an empty string:

* os.get_exec_path() returns ['']
* shutil.which() returns None: DON'T RUN
* subprocess RUNS the program
* distutils.spawn.find_executable('program') returns 'program': RUN the program
* os.execv() RUNS the program

Using PATH=":", they all run the program and os.get_exec_path() returns ['', ''].

Who is right? Which behavior do we want for Python?

Note: When PATH is set to an empty string, shutil.which() and distutils.spawn.find_executable() use the empty string, they don't use os.defpath.

----------
Added file: https://bugs.python.org/file48065/empty_path.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:25:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 09:25:31 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547717131.66.0.356523152186.issue35755@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +11275
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:25:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 09:25:39 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547717139.29.0.746371340332.issue35755@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +11275, 11276
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:25:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 09:25:47 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547717147.52.0.872140590125.issue35755@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11275, 11276, 11277
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:26:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Jan 2019 09:26:12 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547717172.64.0.362674665183.issue34782@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks to me like an error in the user code. What is the use case of passing an object that does not implement the mapping interface as locals to pdb.run()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:28:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 09:28:36 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547717316.29.0.779136445821.issue35755@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 11586 to remove the current directory from os.defpath.

I would prefer to first decide how the os, subprocess, shutil and distutils modules have to handle a PATH variable set to an empty string, before merging my PR. I would prefer to have the same behavior for these modules.


Gregory P. Smith:
> I'm not arguing against this change, just trying to figure out where it came from in the first place.  We should fix the value on all OSes.

Oh, I didn't know that Windows had the same behavior... I didn't know that Windows has a default search path! C:\bin? Who has such directory?

I agree that it's better to have the same behavior on all platforms.


Gregory P. Smith:
> It would be a behavior change so probably only good for 3.8+.

I concur. It's a backward incompatible change.


Christian Heimes:
> My /usr/include/paths.h has #define _PATH_DEFPATH "/usr/bin:/bin" and #define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin". The file is pretty old and has copyright from 89 and 93, https://code.woboq.org/gcc/include/paths.h.html

On my Fedora 29, this file comes from the glibc:

$ rpm -qf /usr/include/paths.h
glibc-headers-2.28-26.fc29.i686

According to execvp() manual page, the current directory has only been removed from glibc 2.24 (2016-08-05).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:35:25 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Jan 2019 09:35:25 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547717725.44.0.803166080242.issue35755@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is how the which command behaves:

$ /usr/bin/which python
/usr/bin/python
$ PATH= /usr/bin/which python
$ PATH=. /usr/bin/which python
./python
$ PATH=: /usr/bin/which python
./python

I think shutil.which() should behave similarly unless there are good reasons for difference.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:42:31 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 17 Jan 2019 09:42:31 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1547718151.67.0.416426341599.issue23078@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@berker.peksag I have converted the patch at https://bugs.python.org/file40470/issue23078.patch and pushed it to a GitHub branch https://github.com/python/cpython/compare/master...tirkarthi:bpo23078 . I am willing to open a PR attributing to @fov in case you haven't had the time to look into this. 

I am removing 3.6 since it's security fixes only mode.

Thanks

----------
nosy: +cjw296, mariocj89, xtreak
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:46:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 09:46:20 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547718380.66.0.69709856053.issue35755@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Alexey Izbyshev:
> Would it make sense to use os.confstr('CS_PATH') instead of a hardcoded path, or is identical behavior on all POSIX platforms preferred to that?

I didn't know this variable. man confstr says:

_CS_PATH: A value for the PATH variable  which  indicates  where  all  the POSIX.2 standard utilities can be found.

On my Fedora 29, it only returns '/usr/bin':

$ python3
>>> import os; os.confstr("CS_PATH")
'/usr/bin'

On Fedora 29, /bin is a symlink to /usr/bin:

$ ls -ld /bin
lrwxrwxrwx. 1 root root 7 13 juil.  2018 /bin -> usr/bin/

So it makes sense to omit /bin from the default search path :-)

On Debian Sid where /bin is still a distinct directory than /usr/bin, CS_PATH is equal to "/bin:/usr/bin".

On Fedora, using confstr() would have the advantage of avoiding one useless syscall stat("/bin/program") in addition to stat("/usr/bin/program") in shutil.which() if the program doesn't exist... It's really a micro optimization which has no impact on the correctness, for the specific case of Fedora.

About the correctness, FreeBSD has a different value:

>>> os.confstr("CS_PATH")
'/usr/bin:/bin:/usr/sbin:/sbin'

Not only it also includes /usr/sbin and /sbin, but /usr/bin has the preference over /bin (posixpath of Python 3 checks /bin before /usr/bin). I'm not sure if the different order has an impact about correctness. I only found two programs which are in /bin and /usr/bin, but the programs in /usr/bin are symbolic links to a program with the same name in /bin :-)

vstinner at freebsd$ python3
Python 3.6.6 (default, Nov 20 2018, 01:57:10) 
>>> import os
>>> usr=os.listdir("/usr/bin")
>>> bin=os.listdir("/bin")
>>> set(usr) & set(bin)
{'pkill', 'pgrep'}

vstinner at freebsd$ file /usr/bin/pkill
/usr/bin/pkill: symbolic link to ../../bin/pkill

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 04:48:11 2019
From: report at bugs.python.org (Greg Ewing)
Date: Thu, 17 Jan 2019 09:48:11 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1547718491.3.0.538998950361.issue35756@roundup.psfhosted.org>


Greg Ewing <greg.ewing at canterbury.ac.nz> added the comment:

There is no bug here; the current implementation is working as intended.

The word "yields" in the quoted section of the PEP indeed refers to the "yield" keyword and nothing else. Possibly that could be clarified, but I believe it's already clear enough when read in the context of the rest of the PEP.

----------
nosy: +greg.ewing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:00:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:00:47 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547719247.63.0.45116374231.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Alexey Izbyshev
> So, if we can't change os.execvp() and/or current subprocess behavior, posix_spawnp seems to be ruled out.

My main motivation for using posix_spawn() is performance. An optimization should not justify to introduce a backward incompatible change. I agree wth posix_spawnp() cannot be used directly in subprocess because of that. But os.posix_spawnp() addition in Python 3.8 remains useful because it allows to use it directly (avoid subprocess).


> A naive emulation of posix_spawnp would be repeatedly calling posix_spawn for each PATH entry, but that's prohibitively expensive.

It should be compared to the current code. Currently, _posixsubprocess uses a loop calling execv(). I don't think that calling posix_spawn() in a loop until one doesn't fail is more inefficient.

The worst case would be when applying process attributes and run file actions would dominate performances... I don't think that such case exists. Syscalls like dup2() and close() should be way faster than the final successful execv() in the overall posix_spawn() call. I'm talking about the case when the program exists.


> Iterate over PATH entries and perform a quick check for common exec errors (ENOENT, ENOTDIR, EACCES) manually (e.g. by stat()).

I dislike this option. There is a high risk of race condition if the program is created, deleted or modified between the check and exec. It can cause subtle bugs, or worse: security vulnerabilities. IMHO the only valid check, to test if a program exists, is to call exec().

Alexey: Do you want to work on a PR to reimplement the "executable_list" and loop used by subprocess with _posixsubproces? You should keep the latest exception to re-raise it if no posix_spawn() successed. Don't forget to clear the exception on success, to not create a reference cycle:

commit acb9fa79fa6453c2bbe3ccfc9cad2837feb90093
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Wed Sep 13 10:10:10 2017 -0700

    bpo-31234, socket.create_connection(): Fix ref cycle (#3546)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:04:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:04:50 +0000
Subject: [issue31267] threading.Timer object is affected by changes to system
 time: Python locks should use a monotonic clock if available
In-Reply-To: <1503521255.96.0.0977006158294.issue31267@psf.upfronthosting.co.za>
Message-ID: <1547719490.54.0.899592517997.issue31267@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm sorrry, I read the issue too quickly and misunderstood it. I guess that it's a duplicate of bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms". This issue is blocked the libc...

Oops, I wanted to post this comment on bpo-35747... There are too many duplicates of bpo-23428...

I close this issue as a duplicate of bpo-23428.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Use the monotonic clock for thread conditions on POSIX platforms

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31267>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:05:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:05:16 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547719516.3.0.823485765332.issue23428@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I marked bpo-31267 "threading.Timer object is affected by changes to system time: Python locks should use a monotonic clock if available" as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:05:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:05:51 +0000
Subject: [issue35747] Python threading event wait influenced by date change
In-Reply-To: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>
Message-ID: <1547719551.56.0.932990190204.issue35747@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oops, I posted the following comment on the wrong issue... I wanted to post the following comment on this issue!

I'm sorrry, I read the issue too quickly and misunderstood it. I guess that it's a duplicate of bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms". This issue is blocked the libc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:06:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:06:55 +0000
Subject: [issue35747] Python threading event wait influenced by date change
In-Reply-To: <1547574873.05.0.783688735174.issue35747@roundup.psfhosted.org>
Message-ID: <1547719615.69.0.443627492543.issue35747@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> looks like duplicate of bugs.python.org/issue23428 

Yes. I close this issue as a duplicate of bpo-23428. Let's discuss the bug there!

----------
stage:  -> resolved
status: open -> closed
superseder:  -> Use the monotonic clock for thread conditions on POSIX platforms

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35747>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:07:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:07:21 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547719641.16.0.569908727789.issue23428@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I closed bpo-35747 "Python threading event wait influenced by date change" as a duplicate of the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:11:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:11:18 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547719878.46.0.206904867743.issue23428@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Is there any progress on the issue? Should someone take over?

It's a limitation of the libc, not directly of Python.

The problem is that the sem_timedwait() function of the glibc doesn't allow to specify which clock is used:
https://sourceware.org/bugzilla/show_bug.cgi?id=14717

Someone has to contribute to the glibc to add an option to sem_init() or sem_timedwait() to allow to use a different clock than CLOCK_REALTIME.

One workaround is to use Python to use the mutex+cond implementation of pthread locks, since this one is already able to use CLOCK_MONOTONIC:
https://bugs.python.org/issue31267#msg302257

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:11:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 10:11:42 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547719902.21.0.557263537866.issue23428@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-12822: "NewGIL should use CLOCK_MONOTONIC if possible".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:30:37 2019
From: report at bugs.python.org (Andrey Ovchinnikov)
Date: Thu, 17 Jan 2019 10:30:37 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547721037.13.0.933986133438.issue23428@roundup.psfhosted.org>


Change by Andrey Ovchinnikov <anikey.m at gmail.com>:


----------
nosy: +anikey

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:40:52 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2019 10:40:52 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547721652.83.0.0384576278835.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

If gcc-8.0.1-0.14.fc28.ppc64le miscompiles memcpy(), perhaps the upstream
priority in https://bugzilla.redhat.com/show_bug.cgi?id=1540995 should be
"release blocker".


CC David Edelsohn, whose PPC64 buildbot (presumably big endian) works.

----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:41:31 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:41:31 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721691.87.0.62395140766.issue35486@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cee29b46a19116261b083dc803217aa754c7df40 by Miss Islington (bot) (Nick Coghlan) in branch 'master':
bpo-35486: Note Py3.6 import system API requirement change (GH-11540)
https://github.com/python/cpython/commit/cee29b46a19116261b083dc803217aa754c7df40


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:42:07 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:42:07 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721727.61.0.43068606087.issue35486@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11278

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:42:17 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:42:17 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721737.13.0.943797266933.issue35486@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11278, 11279

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:42:27 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:42:27 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721747.73.0.713007271593.issue35486@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11278, 11279, 11280

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:42:37 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:42:37 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721757.3.0.95585465244.issue35486@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11279, 11280, 11283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:42:47 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:42:47 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721767.2.0.975954353477.issue35486@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11279, 11280, 11281, 11283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:42:59 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:42:59 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547721779.12.0.958438881204.issue35486@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11279, 11280, 11281, 11282, 11283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:48:17 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 10:48:17 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547722097.87.0.529208013223.issue35486@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 422db3777874f4f31fc8f4e718f440a2abc59347 by Miss Islington (bot) in branch '3.7':
bpo-35486: Note Py3.6 import system API requirement change (GH-11540)
https://github.com/python/cpython/commit/422db3777874f4f31fc8f4e718f440a2abc59347


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:56:40 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 10:56:40 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547722600.05.0.501558960482.issue23428@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> One workaround is to use Python to use the mutex+cond implementation of pthread locks, since this one is already able to use CLOCK_MONOTONIC:

That this have any drawbacks?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:57:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 10:57:11 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547722631.63.0.134895359243.issue23428@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> One workaround is to use Python to use the mutex+cond implementation of pthread locks, since this one is already able to use CLOCK_MONOTONIC:

Does this have any drawbacks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 05:57:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Jan 2019 10:57:17 +0000
Subject: [issue23428] Use the monotonic clock for thread conditions on POSIX
 platforms
In-Reply-To: <1423517667.9.0.82075564578.issue23428@psf.upfronthosting.co.za>
Message-ID: <1547722631.63.0.134895359243.issue23428@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> One workaround is to use Python to use the mutex+cond implementation of pthread locks, since this one is already able to use CLOCK_MONOTONIC:

Does this have any drawbacks?

----------
Removed message: https://bugs.python.org/msg333850

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23428>
_______________________________________

From report at bugs.python.org  Thu Jan 17 06:13:57 2019
From: report at bugs.python.org (yjq)
Date: Thu, 17 Jan 2019 11:13:57 +0000
Subject: [issue34148] Fatal read error on socket transport
In-Reply-To: <1531923784.93.0.56676864532.issue34148@psf.upfronthosting.co.za>
Message-ID: <1547723637.35.0.0355214520909.issue34148@roundup.psfhosted.org>


Change by yjq <yjqiang1 at outlook.com>:


----------
title: Fatal error on SSL transport -> Fatal read error on socket transport

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34148>
_______________________________________

From report at bugs.python.org  Thu Jan 17 06:35:03 2019
From: report at bugs.python.org (David Heiberg)
Date: Thu, 17 Jan 2019 11:35:03 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547724903.99.0.84510842264.issue35701@roundup.psfhosted.org>


David Heiberg <dhdavvie at gmail.com> added the comment:

Ahh yes of course, I will remove that from the notes. With regards to the second note, would it do any harm to leave it in? I suppose it does imply that this was possible before...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:12:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:12:50 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547727170.65.0.88495210717.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

What is your OS (name and version)?

What is your compiler (name and version)?

> Fatal Python error: _PySys_BeginInit: can't initialize sys module

I have no idea why you get this error. You should try to run this function in a debugger like gdb and run the code step by step to see what happens.

"""

0:06:18 load avg: 0.55 [171/416] test_hashlib
*** Error in `./python': corrupted size vs. prev_size: 0x000000000276b7a0 ***
Fatal Python error: Aborted

Current thread 0x00002ba4468c7bc0 (most recent call first):
  File "/usr/local/data/mySoftware/Python-3.7.2/Lib/test/test_hashlib.py", line 904 in _test_pbkdf2_hmac
"""

That's maybe unrelated, but _test_pbkdf2_hmac() is not supposed to crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:14:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:14:50 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547727290.37.0.880263260514.issue35283@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 89669ffe10a9db6343f6ee42239e412c8ad96bde by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-35283: Add deprecation warning for Thread.isAlive (GH-11454)
https://github.com/python/cpython/commit/89669ffe10a9db6343f6ee42239e412c8ad96bde


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:16:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:16:54 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547727414.65.0.74129476774.issue35701@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f1d8e7cf17a010d2657822e06a41b30c9542a8c7 by Victor Stinner (David H) in branch 'master':
bpo-35701: Added __weakref__ slot to uuid.UUID (GH-11570)
https://github.com/python/cpython/commit/f1d8e7cf17a010d2657822e06a41b30c9542a8c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:18:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:18:49 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547727529.35.0.0695580319088.issue35283@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, master now emits a deprecation warning. Is it worth it to emit a pending deprecation warning in Python 3.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:20:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:20:14 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547727614.57.0.505881824244.issue35701@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I understand that the reported issue is now fixed, so I close the issue.

Note: uuid.UUID of Python 3.7 doesn't use slots.

----------
keywords:  -3.7regression
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:29:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Jan 2019 12:29:37 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547728177.84.0.567884354577.issue35701@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What's New changes still are needed.

Are weak references to UUID used in any existing code, or just in the code that is planned to be written?

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:31:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:31:48 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547728308.25.0.353218762896.issue35701@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> What's New changes still are needed.

Sorry, what do you want to document? The fact that uuid.UUID now use slots? If yes, maybe reopen bpo-30977 instead?

This issue is only about fixing a regression caused by bpo-30977 (it wasn't possible to create a weak ref to a UUI), no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:34:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Jan 2019 12:34:45 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547728485.52.0.645769859685.issue35701@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This was already documented. We need to fix the documentation. See the discussion above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:34:50 2019
From: report at bugs.python.org (Thomas Krennwallner)
Date: Thu, 17 Jan 2019 12:34:50 +0000
Subject: [issue35759] inspect module does not implement introspection API for
 asynchronous generators
Message-ID: <1547728489.52.0.471681525673.issue35759@roundup.psfhosted.org>


New submission from Thomas Krennwallner <tk at postsubmeta.net>:

The `inspect` module does not contain functions for determining the current state of asynchronous generators. That is, there is no introspection API for asynchronous generators that match the API for generators and coroutines: https://docs.python.org/3.8/library/inspect.html#current-state-of-generators-and-coroutines.

I propose to add `inspect.getasyncgenstate` and `inspect.getasyncgenlocals` (following `inspect.isasyncgenfunction` and `inspect.isasyncgen`).

% ./python
Python 3.8.0a0 (heads/fix-issue-getasyncgenstate:a24deae1e2, Jan 17 2019, 11:44:45) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> async def agen():
...     x = 1
...     yield x
...     x += 1
...     yield x
... 
>>> ag = agen()
>>> inspect.getasyncgenstate(ag)
'AGEN_CREATED'
>>> inspect.getasyncgenlocals(ag)
{}
>>> ag.__anext__().__next__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration: 1
>>> inspect.getasyncgenstate(ag)
'AGEN_SUSPENDED'
>>> inspect.getasyncgenlocals(ag)
{'x': 1}
>>> ag.__anext__().__next__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration: 2
>>> inspect.getasyncgenstate(ag)
'AGEN_SUSPENDED'
>>> inspect.getasyncgenlocals(ag)
{'x': 2}
>>> ag.aclose().send(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>> inspect.getasyncgenstate(ag)
'AGEN_CLOSED'
>>> inspect.getasyncgenlocals(ag)
{}

----------
components: Library (Lib)
files: 0001-inspect-add-introspection-API-for-asynchronous-gener.patch
keywords: patch
messages: 333861
nosy: tkren
priority: normal
severity: normal
status: open
title: inspect module does not implement introspection API for asynchronous generators
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file48066/0001-inspect-add-introspection-API-for-asynchronous-gener.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35759>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:39:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:39:01 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547728741.81.0.708336517309.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Extract of memoryview pack_signal() function:

#define PACK_SINGLE(ptr, src, type) \
    do {                                     \
        type x;                              \
        x = (type)src;                       \
        memcpy(ptr, (char *)&x, sizeof x);   \
    } while (0)


    /* floats */
    case 'f': case 'd':
        d = PyFloat_AsDouble(item);
        if (d == -1.0 && PyErr_Occurred())
            goto err_occurred;
        if (fmt[0] == 'f') {
            PACK_SINGLE(ptr, d, float);  // ##### BUG IS HERE ###
        }
        else {
            PACK_SINGLE(ptr, d, double);
        }
        break;

Pseudo-code:

double d = PyFloat_AsDouble(item);
float x;
x = (float)d;
memcpy(ptr, (char *)&x, sizeo x);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:42:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 12:42:13 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547728933.11.0.688470665773.issue35701@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

https://docs.python.org/dev/whatsnew/3.8.html#optimizations

"""uuid.UUID now uses __slots__ to reduce its memory footprint. Note that this means that instances can no longer be weak-referenced and that arbitrary attributes can no longer be added to them."""

Oh ok, now I understand previous comments. Yeah, the note should be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:43:38 2019
From: report at bugs.python.org (Florian Weimer)
Date: Thu, 17 Jan 2019 12:43:38 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547729018.57.0.946358485914.issue35752@roundup.psfhosted.org>


Change by Florian Weimer <fweimer at redhat.com>:


----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 07:45:53 2019
From: report at bugs.python.org (David Heiberg)
Date: Thu, 17 Jan 2019 12:45:53 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547729153.77.0.441032249675.issue35701@roundup.psfhosted.org>


David Heiberg <dhdavvie at gmail.com> added the comment:

Should the note on arbitrary attributes also be removed? If this was documented previously then I don't see the need for it here, but if this has never been documented then maybe some other way of wording it may be sensible to include?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:07:56 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 17 Jan 2019 13:07:56 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1547730476.74.0.256242935433.issue35196@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

The recently merged PR GH-10454 significantly reduced the overhead of Squeezer's write() interception.  The overhead should now be entirely insignificant.

IMO that deals with the "... and is slow" part of this issue.  We've still to decide whether the auto-squeezing is "too aggressive".

I'll mention again that Raymond has brought up several additional important issues in the comments, that IMO should be processed into new issues and/or a roadmap for IDLE.  It's Terry's decision how to proceed, but I'll be happy to help with whatever direction he chooses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:20:49 2019
From: report at bugs.python.org (Thomas Krennwallner)
Date: Thu, 17 Jan 2019 13:20:49 +0000
Subject: [issue35759] inspect module does not implement introspection API for
 asynchronous generators
In-Reply-To: <1547728489.52.0.471681525673.issue35759@roundup.psfhosted.org>
Message-ID: <1547731249.26.0.583782156318.issue35759@roundup.psfhosted.org>


Change by Thomas Krennwallner <tk at postsubmeta.net>:


----------
pull_requests: +11284
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35759>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:20:51 2019
From: report at bugs.python.org (Thomas Krennwallner)
Date: Thu, 17 Jan 2019 13:20:51 +0000
Subject: [issue35759] inspect module does not implement introspection API for
 asynchronous generators
In-Reply-To: <1547728489.52.0.471681525673.issue35759@roundup.psfhosted.org>
Message-ID: <1547731251.71.0.366857418886.issue35759@roundup.psfhosted.org>


Change by Thomas Krennwallner <tk at postsubmeta.net>:


----------
pull_requests: +11284, 11285
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35759>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:27:44 2019
From: report at bugs.python.org (Florian Weimer)
Date: Thu, 17 Jan 2019 13:27:44 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547731664.18.0.626386498219.issue35752@roundup.psfhosted.org>


Florian Weimer <fweimer at redhat.com> added the comment:

I believe this is a GCC bug, and filed <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:36:14 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 13:36:14 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547732174.48.0.526943603653.issue35734@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +11286
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:36:20 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 13:36:20 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547732180.31.0.400149323984.issue35734@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch
pull_requests: +11286, 11287
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:36:25 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 13:36:25 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547732185.75.0.174564658121.issue35734@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch, patch
pull_requests: +11286, 11287, 11288
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:37:57 2019
From: report at bugs.python.org (=?utf-8?q?Th=C3=A9ophile_Chevalier?=)
Date: Thu, 17 Jan 2019 13:37:57 +0000
Subject: [issue35710] Make dataclasses.field() accept another name for
 __init__ field's name
In-Reply-To: <1547140271.38.0.846532339527.issue35710@roundup.psfhosted.org>
Message-ID: <1547732277.65.0.424999872241.issue35710@roundup.psfhosted.org>


Change by Th?ophile Chevalier <theophile.chevalier at lenstra.fr>:


----------
nosy: +theophile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35710>
_______________________________________

From report at bugs.python.org  Thu Jan 17 08:40:57 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 13:40:57 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547732457.4.0.620770280491.issue35734@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I opened https://github.com/python/cpython/pull/11591 to remove _valid_mask_octets, _is_valid_netmask and _is_hostmask from ipaddress, the patch proposed in issue27860 has a larger scope so it's probably better to remove those unused methods in this issue.

Does someone know how to set the skip news label on GitHub?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:04:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 14:04:25 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
Message-ID: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The test fails once on AMD64 Windows8.1 Non-Debug 3.x when the Python test suite is run in parallel, but pass if the test is run alone (when the system is more "idle").

https://buildbot.python.org/all/#/builders/12/builds/1898

======================================================================
FAIL: test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release\build\lib\test\test_asyncgen.py", line 684, in test_async_gen_asyncio_gc_aclose_09
    self.assertEqual(DONE, 1)
AssertionError: 0 != 1


It can reproduce the failure on a very busy Windows using 2 terminals:

* python -m test -F -W -j4 test_asyncgen  test_asyncgen test_asyncgen test_asyncgen
* python -m test -j0 -r -u all 

The first command runs the test 4 times in parallel in a loop until if fails, the second command is just one way to stress the system.


The test is based on time and so has a race condition depending on the exact timing:

    def test_async_gen_asyncio_gc_aclose_09(self):
        DONE = 0

        async def gen():
            nonlocal DONE
            try:
                while True:
                    yield 1
            finally:
                await asyncio.sleep(0.01)
                await asyncio.sleep(0.01)
                DONE = 1

        async def run():
            g = gen()
            await g.__anext__()
            await g.__anext__()
            del g

            await asyncio.sleep(0.1)

        self.loop.run_until_complete(run())
        self.assertEqual(DONE, 1)

----------
components: Library (Lib), Tests
messages: 333868
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_async_gen_asyncio_gc_aclose_09() race condition
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:07:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 17 Jan 2019 14:07:25 +0000
Subject: [issue35734] ipaddress's _BaseV4._is_valid_netmask fails to detect
 invalid netmask like 255.254.128.0
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547734045.21.0.695563075459.issue35734@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> I opened https://github.com/python/cpython/pull/11591 to remove _valid_mask_octets, _is_valid_netmask and _is_hostmask from ipaddress, the patch proposed in issue27860 has a larger scope so it's probably better to remove those unused methods in this issue.

Thanks, the subject of the issue is misleading and I would propose changing the issue subject or closing this in favor of the other issue and opening a PR against issue27860 stating that this only removes the unused functions and not the complete patch attached. This would require a review from the module maintainer I hope though it's an internal function that is never used.

> Does someone know how to set the skip news label on GitHub?

It needs to be added by a core dev

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:15:35 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 17 Jan 2019 14:15:35 +0000
Subject: [issue35759] inspect module does not implement introspection API for
 asynchronous generators
In-Reply-To: <1547728489.52.0.471681525673.issue35759@roundup.psfhosted.org>
Message-ID: <1547734535.5.0.684975207986.issue35759@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

see also msg300475

----------
nosy: +ncoghlan, xtreak, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35759>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:16:01 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 14:16:01 +0000
Subject: [issue33687] uu.py calls os.path.chmod which doesn't exist
In-Reply-To: <1527631327.84.0.682650639539.issue33687@psf.upfronthosting.co.za>
Message-ID: <1547734561.01.0.666480279417.issue33687@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 17f05bbc78dbcd1db308266c31370da9ec1b1d47 by Berker Peksag (Timo Furrer) in branch 'master':
bpo-33687: Fix call to os.chmod() in uu.decode() (GH-7282)
https://github.com/python/cpython/commit/17f05bbc78dbcd1db308266c31370da9ec1b1d47


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33687>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:16:16 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 14:16:16 +0000
Subject: [issue33687] uu.py calls os.path.chmod which doesn't exist
In-Reply-To: <1527631327.84.0.682650639539.issue33687@psf.upfronthosting.co.za>
Message-ID: <1547734561.01.0.666480279417.issue33687@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 17f05bbc78dbcd1db308266c31370da9ec1b1d47 by Berker Peksag (Timo Furrer) in branch 'master':
bpo-33687: Fix call to os.chmod() in uu.decode() (GH-7282)
https://github.com/python/cpython/commit/17f05bbc78dbcd1db308266c31370da9ec1b1d47


----------
nosy: +berker.peksag
pull_requests: +11289

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33687>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:16:18 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 14:16:18 +0000
Subject: [issue33687] uu.py calls os.path.chmod which doesn't exist
In-Reply-To: <1527631327.84.0.682650639539.issue33687@psf.upfronthosting.co.za>
Message-ID: <1547734578.27.0.426942355381.issue33687@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11289, 11290

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33687>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:20:24 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 14:20:24 +0000
Subject: [issue33687] uu.py calls os.path.chmod which doesn't exist
In-Reply-To: <1527631327.84.0.682650639539.issue33687@psf.upfronthosting.co.za>
Message-ID: <1547734824.75.0.328423772511.issue33687@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests:  -11290

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33687>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:23:11 2019
From: report at bugs.python.org (=?utf-8?q?Th=C3=A9ophile_Chevalier?=)
Date: Thu, 17 Jan 2019 14:23:11 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
Message-ID: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>


New submission from Th?ophile Chevalier <theophile.chevalier at lenstra.fr>:

Calling dataclasses.replace(instance, **changes) returns a new object of the same type.

>From my understanding there is, however, no method to update in place fields of a dataclass from another one.

I propose to add dataclasses.update(instance_to_update, other_instance, **changes).

This would for instance allow one to change all fields of current object in a sturdy way.
In my case, I currently call obj.__dict__.update(other_obj.__dict__) to perform the operation, but I know it has always to be done pretty carefully.

If this is accepted, I'm willing to post the change.

----------
messages: 333872
nosy: theophile
priority: normal
severity: normal
status: open
title: Allow dataclasses to be updated in place
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:24:02 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 14:24:02 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
In-Reply-To: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>
Message-ID: <1547735042.14.0.907942322742.issue35761@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:26:45 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 17 Jan 2019 14:26:45 +0000
Subject: [issue16638] support multi-line docstring signatures in IDLE calltips
In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za>
Message-ID: <1547735205.56.0.695778851085.issue16638@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since many of the criteria mentioned in msg219204 are now implemented or out of date, should this issue now be re-closed?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16638>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:27:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 14:27:54 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547735274.92.0.423589323901.issue35752@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11291
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:28:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 14:28:04 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547735284.16.0.886671301548.issue35752@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11291, 11292
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:28:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 14:28:14 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547735294.74.0.398271645.issue35752@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11291, 11292, 11293
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:33:02 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 14:33:02 +0000
Subject: [issue33687] uu.py calls os.path.chmod which doesn't exist
In-Reply-To: <1527631327.84.0.682650639539.issue33687@psf.upfronthosting.co.za>
Message-ID: <1547735582.58.0.718872578032.issue33687@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset a261b737617ca8d52e04bf3ead346b1b8786a212 by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-33687: Fix call to os.chmod() in uu.decode() (GH-7282)
https://github.com/python/cpython/commit/a261b737617ca8d52e04bf3ead346b1b8786a212


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33687>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:35:37 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 14:35:37 +0000
Subject: [issue33687] uu.py calls os.path.chmod which doesn't exist
In-Reply-To: <1527631327.84.0.682650639539.issue33687@psf.upfronthosting.co.za>
Message-ID: <1547735737.54.0.330539021401.issue33687@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the report, Poul-Henning and thank you for the PR, Timo!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33687>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:36:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 14:36:57 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547735817.2.0.908903596667.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> If gcc-8.0.1-0.14.fc28.ppc64le miscompiles memcpy(), perhaps the upstream priority in https://bugzilla.redhat.com/show_bug.cgi?id=1540995 should be "release blocker".

With the bug, memoryview doesn't round properly float: rounds to zero rather than rounding to nearest. It's not a critical crash or critical security vulnerability :-)

Anyway, I wrote a fix: PR 11593. My fix is to workaround the GCC compiler bug using volatile but only on ppc64. My change only impacts the 'f' type on ppc64 when compiled by GCC. Other architectures, compilers and types are unaffected and so have no impact on performances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:44:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 14:44:14 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547736254.52.0.711543941858.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug occurs when GCC emits a single instruction (stxsspx) for cast + memcpy.

I understand that the struct module is not affected because there is a condition branch (if) between the cast ("float x = ...") and the memcpy().

static int
np_float(char *p, PyObject *v, const formatdef *f)
{
    float x = (float)PyFloat_AsDouble(v);
    if (x == -1 && PyErr_Occurred()) {
        PyErr_SetString(StructError,
                        "required argument is not a float");
        return -1;
    }
    memcpy(p, (char *)&x, sizeof x);
    return 0;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 09:59:12 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2019 14:59:12 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547737152.49.0.2227065151.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Okay, so it's not a severe bug. That leaves us with the question
what to do about it. As I said above, other call sites could be
affected, too:

_struct.c:

static int
np_float(char *p, PyObject *v, const formatdef *f)
{
    float x = (float)PyFloat_AsDouble(v);
    if (x == -1 && PyErr_Occurred()) {
        PyErr_SetString(StructError,
                        "required argument is not a float");
        return -1;
    }
    memcpy(p, (char *)&x, sizeof x);
    return 0;
}


Even if this one isn't (I can't test) I think I'd prefer a more
global fix for the affected gcc version. Does any switch like
-fno-inline or something else work? If so, we could detect the
issue in configure.ac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:00:28 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2019 15:00:28 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547737228.36.0.716478246034.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Our mails apparently crossed. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:07:55 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2019 15:07:55 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547737675.72.0.480603154182.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Or to put it differently, should we put a specific fix for a single
gcc version into memoryview.c? For all we know, a fix will be pushed
to Fedora 28 in the next 4 months.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:15:49 2019
From: report at bugs.python.org (Florian Weimer)
Date: Thu, 17 Jan 2019 15:15:49 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547738149.04.0.991263240467.issue35752@roundup.psfhosted.org>


Florian Weimer <fweimer at redhat.com> added the comment:

We don't know yet if the GCC bug is specific to POWER.  That depends on what causes it.  Other targets my have double-to-float conversion instructions which hard-code the wrong rounding mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:20:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 15:20:47 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547738447.34.0.0959543071917.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

A colleague working on clang asked me to test clang: no, clang doesn't have the bug. test_buffer pass as expected with clang -O3.

Machine code of the cast + memcpy:

(gdb) p $f31
$1 = -21.100000000000001

(gdb) disassemble $pc,$pc+40
=> 0x0000000010078fbc <pack_single+380>:	frsp    f0,f31
   0x0000000010078fc0 <pack_single+384>:	li      r3,0
   0x0000000010078fc4 <pack_single+388>:	stfsx   f0,0,r29

(gdb) stepi
0x0000000010078fc0	1824	            PACK_SINGLE(ptr, d, float);

(gdb) p $f0
$3 = -21.100000381469727

(gdb) stepi
0x0000000010078fc4	1824	            PACK_SINGLE(ptr, d, float);
(gdb) stepi
0x0000000010078fc8	1824	            PACK_SINGLE(ptr, d, float);

(gdb) p /x (*ptr)@4
$8 = {0xcd, 0xcc, 0xa8, 0xc1}

The first byte is 0xcd: GOOD.

Florian explained in the GCC bug report that "frsp" is needed and clang emits it.

"This is incorrect because stfs rounds to zero.  An frsp instruction is missing before the stfs (and would be emitted without the memcpy)."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892#c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:22:50 2019
From: report at bugs.python.org (Samuel Bayer)
Date: Thu, 17 Jan 2019 15:22:50 +0000
Subject: [issue35762] subprocess.Popen with universal_newlines and nonblocking
 streams failes with "can't concat NoneType to bytes"
Message-ID: <1547738568.37.0.865745194211.issue35762@roundup.psfhosted.org>


New submission from Samuel Bayer <sam at mitre.org>:

This bug is probably related to issue 24560.

This:

>>> import subprocess, fcntl, os
>>>> p = subprocess.Popen(["python", "-c", 'import time; time.sleep(5)'], stdin = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE, universal_newlines= True)
>>> fcntl.fcntl(p.stderr.fileno(), fcntl.F_SETFL, os.O_NONBLOCK | fcntl.fcntl(p.stderr.fileno(), fcntl.F_GETFL))
>>> p.stderr.read()

causes this:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/codecs.py", line 321, in decode
    data = self.buffer + input
TypeError: can't concat NoneType to bytes

I'm assuming the problem is that the underlying unbuffered stream returns None and the incremental byte decoder that's induced by universal_newlines = True isn't expecting it.

----------
components: IO
messages: 333883
nosy: sambayer
priority: normal
severity: normal
status: open
title: subprocess.Popen with universal_newlines and nonblocking streams failes with "can't concat NoneType to bytes"
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35762>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:26:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Jan 2019 15:26:23 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547738783.53.0.224513130021.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

"Or to put it differently, should we put a specific fix for a single
gcc version into memoryview.c? For all we know, a fix will be pushed
to Fedora 28 in the next 4 months."

Right now, test_buffer is skipped in the python3.spec of Fedora (recipe to build the package which compiles Python and then runs the Python test suite) on pp64le because of this bug. With my packager hat: I'm done, the bug has been identified and is already worked around in the package.

With my Python hat: I'm not sure if I'm comfortable to have a known rounding issue on memoryview because of a compiler bug. I'm not sure that the GCC bug will be fixed quickly, nor if all operating systems will quickly update GCC or backport the fix.

Well, I wrote a fix, but I don't feel able to decide if the workaround is worth it or not.

For me, the main risk is to forget to remove the workaround once a new GCC version will be released (in N months).

I wouldn't bet that such GCC bug will be fixed and released in less than 4 months.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:38:10 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 17 Jan 2019 15:38:10 +0000
Subject: [issue35734] Remove unused _BaseV4._is_valid_netmask in ipaddress
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547739490.44.0.150901682012.issue35734@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I changed the subject of this issue as the scope of issue27860 is larger. I will review them and open a new PR for them if appropriate once this one is accepted.

----------
title: ipaddress's _BaseV4._is_valid_netmask fails to  detect invalid netmask like 255.254.128.0 -> Remove unused _BaseV4._is_valid_netmask in ipaddress

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 10:44:57 2019
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 17 Jan 2019 15:44:57 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547739897.03.0.552305299161.issue35752@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> For me, the main risk is to forget to remove the workaround once a new GCC version will be released (in N months).

This is why I suggested using the reproducer in configure.ac, setting something
like HAVE_GCC_MEMCPY_ROUNDING_BUG and then either a) wrap the *entire* PACK_SINGLE()
macro in an #ifdef or b) *preferably* add a global flag like -fno-inline or any
other flag that prevents the issue to CFLAGS.

b) under the condition that any such flag exists.


I may do a) in the weekend, which also addresses Florian Weimer's observation
that it is not known whether the issue is limited to POWER.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 11:31:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Jan 2019 16:31:37 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547742697.04.0.900588386776.issue35752@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Would it help if define PACK_SINGLE as below?

#define PACK_SINGLE(ptr, src, type) \
    do {                                     \
        union {                              \
            type value;                      \
            unsigned char raw[sizeof(type)]; \
        } x;                                 \
        x.value = (type)src;                 \
        memcpy(ptr, x.raw, sizeof(type));    \
    } while (0)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 12:08:37 2019
From: report at bugs.python.org (Florian Weimer)
Date: Thu, 17 Jan 2019 17:08:37 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547744917.85.0.218421864575.issue35752@roundup.psfhosted.org>


Florian Weimer <fweimer at redhat.com> added the comment:

No, GCC will optimize away the union.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:04:47 2019
From: report at bugs.python.org (Sergey Bon.)
Date: Thu, 17 Jan 2019 18:04:47 +0000
Subject: [issue30802] datetime.datetime.strptime('200722', '%Y%U')
In-Reply-To: <1498726688.6.0.920894490968.issue30802@psf.upfronthosting.co.za>
Message-ID: <1547748287.54.0.334493931136.issue30802@roundup.psfhosted.org>


Change by Sergey Bon. <sbon at pm.me>:


----------
keywords: +patch
pull_requests: +11294
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30802>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:05:01 2019
From: report at bugs.python.org (Sergey Bon.)
Date: Thu, 17 Jan 2019 18:05:01 +0000
Subject: [issue30802] datetime.datetime.strptime('200722', '%Y%U')
In-Reply-To: <1498726688.6.0.920894490968.issue30802@psf.upfronthosting.co.za>
Message-ID: <1547748301.14.0.601057370337.issue30802@roundup.psfhosted.org>


Change by Sergey Bon. <sbon at pm.me>:


----------
keywords: +patch, patch
pull_requests: +11294, 11295
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30802>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:05:14 2019
From: report at bugs.python.org (Sergey Bon.)
Date: Thu, 17 Jan 2019 18:05:14 +0000
Subject: [issue30802] datetime.datetime.strptime('200722', '%Y%U')
In-Reply-To: <1498726688.6.0.920894490968.issue30802@psf.upfronthosting.co.za>
Message-ID: <1547748314.75.0.384892101372.issue30802@roundup.psfhosted.org>


Change by Sergey Bon. <sbon at pm.me>:


----------
keywords: +patch, patch, patch
pull_requests: +11294, 11295, 11296
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30802>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:09:34 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 17 Jan 2019 18:09:34 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547748574.85.0.275958221024.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you for the answers, Kyle!

> I'll be preparing a patch for our posix_spawn's signal handling.

Great!

> My mistake in my setuid assessment was pointed out to me- it doesn't seem like a highly likely attack vector, but it is indeed possible.

The specific scenario with non-synchronized posix_spawn/setuid is certainly not a good practice and could probably be considered an application bug (such application effectively spawns a child with "random" privileges -- depending on whether setuid() completed before or after vfork()).

That said, in Linux C libraries protection from that scenario is usually achieved automatically if all signals are blocked before vfork(). This is the result of a Linux-specific detail: at syscall level, setuid() affects a single thread only, but setuid() library function must affect the process as a whole. This forces C libraries to signal all threads when setuid() is called and wait until all threads perform setuid() syscall. This waiting can't complete until vfork() returns (because signals are blocked), so setuid() is effectively postponed. I don't know how setuid() behaves on FreeBSD (so the above may be not applicable at all).

> If the child errored out, they will indeed be properly reapable at that point due to how vfork is implemented -- any observation to the contrary is to be considered a bug.

Ah, that's good, thanks for the confirmation!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:25:29 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 18:25:29 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1547749529.13.0.394662752937.issue24928@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

While I agree having more tests are a good thing, I'm not sure if the test in PR 11437 should be merged as it's not specifically testing a feature of the mock module.

patch.dict() basically does the following operation (ignoring possible AttributeErrors):

   # Keep the original one to use later.
   d = original_dict.copy()

   original_dict.update(new_dict)

I think the relationship between dict and OrderedDict (including any other dict subclasses and dict-like objects) and anything related to insertion order should be tested either in test_dict or in test_ordered_dict.

Also, the test can be simplified, but I will let other core developers chime in with their thoughts before reviewing PR 11437 on GitHub.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:26:04 2019
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jan 2019 18:26:04 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1547749564.41.0.0845362681763.issue24928@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests:  -10872

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:27:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 17 Jan 2019 18:27:19 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1547749639.67.0.460032918911.issue35683@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I have made the changes I suggested (though correctly...), but ultimately we need to create our own Docker image suitable for running these tests.

So for now, I'm proposing in my PR to make most of the change, as well as a few other Pipelines/test-related improvements, but to leave this open in case someone wants to come in later with a suitable image. At that point, the only change necessary to enable the tests will be to add a "posix_deps_yum.sh" script, update the image name/tag and change the manylinux variable to 'true'.

PR 11493 also fixes a missing LICENSE.txt file in the app store package, which was causing an idlelib test to fail as the fallback text only has one line. *Way* too obscure a failure for my liking, but at least we had a test there, so thanks, Terry :)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:28:55 2019
From: report at bugs.python.org (Felipe)
Date: Thu, 17 Jan 2019 18:28:55 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1547718151.67.0.416426341599.issue23078@roundup.psfhosted.org>
Message-ID: <CAJEr+DNYvZAu1KCmyKGjNs8WUPxu3ugzmFyViGxaExD1mEOk8Q@mail.gmail.com>


Felipe <felipe.nospam.ochoa at gmail.com> added the comment:

Please go ahead with the PR. I can't push this one through, but would be
great to have this finally land!

On Thu, 17 Jan 2019 at 03:42, Karthikeyan Singaravelan <
report at bugs.python.org> wrote:

>
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
>
> @berker.peksag I have converted the patch at
> https://bugs.python.org/file40470/issue23078.patch and pushed it to a
> GitHub branch
> https://github.com/python/cpython/compare/master...tirkarthi:bpo23078 . I
> am willing to open a PR attributing to @fov in case you haven't had the
> time to look into this.
>
> I am removing 3.6 since it's security fixes only mode.
>
> Thanks
>
> ----------
> nosy: +cjw296, mariocj89, xtreak
> versions:  -Python 3.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue23078>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:39:23 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 17 Jan 2019 18:39:23 +0000
Subject: [issue32866] zipimport loader.get_data() requires absolute zip file
 path
In-Reply-To: <1518922161.55.0.467229070634.issue32866@psf.upfronthosting.co.za>
Message-ID: <1547750363.55.0.231391753492.issue32866@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

I believe this bug does not affect Python 3.8:

(Using a Python 3.8 virtualenv):

% python demo.pyz 
Reading: resource.txt
Length: 19
% python `pwd`/demo.pyz 
Reading: resource.txt
Length: 19

I think it's too risky (and too much work, given it would have to be ported to the C implementation of zipimport) to change this in earlier Pythons.  So, closing.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32866>
_______________________________________

From report at bugs.python.org  Thu Jan 17 13:40:01 2019
From: report at bugs.python.org (Nina Zakharenko)
Date: Thu, 17 Jan 2019 18:40:01 +0000
Subject: [issue32866] zipimport loader.get_data() requires absolute zip file
 path
In-Reply-To: <1518922161.55.0.467229070634.issue32866@psf.upfronthosting.co.za>
Message-ID: <1547750401.62.0.725018477988.issue32866@roundup.psfhosted.org>


Change by Nina Zakharenko <nzakharenko at gmail.com>:


----------
nosy: +nnja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32866>
_______________________________________

From report at bugs.python.org  Thu Jan 17 14:39:29 2019
From: report at bugs.python.org (Chris Markiewicz)
Date: Thu, 17 Jan 2019 19:39:29 +0000
Subject: [issue22393] multiprocessing.Pool shouldn't hang forever if a worker
 process dies unexpectedly
In-Reply-To: <1410474786.78.0.264797717105.issue22393@psf.upfronthosting.co.za>
Message-ID: <1547753969.51.0.117494512281.issue22393@roundup.psfhosted.org>


Chris Markiewicz <effigies at bu.edu> added the comment:

Just a bump to note that the PR (10441) is ready for another round of review.

----------
nosy: +cjmarkie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22393>
_______________________________________

From report at bugs.python.org  Thu Jan 17 14:54:57 2019
From: report at bugs.python.org (Yongnan Wu)
Date: Thu, 17 Jan 2019 19:54:57 +0000
Subject: [issue34766] BaseProxy cache should be cleaned when Manager client is
 reconnected
In-Reply-To: <1537900896.87.0.545547206417.issue34766@psf.upfronthosting.co.za>
Message-ID: <1547754897.93.0.72796674847.issue34766@roundup.psfhosted.org>


Yongnan Wu <wynfred at yeah.net> added the comment:

ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34766>
_______________________________________

From report at bugs.python.org  Thu Jan 17 15:01:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 20:01:30 +0000
Subject: [issue35763] IDLE calltips: make positional note less obtrusive
Message-ID: <1547755288.11.0.42128686161.issue35763@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

#19903 made calltip.getargspec use inspect.signature.  The latter may include '/' following positional-only arguments.  Slashes are possible for the growing number of C-coded functions processed with Argument Clinic.  They appear in both help output and IDLE calltips, but not yet in the regular docs, let alone Python code.  The result, for instance, is 'float([x])' in the docs and 'float(x=0, /)' in help() and calltips.

Since '/' is effectively undocumented, especially in anything beginners would see, and since there have been questions from beginners as to its meaning, the following note is added to calltips on a new line followed by a blank line:

  ['/' marks preceding arguments as positional-only]

The negative effect is somewhat obtrusively expanding what would typically be 2 lines to 4 in order to say something that hopefully becomes useless.  Raymond's #16638 comment about big tips being distracting prompted me to consider some possible (non-exclusive) changes to reduce the impact.

0. Omit the blank line.  We added the blank line to make it clearer that the comment is not part of the docstring.  This can be done otherwise.

1. Change the font to something like smaller, red, italic characters.  Issue: the tip string is computed as a whole in the user execution process and inserted in the tip window in the IDLE process.  

2. Shorten and move the comment and mark it with '#'. Most builtins have short signatures, so a short enough comment could be appended to the signature line as a comment.  In combination with 0. (and 1., but not visible here), the float tip would shrink from the current

  float(x=0, /)
  ['/' marks preceding arguments as positional-only]

  Convert a string or number to a floating point number, if possible.

back down to

  float(x=0, /)  # / means positional-only
  Convert a string or number to a floating point number, if possible.

3. Limit the number of appearances in a particular session.  The following should work.

slash_comments = 3
...  
    if '/' in sig:
        if slash_comments:
            slash_comments -= 1
            <add slash comment>

I think 3 would be about enough.  I don't want to make it configurable.

Issue: restarting the user execution process would restart the count in that process, where the addition is currently made.


If the proposal to use '/' in the regular docs were ever accepted, I would remove the special calltip comment.

----------
assignee: terry.reedy
components: IDLE
messages: 333897
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE calltips: make positional note less obtrusive
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35763>
_______________________________________

From report at bugs.python.org  Thu Jan 17 15:18:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 20:18:46 +0000
Subject: [issue35764] IDLE: revise calltip doc
Message-ID: <1547756324.8.0.250551276486.issue35764@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Add cross-reference from Menu section entry.  Document '/' for builtins.  Check other details.  (Also remove 'extension' from end of previous entry.)

----------
assignee: terry.reedy
components: IDLE
messages: 333898
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: revise calltip doc
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35764>
_______________________________________

From report at bugs.python.org  Thu Jan 17 15:22:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 20:22:42 +0000
Subject: [issue35763] IDLE calltips: make positional note less obtrusive
In-Reply-To: <1547755288.11.0.42128686161.issue35763@roundup.psfhosted.org>
Message-ID: <1547756562.53.0.134183798637.issue35763@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#35764 is about revising the calltip doc, including adding something about '/' in signatures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35763>
_______________________________________

From report at bugs.python.org  Thu Jan 17 15:29:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 20:29:44 +0000
Subject: [issue16638] support multi-line docstring signatures in IDLE calltips
In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za>
Message-ID: <1547756984.35.0.13069523125.issue16638@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The standard calltip box is two lines: signature and docstring header.  In most cases, such as int, iter, and min, the effect of this patch is to get both lines of a docstring signature, so the result is not abnormally big.  And I agree with Serhiy that getting even more lines, when needed, is a bug fix.  (My change to 'enhancement' was in respect to Raymond's proposal, hence the reversion.)

Bytes is one of the very few functions with more than two header lines, and exceptional at 5.  It could be reduced to 4 if the first and last were combined as done for other functions.  I don't want to add an option or special code for this special case.

#19903 expands the calltip by 2 lines when the signature includes '/'.  This is increasingly common as more builtins get processed by Argument Clinic. I opened #35763 to revisit and revise this behavior.

----------
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16638>
_______________________________________

From report at bugs.python.org  Thu Jan 17 15:30:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 17 Jan 2019 20:30:42 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547757042.77.0.881881118274.issue23156@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since tix has been deprecated since 3.6 (according to the docs with commit bd63353b7433ea8aa831ffb158ac29fb646a6fc9), should this ticket be closed as out of date?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:25:48 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 17 Jan 2019 22:25:48 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547763948.3.0.708209425596.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> It should be compared to the current code. Currently, _posixsubprocess uses a loop calling execv(). I don't think that calling posix_spawn() in a loop until one doesn't fail is more inefficient.

> The worst case would be when applying process attributes and run file actions would dominate performances... I don't think that such case exists. Syscalls like dup2() and close() should be way faster than the final successful execv() in the overall posix_spawn() call. I'm talking about the case when the program exists.

I had vfork() used internally by posix_spawn() in mind when I considered repeatedly calling it "prohibitively expensive". While vfork() is much cheaper than fork(), it doesn't mean that its performance is comparable to dup2() and close(). But on systems where posix_spawn is a syscall the overhead could indeed be lesser. Anyway, it should be measured.

>> Iterate over PATH entries and perform a quick check for common exec errors (ENOENT, ENOTDIR, EACCES) manually (e.g. by stat()).

> I dislike this option. There is a high risk of race condition if the program is created, deleted or modified between the check and exec. It can cause subtle bugs, or worse: security vulnerabilities. IMHO the only valid check, to test if a program exists, is to call exec().

While exec() is of course cleaner, IMHO races don't matter in this case. If our stat()-like check fails, we could as well imagine that it is exec() that failed (while doing the same checks as our stat()), so it doesn't matter what happens with the tested entry afterwards. If the check succeeds, we simply call posix_spawn() that will perform the same checks again. If any race condition occurs, the problem will be detected by posix_spawn(). 

> Alexey: Do you want to work on a PR to reimplement the "executable_list" and loop used by subprocess with _posixsubproces?

I'm currently focused on researching whether it's possible to use vfork()-like approach instead of fork() on Linux, so if anyone wants to implement the PR you suggested, feel free to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:28:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:28:53 +0000
Subject: [issue30290] IDLE: add tests for help_about.py
In-Reply-To: <1494046999.85.0.702748551727.issue30290@psf.upfronthosting.co.za>
Message-ID: <1547764133.74.0.132214604491.issue30290@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Postscript: this test that the retrieved text has at least two lines caught a bug in the new Windows Store python distribution.

    self.assertEqual(printer._Printer__lines[1],
                     dialog._current_textview.textView.get('2.0', '2.end'))

The license file was missing and the backup default had only one line.
#35683, msg333891

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30290>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:30:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:30:31 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1547764231.08.0.510043953677.issue35683@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe it was Louie Lu's idea, #30290, to check more than one line.
I am glad it helped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:38:20 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 17 Jan 2019 22:38:20 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547764700.14.0.124995381091.issue35755@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thanks for the info on CS_PATH, Victor. IMHO it'd make sense to use the libc-provided default PATH at least in shutil.which() since its intent is to emulate "which" from the default shell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:47:58 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 17 Jan 2019 22:47:58 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
In-Reply-To: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>
Message-ID: <1547765278.01.0.217985362255.issue35761@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

What would the interaction be between other_instance and changes? Why is this API different from .replace()?

----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:51:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:51:44 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547765504.43.0.31787659747.issue23156@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +11298
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:52:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:52:00 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547765520.3.0.134769403464.issue23156@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch
pull_requests: +11298, 11299
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:52:15 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:52:15 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547765535.87.0.891592042591.issue23156@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch, patch
pull_requests: +11298, 11299, 11300
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:56:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:56:09 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547765769.53.0.564591266267.issue23156@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If the obsolete text is not to revised, it should be removed, as Ned suggested.  I don't now think a replacement list is needed.

Serhiy, if you have any opinion either way, please say go.

----------
stage: patch review -> needs patch
versions: +Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 17:56:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 22:56:58 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547765818.39.0.412769627582.issue23156@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

/go/so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:16:04 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 17 Jan 2019 23:16:04 +0000
Subject: [issue26414] os.defpath too permissive
In-Reply-To: <1456181417.61.0.91952600054.issue26414@psf.upfronthosting.co.za>
Message-ID: <1547766964.25.0.628264329711.issue26414@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Remove current directory from posixpath.defpath to enhance security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26414>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:19:32 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Jan 2019 23:19:32 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
In-Reply-To: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>
Message-ID: <1547767172.97.0.432581584599.issue35761@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm don't see the point of this proposal.  The fields of dataclasses are already mutable, so they can be updated just like any other object (no need for a special mechanism):

a = InventoryItem(name='Widget', unit_price=37.25, quantity_on_hand=10)

a.quantity_on_hand -= 1           # Sold one
a.unit_price *= 0.90              # Ten percent off sale

Also, it's not hard to directly take data from one instance to another:

a.name = master_catalog.name
a.unit_price = master_catalog.unit_price

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:24:33 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Jan 2019 23:24:33 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547767473.75.0.70291195157.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +11301

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:24:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:24:38 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547767478.53.0.359846847235.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11304

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:24:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:24:46 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547767486.0.0.822911843754.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11304, 11305

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:24:48 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Jan 2019 23:24:48 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547767488.92.0.462778410706.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +11301, 11302

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:24:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:24:54 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547767494.13.0.845704311928.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11304, 11305, 11306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:25:00 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 17 Jan 2019 23:25:00 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547767500.54.0.821709848085.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +11301, 11302, 11303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:26:22 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:26:22 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1547767582.35.0.937774790089.issue34162@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11307

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:26:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:26:57 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547767617.22.0.208857279657.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:27:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:27:10 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547767630.34.0.430814535577.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11305

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:27:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:27:23 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547767643.85.0.321018407118.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11304

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:29:31 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 17 Jan 2019 23:29:31 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
In-Reply-To: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>
Message-ID: <1547767771.17.0.109728743889.issue35761@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that I don't see the point, unless there's something I'm missing with other_instance. Or maybe the proposal is for it to also work with frozen dataclasses? I'm definitely -1 on that.

So unless there's something I'm missing where normal attribute assignment wouldn't work, I'm leaning toward rejecting this. What is it about dataclasses that would need this feature, where regular classes don't? Just do what you'd do with regular classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:43:33 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Jan 2019 23:43:33 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547768613.95.0.274030371338.issue35283@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I think yes.
People will be notified about depreciation earlier, even after 3.8 release not everybody switches to a new version fast.
For example, I still use 3.6 for my job now (but we are planning to switch to 3.7 in a month or two).
Adding PendingDeprecationWarning to 3.7 is safe, I expect a very few code uses `.isAlive()` on Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:44:22 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:44:22 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547768662.56.0.267473640057.issue34161@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 56c16057c639acc2fb89c6b783425320f23a5f6c by Terry Jan Reedy in branch 'master':
bpo-34161: Update idlelib/NEWS.txt to 2019 Jan 17 (GH-11597)
https://github.com/python/cpython/commit/56c16057c639acc2fb89c6b783425320f23a5f6c


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:44:41 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 23:44:41 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547768681.52.0.208375128962.issue34161@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11308

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:44:53 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 23:44:53 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547768693.38.0.278848771537.issue34161@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11308, 11309

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:45:04 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 23:45:04 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547768704.88.0.332669076561.issue34161@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11308, 11309, 11310

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:48:55 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Jan 2019 23:48:55 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1547768935.1.2.1503879305e-06.issue34162@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11311

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:50:22 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:50:22 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547769022.34.0.90134483711.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11310

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:50:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:50:45 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547769045.19.0.442678400198.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11309

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:51:04 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:51:04 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547769064.77.0.87700595882.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11308

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:51:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:51:54 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1547769114.75.0.036538282835.issue34162@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

New changeset 56c16057c639acc2fb89c6b783425320f23a5f6c by Terry Jan Reedy in branch 'master':
bpo-34161: Update idlelib/NEWS.txt to 2019 Jan 17 (GH-11597)
https://github.com/python/cpython/commit/56c16057c639acc2fb89c6b783425320f23a5f6c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:52:14 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:52:14 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547769134.26.0.457466640336.issue34161@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: https://bugs.python.org/msg333912

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 18:55:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 17 Jan 2019 23:55:26 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547769326.77.0.83936651891.issue34161@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sorry for the noise.  It seems like a bug to me that GitHub keeps a secret link to the original title and uses it in the merge box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:00:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 00:00:54 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547769654.02.0.605834293609.issue23156@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset cf27c06229eb4b8280bb5f2b93a57e33163411f4 by Terry Jan Reedy in branch 'master':
bpo-23156: Remove obsolete tix install directions (GH-11595)
https://github.com/python/cpython/commit/cf27c06229eb4b8280bb5f2b93a57e33163411f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:01:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 00:01:09 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547769654.02.0.605834293609.issue23156@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset cf27c06229eb4b8280bb5f2b93a57e33163411f4 by Terry Jan Reedy in branch 'master':
bpo-23156: Remove obsolete tix install directions (GH-11595)
https://github.com/python/cpython/commit/cf27c06229eb4b8280bb5f2b93a57e33163411f4


----------
pull_requests: +11312
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:01:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 00:01:11 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547769654.02.0.605834293609.issue23156@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset cf27c06229eb4b8280bb5f2b93a57e33163411f4 by Terry Jan Reedy in branch 'master':
bpo-23156: Remove obsolete tix install directions (GH-11595)
https://github.com/python/cpython/commit/cf27c06229eb4b8280bb5f2b93a57e33163411f4


----------
pull_requests: +11312, 11313
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:01:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 00:01:13 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547769654.02.0.605834293609.issue23156@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset cf27c06229eb4b8280bb5f2b93a57e33163411f4 by Terry Jan Reedy in branch 'master':
bpo-23156: Remove obsolete tix install directions (GH-11595)
https://github.com/python/cpython/commit/cf27c06229eb4b8280bb5f2b93a57e33163411f4


----------
pull_requests: +11312, 11313, 11314
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:05:33 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 00:05:33 +0000
Subject: [issue34161] (good first issue) Tutorial 7.1 str.format() code
 example syntax error
In-Reply-To: <1532062323.28.0.56676864532.issue34161@psf.upfronthosting.co.za>
Message-ID: <1547769933.66.0.165947528525.issue34161@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11315

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34161>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:07:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 00:07:13 +0000
Subject: [issue23156] Update tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547770033.09.0.81835760966.issue23156@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ebb08beb08461eb5f147aaca6f86cafa4ea15bff by Miss Islington (bot) in branch '3.7':
bpo-23156: Remove obsolete tix install directions (GH-11595)
https://github.com/python/cpython/commit/ebb08beb08461eb5f147aaca6f86cafa4ea15bff


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:31:42 2019
From: report at bugs.python.org (Patrick Rice)
Date: Fri, 18 Jan 2019 00:31:42 +0000
Subject: [issue35765] Document references object x but doesn't show it in the
 example
Message-ID: <1547771500.83.0.912392206765.issue35765@roundup.psfhosted.org>


New submission from Patrick Rice <price at zoox.com>:

https://docs.python.org/3.5/tutorial/inputoutput.html

If you have an object x, you can view its JSON string representation with a simple line of code:

>>>
>>> import json
>>> json.dumps([1, 'simple', 'list'])
'[1, "simple", "list"]'

----------
assignee: docs at python
components: Documentation
messages: 333917
nosy: Patrick Rice, docs at python
priority: normal
severity: normal
status: open
title: Document references object x but doesn't show it in the example
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35765>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:31:45 2019
From: report at bugs.python.org (bryan.koch)
Date: Fri, 18 Jan 2019 00:31:45 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1547771505.97.0.32419395184.issue35756@roundup.psfhosted.org>


bryan.koch <bbkoch94 at gmail.com> added the comment:

Thank you both for the clarifications.  I agree these's no bug in `yield from` however is there a way to reference the return value when a generator with a return is invoked using `for val in gen` i.e. when the generator is invoked without delegation?

I could write my own wrapper around using `next` to work around this but it might be an oversight of the new grammar (new being relative) that the return value is only available when invoked from the `yield from` syntax.

Essentially I have code that looks like
`
for value in generator:
  do thing with value
  yield value
`
where I need to do something before yielding the value.  It would be awesome if invoking a generator above would throw a SyntaxError iff it contained a return and it wasn't invoked through `yield from`.

The below isn't valid Python and I'm not sure that it should be but it's what I need to do.

`
return_value = for value in generator:
  do thing with value
  yield value

if return_value:
  do something with return_value
`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:33:02 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Jan 2019 00:33:02 +0000
Subject: [issue35766] Merge typed_ast back into CPython
Message-ID: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

(This started at https://discuss.python.org/t/merge-typed-ast-back-into-cpython/377. It's somewhat related to https://bugs.python.org/issue33337.) 

I now have a thorough understanding of what typed_ast does, and I think it would be straightforward to port it upstream. We?d need to define two new tokens to represent `# type: ignore` and `# type: <whatever>`, and tokenizer code to recognize these. Then we need a new flag to be passed to the tokenizer (via the parser) that enables this behavior. We make a small number of changes to `Grammar` (inserting optional `TYPE_COMMENT` tokens and to `Python.asdl` (adding fields to a few node types to hold the optional type comment), and a fair number of changes to `ast.c` to extract the type comments. We have similar patches for 3.6 and 3.7, so it's a simple matter of porting those patches to 3.8.

By default, `ast.parse()` should not return type comments, since this would reject some perfectly good Python code (with sonething looking like a type comment in a place where the grammar doesn?t allow it). But passing an new flag will cause the tokenizer to process type comments and the returned tree will contain them.

I could produce a PR with this in a few days (having just gone over most of the process for porting typed_ast from 3.6 to 3.7).

There?s one more feature I?d like to lobby for ? a feature_version flag that modifies the grammar slightly so it resembles an older version of Python (going back to 3.4). This is used in mypy to decouple the Python version you?re running from the Python version for which you?re checking compatibility (useful when checking code that will be deployed on a system with a different Python version installed). I imagine this would be useful to other linters as well, and the implementation is mostly manipulating whether `async` and `await` are keywords. But if there?s pushback to this part I can live without it ? the rest of the work is still useful.

In the next few days I will produce a PR so people can see for themselves.

In https://discuss.python.org/t/merge-typed-ast-back-into-cpython/377/17, ?ukasz offered to merge my PR.

----------
components: Library (Lib)
messages: 333919
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Merge typed_ast back into CPython
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:49:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 00:49:08 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1547772548.23.0.859900184372.issue34162@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 59d7bdb3386ab78ccf6edbbeba9669124515c707 by Terry Jan Reedy (Miss Islington (bot)) in branch '3.7':
bpo-34162: Update idlelib/NEWS.txt to 2019 Jan 17 (GH-11597) (GH-11598)
https://github.com/python/cpython/commit/59d7bdb3386ab78ccf6edbbeba9669124515c707


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Thu Jan 17 19:51:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 00:51:13 +0000
Subject: [issue23156] Remove tix install information in tkinter tix chapter of
 doc
In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za>
Message-ID: <1547772673.88.0.485895144624.issue23156@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Update tix install information in tkinter tix chapter of doc -> Remove tix install information in tkinter tix chapter of doc
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23156>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:00:50 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Jan 2019 01:00:50 +0000
Subject: [issue35601] Race condition in test_signal_handling_args x86-64 High
 Sierra 3.75
In-Reply-To: <1545968759.07.0.590219498678.issue35601@roundup.psfhosted.org>
Message-ID: <1547773250.63.0.199330938506.issue35601@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7eef540ab89e426b622373f43713521876447f2f by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-35601: Alleviate race condition when waiting for SIGALRM in test_asyncio (GH-11337) (GH-11348)
https://github.com/python/cpython/commit/7eef540ab89e426b622373f43713521876447f2f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35601>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:07:41 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Jan 2019 01:07:41 +0000
Subject: [issue35525] Incorrect keyword name in NNTP.starttls() documentation
In-Reply-To: <1545146886.62.0.788709270274.issue35525@psf.upfronthosting.co.za>
Message-ID: <1547773661.63.0.881403600222.issue35525@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7887c02d3372ebe3b39379588364134521a36c4e by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-35525: Correct the argument name for NNTP.starttls() (GH-11310) (GH-11417)
https://github.com/python/cpython/commit/7887c02d3372ebe3b39379588364134521a36c4e


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35525>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:09:22 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 18 Jan 2019 01:09:22 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1547773762.83.0.58819557499.issue34850@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Lets move forward with this as a SyntaxWarning in 3.8 and see if anyone complains during the betas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:11:12 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Jan 2019 01:11:12 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547773872.65.0.841639208635.issue35486@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 1edb3dc6ff70db88a7e89586578e58a86ee0e75e by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-35486: Note Py3.6 import system API requirement change (GH-11540) (GH-11588)
https://github.com/python/cpython/commit/1edb3dc6ff70db88a7e89586578e58a86ee0e75e


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:12:22 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Jan 2019 01:12:22 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1547773942.26.0.643522549675.issue35486@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I've merged the doc changes for 3.6, thanks.  Can we close this now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:25:21 2019
From: report at bugs.python.org (Jason Fried)
Date: Fri, 18 Jan 2019 01:25:21 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
Message-ID: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>


New submission from Jason Fried <me at jasonfried.info>:

https://github.com/python/cpython/blob/3.7/Lib/unittest/loader.py#L232

fullName = '%s.%s' % (testCaseClass.__module__, testFunc.__qualname__)

Instead we should probably replace testFunc.__qualname__ with attrname

I ran into this while running a test suite that built up test functions using partials and added them to the TestCase class with setattr. 

This works in 3.6.3

----------
messages: 333926
nosy: fried, lisroach, lukasz.langa
priority: normal
severity: normal
status: open
title: unittest loader doesn't work with partial test functions
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:29:12 2019
From: report at bugs.python.org (Jason Fried)
Date: Fri, 18 Jan 2019 01:29:12 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1547774952.6.0.94204557074.issue35767@roundup.psfhosted.org>


Jason Fried <me at jasonfried.info> added the comment:

Oh this is broken in 3.7 trunk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:44:57 2019
From: report at bugs.python.org (Jason Fried)
Date: Fri, 18 Jan 2019 01:44:57 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1547775897.44.0.521495667917.issue35767@roundup.psfhosted.org>


Jason Fried <me at jasonfried.info> added the comment:

working on a pull request

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 20:51:19 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 18 Jan 2019 01:51:19 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547776279.25.0.288986965975.issue35701@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

The UUID module documentation (and docstring) begin with:

"This module provides immutable UUID objects"

Immutable is a stronger guarantee than __slots__ enforces already, so the documentation already ruled out adding arbitrary attributes to UUID (and the __setattr__ that unconditionally raised TypeError('UUID objects are immutable') supported that.

Given the behavior hasn't changed in any way that contradicts the docs, nor would it affect anyone who wasn't intentionally working around the __setattr__ block, I don't feel a need to mention the arbitrary attribute limitation.

It's fine to leave in the What's New note (it is a meaningful memory savings for applications using lots of UUIDs), but the note can simplify to just:

"""uuid.UUID now uses __slots__ to reduce its memory footprint."""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:04:23 2019
From: report at bugs.python.org (Jason Fried)
Date: Fri, 18 Jan 2019 02:04:23 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1547777063.0.0.643861582334.issue35767@roundup.psfhosted.org>


Change by Jason Fried <me at jasonfried.info>:


----------
keywords: +patch
pull_requests: +11316
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:04:27 2019
From: report at bugs.python.org (Jason Fried)
Date: Fri, 18 Jan 2019 02:04:27 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1547777067.74.0.476555719745.issue35767@roundup.psfhosted.org>


Change by Jason Fried <me at jasonfried.info>:


----------
keywords: +patch, patch
pull_requests: +11316, 11317
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:04:33 2019
From: report at bugs.python.org (Jason Fried)
Date: Fri, 18 Jan 2019 02:04:33 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1547777073.76.0.389708084683.issue35767@roundup.psfhosted.org>


Change by Jason Fried <me at jasonfried.info>:


----------
keywords: +patch, patch, patch
pull_requests: +11316, 11317, 11318
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:07:28 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Jan 2019 02:07:28 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547777248.12.0.818975021698.issue35283@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Great!
Should we notify this deprecation also on Doc/whatsnew/3.7.rst?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:13:29 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 02:13:29 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547777609.09.0.0882932634963.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:13:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 02:13:47 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547777627.81.0.543542180273.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:18:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 02:18:07 +0000
Subject: [issue35765] Document references object x but doesn't show it in the
 example
In-Reply-To: <1547771500.83.0.912392206765.issue35765@roundup.psfhosted.org>
Message-ID: <1547777887.69.0.643341687654.issue35765@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. I think x here is implied as [1, 'simple', 'list']. Do you want to make it explicit with x = [1, 'simple', 'list'] in the code block?

Removing 3.5 since it's in security fixes only mode.

----------
nosy: +xtreak
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35765>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:24:17 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 18 Jan 2019 02:24:17 +0000
Subject: [issue35757] slow subprocess.Popen(..., close_fds=True)
In-Reply-To: <1547699341.03.0.843639889929.issue35757@roundup.psfhosted.org>
Message-ID: <1547778257.58.0.000544349747846.issue35757@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Others can correct me if I'm wrong, but I'm fairly sure 2.7 isn't making changes unless they fix critical or security-related bugs.

The code here is suboptimal, but it's already been fixed in Python 3 (in #8052), as part of a C accelerator module (that reduces the risk of race conditions and other conflicts your Python level fix entails). Unless someone corrects me, I'll close this as "Won't Fix".

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35757>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:26:15 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 02:26:15 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547778375.3.0.488567350587.issue35730@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset e55cf024cae203f63b4f78f1b21c1375fe424441 by Terry Jan Reedy (Tal Einat) in branch 'master':
bpo-35730: IDLE - test squeezer reload() by checking load_font() (GH-11585)
https://github.com/python/cpython/commit/e55cf024cae203f63b4f78f1b21c1375fe424441


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:26:25 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 02:26:25 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547778385.85.0.95858321302.issue35730@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11320

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:26:34 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 02:26:34 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547778394.95.0.997326131267.issue35730@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11320, 11321

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:26:43 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 02:26:43 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547778403.77.0.741630334553.issue35730@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11320, 11321, 11322

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 21:44:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 02:44:13 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547779453.4.0.471899047034.issue35730@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 237f864c905531b2da211bebc5f6109b0b797bac by Miss Islington (bot) in branch '3.7':
bpo-35730: IDLE - test squeezer reload() by checking load_font() (GH-11585)
https://github.com/python/cpython/commit/237f864c905531b2da211bebc5f6109b0b797bac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Thu Jan 17 22:01:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 03:01:30 +0000
Subject: [issue31860] IDLE: Make font sample editable
In-Reply-To: <1508851240.71.0.213398074469.issue31860@psf.upfronthosting.co.za>
Message-ID: <1547780490.8.0.396414021355.issue31860@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Closing #31777 as duplicate of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31860>
_______________________________________

From report at bugs.python.org  Thu Jan 17 22:01:39 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 03:01:39 +0000
Subject: [issue31777] IDLE: Let users add to font selection
In-Reply-To: <1507846043.1.0.213398074469.issue31777@psf.upfronthosting.co.za>
Message-ID: <1547780499.97.0.241144278781.issue31777@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Serhiy opened #31860 with a patch.  So close this as duplicate.

----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> IDLE: Make font sample editable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31777>
_______________________________________

From report at bugs.python.org  Thu Jan 17 22:49:43 2019
From: report at bugs.python.org (ulin)
Date: Fri, 18 Jan 2019 03:49:43 +0000
Subject: [issue35734] Remove unused _BaseV4._is_valid_netmask in ipaddress
In-Reply-To: <1547437878.33.0.689203196624.issue35734@roundup.psfhosted.org>
Message-ID: <1547783383.27.0.432738653162.issue35734@roundup.psfhosted.org>


ulin <linlin152 at foxmail.com> added the comment:

OK, message copied, I'll mark it closed. :)

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35734>
_______________________________________

From report at bugs.python.org  Thu Jan 17 23:42:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 04:42:28 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1547786548.95.0.506324140977.issue35767@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems this was introduced with issue32071

----------
nosy: +jonash, pitrou, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 17 23:51:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 04:51:21 +0000
Subject: [issue35768] IDLE: Auto measure font fixed pitch characteristics
Message-ID: <1547787079.94.0.0809073179555.issue35768@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The greatly expanded configdialog Font tab multi-alphabet sample reveals to some degree how well tk fills in BMP Unicode characters on a particular machine.  It also lets users extend the sample.

The sample has 2 lines of 20 ascii characters each and lines of 20 non-Latin1, IPA, Greek, Cyrillic, Hebrew, and Arabic characters.  The intention is to let one see if a font (as extended) is fixed-pitch for Ascii and if that property extends to any of those other European and Near East alphabets. On my machine, the number of fixed alphabets varies from 0, 1 (ascii), 2 (rest of Latin1) up to 7 (for Courier) (and some in between).

On #35196, Raymond Hettinger asked whether fixed-pitch fonts could be detected.  With the caveat that this property is not binary unless we restrict attention to Ascii, yes.  Without measuring each character, we could check the ascii lines and then the others. We could then highlight the lines in the sample that pass.

Before coding, we need to experiment a bit with the Font measuring method.  Should we cache results in .idlerc?

For all the fonts on my machine, the East Asian CJK characters are filled in with a fixed-pitch that is about 1.6 to 1.8 (not 2.0) times the Ascii fixed or average pitch.

Raymond also suggested limiting the font list to those with fixed ascii.  I think at least segregating fixed Ascii pitch fonts to make them easy to find is a great idea.  Some detail need to be thought about.

----------
assignee: terry.reedy
components: IDLE
messages: 333939
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Auto measure font fixed pitch characteristics
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35768>
_______________________________________

From report at bugs.python.org  Thu Jan 17 23:56:53 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Jan 2019 04:56:53 +0000
Subject: [issue35757] slow subprocess.Popen(..., close_fds=True)
In-Reply-To: <1547699341.03.0.843639889929.issue35757@roundup.psfhosted.org>
Message-ID: <1547787413.91.0.012790802943.issue35757@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Yeah, this is WONTFIX particularly since you can have the Python3 implementation in Python 2 easily with https://pypi.org/project/subprocess32/.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35757>
_______________________________________

From report at bugs.python.org  Fri Jan 18 00:47:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2019 05:47:52 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1547790472.01.0.65586914583.issue34850@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3bcbedc9f1471d957a30a90f9d1251516b422416 by Serhiy Storchaka in branch 'master':
bpo-34850: Emit a warning for "is" and "is not" with a literal. (GH-9642)
https://github.com/python/cpython/commit/3bcbedc9f1471d957a30a90f9d1251516b422416


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Fri Jan 18 00:48:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2019 05:48:42 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1547790522.23.0.011486335955.issue34850@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thanks.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:19:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:19:08 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
Message-ID: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Conform to PEP 8.

----------
assignee: terry.reedy
components: IDLE
messages: 333943
nosy: terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: IDLE: change new file name from  ''Untitled" to "untitled"
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:35:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:35:38 +0000
Subject: [issue25522] IDLE: warn if save-as name matches stdlib name
In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>
Message-ID: <1547793338.07.0.432206943393.issue25522@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Also check if the name is not an identifier and therefore could not be imported.  Example:

>>> exec('import abc--bb')
    import abc--bb
              ^
SyntaxError: invalid syntax

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25522>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:36:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:36:27 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547793387.88.0.281523259262.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11322

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:36:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:36:43 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547793403.96.0.879215105828.issue35730@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11321

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:42:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 06:42:09 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
Message-ID: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I used to launch IDLE using from master using ./python.exe -m idlelib . It used to work but fails on master on Mac OS now. There seems to be some discussion about this on msg332672 after the commit c1b4b0f6160e1919394586f44b12538505fed300. Feel free to close this if it's a known issue. I haven't tested it on latest 3.7 but it seems the commit was also merged to 3.7 so I am just adding 3.8 as version.

Mac OS version : 10.10.4

?  cpython git:(master) ? git checkout c1b4b0f6160e1919394586f44b12538505fed300 Lib/idlelib && ./python.exe -m idlelib
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/runpy.py", line 192, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/idlelib/__main__.py", line 7, in <module>
    idlelib.pyshell.main()
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/idlelib/pyshell.py", line 1507, in main
    macosx.setupApp(root, flist)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/idlelib/macosx.py", line 280, in setupApp
    overrideRootMenu(root, flist)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/idlelib/macosx.py", line 181, in overrideRootMenu
    del mainmenu.menudefs[-2][1][0]
IndexError: list assignment index out of range

?  cpython git:(master) ? git checkout c1b4b0f6160e1919394586f44b12538505fed300~1 Lib/idlelib && ./python.exe -m idlelib # Works


$ git show c1b4b0f6160e1919394586f44b12538505fed300
commit c1b4b0f6160e1919394586f44b12538505fed300 (bpo35557, 35559)
Author: Cheryl Sabella <cheryl.sabella at gmail.com>
Date:   Sat Dec 22 01:25:45 2018 -0500

     bpo-22703: IDLE: Improve Code Context and Zoom Height menu labels (GH-11214)



    The Code Context menu label now toggles between Show/Hide Code Context.
     The Zoom Height menu now toggles between Zoom/Restore Height.
     Zoom Height has moved from the Window menu to the Options menu.


    https://bugs.python.org/issue22703

----------
assignee: terry.reedy
components: IDLE
messages: 333945
nosy: cheryl.sabella, taleinat, terry.reedy, xtreak
priority: normal
severity: normal
status: open
title: IDLE: python -m idlelib fails on master on Mac OS 10.10.4
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:42:41 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:42:41 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1547793761.91.0.225744067297.issue35769@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +11323
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:42:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:42:45 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1547793765.27.0.840820682018.issue35769@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch
pull_requests: +11323, 11324
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:46:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:46:53 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1547794013.25.0.170344613927.issue35769@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11324

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:51:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:51:08 +0000
Subject: [issue35771] IDLE: Fix tooltip Hovertiptest failure
Message-ID: <1547794267.4.0.582455332849.issue35771@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In the buildbot testing for #35730, this test failed on X86 Windows 3.7 and passed on retest.  I did not check the green bots, so there could be other fail and pass results.

======================================================================
FAIL: test_showtip_on_mouse_enter_hover_delay (idlelib.idle_test.test_tooltip.HovertipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.7.bolen-windows7\build\lib\idlelib\idle_test\test_tooltip.py", line 112, in test_showtip_on_mouse_enter_hover_delay
    self.assertFalse(tooltip.tipwindow and tooltip.tipwindow.winfo_viewable())
AssertionError: 1 is not false

We should at least look at this since it might someday fail twice in a row on 1 machine.

----------
messages: 333946
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Fix tooltip Hovertiptest failure
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35771>
_______________________________________

From report at bugs.python.org  Fri Jan 18 01:54:15 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 06:54:15 +0000
Subject: [issue35730] IDLE: Fix squeezer test_reload.
In-Reply-To: <1547400161.39.0.565587662986.issue35730@roundup.psfhosted.org>
Message-ID: <1547794455.29.0.42164648923.issue35730@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I looked at the non-green results on the buildbot grid and found one IDLE failure, which passed on retest.  I opened #35771 for this.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35730>
_______________________________________

From report at bugs.python.org  Fri Jan 18 02:10:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 07:10:00 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1547795400.42.0.729423594063.issue35769@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset a902239f22c322d8988c514dd1c724aade3e4ef3 by Terry Jan Reedy in branch 'master':
bpo-35769: Change IDLE's name for new files from 'Untitled' to 'untitled' (GH-11602)
https://github.com/python/cpython/commit/a902239f22c322d8988c514dd1c724aade3e4ef3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 02:10:12 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 07:10:12 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1547795412.3.0.483494036256.issue35769@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11325

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 02:24:12 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 07:24:12 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1547796252.95.0.293991677967.issue35769@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5f9a168a313485791d85250e5bf673b66bd51244 by Miss Islington (bot) in branch '3.7':
bpo-35769: Change IDLE's name for new files from 'Untitled' to 'untitled' (GH-11602)
https://github.com/python/cpython/commit/5f9a168a313485791d85250e5bf673b66bd51244


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Fri Jan 18 03:15:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 08:15:44 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547799344.0.0.367318197864.issue35770@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for the report.  The error line "del mainmenu.menudefs[-2][1][0]" follows this comment.
  # Remove the 'Configure Idle' entry from the options menu, it is in the
  # application menu as 'Preferences'
However, -2 is the Window menu, while Options is -3.  Before the c1b patch, Window started with one entry, Zoom Height.  This explains why 'Configure IDLE' is still present, and Zoom Height is absent.  I did not notice the latter gone before because there is an Apple-supplied Zoom entry, which maximizes width as well as height.  I did not notice that this was a replacement.

After the patch, Window starts empty, which is why even index 0 fails.  So try changing -2 to -3 in macosx, getting [-3][1][0] and see if everything works.

When the dialog is removed, the menu will start with a separator bar.  It should go to.  So next try [-3][1][0:1]

----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 03:17:24 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jan 2019 08:17:24 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547799444.06.0.747255746075.issue35283@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 03:25:00 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Jan 2019 08:25:00 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547799900.79.0.105919403937.issue35283@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Not sure. IMHO it is not a *notable* change worth to be mentioned in https://docs.python.org/3/whatsnew/3.7.html#notable-changes-in-python-3-7-2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 03:26:45 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 18 Jan 2019 08:26:45 +0000
Subject: [issue25522] IDLE: warn if save-as name matches stdlib name
In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>
Message-ID: <1547800005.91.0.57613512216.issue25522@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Many beginners don't write files in order to import them. For them, these name-checking is simply adding noise. If you want to do something in this area, I think a much more useful (and difficult) course of action would be to check on the opposite end. If an AttributeError "module blah has no attribute foo" is raised, then check whether a file in the current directory (or simply the current file) is named blah, and there is also a stdlib blah that has fool.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25522>
_______________________________________

From report at bugs.python.org  Fri Jan 18 03:38:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 08:38:47 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547800727.21.0.527993488794.issue35770@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks, I can confirm that your fix launches idlelib.

Not working : del mainmenu.menudefs[-2][1][0]

Working : del mainmenu.menudefs[-3][1][0]

Options menu listing on master with the fix with "Show code context" disabled.
- Show code context
- Zoom height

git checkout v3.7.2 Lib/idlelib/ also works fine so I guess it's a regression but I don't know if this affects other versions of Mac OS.

Options menu listing on 3.7.2
- Configure IDLE
- Code Context

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:07:22 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Jan 2019 09:07:22 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547802442.18.0.522998705202.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +11326

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:07:37 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Jan 2019 09:07:37 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547802457.92.0.420659387268.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +11326, 11327

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:07:51 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Jan 2019 09:07:51 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547802471.27.0.875051923867.issue35283@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +11326, 11327, 11328

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:08:50 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Jan 2019 09:08:50 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547802530.93.0.600367733378.issue35283@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I've upload PR 11604
Thanks always

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:46:27 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 18 Jan 2019 09:46:27 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547804787.64.0.341849232103.issue33416@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch
pull_requests: +11329
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:46:44 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 18 Jan 2019 09:46:44 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547804804.93.0.028675647792.issue33416@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11329, 11330
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:47:02 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 18 Jan 2019 09:47:02 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547804822.15.0.949490920851.issue33416@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11329, 11330, 11331
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:50:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 09:50:20 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1547805020.76.0.0306170311134.issue33416@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Fri Jan 18 04:50:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 09:50:51 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547805051.15.0.759930485697.issue35283@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 36d9e9a4d5238d5a2f09679b6c51be66fbfc12c4 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-35283: Update the docstring of threading.Thread.join method (GH-11596)
https://github.com/python/cpython/commit/36d9e9a4d5238d5a2f09679b6c51be66fbfc12c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 06:15:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 11:15:46 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
Message-ID: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The following test_tarfile tests fail on ppc64 when using tmpfs filesystem (which is the case on RHEL package build server):

* test_sparse_file_00 (test.test_tarfile.GNUReadTest)
* test_sparse_file_01 (test.test_tarfile.GNUReadTest)
* test_sparse_file_10 (test.test_tarfile.GNUReadTest)
* test_sparse_file_old (test.test_tarfile.GNUReadTest)

Example of failure:

======================================================================
FAIL: test_sparse_file_00 (test.test_tarfile.GNUReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.6.6/Lib/test/test_tarfile.py", line 964, in test_sparse_file_00
    self._test_sparse_file("gnu/sparse-0.0")
  File "/builddir/build/BUILD/Python-3.6.6/Lib/test/test_tarfile.py", line 958, in _test_sparse_file
    self.assertLess(s.st_blocks * 512, s.st_size)
AssertionError: 131072 not less than 86016

Bug first report on RHEL8:
https://bugzilla.redhat.com/show_bug.cgi?id=1639490


test_tarfile has _fs_supports_holes() function to check if the filesystem supports sparse files with holes. The function returns True on:

* ext4 filesystem on x86_64 on my Fedora 29 (kernel 4.19)
* ext4 filesystem on x86_64 on my Fedora 29 (kernel 4.19)
* XFS filesystem on ppc64le (kernel 4.18)
* tmpfs filesystem on ppc64le (kernel 4.18)

In short, it always return True on x86_64 and ppc64le Linux kernels.

Problem: in practice, "tmpfs filesystem on ppc64le (kernel 4.18)" doesn't fully support sparse files.

--

Example from:
https://bugzilla.redhat.com/show_bug.cgi?id=1639490#c5

# ls -lhs ~/sparse 
48K -rw-r--r--. 1 root root 84K Jan 18 05:36 /root/sparse

Copy a sparse file from XFS to tmpfs: cp --sparse=always and fallocate --dig fail to punch holes, the file always take 128K on disk on tmpfs.

# cp sparse /root/mytmp/sparse --sparse=always
# ls -lhs /root/mytmp/sparse 
128K -rw-r--r--. 1 root root 84K Jan 18 06:10 /root/mytmp/sparse
# fallocate --dig /root/mytmp/sparse
# ls -lhs /root/mytmp/sparse 
128K -rw-r--r--. 1 root root 84K Jan 18 06:10 /root/mytmp/sparse

Counter example on XFS, source and destionation files use 48K on disk fo 84K of data:

# cp sparse sparse2 --sparse=always
# ls -lhs sparse*
48K -rw-r--r--. 1 root root 84K Jan 18 05:36 sparse
48K -rw-r--r--. 1 root root 84K Jan 18 06:13 sparse2

--

Attached PR fix the _fs_support_holes() heuristic to return properly False on tmpfs on ppc64le.

----------
components: Tests
messages: 333956
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_tarfile fails on ppc64le when using tmpfs filesystem
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 06:16:17 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 18 Jan 2019 11:16:17 +0000
Subject: [issue35762] subprocess.Popen with universal_newlines and nonblocking
 streams fails with "can't concat NoneType to bytes"
In-Reply-To: <1547738568.37.0.865745194211.issue35762@roundup.psfhosted.org>
Message-ID: <1547810177.64.0.976528564195.issue35762@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
title: subprocess.Popen with universal_newlines and nonblocking streams failes with "can't concat NoneType to bytes" -> subprocess.Popen with universal_newlines and nonblocking streams fails with "can't concat NoneType to bytes"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35762>
_______________________________________

From report at bugs.python.org  Fri Jan 18 06:22:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 11:22:38 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547810558.53.0.898500831537.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +11332
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 06:22:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 11:22:40 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547810560.85.0.217471664258.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch, patch
pull_requests: +11332, 11333
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 06:37:30 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Fri, 18 Jan 2019 11:37:30 +0000
Subject: [issue35755] Remove current directory from posixpath.defpath to
 enhance security
In-Reply-To: <1547682106.56.0.245747157525.issue35755@roundup.psfhosted.org>
Message-ID: <1547811450.62.0.0636775826028.issue35755@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35755>
_______________________________________

From report at bugs.python.org  Fri Jan 18 06:57:59 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 18 Jan 2019 11:57:59 +0000
Subject: [issue35773] test_bdb fails on AIX bot (regression)
Message-ID: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

I see in the bot history that test_bdb is now failing on AIX

https://buildbot.python.org/all/#/builders/161/builds/718/steps/4/logs/stdio

== CPython 3.8.0a0 (heads/master:a37f52436f, Jan 15 2019, 22:53:01) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /home/buildbot/buildarea/3.x.aixtools-aix-power6/build/build/test_python_5177546
== CPU count: 8
== encodings: locale=ISO8859-15, FS=iso8859-15

FYI: it is not failing on the GCC based bot (mine is based on XLC).

----------
components: Tests
messages: 333957
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_bdb fails on AIX bot (regression)
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35773>
_______________________________________

From report at bugs.python.org  Fri Jan 18 07:28:27 2019
From: report at bugs.python.org (Dhiraj)
Date: Fri, 18 Jan 2019 12:28:27 +0000
Subject: [issue35774] ASAN, memory leak
Message-ID: <1547814506.63.0.194209135829.issue35774@roundup.psfhosted.org>


New submission from Dhiraj <mishra.dhiraj95 at gmail.com>:

Hi Team, 

I have compiled cpython via clang using ASAN and memory leak was observed.

After successful build of python,
1. Run python
2. Ctrl + D

==21461==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 257790 byte(s) in 93 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12

Direct leak of 1640 byte(s) in 3 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12
    #4 0x96cea4 in _PyObject_GC_Malloc /home/input0/Desktop/cpython/Modules/gcmodule.c:1908:12
    #5 0x96cea4 in _PyObject_GC_NewVar /home/input0/Desktop/cpython/Modules/gcmodule.c:1937

Direct leak of 663 byte(s) in 1 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12
    #4 0x8b9dd8 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1362:20
    #5 0x8b84a5 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1194:18
    #6 0x8b9e09 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1365:22
    #7 0x8bf86a in read_object /home/input0/Desktop/cpython/Python/marshal.c:1451:9
    #8 0x8bf86a in marshal_loads_impl /home/input0/Desktop/cpython/Python/marshal.c:1763
    #9 0x8bf86a in marshal_loads /home/input0/Desktop/cpython/Python/clinic/marshal.c.h:158
    #10 0x564da7 in _PyMethodDef_RawFastCallKeywords /home/input0/Desktop/cpython/Objects/call.c

Direct leak of 579 byte(s) in 1 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12
    #4 0x8b9dd8 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1362:20
    #5 0x8b84a5 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1194:18
    #6 0x8b9e09 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1365:22
    #7 0x8b84a5 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1194:18
    #8 0x8b9e09 in r_object /home/input0/Desktop/cpython/Python/marshal.c:1365:22
    #9 0x8b409d in PyMarshal_ReadObjectFromString /home/input0/Desktop/cpython/Python/marshal.c:1568:14
    #10 0x8a0d81 in get_frozen_object /home/input0/Desktop/cpython/Python/import.c:1277:12
    #11 0x8a0d81 in _imp_get_frozen_object_impl /home/input0/Desktop/cpython/Python/import.c:2036
    #12 0x8a0d81 in _imp_get_frozen_object /home/input0/Desktop/cpython/Python/clinic/import.c.h:198
    #13 0x5623eb in _PyCFunction_FastCallDict /home/input0/Desktop/cpython/Objects/call.c:584:14
    #14 0x5623eb in PyCFunction_Call /home/input0/Desktop/cpython/Objects/call.c:789

Direct leak of 536 byte(s) in 1 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x6403b0 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x6403b0 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x6403b0 in pymalloc_realloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1869
    #4 0x6403b0 in _PyObject_Realloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1888
    #5 0x644ead in PyObject_Realloc /home/input0/Desktop/cpython/Objects/obmalloc.c:658:12

Indirect leak of 15640 byte(s) in 17 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12
    #4 0x675f9a in PyType_GenericAlloc /home/input0/Desktop/cpython/Objects/typeobject.c:975:15

Indirect leak of 7440 byte(s) in 7 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12

Indirect leak of 2571 byte(s) in 2 object(s) allocated from:
    #0 0x4f1460 in malloc (/home/input0/Desktop/cpython/python+0x4f1460)
    #1 0x63fc59 in PyMem_RawMalloc /home/input0/Desktop/cpython/Objects/obmalloc.c:527:12
    #2 0x63fc59 in _PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:1550
    #3 0x644d77 in PyObject_Malloc /home/input0/Desktop/cpython/Objects/obmalloc.c:640:12
    #4 0x687d07 in type_call /home/input0/Desktop/cpython/Objects/typeobject.c:934:11

SUMMARY: AddressSanitizer: 286859 byte(s) leaked in 125 allocation(s).

----------
messages: 333958
nosy: Dhiraj_Mishra
priority: normal
severity: normal
status: open
title: ASAN, memory leak
type: security
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35774>
_______________________________________

From report at bugs.python.org  Fri Jan 18 07:33:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 12:33:26 +0000
Subject: [issue35774] ASAN, memory leak
In-Reply-To: <1547814506.63.0.194209135829.issue35774@roundup.psfhosted.org>
Message-ID: <1547814806.23.0.304884216286.issue35774@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35774>
_______________________________________

From report at bugs.python.org  Fri Jan 18 07:43:24 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 12:43:24 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547815404.46.0.342396662047.issue35770@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Karthikeyan,

Thanks for catching this!  Did you want to submit the patch for it or did you want me to make the PR?  We're still working on the tests for the menus, so this would just be a code change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 07:58:50 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 12:58:50 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547816330.12.0.215621595313.issue35770@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Cheryl, feel free to submit a patch since I have less exposure to IDLE code. I can manually test the PR on my Mac and report back since this seems to be a Mac specific patch. It would be helpful if someone with access to other Mac OS versions can possibly test this so that it doesn't cause issues on other versions.

Applying the fix suggested by Terry on my machine and running tests

$ git diff | cat
diff --git a/Lib/idlelib/macosx.py b/Lib/idlelib/macosx.py
index 9be4ed2ec4..16a13a0f2e 100644
--- a/Lib/idlelib/macosx.py
+++ b/Lib/idlelib/macosx.py
@@ -178,7 +178,7 @@ def overrideRootMenu(root, flist):
     del mainmenu.menudefs[-1][1][0:2]
     # Remove the 'Configure Idle' entry from the options menu, it is in the
     # application menu as 'Preferences'
-    del mainmenu.menudefs[-2][1][0]
+    del mainmenu.menudefs[-3][1][0]
     menubar = Menu(root)
     root.configure(menu=menubar)
     menudict = {}

$ ./python.exe -m unittest idlelib.idle_test
sss......s..........................ss..ss...............................s.......s.............s.sssss...........s.ss..sss.ss....sss..s..s..s...s.....s.s.s................s..s........ss.........ssss.................ssss...................sssssss..s.sss...ss...........sssss.....s.s
----------------------------------------------------------------------
Ran 241 tests in 1.246s

OK (skipped=66)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:43:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 13:43:14 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547818994.6.0.788101537982.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:44:51 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 18 Jan 2019 13:44:51 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547819091.03.0.115177020736.issue35537@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11334

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:45:07 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 18 Jan 2019 13:45:07 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547819107.43.0.308094150706.issue35537@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11334, 11335

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:45:24 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 18 Jan 2019 13:45:24 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547819124.01.0.160153363455.issue35537@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
pull_requests: +11334, 11335, 11336

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:49:03 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 18 Jan 2019 13:49:03 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547819343.32.0.396072915067.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

My proposal vastly improves the situation for Decimal. I will write a PR for this and I hope that it won't be rejected just because it's not perfect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:55:27 2019
From: report at bugs.python.org (=?utf-8?q?Th=C3=A9ophile_Chevalier?=)
Date: Fri, 18 Jan 2019 13:55:27 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
In-Reply-To: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>
Message-ID: <1547819727.14.0.485882669633.issue35761@roundup.psfhosted.org>


Th?ophile Chevalier <theophile.chevalier at lenstra.fr> added the comment:

I understand your points, I'll give an example with a simplified version of my problem:


import dataclasses
import othermodule # is an external dependency

@dataclass
class City:
    name: str
    position: othermodule.Point # Point is a dataclass

    def update_position(self):
        obj = anymodule.get_position(name=self.name)
        
        # The classic solution would be to do
        self.position.x = obj.x
        self.position.y = obj.y

        # what if othermodule adds z (altitude) to Point?
        # we could imagine:
        dataclasses.update(self.position, obj)

        # I'm currently doing:
        self.position.__dict__.update(obj.__dict__)

Maybe I simply handle the issue the wrong way, so my dataclass proposal is out of scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Fri Jan 18 08:57:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 13:57:24 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547819844.25.0.494563427145.issue35707@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Not for Decimal! In fact sleep(Decimal("0.99")) is interpreted as sleep(0) because __int__ is used to convert.

Oh oh. I didn't know that. It should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:04:51 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 14:04:51 +0000
Subject: [issue35775] Add a general selection function to statistics
Message-ID: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Like discussed in #30999, the attached PR adds a general selection function to the statistics module. This allows to simply get the element at a given quantile of a collection.

https://www.cs.rochester.edu/~gildea/csc282/slides/C09-median.pdf

----------
components: Library (Lib)
messages: 333964
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: Add a general selection function to statistics
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:05:07 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 14:05:07 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547820307.6.0.0260466017262.issue35775@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +11337
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:05:10 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 14:05:10 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547820310.01.0.136825741386.issue35775@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch, patch
pull_requests: +11337, 11338
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:05:38 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 14:05:38 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547820338.18.0.553328735325.issue35775@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +rhettinger, steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:07:22 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 14:07:22 +0000
Subject: [issue30999] statistics module: add "key" keyword argument to median, 
 mode, ...
In-Reply-To: <1500847822.23.0.66362631161.issue30999@psf.upfronthosting.co.za>
Message-ID: <1547820442.54.0.123628276737.issue30999@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I suggest we closed this issue in favor of #35775 to discuss adding a selection function and the attached PR.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30999>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:09:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:09:48 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547820588.02.0.108629198438.issue35283@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c2647f2e45d2741fc44fd621966e05d15f2cd26a by Victor Stinner (Dong-hee Na) in branch '3.7':
bpo-35283: Add pending deprecation warning for Thread.isAlive (GH-11604)
https://github.com/python/cpython/commit/c2647f2e45d2741fc44fd621966e05d15f2cd26a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:14:31 2019
From: report at bugs.python.org (=?utf-8?q?Th=C3=A9ophile_Chevalier?=)
Date: Fri, 18 Jan 2019 14:14:31 +0000
Subject: [issue35761] Allow dataclasses to be updated in place
In-Reply-To: <1547734989.68.0.404239918534.issue35761@roundup.psfhosted.org>
Message-ID: <1547820871.08.0.827910683464.issue35761@roundup.psfhosted.org>


Th?ophile Chevalier <theophile.chevalier at lenstra.fr> added the comment:

I cannot do self.position = obj because I have references on position elsewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35761>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:15:02 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 18 Jan 2019 14:15:02 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547820902.71.0.568003126127.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I guess I should wait until PR 11507 is merged, to avoid merge conflicts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:16:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:16:53 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1547821013.53.0.00959370431741.issue35707@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

No please don't wait for my PR 11507. I'm not sure that it's correct, and this bug is more important than NaN/inf :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:17:47 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 18 Jan 2019 14:17:47 +0000
Subject: [issue35283] "threading._DummyThread" redefines "is_alive" but
 forgets "isAlive"
In-Reply-To: <1542752189.25.0.788709270274.issue35283@psf.upfronthosting.co.za>
Message-ID: <1547821067.56.0.497752027574.issue35283@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35283>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:27:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:27:37 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547821657.89.0.319290918275.issue35772@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oops, I forgot to attached my test script: create_sparse.py

----------
Added file: https://bugs.python.org/file48067/create_sparse.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:38:42 2019
From: report at bugs.python.org (Florian Weimer)
Date: Fri, 18 Jan 2019 14:38:42 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547822322.85.0.586687361733.issue35772@roundup.psfhosted.org>


Florian Weimer <fweimer at redhat.com> added the comment:

offsets = ( 4096, 12288, 20480, 28672, 36864, 45056, 53248, 61440, 69632,
        77824,)

These offsets are less than 64 KiB apart.  On systems with a 64 KiB page size, this will not result in a sparse file on tmpfs because the effective block size is the page size (tmpfs lives in the page cache).

Red Hat Enterprise Linux uses 64 KiB pages on aarch64, ppc64, ppc64le.  Only s390x and x86_64 use 4 KiB pages.

----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:42:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:42:07 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547822527.13.0.172311333175.issue35772@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ah yes, I confirm that ppc64le uses 64 KiB page size:

# python3
Python 3.6.8 (default, Jan 11 2019, 01:44:37) 
[GCC 8.2.1 20180905 (Red Hat 8.2.1-3)] on linux
>>> import resource
>>> resource.getpagesize()
65536

whereas my x86_64 laptop uses 4 KiB page size:

$ python3
Python 3.7.2 (default, Jan  3 2019, 09:14:01) 
[GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux
>>> import resource
>>> resource.getpagesize()
4096

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:46:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:46:35 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547822795.91.0.344188015403.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11339, 11340

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:46:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:46:28 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547822788.8.0.898977514735.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11339

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:46:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:46:43 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547822803.69.0.249295810277.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11339, 11340, 11341

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 09:57:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 14:57:31 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1547823451.95.0.326774618335.issue35772@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I updated PR 11606 to mention the link between tmpfs and the page size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:09:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:09:32 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547824172.9.0.113411436784.issue35045@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 34de2d312b3687994ddbc29adb66e88f672034c7 by Victor Stinner (Christian Heimes) in branch 'master':
bpo-35045: Accept TLSv1 default in min max test (GH-11510)
https://github.com/python/cpython/commit/34de2d312b3687994ddbc29adb66e88f672034c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:09:45 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 15:09:45 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547824185.4.0.980910867947.issue35045@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11342

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:09:57 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 15:09:57 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547824197.0.0.910246502767.issue35045@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11342, 11343

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:10:07 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 15:10:07 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547824207.66.0.507540851401.issue35045@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11342, 11343, 11344

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:10:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:10:24 +0000
Subject: [issue35136] test_ssl fails in AMD64 FreeBSD CURRENT Shared 3.6
 buildbot, OpenSSL 1.1.1a
In-Reply-To: <1541081962.85.0.788709270274.issue35136@psf.upfronthosting.co.za>
Message-ID: <1547824224.21.0.0714298622731.issue35136@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_ssl fails in AMD64 FreeBSD CURRENT Shared 3.6 buildbot -> test_ssl fails in AMD64 FreeBSD CURRENT Shared 3.6 buildbot, OpenSSL 1.1.1a

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35136>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:12:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:12:13 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547824333.46.0.121177590181.issue35045@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 2.7 is not affected: test_ssl doesn't test minimum_version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:19:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:19:32 +0000
Subject: [issue34834] test_ssl.test_options does not correctly account for
 built-in ctx defaults with openssl 1.1.1
In-Reply-To: <1538151296.99.0.545547206417.issue34834@psf.upfronthosting.co.za>
Message-ID: <1547824772.07.0.0642769903711.issue34834@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 2.7 doesn't support properly OpenSSL 1.1.1 yet, see:

* PR 10607
* PR 10608

I would prefer to have _ssl.OP_ENABLE_MIDDLEBOX_COMPAT rather than have an hardcoded constant in test_ssl. In master, test_ssl has been fixed and the constant has been added by:

commit 05d9fe32a1245b9a798e49e0c1eb91f110935b69
Author: Christian Heimes <christian at python.org>
Date:   Tue Feb 27 08:55:39 2018 +0100

    bpo-32947: OpenSSL 1.1.1-pre1 / TLS 1.3 fixes (#5663)
    
    * bpo-32947: OpenSSL 1.1.1-pre1 / TLS 1.3 fixes
    
    Misc fixes and workarounds for compatibility with OpenSSL 1.1.1-pre1 and
    TLS 1.3 support. With OpenSSL 1.1.1, Python negotiates TLS 1.3 by
    default. Some test cases only apply to TLS 1.2. Other tests currently
    fail because the threaded or async test servers stop after failure.
    
    I'm going to address these issues when OpenSSL 1.1.1 reaches beta.
    
    OpenSSL 1.1.1 has added a new option OP_ENABLE_MIDDLEBOX_COMPAT for TLS
    1.3. The feature is enabled by default for maximum compatibility with
    broken middle boxes. Users should be able to disable the hack and CPython's test suite needs
    it to verify default options.
    
    Signed-off-by: Christian Heimes <christian at python.org>

diff --git a/Doc/library/ssl.rst b/Doc/library/ssl.rst
index 7371024dce..5d5232eda3 100644
--- a/Doc/library/ssl.rst
+++ b/Doc/library/ssl.rst
@@ -831,6 +831,15 @@ Constants
 
    .. versionadded:: 3.3
 
+.. data:: OP_ENABLE_MIDDLEBOX_COMPAT
+
+   Send dummy Change Cipher Spec (CCS) messages in TLS 1.3 handshake to make
+   a TLS 1.3 connection look more like a TLS 1.2 connection.
+
+   This option is only available with OpenSSL 1.1.1 and later.
+
+   .. versionadded:: 3.8
+
 .. data:: OP_NO_COMPRESSION
 
    Disable compression on the SSL channel.  This is useful if the application
(...)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34834>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:21:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:21:55 +0000
Subject: [issue33995] test_min_max_version in test_ssl.py fails when Python is
 built against LibreSSL;
 {min,max}imum_version behavior differs from OpenSSL
In-Reply-To: <1530250345.83.0.56676864532.issue33995@psf.upfronthosting.co.za>
Message-ID: <1547824915.53.0.795009094979.issue33995@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, this issue looks like bpo-35045 which has been fixed.

----------
nosy: +vstinner
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> test_min_max_version (test.test_ssl.ContextTests) fails on Fedora 29+ and openssl 1.1.1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33995>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:27:05 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 15:27:05 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>
Message-ID: <1547825225.26.0.147780198807.issue20479@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Is this proposal still relevant? If so, I would like to work on its implementation.

I think the third proposition to change the API to have a new `weights` parameter is the best has it does not blindly suppose that a tuple is a pair (value, weight) which could not always be true.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:27:31 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 15:27:31 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>
Message-ID: <1547825251.49.0.452058604752.issue20479@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:29:12 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 15:29:12 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547825352.2.0.32530712831.issue35045@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6ca7183b3549d3eaa8a0c3b73255eeac24d7974d by Miss Islington (bot) in branch '3.7':
bpo-35045: Accept TLSv1 default in min max test (GH-11510)
https://github.com/python/cpython/commit/6ca7183b3549d3eaa8a0c3b73255eeac24d7974d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:30:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:30:16 +0000
Subject: [issue30212] test_ssl.py is broken in Centos7
In-Reply-To: <1493507734.99.0.744824306698.issue30212@psf.upfronthosting.co.za>
Message-ID: <1547825416.9.0.834327848819.issue30212@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

@david-cpi: Ping? Can you please try comments in my previous comment?

Without feedback from your side, I will close the issue as "outdated" in 2 weeks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30212>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:30:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 15:30:46 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1547825446.95.0.0103823961768.issue35045@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Christian. I merged your PR.

I like the simplicity of your fix ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:48:42 2019
From: report at bugs.python.org (David Antonio Garcia Campos)
Date: Fri, 18 Jan 2019 15:48:42 +0000
Subject: [issue30212] test_ssl.py is broken in Centos7
In-Reply-To: <1493507734.99.0.744824306698.issue30212@psf.upfronthosting.co.za>
Message-ID: <1547826522.82.0.394624316386.issue30212@roundup.psfhosted.org>


David Antonio Garcia Campos <dgarciacampos at gmail.com> added the comment:

Hello Victor,
I just saw your message. I will try to setup my enviorment and will come back to you.
BR David Garcia

----------
nosy: +David Antonio Garcia Campos

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30212>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:49:20 2019
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 18 Jan 2019 15:49:20 +0000
Subject: [issue21257] Document parse_headers function of http.client
In-Reply-To: <1397666699.47.0.0992171618243.issue21257@psf.upfronthosting.co.za>
Message-ID: <1547826560.18.0.327295721249.issue21257@roundup.psfhosted.org>


Brian Curtin <brian at python.org> added the comment:


New changeset 478f8291327a3e3ab17b5857699565df43a9e952 by Brian Curtin (Ashwin Ramaswami) in branch 'master':
bpo-21257: document http.client.parse_headers (GH-11443)
https://github.com/python/cpython/commit/478f8291327a3e3ab17b5857699565df43a9e952


----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21257>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:51:09 2019
From: report at bugs.python.org (Tasy)
Date: Fri, 18 Jan 2019 15:51:09 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547826669.78.0.530805802714.issue35713@roundup.psfhosted.org>


Tasy <obiwan408 at mail.com> added the comment:

Compiler:
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4

OS:
$ uname -a
Linux machine 4.4.0-141-generic #167~14.04.1-Ubuntu SMP Mon Dec 10 13:20:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Home directory is of type nfs in case that is relevant.
I'll try to do the gdb thing over the weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Fri Jan 18 10:59:04 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 18 Jan 2019 15:59:04 +0000
Subject: [issue20399] Comparison of memoryview
In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za>
Message-ID: <1547827144.25.0.973136914322.issue20399@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

The lack of support for the rich comparison operators on even the most basic memoryviews (e.g. 'B' format) means that memoryview is still a regression from some of the functionality buffer offered back in Python 2 ( https://stackoverflow.com/a/13574862/364696 ); you either need to convert back to bytes (losing the zero-copy behavior) or hand-write a comparator of your own to allow short-circuiting (which thanks to sort not taking cmp functions anymore, means you need to write it, then wrap it with functools.cmp_to_key if you're sorting, not just comparing individual items).

While I'll acknowledge it gets ugly to try to support every conceivable format, it seems like, at the very least, we could provide the same functionality as buffer for 1D contiguous memoryviews in the 'B' and 'c' formats (both of which should be handleable by a simple memcmp).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20399>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:07:18 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 16:07:18 +0000
Subject: [issue20399] Comparison of memoryview
In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za>
Message-ID: <1547827638.96.0.523787481382.issue20399@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20399>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:15:38 2019
From: report at bugs.python.org (Nazar)
Date: Fri, 18 Jan 2019 16:15:38 +0000
Subject: [issue35776] Virtualenv 16.2.0 Error Finding Pip
Message-ID: <1547828136.9.0.603302624111.issue35776@roundup.psfhosted.org>


New submission from Nazar <nazartrilisky at yahoo.com>:

Issue resolved by downgrading virtualenv from 16.2.0 to 15.1.0.

$ virtualenv -p python my_venv
Already using interpreter /usr/bin/python
New python executable in /home/your_user_name/my_venv/bin/python
Cannot find a wheel for setuptools
Cannot find a wheel for pip
Installing setuptools, pip, wheel...

  Complete output from command /home/your_user_name/my_venv/bin/python - setuptools pip wheel:
  Traceback (most recent call last):
  File "<stdin>", line 11, in <module>
ImportError: No module named pip
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 11, in <module>
    load_entry_point('virtualenv==16.2.0', 'console_scripts', 'virtualenv')()
  File "build/bdist.cygwin-<version>-x86_64/egg/virtualenv.py", line 768, in main
  File "build/bdist.cygwin-<version>-x86_64/egg/virtualenv.py", line 1030, in create_environment
  File "build/bdist.cygwin-<version>-x86_64/egg/virtualenv.py", line 983, in install_wheel
  File "build/bdist.cygwin-<version>-x86_64/egg/virtualenv.py", line 861, in call_subprocess
OSError: Command /home/your_user_name/my_venv/bin/python - setuptools pip wheel failed with error code 1

----------
components: Installation
messages: 333986
nosy: NazarTrilisky
priority: normal
severity: normal
status: open
title: Virtualenv 16.2.0 Error Finding Pip
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35776>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:20:44 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jan 2019 16:20:44 +0000
Subject: [issue20399] Comparison of memoryview
In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za>
Message-ID: <1547828443.99.0.537535579243.issue20399@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Josh, could you say what your use case is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20399>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:23:43 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Jan 2019 16:23:43 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547828623.15.0.300273555537.issue35775@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:31:42 2019
From: report at bugs.python.org (Henry Chen)
Date: Fri, 18 Jan 2019 16:31:42 +0000
Subject: [issue34782] Pdb crashes when code is executed in a mapping that does
 not define `__contains__`
In-Reply-To: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>
Message-ID: <1547829102.96.0.0119995792663.issue34782@roundup.psfhosted.org>


Henry Chen <tahafut at gmail.com> added the comment:

An attempt to clarify the issue in my own mind:

def foo():
    # import pdb; pdb.set_trace()
    exec('pass', {}, FakeContainer())

This function runs successfully. But if you uncomment the pdb line and then step thru in the pdb console, there is an Exception.

I *think* the underlying principle is that code that runs normally should also run under pdb, which this example violates. However, to adhere to the principle 100% could be a very steep technical cost.

Alternatively, I'd argue that the function should NOT run even without pdb, since exec requires a (complete) mapping type according to the documentation. Perhaps the thing to do is to add more stringent type checking to exec and eval?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34782>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:45:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 16:45:21 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1547829921.59.0.236638098878.issue32947@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11345

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:45:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 16:45:43 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1547829943.13.0.541812639096.issue32947@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11345, 11346

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:46:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 16:46:04 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1547829964.57.0.828676764861.issue32947@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11345, 11346, 11347

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:48:02 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 16:48:02 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547830082.69.0.801597482541.issue35770@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since it is my fix, I will write the PR.  But first, please test part 2, changing '0' to '0:1', just to make sure it works.

c1b added 'None,' (for separater bar) after the configdialog entry.  When the configdialog entry is removed, the None should be also.  On Windows, a menu that starts with None starts with a visible bar.  On my Mac Mohave, and perhaps on your machine, it is supressed.  But a) I would rather have the data structure match what is shown, and b) we cannot know if the supression occurs on all versions of macOS and predecessors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:52:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 16:52:01 +0000
Subject: [issue32947] Support OpenSSL 1.1.1
In-Reply-To: <1519559680.67.0.467229070634.issue32947@psf.upfronthosting.co.za>
Message-ID: <1547830321.69.0.971041014534.issue32947@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

On Fedora 29 with OpenSSL 1.1.1 FIPS  11 Sep 2018, test_connect_cadata() of test_ssl fails randomly:

---
$ ./python -m test -u all -F -m test_connect_cadata test_ssl 
Run tests sequentially
0:00:00 load avg: 0.43 [  1] test_ssl
test test_ssl failed -- Traceback (most recent call last):
  File "/home/vstinner/prog/python/3.6/Lib/test/test_ssl.py", line 1642, in test_connect_cadata
    s.connect(self.server_addr)
  File "/home/vstinner/prog/python/3.6/Lib/ssl.py", line 1109, in connect
    self._real_connect(addr, False)
  File "/home/vstinner/prog/python/3.6/Lib/ssl.py", line 1100, in _real_connect
    self.do_handshake()
  File "/home/vstinner/prog/python/3.6/Lib/ssl.py", line 1077, in do_handshake
    self._sslobj.do_handshake()
  File "/home/vstinner/prog/python/3.6/Lib/ssl.py", line 689, in do_handshake
    self._sslobj.do_handshake()
ConnectionResetError: [Errno 104] Connection reset by peer

test_ssl failed

== Tests result: FAILURE ==

1 test failed:
    test_ssl

Total duration: 131 ms
Tests result: FAILURE
---

This bug has been fixed in master by commit 529525fb5a8fd9b96ab4021311a598c77588b918. It was partially backported in 3.6 with commit 2a4ee8aa01d61b6a9c8e9c65c211e61bdb471826, but the backport is incomplete.

I wrote PR 11612 to backport remaining fixes.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32947>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:53:11 2019
From: report at bugs.python.org (David Heiberg)
Date: Fri, 18 Jan 2019 16:53:11 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547830391.58.0.550194720753.issue35701@roundup.psfhosted.org>


David Heiberg <dhdavvie at gmail.com> added the comment:

Agreed. I will fix the documentation and submit a PR this weekend hopefully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:55:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Jan 2019 16:55:55 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547830555.24.0.0246433507713.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum. Are you aware that PGO with GCC is broken on such old and unsupported Ubuntu version?

My old note about that:

"PGO is broken on Ubuntu 14.04 LTS with GCC 4.8.4-2ubuntu1~14.04: Modules/socketmodule.c:7743:1: internal compiler error: in edge_badness, at ipa-inline.c:895"

https://pyperformance.readthedocs.io/usage.html#compile

See also https://bugs.python.org/issue31963

I suggest you to not use PGO compilation on old Ubuntu. Maybe upgrade to latest Ubuntu LTS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:55:59 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 16:55:59 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547830559.34.0.565204453192.issue35770@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Terry,

I've started working on a PR to change menudefs to a dictionary.  Since dictionaries are in guaranteed order now, it would be easier to reference the menus by their name instead of an index number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 11:59:44 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 18 Jan 2019 16:59:44 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1547830784.72.0.162050736224.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

>> * pass_fds: there is not API to mark a fd as inheritable (clear O_CLOEXEC flag)

> POSIX has a bug for this [5]. It's marked fixed, but the current POSIX docs doesn't reflect the changes. The idea is to make posix_spawn_file_actions_adddup2() clear O_CLOEXEC if the source and the destination are the same (unlike dup2(), which would do nothing). musl has already implemented the new behavior [6], but glibc hasn't.

Update: glibc has implemented it for 2.29 (https://sourceware.org/bugzilla/show_bug.cgi?id=23640).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:13:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 17:13:40 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547831620.12.0.23890623653.issue35770@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> Since it is my fix, I will write the PR.  But first, please test part 2, changing '0' to '0:1', just to make sure it works.

Just tested it and it works fine with slice. Please find the respective diff and options menu displayed as below : 

git diff | cat
diff --git a/Lib/idlelib/macosx.py b/Lib/idlelib/macosx.py
index 9be4ed2ec4..16a13a0f2e 100644
--- a/Lib/idlelib/macosx.py
+++ b/Lib/idlelib/macosx.py
@@ -178,7 +178,7 @@ def overrideRootMenu(root, flist):
     del mainmenu.menudefs[-1][1][0:2]
     # Remove the 'Configure Idle' entry from the options menu, it is in the
     # application menu as 'Preferences'
-    del mainmenu.menudefs[-2][1][0]
+    del mainmenu.menudefs[-3][1][0]
     menubar = Menu(root)
     root.configure(menu=menubar)
     menudict = {}

Options menu
- Show code context (disabled)
- Zoom height

git diff | cat
diff --git a/Lib/idlelib/macosx.py b/Lib/idlelib/macosx.py
index 9be4ed2ec4..d6a1b376a1 100644
--- a/Lib/idlelib/macosx.py
+++ b/Lib/idlelib/macosx.py
@@ -178,7 +178,7 @@ def overrideRootMenu(root, flist):
     del mainmenu.menudefs[-1][1][0:2]
     # Remove the 'Configure Idle' entry from the options menu, it is in the
     # application menu as 'Preferences'
-    del mainmenu.menudefs[-2][1][0]
+    del mainmenu.menudefs[-3][1][0:1]
     menubar = Menu(root)
     root.configure(menu=menubar)
     menudict = {}

Options menu
- Show code context (disabled)
- Zoom height

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:28:26 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 18 Jan 2019 17:28:26 +0000
Subject: [issue35776] Virtualenv 16.2.0 Error Finding Pip
In-Reply-To: <1547828136.9.0.603302624111.issue35776@roundup.psfhosted.org>
Message-ID: <1547832506.1.0.890315067463.issue35776@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

virtualenv is not part of the Python standard library; please open an issue on the virtualenv bug tracker (https://github.com/pypa/virtualenv/issues).

----------
nosy: +zach.ware
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35776>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:40:00 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 18 Jan 2019 17:40:00 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1547833200.79.0.0541207635121.issue33944@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I have a directory inside my home directory, and inside it I have files with various utilities I have written over the years. So far, whenever I have installed a new version of Python, I have simply put a util.pth into site-packages. If you remove that possibility, what am I supposed to do? Every other solution is either much more complicated, or doesn't enable me to evolve my utilities inplace, or both. What am I missing? (My OS is Windows, and shortcuts don't work, I've tried.)

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:46:05 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 17:46:05 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547833565.2.0.344965831877.issue35770@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Cheryl, that sort of change needs an issue for discussion before going very far.  I am dubious that it will work (but you can try to show otherwise).

1. overrideRootMenu does an insertion that I don't think you can do with a dict.
  mainmenu.menudefs[0][1].insert(6, closeItem)

2. The structure of menudefs is part of the extension interface.  (The file should say so.)  The test extension zzdummy is incomplete.  test_zzdummy has not yet been written, and the definition of ZaDummy.menudefs, currently commented out, needs to me made conditional on whether tests are being run (__init__.testing)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:46:48 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 17:46:48 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1547833608.49.0.264194602763.issue23078@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11348

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:47:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 17:47:15 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1547833635.63.0.853466542858.issue23078@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11348, 11349

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:47:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 18 Jan 2019 17:47:41 +0000
Subject: [issue23078] unittest.mock patch autospec doesn't work on
 staticmethods
In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za>
Message-ID: <1547833661.6.0.493820864469.issue23078@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11348, 11349, 11350

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23078>
_______________________________________

From report at bugs.python.org  Fri Jan 18 12:52:46 2019
From: report at bugs.python.org (Tasy)
Date: Fri, 18 Jan 2019 17:52:46 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1547833966.96.0.626920438392.issue35713@roundup.psfhosted.org>


Tasy <obiwan408 at mail.com> added the comment:

compiling without optimizations worked.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:08:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 18:08:00 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547834880.9.0.213844128832.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +11351
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:08:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 18:08:10 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547834890.08.0.98892871826.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch
pull_requests: +11351, 11352
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:08:18 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 18:08:18 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547834898.2.0.78940231721.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch, patch, patch
pull_requests: +11351, 11352, 11353
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:19:15 2019
From: report at bugs.python.org (Gareth Rees)
Date: Fri, 18 Jan 2019 18:19:15 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547835555.25.0.0384839803538.issue17005@roundup.psfhosted.org>


Gareth Rees <gdr at garethrees.org> added the comment:

I approve in general with the principle of including a topological sort algorithm in the standard library. However, I have three problems with the approach in PR 11583:

1. The name "topsort" is most naturally parsed as "top sort" which could be misinterpreted (as a sort that puts items on top in some way). If the name must be abbreviated then "toposort" would be better.

2. "Topological sort" is a terrible name: the analogy with topological graph theory is (i) unlikely to be helpful to anyone; and (ii) not quite right. I know that the name is widely used in computing, but a name incorporating "linearize" or "linear order" or "total order" would be much clearer.

3. The proposed interface is not suitable for all cases! The function topsort takes a list of directed edges and returns a linear order on the vertices in those edges (if any linear order exists). But this means that if there are any isolated vertices (that is, vertices with no edges) in the dependency graph, then there is no way of passing those vertices to the function. This means that (i) it is inconvenient to use the proposed interface because you have to find the isolated vertices in your graph and add them to the linear order after calling the function; (ii) it is a bug magnet because many programmers will omit this step, meaning that their code will unexpectedly fail when their graph has an isolated vertex. The interface needs to be redesigned to take the graph in some other representation.

----------
nosy: +gdr at garethrees.org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:32:50 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 18:32:50 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547836370.41.0.161586984561.issue35770@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I'll submit a quick PR as a PoC.  Tal emailed with additional ideas about menudefs, so I agree that another issue would probably be suitable for more discussion.

I haven't looked at the extensions too closely yet, but the insert you're referring to is actually on the 'values' part, so it's not an issue.

mainmenu.menudefs[0][1] refers to menu item 0 (file menu) and the [1] means the nested list of tuples within menu 0.  I learned that while converting to a dict.

A trickier one is this because it changes the menus:
        mainmenu.menudefs.insert(0,
            ('application', [
                ('About IDLE', '<<about-idle>>'),
                    None,
                ]))

But I think this will work for that:
        appmenu = {'application': [
                        ('About IDLE', '<<about-idle>>'),
                         None,
                        ]}
        mainmenu.menudefs = {**appmenu, **mainmenu.menudefs}

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:35:20 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 18:35:20 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547836520.38.0.818595343045.issue35770@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +11354
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:35:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 18:35:28 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547836528.47.0.041397194151.issue35770@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +11354, 11355
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:35:35 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 18:35:35 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547836535.38.0.452592466901.issue35770@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +11354, 11355, 11356
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 13:36:12 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 18 Jan 2019 18:36:12 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547836572.31.0.973363123622.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> 1. The name "topsort" is most naturally parsed as "top sort" which could be misinterpreted (as a sort that puts items on top in some way). If the name must be abbreviated then "toposort" would be better.


I totally agree that `topsort` is a bad name, I used it more or less as a dummy for starting the discussion about the implementation.

> 2. "Topological sort" is a terrible name: the analogy with topological graph theory is (i) unlikely to be helpful to anyone; and (ii) not quite right. I know that the name is widely used in computing, but a name incorporating "linearize" or "linear order" or "total order" would be much clearer.


Topological sort (not as the function name) but as an operation is a very well known concept and is well defined. If you are referring to not use "Topological Sort" in the docstrings or the documentation, I strongly oppose.


Regarding the interface, I am more happy to change it once there is an agreement. I am still awaiting Raymond's comments regarding this so we can start discussing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:00:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 19:00:49 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547838049.0.0.224167637237.issue35770@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 39ed289a3511d2e9bf0950a9d5dc53c8194f61b9 by Terry Jan Reedy in branch 'master':
bpo-35770: IDLE macosx deletes Options => Configure IDLE. (GH-11614)
https://github.com/python/cpython/commit/39ed289a3511d2e9bf0950a9d5dc53c8194f61b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:01:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 19:01:13 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547838073.67.0.405429095487.issue35770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11357

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:01:19 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 19:01:19 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547838079.48.0.0253575753108.issue35770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11357, 11358

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:01:25 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 19:01:25 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547838085.54.0.654246786584.issue35770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11357, 11358, 11359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:16:04 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 19:16:04 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547838964.53.0.382424676544.issue35770@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a01e23559fd77083a2c6c59692b70d7896e5f59a by Miss Islington (bot) in branch '3.7':
bpo-35770: IDLE macosx deletes Options => Configure IDLE. (GH-11614)
https://github.com/python/cpython/commit/a01e23559fd77083a2c6c59692b70d7896e5f59a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:16:36 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jan 2019 19:16:36 +0000
Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute
In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za>
Message-ID: <1547838996.18.0.0959126702378.issue35321@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

Frozen module's origin isn't really documented AFAICT.  Here's the link to the library reference:

https://docs.python.org/3/library/importlib.html?highlight=origin#importlib.machinery.ModuleSpec.origin

The language reference doesn't really have anything to say here.  I think it wouldn't be difficult to add 'frozen' to the origin, but it should also be documented in the library reference (and of course, tested).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35321>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:16:50 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jan 2019 19:16:50 +0000
Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute
In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za>
Message-ID: <1547839010.1.0.283489695917.issue35321@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35321>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:21:48 2019
From: report at bugs.python.org (Nina Zakharenko)
Date: Fri, 18 Jan 2019 19:21:48 +0000
Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute
In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za>
Message-ID: <1547839308.42.0.381303656429.issue35321@roundup.psfhosted.org>


Change by Nina Zakharenko <nzakharenko at gmail.com>:


----------
assignee:  -> nnja
nosy: +nnja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35321>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:22:22 2019
From: report at bugs.python.org (Nina Zakharenko)
Date: Fri, 18 Jan 2019 19:22:22 +0000
Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute
In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za>
Message-ID: <1547839342.48.0.608644441516.issue35321@roundup.psfhosted.org>


Nina Zakharenko <nzakharenko at gmail.com> added the comment:

I'll be happy to take a look at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35321>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:22:38 2019
From: report at bugs.python.org (Nina Zakharenko)
Date: Fri, 18 Jan 2019 19:22:38 +0000
Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute
In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za>
Message-ID: <1547839342.48.0.608644441516.issue35321@roundup.psfhosted.org>


Nina Zakharenko <nzakharenko at gmail.com> added the comment:

I'll be happy to take a look at this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35321>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:22:40 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 18 Jan 2019 19:22:40 +0000
Subject: [issue35321] None _frozen_importlib.__spec__.origin attribute
In-Reply-To: <1543274371.24.0.788709270274.issue35321@psf.upfronthosting.co.za>
Message-ID: <1547839360.25.0.0923917127341.issue35321@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

I am mentoring Nina so I'll review this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35321>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:30:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2019 19:30:30 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547839830.57.0.83155477305.issue35733@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 74176226179ed56ad1c910bec5c4100e72ab4e84 by Serhiy Storchaka (Anthony Sottile) in branch 'master':
bpo-35733: Make isinstance(ast.Constant(boolean), ast.Num) be false. (GH-11547)
https://github.com/python/cpython/commit/74176226179ed56ad1c910bec5c4100e72ab4e84


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Fri Jan 18 14:30:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Jan 2019 19:30:53 +0000
Subject: [issue35733] isinstance(ast.Constant(value=True),
 ast.Num) should be False
In-Reply-To: <1547433079.8.0.602510928085.issue35733@roundup.psfhosted.org>
Message-ID: <1547839853.3.0.214206227955.issue35733@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35733>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:10:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:10:17 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842217.84.0.868835795159.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11352

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:10:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:10:35 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842235.39.0.382757937462.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11353

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:10:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:10:58 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842258.59.0.232643386677.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11355

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:11:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:11:26 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842286.67.0.278746593721.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11356

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:11:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:11:49 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842309.2.0.83957541256.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:12:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:12:10 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842330.12.0.587002547298.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11358

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:19:06 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 20:19:06 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547842746.12.0.828876390003.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:43:08 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 18 Jan 2019 20:43:08 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1547844188.8.0.912522012027.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +11360

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:43:26 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 18 Jan 2019 20:43:26 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1547844206.49.0.021338639822.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +11360, 11361

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:43:41 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 18 Jan 2019 20:43:41 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1547844221.99.0.340145834191.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +11360, 11361, 11362

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Jan 18 15:54:12 2019
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 18 Jan 2019 20:54:12 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1547844852.13.0.45983858382.issue35752@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:01:17 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 18 Jan 2019 21:01:17 +0000
Subject: [issue20399] Comparison of memoryview
In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za>
Message-ID: <1547845277.59.0.06844402795.issue20399@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Not my use case specifically, but my link in the last post (repeated below) was to a StackOverflow answer to a problem where using buffer was simple and fast, but memoryview required annoying workarounds. Admittedly, in most cases it's people wanting to do this with strings, so in Python 3 it only actually works if you convert to bytes first (possibly wrapped in a memoryview cast to a larger width if you need to support ordinals outside the latin-1 range). But it seems a valid use case.

Examples where rich comparisons were needed include:

Effcient way to find longest duplicate string for Python (From Programming Pearls) - https://stackoverflow.com/a/13574862/364696 (which provides a side-by-side comparison of code using buffer and memoryview, and memoryview lost, badly)

strcmp for python or how to sort substrings efficiently (without copy) when building a suffix array - https://stackoverflow.com/q/2282579/364696 (a case where they needed to sort based on potentially huge suffixes of huge strings, and didn't want to end up copying all of them)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20399>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:09:37 2019
From: report at bugs.python.org (Gareth Rees)
Date: Fri, 18 Jan 2019 21:09:37 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547845777.48.0.128474567438.issue17005@roundup.psfhosted.org>


Gareth Rees <gdr at garethrees.org> added the comment:

Just to elaborate on what I mean by "bug magnet". (I'm sure Pablo understands this, but there may be other readers who would like to see it spelled out.)

Suppose that you have a directed graph represented as a mapping from a vertex to an iterable of its out-neighbours. Then the "obvious" way to get a total order on the vertices in the graph would be to generate the edges and pass them to topsort:

    def edges(graph):
        return ((v, w) for v, ww in graph.items() for w in ww)
    order = topsort(edges(graph))

This will appear to work fine if it is never tested with a graph that has isolated vertices (which would be an all too easy omission).

To handle isolated vertices you have to remember to write something like this:

    reversed_graph = {v: [] for v in graph}
    for v, ww in graph.items():
        for w in ww:
            reversed_graph[w].append(v)
    order = topsort(edges(graph)) + [
          v for v, ww in graph.items() if not ww and not reversed_graph[v]]

I think it likely that beginner programmers will forget to do this and be surprised later on when their total order is missing some of the vertices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:26:41 2019
From: report at bugs.python.org (Jez Hill)
Date: Fri, 18 Jan 2019 21:26:41 +0000
Subject: [issue35777] mismatched eval() and ast.literal_eval() behavior with
 unicode_literals
Message-ID: <1547846800.05.0.589923940496.issue35777@roundup.psfhosted.org>


New submission from Jez Hill <jezhill at gmail.com>:

Following  `from __future__ import unicode_literals`   the expression `eval(" 'foo' ")` will return a `unicode` instance.  However, using the same input, `ast.literal_eval(" 'foo' ")` will return a `str` instance. The caller's preference, that those plain single-quotes should a denote unicode literal, is respected by `eval()` but not by `ast.literal_eval()`.   I propose that `ast.literal_eval()` be made sensitive to this preference, to bring it in line with `eval()`.

----------
messages: 334011
nosy: jez
priority: normal
severity: normal
status: open
title: mismatched eval() and ast.literal_eval() behavior with unicode_literals
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35777>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:27:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 21:27:32 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547846852.67.0.653585648459.issue17005@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think 'toposort' is a good name for a function that implements 'topological sorting'.
https://en.wikipedia.org/wiki/Topological_sorting

----------
versions: +Python 3.8 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:29:45 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 18 Jan 2019 21:29:45 +0000
Subject: [issue20399] Comparison of memoryview
In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za>
Message-ID: <1547846985.21.0.977468752259.issue20399@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

If not wanting to support the whole gamut of PEP 3118 types, one could start by only providing ordered comparisons when format == 'B'.

----------
stage:  -> needs patch
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20399>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:34:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 21:34:08 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547847248.76.0.641163467037.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11363

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:34:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 21:34:17 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547847257.19.0.240246214182.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11363, 11364

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:34:24 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 21:34:24 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547847264.62.0.424652812085.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +11363, 11364, 11365

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:35:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 21:35:43 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547847343.53.0.830961121872.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11365

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:35:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 21:35:59 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547847359.89.0.719789169373.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11364

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 16:39:45 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 18 Jan 2019 21:39:45 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1547847585.16.0.0232246263653.issue17005@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This is why I prefer the API exposed by https://pypi.org/project/toposort/

list(toposort({2: {11},
               9: {11, 8, 10},
               10: {11, 3},
               11: {7, 5},
               8: {7, 3},
              }))

returns [{3, 5, 7}, {8, 11}, {2, 10}, {9}]

For an node with no edges, use an empty set:

list(toposort({100: set(),
               2: {11},
               9: {11, 8, 10},
               10: {11, 3},
               11: {7, 5},
               8: {7, 3},
              }))
[{3, 100, 5, 7}, {8, 11}, {2, 10}, {9}]

I also don't think we should provide multiple APIs. Let's just provide one, and recipes for any helpers, if needed. For example, to flatten the result into a list. Or to take a list of edges as the input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:03:26 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 18 Jan 2019 22:03:26 +0000
Subject: [issue35777] mismatched eval() and ast.literal_eval() behavior with
 unicode_literals
In-Reply-To: <1547846800.05.0.589923940496.issue35777@roundup.psfhosted.org>
Message-ID: <1547849006.28.0.76501724835.issue35777@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Python 2.7 has long passed feature freeze, and this would be new behaviour appearing in a bug-fix release, which we don't normally do.

I'm going to close this as Rejected, but if you think you can make a good case for why this enhancement is sufficiently important to break backwards-compatibility in a bug-fix release, or alternatively that the current behaviour is a bug (e.g. that it goes against the documentation) then we can re-open it.

(Merely "doesn't do what I think the user expects" is not a bug.)

----------
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35777>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:05:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 22:05:43 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547849143.01.0.751454997065.issue35770@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 2cf1ddaff4c869780d9e796b21ef3e506f8ad321 by Terry Jan Reedy in branch 'master':
bpo-35770: Fix off-by-1 error. (#11618)
https://github.com/python/cpython/commit/2cf1ddaff4c869780d9e796b21ef3e506f8ad321


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:05:56 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 22:05:56 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547849156.46.0.907876748324.issue35770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11366

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:06:07 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 22:06:07 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547849167.97.0.654680669653.issue35770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11366, 11367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:06:19 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 22:06:19 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547849179.4.0.938605580745.issue35770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11366, 11367, 11368

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:15:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 22:15:34 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1547849734.58.0.990517578216.issue35756@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

No bug here.  You can discuss possible change on python-ideas, but I strongly suggest that you write your next wrapper and move on.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.7 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:23:55 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Jan 2019 22:23:55 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547850235.6.0.734343779117.issue35770@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 47290e7642dd41d94437dd0e2c0f6bfceb0281b5 by Miss Islington (bot) in branch '3.7':
bpo-35770: Fix off-by-1 error. (GH-11618)
https://github.com/python/cpython/commit/47290e7642dd41d94437dd0e2c0f6bfceb0281b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:29:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 22:29:17 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547850557.63.0.688939781122.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11368

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:29:33 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Jan 2019 22:29:33 +0000
Subject: [issue35770] IDLE: python -m idlelib fails on master on Mac OS 10.10.4
In-Reply-To: <1547793727.58.0.008691556265.issue35770@roundup.psfhosted.org>
Message-ID: <1547850573.73.0.738804016694.issue35770@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -11367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35770>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:34:06 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 18 Jan 2019 22:34:06 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547850846.76.0.978456211891.issue35775@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm very interested in adding quartiles and general quantiles/fractiles, but I'm not so sure that this select(data, index) function would be useful. Can you explain how you would use this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:38:27 2019
From: report at bugs.python.org (Greg Ewing)
Date: Fri, 18 Jan 2019 22:38:27 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547771505.97.0.32419395184.issue35756@roundup.psfhosted.org>
Message-ID: <5C42555C.6060803@canterbury.ac.nz>


Greg Ewing <greg.ewing at canterbury.ac.nz> added the comment:

bryan.koch wrote:
> It would be awesome if invoking a generator above would throw a
> SyntaxError iff it contained a return and it wasn't invoked through `yield
> from`.

Why do you care about that so much? There's nothing to stop you
from ignoring the return value of an ordinary function. Why should
generator functions be different?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Fri Jan 18 17:54:54 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 18 Jan 2019 22:54:54 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1547547794.3.0.264188583687.issue35633@roundup.psfhosted.org>
Message-ID: <C533F5B5-1350-4705-B264-3EC02C83E57D@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I?ll make a new PR and delete the news entry. 

Sent from my iPhone

> On 15 Jan 2019, at 11:23, STINNER Victor <report at bugs.python.org> wrote:
> 
> 
> STINNER Victor <vstinner at redhat.com> added the comment:
> 
>> On AIX the test for flock() passes, but the test for lockf() fails: (...)
> 
> I would prefer to simply skip the lockf() test rather than ignoring PermissionError for flock() and lockf() on all platforms. Can you please write a PR for that?
> 
> There is no need to add a NEWS entry, I will add "skip news". If you want to add a NEWS entry, mention at least the fixed test and AIX.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35633>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35633>
_______________________________________

From report at bugs.python.org  Fri Jan 18 18:13:35 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 18 Jan 2019 23:13:35 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547853215.98.0.762265375266.issue35775@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Wouldn't be the 5-th percentile be select(data, round(len(data)/20)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 18:29:16 2019
From: report at bugs.python.org (Oscar Esteban)
Date: Fri, 18 Jan 2019 23:29:16 +0000
Subject: [issue35778] RF: ``pathlib.Path.checksum()`` member
Message-ID: <1547854155.56.0.887499494247.issue35778@roundup.psfhosted.org>


New submission from Oscar Esteban <oesteban at stanford.edu>:

Gauging the interest in a checksum calculation function built-in Path objects:

```
>>> Path('somefile.img').checksum()
'4976c36bacf922cbc5c811c9c288e61d'

>>> Path('somefile.img').checksum(hash='md5')
'4976c36bacf922cbc5c811c9c288e61d'

>>> Path('somefile.img').checksum(hash='sha256')
'12917abe21e1eb4ba3c704600db53a1ff1434b3259422b86bfd08afa8216e4aa'

>>> Path.home().checksum()
'798d3a5c2b679750a90e91b09cf93129'

>>> Path.home().checksum(hash='sha256')
'b3e04961fd54818d93aac305db4a3dec51b9731808c19ea9c59460c841e2d145'

# Do not checksum content, just the file's path, as for directories
>>> Path('somefile.img').checksum(content=False)
'3fb531e352cbc2e2103ab73ede40f2d6'
```

----------
components: Library (Lib)
messages: 334023
nosy: oesteban
priority: normal
severity: normal
status: open
title: RF: ``pathlib.Path.checksum()`` member
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35778>
_______________________________________

From report at bugs.python.org  Fri Jan 18 18:32:47 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 23:32:47 +0000
Subject: [issue15613] argparse ArgumentDefaultsHelpFormatter interacts badly
 with --arg and nargs=+
In-Reply-To: <1344578813.57.0.70269968542.issue15613@psf.upfronthosting.co.za>
Message-ID: <1547854367.06.0.506535236912.issue15613@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15613>
_______________________________________

From report at bugs.python.org  Fri Jan 18 18:43:59 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 18 Jan 2019 23:43:59 +0000
Subject: [issue15613] argparse ArgumentDefaultsHelpFormatter interacts badly
 with --arg and nargs=+
In-Reply-To: <1344578813.57.0.70269968542.issue15613@psf.upfronthosting.co.za>
Message-ID: <1547855039.92.0.492794075275.issue15613@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Closing per paul.j3's last comment which also is mentioned in the documentation (https://docs.python.org/3.8/library/argparse.html#default
):

> For positional arguments with nargs equal to ? or *, the default value is used when no command-line argument was present

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15613>
_______________________________________

From report at bugs.python.org  Fri Jan 18 19:25:39 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 19 Jan 2019 00:25:39 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547857539.11.0.0878038947953.issue35711@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I'm re-opening this.  The original intent of the PR was missed even though the change in the PR as is was not how we want to do this in the CPython VM.

Background: We build our default non-production test interpreter in `#undef NDEBUG` mode at Google which is why sfreilich@ ran into this while working on some code.

What we have today are a bunch of assert(!PyErr_Occurred()); statements around the CPython internals.

A failure (crash) from such asserts provides no information on its own about the unhandled exception itself to help the developer track down the C API use error that led to this state.

It'd be useful if all of these provided more information about the untracked/unhandled exception before crashing.

So instead of

```c
  assert(!PyErr_Occurred());
```

Something equivalent to:

```c
#ifndef NDEBUG
  if (PyErr_Occurred()) {
    PyErr_Print();
    assert(!PyErr_Occurred());  // crash
  }
#endif
```

were used.  But that is extremely verbose, so we wouldn't want to update all of the existing asserts into that.  Instead that should be encapsulated within something that, as with assert, compiles as a non-existant no-op in the NDEBUG (release) build state.  But otherwise does that.

Given this is C, a conditional macro is reasonable.  (i'd suggest a void function who's body is empty... but that still has consequences and would not be removed in all compilation and linking situations) potentially impacting performance.  A conditional macro similar to this would not:

```c
#ifdef NDEBUG
# define _Assert_No_PyErr_Occurred() ((void)0)
#else  /* Not NDEBUG (assertions enabled). */
# define _Assert_No_PyErr_Occurred()  do { \
        int _unhandled_error = PyErr_Occurred();
        if (_unhandled_error) {
            PyErr_Print();
            assert(!_unhandled_error);  // crash.
        }
    } while(0)
#endif
```

along with replacing all ~38 of our current `assert(!PyErr_Occurred());` statements with a call to that macro.

If, as vstinner noted in the PR comments, rather than just PyErr_Print() for this... using the new `_PyObject_ASSERT()` from Include/cpython/object.h macro giving it the unhandled exception object itself as obj would be good as it would produce even more useful debugging information.

Code doing that gets complicated but probably looks something like (untested):

```c
#ifdef NDEBUG
# define _Assert_No_PyErr_Occurred() ((void)0)
#else  /* Not NDEBUG (assertions enabled). */
# define _Assert_No_PyErr_Occurred()  do {  \
        int _unhandled_exception = PyErr_Occurred();  \
        if (_unhandled_exception) {  ]
            PyObject *sys_module, *exception_object;  \
            PyErr_Print();  /* Clears PyErr_Occurred() and sets sys.last_value. */  \
            sys_module = PyImport_ImportModule("sys");  \
            assert(sys_module /* within _Assert_No_PyErr_Occurred() */);  \
            exception_object = PyObject_GetAttrString(sys_module, "last_value");  \
            if (exception_object == NULL) {  \
                PyErr_Clear();  /* AttributeError */  \
                /* Given PyErr_Print probably instantiated a value of there was  */  \
                /* only a type, I don't even know if this code path is possible. */  \
                /* Playing it safe and useful in debugging code. */  \
                exception_object = PyObject_GetAttrString(sys_module, "last_type");  \
            }  \
            Py_DECREF(sys_module);  \
            _PyObject_ASSERT(exception_object, _unhandled_exception);  \
            /* Unreachable code, _PyObject_ASSERT should have aborted. */  \
            Py_XDECREF(exception_object);  \
            abort();  \
        }  \
    } while(0)
#endif
```

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Fri Jan 18 21:32:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 02:32:25 +0000
Subject: [issue35778] RF: ``pathlib.Path.checksum()`` member
In-Reply-To: <1547854155.56.0.887499494247.issue35778@roundup.psfhosted.org>
Message-ID: <1547865145.01.0.226516237278.issue35778@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35778>
_______________________________________

From report at bugs.python.org  Fri Jan 18 21:43:37 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 19 Jan 2019 02:43:37 +0000
Subject: [issue35779] Print friendly version message in REPL
Message-ID: <1547865815.91.0.564607608514.issue35779@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

The current version message in REPL is too complicate for official release.

Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 

tags/v3.7.2   git tag is superfluous.
9a3ffc0492    git commit id may scare junior users.
23:09:28      quite meaningless.
win32         "I'm using a 64 bit Windows, why call it win32?"

IMO, we can simply print this message for official release:
Python 3.7.2 (64 bit, Dec 23 2018) on Windows

How about this logic?

if version in git_tag and "dirty" not in commit_id:
    print_simplified_message()
else:
    print_current_message()

----------
messages: 334026
nosy: Ma Lin
priority: normal
severity: normal
status: open
title: Print friendly version message in REPL
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Fri Jan 18 22:22:05 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 03:22:05 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547853215.98.0.762265375266.issue35775@roundup.psfhosted.org>
Message-ID: <20190119032157.GP13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Jan 18, 2019 at 11:13:41PM +0000, R?mi Lapeyre wrote:

> Wouldn't be the 5-th percentile be select(data, round(len(data)/20)?

Oh if only it were that simple!

Using the method you suggest, the 50th percentile is not the same as the 
median unless the length of the list is three more than a multiple of 
four. It also runs into problems for small lists where the index rounds 
down to zero.

Langford (2006) does a literature review and finds fifteen methods for 
calculating the quartiles (Q1, Q2, Q3), of which twelve are distinct and 
incompatible; Hyndman & Fan (1996) did similar for general quantiles and 
came up with nine, of which seven match Langford's.

I know of at least six other methods, which gives a total of 20 distinct 
ways of calculating quartiles or quantiles.

http://jse.amstat.org/v14n3/langford.html

https://robjhyndman.com/publications/quantiles/

I stress that these are not merely different algorithms which give the 
same answer, but different methods which sometimes disagree on their 
answers. So whichever method you use, some people are going to be 
annoyed or confused or both.

http://mathforum.org/library/drmath/view/60969.html

Other statistics libraries provide a choice, e.g.:

- R and Octave provide the same 9 as H&F.
- Maple provides 6 of those, plus 2 others.
- Wessa provides 5 that match H&F, plus another 3.
- SAS provides 5.
- even Excel provides 2 different ways.

Statisticians don't even agree on which is the "best" method. H&F 
recommend their method number 8. Langford recommends his method 4. I 
think that your suggestion matches Langford's method 14, which is H&F's 
method 3.

Selecting the i-th item from a list is the easy part. Turning that into 
meaningful quantiles, percentiles etc is where it gets really hairy. My 
favourite quote on this comes from J Nash on the Gnumeric mailing list:

    Ultimately, this question boils down to where to cut to
    divide 4 candies among 5 children. No matter what you do,
    things get ugly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Fri Jan 18 22:45:26 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 03:45:26 +0000
Subject: [issue35779] Print friendly version message in REPL
In-Reply-To: <1547865815.91.0.564607608514.issue35779@roundup.psfhosted.org>
Message-ID: <1547869526.13.0.476707938242.issue35779@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The version message doesn't look "too complicated" to me. It looks no more complicated as that which Python has always displayed, going back to Python 1.5 (the oldest version I still have access to).

Python 1.5.2 (#1, Aug 27 2012, 09:09:18)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2

Python 2.7.2 (default, May 18 2012, 18:25:10)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2


You say:

> 9a3ffc0492    git commit id may scare junior users.

I think that's quite patronising towards juniors. Any junior who doesn't know what that means will likely just ignore it. Besides, Python isn't designed solely for junior users, and they will never cease to be junior users if we dumb everything down least it "scare" them.

> 23:09:28      quite meaningless.

Its a time stamp, and it goes with the date. There can easily be two or more commits on a single day, having the time visible is useful.


> win32         "I'm using a 64 bit Windows, why call it win32?"

*shrug* Ask Microsoft.

https://duckduckgo.com/?q=I%27m+using+a+64+bit+Windows%2C+why+call+it+win32



I don't think anything here needs to change. We've been printing the same information going back to 1.5. Giving too much information hasn't been a problem, the usual problem is trying to get beginners to supply *sufficient* information. Having them copy and paste the startup message is useful for diagnosing problems. Don't dumb it down.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Fri Jan 18 23:19:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 04:19:40 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
Message-ID: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

After the check for popresult==Py_None, there is the comment that was mostly copied from the Python version but doesn't match the actual code:

 /* Getting here means that this same key was added to the
    cache while the lock was released.  Since the link
    update is already done, we need only return the
    computed result and update the count of misses. */

The cache.pop uses the old key (the one being evicted), so at this point in the code we have an extracted link containing the old key but the pop failed to find the dictionary reference to that link.  It tells us nothing about whether the current new key has already been added to the cache or whether another thread added a different key. This code path doesn't add the new key.  Also, it leaves the self->full variable set to True even though we're now at least one link short of maxsize.

The next test is for popresult == NULL. If I'm understanding it correctly, it means that an error occurred during lookup (possible during the equality check).  If so, then why is the link being moved to the front of the lru_cache -- it should have remained at the oldest position.  The solution to this is only extract the link after a successful pop rather than before.

The final case runs code when the pop succeeded in finding the oldest link.  The popresult is decreffed but not checked to make sure that it actually is the oldest link.  Afterwards, _PyDict_SetItem_KnownHash() is called with the new key.  Unlike the pure python code, it does not check to see if the new key has already been added by another thread.  This can result in an orphaned link (a link not referred to by the cache dict).  I think that is why popresult code can ever get to a state where it can return Py_None (it means that the cache structure is in an inconsistent state).

I think the fix is to make the code more closely follow the pure python code.  Verify that the new key hasn't been added by another thread during the user function call.  Don't delete the old link until it has been successfully popped.  A Py_None return from the pop should be regarded as sign the structure is in an inconsistent state.  The self->full variable needed to be reset if there are any code paths that deletes links but don't add them back.  Better yet, the extraction of a link should be immediately followed by repopulating it will new values and moving it to the front of the cache.  That way, the cache structure will always remain in a consistent state and the number of links will be constant from start to finish.

The current code likely doesn't fail in any spectacular way.  Instead, it will occasionally have unreferenced orphan links, will occasionally be marked as full when it is short one or more links (and never regaining the lost links), will occasionally not put the result of the newest function call into the cache, and will occasionally mark the oldest link as being the newest even though there wasn't a user function call to the corresponding old key.

Minor nit:  The decrefs should be done at the bottom of each code path instead of the top.  This makes it a lot easier to verify that we aren't making arbitrary reentrant callbacks until the cache data structures have been put into a consistent state.

Minor nit: The test "self->root.next != &self->root" may no longer be necessary if the above issues are fixed.  We can only get to this wrapper when maxsize > 0, so self->full being true implies that there is at least one link in the chain, so self->root.next cannot point back to itself.  Possibly the need for this test exists only because the cache is getting into an inconsistent state where it is marked as full but there aren't any extant links.

Minor nit:  "lru_cache_extricate_link" should be named "lru_cache_extract_link".  The word "extricate" applies only when solving an error case; whereas, "extract" applies equally well to normal cases and cases.  The latter word more closely means "remove an object from a data structure" which is what was likely intended.

Another minor nit:  The code in lru_cache_append_link() is written in way where the compiler has to handle an impossible case where "link->prev->next = link->next" changes the value of "link->next".  The suspicion of aliased pointers causes the compiler to generate an unnecessary and redundant memory fetch.   The solution again is to more closely follow the pure python code:

diff --git a/Modules/_functoolsmodule.c b/Modules/_functoolsmodule.c
index 0fb4847af9..8cbd79ceaf 100644
--- a/Modules/_functoolsmodule.c
+++ b/Modules/_functoolsmodule.c
@@ -837,8 +837,10 @@ infinite_lru_cache_wrapper(lru_cache_object *self, PyObject *args, PyObject *kwd
 static void
 lru_cache_extricate_link(lru_list_elem *link)
 {
-    link->prev->next = link->next;
-    link->next->prev = link->prev;
+    lru_list_elem *link_prev = link->prev;
+    lru_list_elem *link_next = link->next;
+    link_prev->next = link->next;
+    link_next->prev = link->prev;
 }

    Clang assembly before:

        movq    16(%rax), %rcx      # link->prev
        movq    24(%rax), %rdx      # link->next
        movq    %rdx, 24(%rcx)      # link->prev->next = link->next;
        movq    24(%rax), %rdx      # duplicate fetch of link->next
        movq    %rcx, 16(%rdx)      # link->next->prev = link->prev;

    Clang assembly after:

        movq    16(%rax), %rcx
        movq    24(%rax), %rdx
        movq    %rdx, 24(%rcx)
        movq    %rcx, 16(%rdx)

Open question:  Is the any part of the code that relies on the cache key being a tuple?  If not, would it be reasonable to emulate the pure python code and return a scalar instead of a tuple when the tuple length is one and there are no keyword arguments or typing requirements?  In other words, does f(1) need to have a key of (1,) instead of just 1?  It would be nice to save a little space (for the enclosing tuple) and get a little speed (hash the object directly instead of hashing a tuple with just one object).

----------
assignee: serhiy.storchaka
components: Extension Modules
messages: 334029
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Recheck logic in the C version of the lru_cache()
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/issue35780>
_______________________________________

From report at bugs.python.org  Fri Jan 18 23:50:54 2019
From: report at bugs.python.org (yuji38kwmt)
Date: Sat, 19 Jan 2019 04:50:54 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
Message-ID: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>


New submission from yuji38kwmt <yuji38kwmt at gmail.com>:

### Target Documentation

https://docs.python.org/3/howto/logging.html#configuring-logging


### Actual Sample Code

```
# 'application' code
logger.debug('debug message')
logger.info('info message')
logger.warn('warn message')
logger.error('error message')
logger.critical('critical message')
```

### Expected Sample Code

```
# 'application' code
logger.debug('debug message')
logger.info('info message')
logger.warning('warn message')
logger.error('error message')
logger.critical('critical message')
```

### Reference

> There is an obsolete method warn which is functionally identical to warning. As warn is deprecated, please do not use it - use warning instead.

https://docs.python.org/3.7/library/logging.html#logging.Logger.warning

----------
assignee: docs at python
components: Documentation
messages: 334030
nosy: docs at python, yuji38kwmt
priority: normal
severity: normal
status: open
title: `logger.warn` method is used in "Logging HOWTO" documentation though `logger.warn` method is deprecated in Python 3.7
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Sat Jan 19 00:05:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 05:05:04 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1547874304.69.0.129631257161.issue35781@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Would you like to propose a PR for this? 

Cases of using warn method in documentation examples : 

* https://github.com/python/cpython/blob/master/Doc/howto/logging.rst
* https://github.com/python/cpython/blob/master/Doc/howto/logging-cookbook.rst

Doc/howto/logging.rst
613:    logger.warn('warn message')
643:    logger.warn('warn message')

Doc/howto/logging-cookbook.rst
189:    logger.warn('warn message')
298:            logger.warn('warn message')

----------
nosy: +vinay.sajip, xtreak
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Sat Jan 19 00:34:41 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 05:34:41 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547876081.88.0.0454573033876.issue35748@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I believe that Python's behaviour here is correct. You are supplying a netloc which includes a username "www.google.com\" with no password. That might be what you intend to do, or it might be malicious data. That depends on context, and the urlparse module can't tell what the context is and has no reason to assume malice.

If I am reading this correctly:

https://tools.ietf.org/html/rfc1738#section-3.1

the colon after the username can be omitted, so the URL is legal and Python has returned the correct value for the netloc.

As Christian says, Python is not an end-user application like a browser. It is right and proper for a browser to expect that the user is non-technical and may not have noticed the @ sign, and to expect malicious behaviour, or to assume that backslash \ is a typo for forward slash / but Python programmers by definition are technical users and it is their responsibility to validate their data.

There are legitimate uses for the userinfo component (user:password at hostname) and it is not the library's responsibility to assume that backslashes are typos for forward slashes.

So I think that the behaviour here is correct, and this should be closed. But if you disagree, please explain what you think the library should do, and why. WHen you do, remember that:

* there are legitimate users for user:password at hostname;
* either the user name or the password can contain backslashes.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Sat Jan 19 00:53:33 2019
From: report at bugs.python.org (Louie Lu)
Date: Sat, 19 Jan 2019 05:53:33 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
Message-ID: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>


New submission from Louie Lu <me at louie.lu>:

In random.py:randrange

  File "/usr/lib/python3.7/random.py", line 200, in randrange
    raise ValueError("empty range for randrange() (%d,%d, %d)" % (istart, istop, width))
ValueError: empty range for randrange() (3,3, 0)


should be "empty range for randrange() (3, 3, 0)"

----------
components: Library (Lib)
messages: 334033
nosy: louielu
priority: normal
severity: normal
status: open
title: Missing whitespace after comma in randrange raise error
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 00:55:38 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 05:55:38 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547771505.97.0.32419395184.issue35756@roundup.psfhosted.org>
Message-ID: <20190119055531.GQ13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Jan 18, 2019 at 12:31:51AM +0000, bryan.koch wrote:

> Thank you both for the clarifications.  I agree these's no bug in 
> `yield from` however is there a way to reference the return value when 
> a generator with a return is invoked using `for val in gen` i.e. when 
> the generator is invoked without delegation?

I don't believe so, because the for loop machinery catches and consumes 
the StopIteration.

Any change to that behaviour would be new functionality that would 
probably need to go through Python-Ideas first.

[...]
> Essentially I have code that looks like
> `
> for value in generator:
>   do thing with value 
>   yield value 
> ` 
> where I need to do something before yielding the value.
> It would be awesome if invoking a generator above would throw a 
> SyntaxError iff it contained a return and it wasn't invoked through 
> `yield from`.

How is the interpreter supposed to know? (I assume you mean for the 
SytnaxError to be generated at compile-time.) Without doing a 
whole-program analysis, there is no way for the interpreter to compile a 
generator:

    def gen():
        yield 1
        return 1

and know that no other piece of code in some other module will never 
call it via a for loop.

> The below isn't valid Python and I'm not sure that it should be but 
> it's what I need to do.
> 
> `
> return_value = for value in generator:
>   do thing with value
>   yield value
> 
> if return_value:
>   do something with return_value
> `

Let me be concrete here. You have a generator which produces a sequence 
of values [spam, eggs, cheese, aardvark] and you need to treat the 
final value, aardvark, differently from the rest:

    do thing with spam, eggs, cheese
    do a different thing with aardvark (if aardvark is a True value)

Am I correct so far?

Consequently you writing this as:

def gen():
    yield spam
    yield eggs
    yield cheese
    return aardvark

Correct?

That's an interesting use-case, but I don't think there is any obvious 
way to solve that right now. Starting in Python 3.8, I think you should 
be able to write:

for x in (final := (yield from gen())):
    do something with x  # spam, eggs, cheese
if final:
    do something different with final  # aardvark

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Sat Jan 19 00:56:54 2019
From: report at bugs.python.org (Louie Lu)
Date: Sat, 19 Jan 2019 05:56:54 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547877414.2.0.204514444363.issue35782@roundup.psfhosted.org>


Change by Louie Lu <me at louie.lu>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 00:59:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 05:59:53 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547877593.34.0.289176458296.issue35782@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Cheryl, do you want to neaten-up this error message?  

It is triggered by randrange(3, 3).

----------
assignee:  -> cheryl.sabella
nosy: +cheryl.sabella, rhettinger
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:01:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 06:01:30 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547877690.93.0.186741253345.issue35775@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I'm very interested in adding quartiles and 
> general quantiles/fractiles, but I'm not 
> so sure that this select(data, index) function would be useful. 

I concur with Steven.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:04:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 06:04:40 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1391304071.38.0.177384686096.issue20479@psf.upfronthosting.co.za>
Message-ID: <1547877880.84.0.559129787945.issue20479@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Is this proposal still relevant? If so, I would 
> like to work on its implementation.

The first question is the important one.  Writing implementations is usually the easy part.  Deciding on whether there is a real need and creating a usable, extendable, and clean API is often the hard part.  So please don't run to a PR, that just complicates the important part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:07:31 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 06:07:31 +0000
Subject: [issue35737] crypt AuthenticationError introduced with new Linux
 kernel
In-Reply-To: <1547481144.26.0.447593759473.issue35737@roundup.psfhosted.org>
Message-ID: <1547878051.03.0.341020799976.issue35737@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. I couldn't find any CPython related stack trace in the traceback and this looks like a custom validation error raised by salt. Can you please add a simple reproducer without any external dependencies to reproduce this without which I propose to close this as third-party.

The Python version in GitHub issue report is Python 2.7.5 which is very old so can you please test this on Python 2.7.15 under different kernels as in the GitHub issue and perhaps add the traceback here for the same with a pure python reproducer without dependencies.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35737>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:08:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 06:08:57 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547878137.08.0.784933070499.issue35782@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
stage: resolved -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:30:43 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 06:30:43 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <1547825225.26.0.147780198807.issue20479@roundup.psfhosted.org>
Message-ID: <20190119063036.GR13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Is this proposal still relevant?

Yes.

As Raymond says, deciding on a good API is the hard part. Its relatively 
simple to change a poor implementation for a better one, but backwards 
compatibility means that changing the API is very difficult.

I would find it very helpful if somebody has time to do a survey of 
other statistics libraries or languages (e.g. numpy, R, Octave, Matlab, 
SAS etc) and see how they handle data with weights.

- what APIs do they provide?
- do they require weights to be positive integers, or do they 
  support arbitrary float weights?
- including negative weights? 
  (what physical meaning does a negative weight have?)

At the moment, a simple helper function seems to do the trick for 
non-negative integer weights:

def flatten(items):
    for item in items:
        yield from item

py> data = [1, 2, 3, 4]
py> weights = [1, 4, 1, 2]
py> statistics.mean(flatten([x]*w for x, w in zip(data, weights)))
2.5

In principle, the implementation could be as simple as a single 
recursive call:

def mean(data, weights=None):
    if weights is not None:
        return mean(flatten([x]*w for x, w in zip(data, weights)))
    # base case without weights is unchanged

or perhaps it could be just a recipe in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:34:11 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Sat, 19 Jan 2019 06:34:11 +0000
Subject: [issue35299] LGHT0091: Duplicate symbol 'File:include_pyconfig.h'
 found
In-Reply-To: <1542954685.4.0.788709270274.issue35299@psf.upfronthosting.co.za>
Message-ID: <1547879651.07.0.627500353758.issue35299@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

I want to document a workaround if anyone benefits from it, this would be step 7:

7) This error goes away if you remove the pyconfig.h from the include directory before the tests end (and of course, after the test distutils).

This is only a workaround and requires the user placing attention to the build process (maybe for the first 5-10 minutes). Having the option "-q" removed from the buildrelease.bat file (as discussed in issue https://bugs.python.org/issue35739 ) helps with determining when to safely remove the file so that the distutils test pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35299>
_______________________________________

From report at bugs.python.org  Sat Jan 19 01:52:28 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 19 Jan 2019 06:52:28 +0000
Subject: [issue18140] urlparse,
 urlsplit confused when password includes fragment (#), query (?)
In-Reply-To: <1370425503.35.0.436511643169.issue18140@psf.upfronthosting.co.za>
Message-ID: <1547880748.02.0.318455624207.issue18140@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Today I read RFC 3986, and I think the URLs in the bug reports are valid, and are already parsed correctly. The path is allowed to have a literal ?at? symbol:

path-abempty = *( "/" segment )
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

The query and fragment are allowed to have ?at? and question marks:

query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )

So I think this could be closed because the parsing is working correctly.

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18140>
_______________________________________

From report at bugs.python.org  Sat Jan 19 02:03:19 2019
From: report at bugs.python.org (Jorge Ramos)
Date: Sat, 19 Jan 2019 07:03:19 +0000
Subject: [issue35739] Enable verbose of tests during PGO build on amd64
 platforms
In-Reply-To: <1547530007.74.0.355457877892.issue35739@roundup.psfhosted.org>
Message-ID: <1547881399.16.0.101464286772.issue35739@roundup.psfhosted.org>


Jorge Ramos <neyuru at gmail.com> added the comment:

Mmm, I don't find that option documented in the readme of the MSI folder nor in the help for buildrelease.bat (and also is not intuitive, what does IIRC stand for?), nevertheless:

It should be no problem if this PR doesn't pass but it should help newcomers like me to debug builds (the option -q is also not documented in the buildrelease but I found that option tracking the build calls all the way to regrtest.py) I leave this info here if anyone benefits from it.

In fact I edited the PGO option in the buildrelease file to:

PGO= -m test --pgo -uall -j8 -M 27Gb -x test_bigmem test_bz2 test_codecs test_httpservers test_nntplib test_platform test_regrtest test_sysconfig test_zlib

The test suite now reads: PASS (I know, it is not necessary for all the tests to pass, but it is a nice view IMO). The benefit of the -j option is  that it permits some tests to pass when they where failing before this option. The option -uall opens resources to the tests, so that some of them will no longer be denied to tests (and therefore leaving no tests run -or skipped- by lack of resources). The 27Gb memory "allocated" to the tests is overkill, but my system could handle it (it may be that some tests need more than that but I have no further memory). 

Sure, it takes a long time to build (close to 1 hr) but it is the best way I have found so far to minimize the number of failed tests: with this option, only those 9 tests fail out of the 407 in Python 3.6 This info was found by disabling the quiet option, so that is another plus.

If you have time, can I ask a question related to the *.pgc files?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35739>
_______________________________________

From report at bugs.python.org  Sat Jan 19 02:09:18 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 19 Jan 2019 07:09:18 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org>
Message-ID: <1547881758.9.0.617798565977.issue35748@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

The ?urllib.parse? module generally follows RFC 3986, which does not allow a literal backslash in the ?userinfo? part:

userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

The RFC does not allow a backslash in the host name, path, query or fragment either. That is why I said the URL is not valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Sat Jan 19 02:42:46 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 19 Jan 2019 07:42:46 +0000
Subject: [issue13322] buffered read() and write() does not raise
 BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1547883766.29.0.33860906315.issue13322@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Issue 35762 was opened specifically about Izbyshev?s case: TextIOWrapper behaviour with a non-blocking file. Calling ?os.fdopen? with mode='r' (text mode) returns a TextIOWrapper object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Sat Jan 19 02:42:50 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 19 Jan 2019 07:42:50 +0000
Subject: [issue35762] subprocess.Popen with universal_newlines and nonblocking
 streams fails with "can't concat NoneType to bytes"
In-Reply-To: <1547738568.37.0.865745194211.issue35762@roundup.psfhosted.org>
Message-ID: <1547883770.62.0.639075472135.issue35762@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Yes, universal newlines mode uses the TextIOWrapper class to read the pipe, which isn?t really designed for non-blocking mode. This is the same problem described by Izbyshev at <https://bugs.python.org/issue13322#msg307763>.

Raising TypeError isn?t ideal. IMO it would be better to raise BlockingIOError, which is what basic calls like ?os.read? would do, and what ?BufferedReader.read? is supposed to do according to the documentation. (However the documentation and implementation don?t match; that is what Issue 13322 is about.)

----------
nosy: +martin.panter
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35762>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:01:45 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Sat, 19 Jan 2019 08:01:45 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547884905.71.0.550877052035.issue35699@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
nosy: +uranusjr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:04:23 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 19 Jan 2019 08:04:23 +0000
Subject: [issue35507] multiprocessing: seg fault when creating RawArray from
 numpy ctypes
In-Reply-To: <1544849056.09.0.788709270274.issue35507@psf.upfronthosting.co.za>
Message-ID: <1547885063.46.0.445231858333.issue35507@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Looks like the numpy PR was merged. We can close this issue?

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35507>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:05:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 08:05:50 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547885150.33.0.728512587132.issue35780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Suggested code for the open question listed above:

--- a/Modules/_functoolsmodule.c
+++ b/Modules/_functoolsmodule.c
@@ -733,6 +733,15 @@ lru_cache_make_key(PyObject *args, PyObject *kwds, int typed)

     /* short path, key will match args anyway, which is a tuple */
     if (!typed && !kwds) {
+        if (PyTuple_GET_SIZE(args) == 1) {
+            key = PyTuple_GET_ITEM(args, 0);
+            if (!PySequence_Check(key)) {
+                /* For scalar keys, save space and
+                   drop the enclosing args tuple  */
+                Py_INCREF(key);
+                return key;
+            }
+        }
         Py_INCREF(args);
         return args;
     }

----------
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:40:19 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNC60YEg0JLQtdGA0L3QtdGA?=)
Date: Sat, 19 Jan 2019 08:40:19 +0000
Subject: [issue35783] incorrect example of fetching messages in imaplib
 documentation
Message-ID: <1547887217.4.0.578077466695.issue35783@roundup.psfhosted.org>


New submission from ???? ?????? <mvarnar at gmail.com>:

An example of fetching messages from the mailbox given in "IMAP4 Example" section is incorrect:

typ, data = M.fetch(num, '(RFC822)')
print('Message %s\n%s\n' % (num, data[0][1]))

"fetch" may return server data that was not requested (see "7.4.2.  FETCH Response" section of RFC 3501). In that case "data[0][1]" won't return what user expects.
This is a bad example, that many people repeat and advise to other developers:
https://stackoverflow.com/questions/13210737/get-only-new-emails-imaplib-and-python
https://gist.github.com/robulouski/7441883
https://stackoverflow.com/questions/51098962/check-if-email-inbox-is-empty-imaplib-python3
https://stackoverflow.com/questions/21116498/imaplib-not-getting-all-emails-in-folder
https://stackoverflow.com/questions/2230037/how-to-fetch-an-email-body-using-imaplib-in-python

I guess, this peculiarity should be clarified in the documentation. I offer to mark this fetching method is not safe and requests careful fetch result parsing.

----------
assignee: docs at python
components: Documentation, email
messages: 334048
nosy: barry, docs at python, r.david.murray, ???? ??????
priority: normal
severity: normal
status: open
title: incorrect example of fetching messages in imaplib documentation
type: enhancement
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/issue35783>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:50:39 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 08:50:39 +0000
Subject: [issue35748] urlparse library detecting wrong hostname leads to open
 redirect vulnerability
In-Reply-To: <1547881758.9.0.617798565977.issue35748@roundup.psfhosted.org>
Message-ID: <20190119085032.GS13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> The ?urllib.parse? module generally follows RFC 3986, which does not 
> allow a literal backslash in the ?userinfo? part:

And yet the parse() function seems to allow arbitrary unescaped 
characters. This is from 3.8.0a0:

py> from urllib.parse import urlparse
py> urlparse(r'http://spam\eggs!cheese&aardvark at evil.com').netloc
'spam\\eggs!cheese&aardvark at evil.com'
py> urlparse(r'http://spam\eggs!cheese&aardvark at evil.com').hostname
'evil.com'

If that's a bug, it is a separate bug to this issue.

Backslash doesn't seem relevant to the security issue of userinfo being 
used to mislead:

py> urlparse('http://www.google.com at evil.com').netloc
'www.google.com at evil.com'
py> urlparse('http://www.google.com at evil.com').hostname
'evil.com'

If it is relevant, can somebody explain to me how?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35748>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:57:10 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jan 2019 08:57:10 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547888230.39.0.809337033543.issue35782@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11369
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:57:15 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jan 2019 08:57:15 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547888235.28.0.36143621719.issue35782@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11369, 11370
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:57:20 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jan 2019 08:57:20 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547888240.44.0.296496415935.issue35782@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11369, 11370, 11371
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 03:57:25 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jan 2019 08:57:25 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547888245.18.0.23626887578.issue35782@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11369, 11370, 11371, 11372
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 04:31:07 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 09:31:07 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547890267.07.0.0655530638913.issue35780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

---------  Demonstration of one of the bugs ---------

# The currsize is initially equal to maxsize of 10
# Then we cause an orphan link in a full cache 
# The currsize drops to 9 and never recovers the full size of 10

from functools import lru_cache

once = True

@lru_cache(maxsize=10)
def f(x):
    global once
    rv = f'.{x}.'
    if x == 20 and once:
        once = False
        print('Calling again', f(x))
    return rv

for x in range(15):
    f(x)

print(f.cache_info())
print(f(20))
print(f.cache_info())
print(f(21))
print(f.cache_info())


------ Output --------
CacheInfo(hits=0, misses=15, maxsize=10, currsize=10)
Calling again .20.
.20.
CacheInfo(hits=0, misses=17, maxsize=10, currsize=9)
.21.
CacheInfo(hits=0, misses=18, maxsize=10, currsize=9)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 04:35:13 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 19 Jan 2019 09:35:13 +0000
Subject: [issue35779] Print friendly version message in REPL
In-Reply-To: <1547865815.91.0.564607608514.issue35779@roundup.psfhosted.org>
Message-ID: <1547890513.5.0.413501733867.issue35779@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

It's interesting to see the a Python 1.5.2 from April 1999 :)

Thanks for your opinion, let me explain:

We only print simplified message in official binary release, any Linux/private builds still using the current message. We know enough information about official binary release.

Junior users are people such as students learning programming in middle school, I think git information will confuse them, maybe many of them will never know git knowledges.

In recent versions, there is a "tags/" prepend to git tag, make the line longer. Just concatenating the string provided by git/compiler is a bit ugly IMO.

Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32
Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32

Another problem is indicating 32bit or 64bit build, IMHO this is an useful information.
64bit machine did not exist in 1999, but now there are many kinds platforms, desktop, IOT, Raspberry Pi. This seems another topic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Sat Jan 19 04:51:54 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Sat, 19 Jan 2019 09:51:54 +0000
Subject: [issue35784] document that hashlib.new takes kwargs
Message-ID: <1547891512.78.0.551625258156.issue35784@roundup.psfhosted.org>


New submission from J?rn Heissler <launchpad at joern.heissler.de>:

This code works:
hashlib.new('blake2b', b'foo', digest_size=7)

https://github.com/python/cpython/blob/master/Lib/hashlib.py#L7
documents the function as: new(name, data=b'', **kwargs)

But the **kwargs argument is missing in https://docs.python.org/3/library/hashlib.html#hashlib.new and there aren't any examples either.

----------
assignee: docs at python
components: Documentation
messages: 334053
nosy: docs at python, joernheissler
priority: normal
severity: normal
status: open
title: document that hashlib.new takes kwargs
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35784>
_______________________________________

From report at bugs.python.org  Sat Jan 19 05:58:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 10:58:12 +0000
Subject: [issue35784] document that hashlib.new takes kwargs
In-Reply-To: <1547891512.78.0.551625258156.issue35784@roundup.psfhosted.org>
Message-ID: <1547895492.26.0.760852700819.issue35784@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +christian.heimes, gregory.p.smith
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35784>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:03:49 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Jan 2019 11:03:49 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1547895829.77.0.728034271625.issue35711@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Not PyErr_Print(). Maybe PyErr_WriteUnraisable().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:09:48 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Jan 2019 11:09:48 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547896188.2.0.739880116717.issue35780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> would it be reasonable to emulate the pure python code and return a scalar instead of a tuple when the tuple length is one and there are no keyword arguments or typing requirements?

It was discussed before, and there is a closed issue. I am not sure about the optimization in the Python code. It may lead to bugs in corner cases too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:22:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Jan 2019 11:22:28 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547896948.81.0.499044989912.issue35780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> After the check for popresult==Py_None, there is the comment that was mostly copied from the Python version but doesn't match the actual code:

Seems the comment was placed at wrong place. And it should be updated since locks are not used, but the GIL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:28:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Jan 2019 11:28:16 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547897296.22.0.210770432288.issue35780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> If so, then why is the link being moved to the front of the lru_cache -- it should have remained at the oldest position.

It may be unintentionally. In any case, this is a case that should be very rare.

> The solution to this is only extract the link after a successful pop rather than before.

Then there is a possibility to pop the same key (from the last link) twice. The GIL can be released in _PyDict_Pop_KnownHash() and other thread can went the same way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:29:27 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 19 Jan 2019 11:29:27 +0000
Subject: [issue35507] multiprocessing: seg fault when creating RawArray from
 numpy ctypes
In-Reply-To: <1544849056.09.0.788709270274.issue35507@psf.upfronthosting.co.za>
Message-ID: <1547897367.47.0.168241899476.issue35507@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

yes, please do

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35507>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:34:32 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Jan 2019 11:34:32 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547897672.86.0.0252155545235.issue35780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Operations with the linked list are atomic (guarded with the GIL), while operations with the cache dict are not. That is why links are removed first from the linked list and added back in case of error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:37:17 2019
From: report at bugs.python.org (Louie Lu)
Date: Sat, 19 Jan 2019 11:37:17 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547897837.05.0.516653388606.issue35782@roundup.psfhosted.org>


Louie Lu <me at louie.lu> added the comment:

I previously close this issue is because not sure if someone rely on exception string to do something, should we consider this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:54:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 11:54:16 +0000
Subject: [issue35507] multiprocessing: seg fault when creating RawArray from
 numpy ctypes
In-Reply-To: <1544849056.09.0.788709270274.issue35507@psf.upfronthosting.co.za>
Message-ID: <1547898856.71.0.133757976181.issue35507@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am closing this with third party as resolution. Feel free to reopen this if it's an issue with multiprocessing and CPython.

Thanks for triaging.

----------
nosy: +xtreak
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35507>
_______________________________________

From report at bugs.python.org  Sat Jan 19 06:58:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 11:58:03 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1547899083.87.0.882921597626.issue35782@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> I previously close this issue is because not sure if someone rely on exception string to do something, should we consider this?

I think this is a valid issue since error messages have been modified in the past. I am not sure if this will be backported to 3.7 though.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Sat Jan 19 07:11:17 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 19 Jan 2019 12:11:17 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1547899877.19.0.717020077145.issue35766@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Sat Jan 19 07:22:48 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jan 2019 12:22:48 +0000
Subject: [issue35778] RF: ``pathlib.Path.checksum()`` member
In-Reply-To: <1547854155.56.0.887499494247.issue35778@roundup.psfhosted.org>
Message-ID: <1547900568.78.0.322879395168.issue35778@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, but it does not make sense to me (not would it make sense to add e.g. a JPEG decoder to pathlib).  Each project or application would want their own checksumming specification and pathlib does not have to cater to that.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35778>
_______________________________________

From report at bugs.python.org  Sat Jan 19 11:11:08 2019
From: report at bugs.python.org (David Heiberg)
Date: Sat, 19 Jan 2019 16:11:08 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547914268.4.0.765840300084.issue35701@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
pull_requests: +11374
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Sat Jan 19 11:11:20 2019
From: report at bugs.python.org (David Heiberg)
Date: Sat, 19 Jan 2019 16:11:20 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547914280.11.0.583734638821.issue35701@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
pull_requests: +11374, 11375
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Sat Jan 19 11:11:29 2019
From: report at bugs.python.org (David Heiberg)
Date: Sat, 19 Jan 2019 16:11:29 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1547914289.35.0.513793964661.issue35701@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
pull_requests: +11374, 11375, 11376
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Sat Jan 19 11:41:54 2019
From: report at bugs.python.org (Tal Einat)
Date: Sat, 19 Jan 2019 16:41:54 +0000
Subject: [issue35771] IDLE: Fix tooltip Hovertiptest failure
In-Reply-To: <1547794267.4.0.582455332849.issue35771@roundup.psfhosted.org>
Message-ID: <1547916114.86.0.315496297735.issue35771@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

This is due to the test using a 50ms delay on hover, and checking "immediately" after generating an "<Enter>" event that it hasn't triggered yet.  Note that this isn't actually "immediately": The Tk root's update() is called in between to simulate having a live Tk event loop.

On slow machines this could indeed fail due to the update() call taking a while.

I originally chose 50ms since it seemed like more than enough. Using a longer delay would make the test more robust, but would make testing unnecessarily slow on fast machines.

Perhaps we should look for a more general solution, such as multiplying all test time values by a scale factor depending on a machine's execution speed?  That would avoid such future errors in many tests, while keeping the tests faster on fast machines.

Otherwise let's just increase this to 100ms or 200ms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35771>
_______________________________________

From report at bugs.python.org  Sat Jan 19 12:38:07 2019
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 19 Jan 2019 17:38:07 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
Message-ID: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>


New submission from Eric Fahlgren <ericfahlgren at gmail.com>:

When argparse is configured with an option that takes arguments, then the script is invoked with the switch but no arguments, a nonsensical exception is raised during gettext processing.

In the 3.7.1 source, the error is at line 2077 of argparse.py, where 'action.nargs' is not an integer as expected by 'ngettext', but one of None, '*' or '?':

            default = ngettext('expected %s argument',
                               'expected %s arguments',
                               action.nargs) % action.nargs
            msg = nargs_errors.get(action.nargs, default)

Fix should be pretty trivial, swap the two lines and if 'get' produces None, only then compute the default.

  File "C:\Program Files\Python37\lib\argparse.py", line 1749, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "C:\Program Files\Python37\lib\argparse.py", line 1781, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "C:\Program Files\Python37\lib\argparse.py", line 1987, in _parse_known_args
    start_index = consume_optional(start_index)
  File "C:\Program Files\Python37\lib\argparse.py", line 1917, in consume_optional
    arg_count = match_argument(action, selected_patterns)
  File "C:\Program Files\Python37\lib\argparse.py", line 2079, in _match_argument
    action.nargs) % action.nargs
  File "C:\Program Files\Python37\lib\gettext.py", line 631, in ngettext
    return dngettext(_current_domain, msgid1, msgid2, n)
  File "C:\Program Files\Python37\lib\gettext.py", line 610, in dngettext
    return t.ngettext(msgid1, msgid2, n)
  File "C:\Program Files\Python37\lib\gettext.py", line 462, in ngettext
    tmsg = self._catalog[(msgid1, self.plural(n))]
  File "<string>", line 4, in func
  File "C:\Program Files\Python37\lib\gettext.py", line 168, in _as_int
    (n.__class__.__name__,)) from None
TypeError: Plural value must be an integer, got NoneType

----------
components: Library (Lib)
messages: 334065
nosy: eric.fahlgren
priority: normal
severity: normal
status: open
title: argparse crashes in gettext when processing missing arguments
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 12:38:37 2019
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 19 Jan 2019 17:38:37 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547919517.73.0.79280149559.issue35785@roundup.psfhosted.org>


Change by Eric Fahlgren <ericfahlgren at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 12:52:24 2019
From: report at bugs.python.org (Vinay Badhan)
Date: Sat, 19 Jan 2019 17:52:24 +0000
Subject: [issue35533] argparse standard error usage for exit / error
In-Reply-To: <1545220030.92.0.788709270274.issue35533@psf.upfronthosting.co.za>
Message-ID: <1547920344.66.0.50423073284.issue35533@roundup.psfhosted.org>


Vinay Badhan <vinay.badhan21 at gmail.com> added the comment:

Add documentation for exit() function

----------
keywords: +patch
nosy: +vinayb21
pull_requests: +11377
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35533>
_______________________________________

From report at bugs.python.org  Sat Jan 19 13:08:06 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 19 Jan 2019 18:08:06 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547921286.35.0.970944876597.issue35785@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +bethard

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 13:34:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jan 2019 18:34:36 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547922876.05.0.409128443017.issue35780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> It was discussed before, and there is a closed issue.

That is a non-answer.  The above patch is correct and achieves an essential goal of the lru_cache to save space when possible (avoid an unnecessary extra tuple per entry).   Also, please apply the other patch to eliminate the unnecessary double lookup in lru_cache_extricate_link().   Please also fix the naming problem, "extricate" -> "extract".

> It may be unintentionally. In any case, this is a case that should be very rare.

Please just fix the bug.  That code path incorrectly refreshes an old-key that has not been called recently.  It fails to add the new key that was just called.  It leaves an orphan link causing an unnecessary downstream check for root!=next to guard for the broken invariants.  It leaves the full variable set when the cache is not longer full (missing link).

FWIW, one principal use case for lru_cache() is to support dynamic programming in recursive functions.  So a "call within a call" should not be regarded as "rare".

> Seems the comment was placed at wrong place.

Not just that.  The relevant code was omitted.  It is important to check to see if the new key has already been added by the user_function().  The knowledge of whether that key is present is stale after the user function call.  Please follow the pure python code in this regard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 16:12:08 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 19 Jan 2019 21:12:08 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1547932328.58.0.642254029858.issue35766@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Sat Jan 19 16:15:42 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 19 Jan 2019 21:15:42 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1547932542.37.0.129482936163.issue35766@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

Seems also related to https://bugs.python.org/issue24119

with python2 / python3.5 (hopefully) rapidly falling off in usage I would assume the specialized treatment of `# type: ...` comments would become less and less necessary

Though I guess there's still `# type: ignore`, though if I recall correctly ignores are bubbled up to the module level and are applied on a line-by-line basis and wouldn't necessarily need specialized AST treatment (though a second parse over the token stream is a bit unfortunate)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Sat Jan 19 16:19:48 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 19 Jan 2019 21:19:48 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547932788.51.0.808090830872.issue35785@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

Can you provide a reproducer? I'm having difficulty reproducing with this script:

import argparse

p = argparse.ArgumentParser()
p.add_argument('--foo', nargs=None)
args = p.parse_args()


$ python3.7 --version
Python 3.7.2
$ python3.7 t.py --foo
usage: t.py [-h] [--foo FOO]
t.py: error: argument --foo: expected one argument

----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 16:50:34 2019
From: report at bugs.python.org (Lorenzo Persichetti)
Date: Sat, 19 Jan 2019 21:50:34 +0000
Subject: [issue35786] get_lock() method is not present for Values created
 using multiprocessing.Manager()
Message-ID: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org>


New submission from Lorenzo Persichetti <lpersichetti at gmail.com>:

According to the documentation of the multiprocessing.Value() class available here https://docs.python.org/3.6/library/multiprocessing.html#multiprocessing.Value

Operations like += which involve a read and write are not atomic. So if, for instance, you want to atomically increment a shared value it is insufficient to just do

counter.value += 1
Assuming the associated lock is recursive (which it is by default) you can instead do

with counter.get_lock():
    counter.value += 1

What happens is that when running the following snippet

import multiprocessing
manager = multiprocessing.Manager()
value = manager.Value('i', 0)
value.get_lock()

the result is 
AttributeError: 'ValueProxy' object has no attribute 'get_lock'

----------
assignee: docs at python
components: Documentation, Library (Lib), Windows
messages: 334070
nosy: Lorenzo Persichetti, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: get_lock() method is not present for Values created using multiprocessing.Manager()
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35786>
_______________________________________

From report at bugs.python.org  Sat Jan 19 16:57:16 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Jan 2019 21:57:16 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1547935036.27.0.425017571689.issue35766@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

You?d be surprised how tenacious old versions are. 

Anywa, I am working on this on my copious spare time ? you can follow my progress at https://github.com/gvanrossum/cpython/tree/ast-type-comments?files=1 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Sat Jan 19 16:58:29 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Jan 2019 21:58:29 +0000
Subject: [issue24119] Carry comments with the AST
In-Reply-To: <1430666470.75.0.339272692521.issue24119@psf.upfronthosting.co.za>
Message-ID: <1547935109.25.0.90616740032.issue24119@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

See also issue35766.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24119>
_______________________________________

From report at bugs.python.org  Sat Jan 19 17:17:50 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 19 Jan 2019 22:17:50 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1547936270.89.0.151404966944.issue35766@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

> You?d be surprised how tenacious old versions are. 

heh that's true, at my last job we finally got rid of python2.6 in 2016 :'(

anyway -- I don't mean to discourage this, definitely seems valuable to the maintenance of mypy!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Sat Jan 19 17:44:45 2019
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 19 Jan 2019 22:44:45 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547937885.98.0.456507474313.issue35785@roundup.psfhosted.org>


Eric Fahlgren <ericfahlgren at gmail.com> added the comment:

After a bit more digging, it's a side effect of having the locale set with 'Plural-Forms'.  I've attached the resulting .mo file, but since it's a binary, I'm not sure it will work cross-platform, so here's how to recreate it.

> cat en_US/LC_MESSAGES/foo.po
msgid ""
msgstr "Plural-Forms: nplurals=2; plural=(n != 1);\n"

> python /Python37/Tools/i18n/msgfmt.py en_US/LC_MESSAGES/foo.po
> ll en_US/LC_MESSAGES/
-rwx------+ 1 efahlgren Domain Users 89 2019-01-19 14:36 foo.mo*
-rw-r--r--+ 1 efahlgren Domain Users 69 2019-01-19 14:34 foo.po

Then you can reproduce with some setup in your script:

import os
import gettext
import argparse

os.putenv('LANG', 'en_US')  # Just to make sure.
gettext.bindtextdomain('foo', '.')
gettext.textdomain('foo')

p = argparse.ArgumentParser()
p.add_argument('--foo', nargs=None)
p.parse_args()

----------
Added file: https://bugs.python.org/file48068/foo.mo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 18:27:32 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Jan 2019 23:27:32 +0000
Subject: [issue35775] Add a general selection function to statistics
In-Reply-To: <1547820289.72.0.450290663887.issue35775@roundup.psfhosted.org>
Message-ID: <1547940452.3.0.168782150517.issue35775@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

R?mi. I've read over your patch and have some comments:

(1) You call sorted() to produce a list, but then instead of retrieving the item using ``data[i-1]`` you use ``itertools.islice``. That seems unnecessary to me. Do you have a reason for using ``islice``?

(2) select is not very useful on its own, we actually want it so we can calculate quantiles, e.g. percentiles, deciles, quartiles. If we want the k-quantile (e.g. k=100 for percentiles) then there are k+1 k-quantiles in total, including the minimum and maximum. E.g quartiles divide the data set into four equal sections, so there are five boundary values including the min and max.

So the caller is likely to be calling select repeatedly on the same data set, and hence making a copy of that data and sorting it repeatedly. If the data set is small, repeatedly making sorted copies is still cheap enough, but for large data sets, that will be expensive.

Do you have any thoughts on how to deal with that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35775>
_______________________________________

From report at bugs.python.org  Sat Jan 19 19:57:25 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Jan 2019 00:57:25 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547945845.87.0.322324782335.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +11378
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 19:57:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Jan 2019 00:57:29 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547945849.12.0.492057923595.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11378, 11379
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 19:57:32 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Jan 2019 00:57:32 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1547945852.48.0.910575331677.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11378, 11379, 11380
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 19 22:25:17 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 20 Jan 2019 03:25:17 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547954717.38.0.661449893039.issue35785@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

No crash at Python 3.7.2+ (heads/3.7:47290e7642, Jan 20 2019, 12:22:44)
and master branch

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 22:46:48 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 20 Jan 2019 03:46:48 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547956008.04.0.663947890425.issue35785@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Umm looks like I should pass an argument on cmd to reproduce it. I will try to reproduce it later

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sat Jan 19 22:58:27 2019
From: report at bugs.python.org (Ma Lin)
Date: Sun, 20 Jan 2019 03:58:27 +0000
Subject: [issue34294] re.finditer and lookahead bug
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1547956707.78.0.450594370786.issue34294@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Serhiy Storchaka lost his sight.
Please stop any work and rest, because your left eye will have more burden, and your mental burden will make it worse.
Go to hospital ASAP.

If any other core developer want to review this patch, I would like to give a detailed explanation, the logic is not very compilcated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Sun Jan 20 02:42:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 20 Jan 2019 07:42:05 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1547970125.81.0.474400905072.issue35699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Reminder to myself (or permission for anyone else) to merge this. My phone won't let me actually click the github merge button, unfortunately, but this seems good to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sun Jan 20 04:10:37 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 20 Jan 2019 09:10:37 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1547975437.87.0.195926533207.issue35785@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

?  cpython.git git:(3.7) ? ./python.exe bpo-35785.py --foo test
?  cpython.git git:(3.7) ? ./python.exe bpo-35785.py --foo 1
?  cpython.git git:(3.7) ? ./python.exe bpo-35785.py --foo
usage: bpo-35785.py [-h] [--foo FOO]
bpo-35785.py: error: argument --foo: expected one argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sun Jan 20 05:23:16 2019
From: report at bugs.python.org (Max)
Date: Sun, 20 Jan 2019 10:23:16 +0000
Subject: [issue35787] shlex.split inserts extra item on backslash space space
Message-ID: <1547979795.17.0.450145238356.issue35787@roundup.psfhosted.org>


New submission from Max <maxmoroz at gmail.com>:

I believe in both cases below, the ouptu should be ['a', 'b']; the extra ' ' inserted in the list is incorrect:

python3.6
Python 3.6.2 (default, Aug  4 2017, 14:35:04)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shlex
>>> shlex.split('a \ b')
['a', ' b']
>>> shlex.split('a \  b')
['a', ' ', 'b']
>>>

Doc reference: https://docs.python.org/3/library/shlex.html#parsing-rules
> Non-quoted escape characters (e.g. '\') preserve the literal value of the next character that follows;

I believe this implies that backslash space should be just space; and then two adjacent spaces should be used (just like a single space) as a separator between arguments.

----------
components: Library (Lib)
messages: 334081
nosy: max
priority: normal
severity: normal
status: open
title: shlex.split inserts extra item on backslash space space
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35787>
_______________________________________

From report at bugs.python.org  Sun Jan 20 05:33:03 2019
From: report at bugs.python.org (Peter Otten)
Date: Sun, 20 Jan 2019 10:33:03 +0000
Subject: [issue35787] shlex.split inserts extra item on backslash space space
In-Reply-To: <1547979795.17.0.450145238356.issue35787@roundup.psfhosted.org>
Message-ID: <1547980383.91.0.265273665756.issue35787@roundup.psfhosted.org>


Peter Otten <__peter__ at web.de> added the comment:

To me the current shlex behaviour makes sense, and the shell (tested with bash) behaves the same way:

$ python3 -c 'import sys; print(sys.argv)' a   b
['-c', 'a', 'b']
$ python3 -c 'import sys; print(sys.argv)' a \  b
['-c', 'a', ' ', 'b']

----------
nosy: +peter.otten

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35787>
_______________________________________

From report at bugs.python.org  Sun Jan 20 06:14:35 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 20 Jan 2019 11:14:35 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
Message-ID: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>


New submission from Samuel Colvin <samcolvin at gmail.com>:

smtpd.PureProxy.process_message and smtpd.MailmanProxy.process_message are defined to not receive the extra kwargs which they're called with.

They both also expect "data" to be str when it's actually bytes.

Thus they're completed broken at the moment.

I'd like to submit a PR to fix these two bugs.

There are a number of other issues/potential improvements to smtpd which are not critical but I guess should be fixed:
* no support for starttls
* use of print(..., file=DEBUGSTREAM) instead of logger.debug
* no type hints
* PureProxy's forwarding doesn't try starttls

Should I create a new issue(s) for these problems or is there some agreement that only actual bugs will be fixed in little-used modules like this?

----------
components: email
messages: 334083
nosy: barry, r.david.murray, samuelcolvin
priority: normal
severity: normal
status: open
title: smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
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/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 07:25:55 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 20 Jan 2019 12:25:55 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547987155.66.0.3460947759.issue35788@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch
pull_requests: +11381
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 07:26:03 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 20 Jan 2019 12:26:03 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547987163.28.0.501403044555.issue35788@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11381, 11382
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 07:26:10 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 20 Jan 2019 12:26:10 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547987170.8.0.34896718306.issue35788@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11381, 11382, 11383
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 07:26:18 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 20 Jan 2019 12:26:18 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547987178.24.0.348966742577.issue35788@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11381, 11382, 11383, 11384
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 09:22:44 2019
From: report at bugs.python.org (tjh)
Date: Sun, 20 Jan 2019 14:22:44 +0000
Subject: [issue27542] Segfault in gcmodule.c:360 visit_decref
In-Reply-To: <1468755086.8.0.27245311458.issue27542@psf.upfronthosting.co.za>
Message-ID: <1547994164.54.0.701242533307.issue27542@roundup.psfhosted.org>


tjh <info at nvimp.com> added the comment:

If you're here looking for a solution, deleting previously installed deps helped me. In my case this was:

$ rm -rf ~/.local/lib/python2.7/site-packages/  # path may differ depending where you install these
$ pip install cffi

----------
nosy: +tjh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27542>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:03:19 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 20 Jan 2019 15:03:19 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1547996599.82.0.583586102102.issue24928@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi Berker, 

Thanks for you response. 

I agree when you say that patch.dict is a simply operation, but I think that this test can be necessary, if for some reason the implementation of patch.dict (or its parts) decide change. 

> I think the relationship between dict and OrderedDict (including any other dict subclasses and dict-like objects) and anything related to insertion order should be tested either in test_dict or in test_ordered_dict.

I am not sure if this has to be tested on test_dict or test_oredered_dict, because we are not testing specifically dict-like objects.

This test, can be written on test_patch_dict and not create a new `test_patch_dict_with_orderdict`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:08:32 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 20 Jan 2019 15:08:32 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547996912.8.0.218302180103.issue35788@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

> Should I create a new issue(s) for these problems or is there some agreement that only actual bugs will be fixed in little-used modules like this?

I would create new issue for each point to discuss, but I would like listen other opinions

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:12:33 2019
From: report at bugs.python.org (Jim Carroll)
Date: Sun, 20 Jan 2019 15:12:33 +0000
Subject: [issue35789] Typo in unittest.mock docs
Message-ID: <1547997151.52.0.475948555823.issue35789@roundup.psfhosted.org>


New submission from Jim Carroll <jim at carroll.com>:

There is a typo in the unittest.mock documentation found at https://docs.python.org/3/library/unittest.mock.html.

There are seven(7) instances of the word assret, where the author clearly intended assert.

----------
assignee: docs at python
components: Documentation
messages: 334087
nosy: docs at python, jamercee
priority: normal
severity: normal
status: open
title: Typo in unittest.mock docs
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/issue35789>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:12:35 2019
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Jan 2019 15:12:35 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547997155.22.0.0314724058494.issue35788@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for being willing to work on this, but smtpd is deprecated in favor of aiosmtpd (which is not part of the stdlib).  smtpd should really only be used for internal stdlib testing, but it is retained for backward compatibility reasons.

All of these issues have been previously reported and were closed in favor of recommending aiosmtpd because we are no longer maintaining smtpd.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:15:17 2019
From: report at bugs.python.org (Jim Carroll)
Date: Sun, 20 Jan 2019 15:15:17 +0000
Subject: [issue35789] Typo in unittest.mock docs
In-Reply-To: <1547997151.52.0.475948555823.issue35789@roundup.psfhosted.org>
Message-ID: <1547997317.46.0.785674332881.issue35789@roundup.psfhosted.org>


Jim Carroll <jim at carroll.com> added the comment:

Never mind....i see this issue has been reported previously and the typo is considered intentional.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35789>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:23:37 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 20 Jan 2019 15:23:37 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1547997817.84.0.853254166699.issue35788@roundup.psfhosted.org>


Samuel Colvin <samcolvin at gmail.com> added the comment:

Thanks for the explanation David.

It would be really useful if this was prominently noted in smtpd, it would have saved me spending my morning fixing these things. There's also (AFAIK) nothing about this being deprecated in the docs.

More generally I understand the idea of deprecated code that doesn't get updated to conform to latest conventions, but surely if the code exists in the standard lib. it should at least work as it was originally intended or be removed?

Since the PR is done and passing surely it would be better to merge it than leave PureProxy completely broken.

By the way, aiosmtpd is not in good shape:
1. Its proxy handler is blocking https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/handlers.py#L119
2. Its proxy handler appears to be broken in some other way, I couldn't get it to forward emails which is why I resorted to using standard smtpd.
3. It's built in a very odd way, it appears to use threading not asyncio to run the main controller https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/controller.py#L54

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Sun Jan 20 10:27:33 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Jan 2019 15:27:33 +0000
Subject: [issue35787] shlex.split inserts extra item on backslash space space
In-Reply-To: <1547979795.17.0.450145238356.issue35787@roundup.psfhosted.org>
Message-ID: <1547998053.28.0.186120901198.issue35787@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that the current behavior makes sense. I think "preserve the literal value of the next character" means the space won't be interpreted as a separator.

In the first example (I think better written as shlex.split(r'a \ b')), the first space is a separator. The second space is not a separator because of the backslash, so it's part of the second token ' b'.

In the second example (shlex.split(r'a \  b')), the first space is a separator, the second space is not a separator because of the backslash, and the third space is a separator. This explains why there's no space before the 'b'.

I assume peter.otten's example is bash. I can confirm with zsh:

[~]$ python3 -c 'import sys; print(sys.argv)' a   b
['-c', 'a', 'b']
[~]$ python3 -c 'import sys; print(sys.argv)' a \ b
['-c', 'a', ' b']
[~]$ python3 -c 'import sys; print(sys.argv)' a \  b
['-c', 'a', ' ', 'b']

I'm going to close this. But anyone wants to suggest a documentation patch, feel free to reopen this.

Also, changing this would no doubt break some code, so I'd recommend against changing it even if I didn't think it was doing the right thing.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35787>
_______________________________________

From report at bugs.python.org  Sun Jan 20 11:39:45 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 20 Jan 2019 16:39:45 +0000
Subject: [issue35790] Correct a statement about sys.exc_info() values
 restoration
Message-ID: <1548002384.27.0.286179066843.issue35790@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

In the documentation of the try statement (https://docs.python.org/3/reference/compound_stmts.html#the-try-statement), I think that the sentence:

"sys.exc_info() values are restored to their previous values (before the call) when returning from a function that handled an exception."

should be replaced by this sentence:

"sys.exc_info() values are restored to their previous values (before the call) when leaving an exception handler."

as proven by this code which does not use any "function that handled an exception" and yet restores sys.exc_info() values:


>>> try:
...     raise ValueError
... except:
...     try:
...          raise TypeError
...     except:
...         print(sys.exc_info())
...     print(sys.exc_info())
... 
(<class 'TypeError'>, TypeError(), <traceback object at 0x10ca19bc8>)
(<class 'ValueError'>, ValueError(), <traceback object at 0x10ca19c08>)

----------
assignee: docs at python
components: Documentation
messages: 334092
nosy: docs at python, eric.araujo, ezio.melotti, maggyero, mdk, willingc
priority: normal
severity: normal
status: open
title: Correct a statement about sys.exc_info() values restoration
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35790>
_______________________________________

From report at bugs.python.org  Sun Jan 20 11:56:50 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 20 Jan 2019 16:56:50 +0000
Subject: [issue35790] Correct a statement about sys.exc_info() values
 restoration
In-Reply-To: <1548002384.27.0.286179066843.issue35790@roundup.psfhosted.org>
Message-ID: <1548003410.77.0.651214619198.issue35790@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch
pull_requests: +11386
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35790>
_______________________________________

From report at bugs.python.org  Sun Jan 20 11:57:02 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 20 Jan 2019 16:57:02 +0000
Subject: [issue35790] Correct a statement about sys.exc_info() values
 restoration
In-Reply-To: <1548002384.27.0.286179066843.issue35790@roundup.psfhosted.org>
Message-ID: <1548003422.02.0.493007181932.issue35790@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11386, 11387
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35790>
_______________________________________

From report at bugs.python.org  Sun Jan 20 11:57:10 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 20 Jan 2019 16:57:10 +0000
Subject: [issue35790] Correct a statement about sys.exc_info() values
 restoration
In-Reply-To: <1548002384.27.0.286179066843.issue35790@roundup.psfhosted.org>
Message-ID: <1548003430.06.0.898804802088.issue35790@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11386, 11387, 11388
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35790>
_______________________________________

From report at bugs.python.org  Sun Jan 20 12:24:14 2019
From: report at bugs.python.org (Eric Fahlgren)
Date: Sun, 20 Jan 2019 17:24:14 +0000
Subject: [issue35785] argparse crashes in gettext when processing missing
 arguments
In-Reply-To: <1547919486.3.0.425644467841.issue35785@roundup.psfhosted.org>
Message-ID: <1548005054.0.0.972850162767.issue35785@roundup.psfhosted.org>


Eric Fahlgren <ericfahlgren at gmail.com> added the comment:

Thanks, I installed 3.7.2 on one of our non-production machines and it appears that gettext has been fixed, so I'm closing this.

> python -V
Python 3.7.2
> python bpo35785.py --foo
usage: bpo35785.py [-h] [--foo FOO]
bpo35785.py: error: argument --foo: expected one argument

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35785>
_______________________________________

From report at bugs.python.org  Sun Jan 20 12:38:25 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Jan 2019 17:38:25 +0000
Subject: [issue35791] Unexpected exception with importlib
Message-ID: <1548005903.93.0.648072616722.issue35791@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Using Python 3.7.2 on macOS 10.14 I get an unexpected exception when calling "importlib.util.find_spec('py')" after importing "py". find_spec works as expected before I import 'py'. 

See the repl session below:

Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib.util
>>> importlib.util.find_spec("py")
ModuleSpec(name='py', loader=<_frozen_importlib_external.SourceFileLoader object at 0x10a953fd0>, origin='/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/py/__init__.py', submodule_search_locations=['/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/py'])
>>> import py
>>> importlib.util.find_spec("py")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/importlib/util.py", line 111, in find_spec
    raise ValueError('{}.__spec__ is not set'.format(name)) from None
ValueError: py.__spec__ is not set

This is with py version 1.7.0 installed (pip install py)

----------
components: Library (Lib)
messages: 334094
nosy: brett.cannon, eric.snow, ncoghlan, ronaldoussoren
priority: normal
severity: normal
status: open
title: Unexpected exception with importlib
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35791>
_______________________________________

From report at bugs.python.org  Sun Jan 20 12:40:21 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Jan 2019 17:40:21 +0000
Subject: [issue35791] Unexpected exception with importlib
In-Reply-To: <1548005903.93.0.648072616722.issue35791@roundup.psfhosted.org>
Message-ID: <1548006021.94.0.807960607466.issue35791@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This might be a bug in "py", which uses a vendored version of apipkg that replaces sys.modules["py"] with a lazy loading object. That copy of apipkg does not copy __spec__ into the lazy loading object.

If this is indeed consider to be a bug in py I'll file an issue with them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35791>
_______________________________________

From report at bugs.python.org  Sun Jan 20 13:22:25 2019
From: report at bugs.python.org (Jens Troeger)
Date: Sun, 20 Jan 2019 18:22:25 +0000
Subject: [issue34424] Unicode names break email header
In-Reply-To: <1534546922.5.0.56676864532.issue34424@psf.upfronthosting.co.za>
Message-ID: <1548008545.26.0.0694565047583.issue34424@roundup.psfhosted.org>


Jens Troeger <jens.troeger at gmail.com> added the comment:

Can somebody please review and merge https://github.com/python/cpython/pull/8803 ? I am still waiting for this fix the become mainstream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34424>
_______________________________________

From report at bugs.python.org  Sun Jan 20 13:47:44 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Jan 2019 18:47:44 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548010064.63.0.248403688757.issue35699@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset b2dc4a3313c236fedbd6df664722cd47f3d91a72 by Ned Deily (Marc Schlaich) in branch 'master':
bpo-35699: fix distuils cannot detect Build Tools 2017 anymore (GH-11495)
https://github.com/python/cpython/commit/b2dc4a3313c236fedbd6df664722cd47f3d91a72


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sun Jan 20 13:48:01 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Jan 2019 18:48:01 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548010081.92.0.532729236205.issue35699@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11389

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sun Jan 20 13:48:13 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Jan 2019 18:48:13 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548010093.22.0.0700785289193.issue35699@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11389, 11390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sun Jan 20 13:48:26 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Jan 2019 18:48:26 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548010106.0.0.750516990985.issue35699@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11389, 11390, 11391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sun Jan 20 14:00:37 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 19:00:37 +0000
Subject: [issue32603] Deprecation warning on strings used in re module
In-Reply-To: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>
Message-ID: <1548010837.38.0.370236578335.issue32603@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Sun Jan 20 14:06:10 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Jan 2019 19:06:10 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548011170.8.0.164579771394.issue35699@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2fa53cfa8960f4bcb36718da4424e980fc305ef5 by Miss Islington (bot) in branch '3.7':
bpo-35699: fix distuils cannot detect Build Tools 2017 anymore (GH-11495)
https://github.com/python/cpython/commit/2fa53cfa8960f4bcb36718da4424e980fc305ef5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Sun Jan 20 15:41:47 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 20:41:47 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1548016907.16.0.3262192043.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have updated the PR to receive a dictionary of sets as in Eric V. Smith's package. I have maintained the guts of the current algorithm as it scales much better:

>>> test_data = {x:{x+n for n in range(100)} for x in range(1000)}

>>> %timeit list(toposort.toposort(l)) # The one in PyPi
910 ms ? 2.1 ms per loop (mean ? std. dev. of 7 runs, 1 loop each)

>>> %timeit list(functools.toposort(l)) # In this PR

69.3 ms ? 280 ?s per loop (mean ? std. dev. of 7 runs, 10 loops each)

>>> list(functools.toposort(l)) == list(toposort.toposort(l))
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 20 15:42:38 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 20:42:38 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1548016958.92.0.0561692386438.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have updated the PR to receive a dictionary of sets as in Eric V. Smith's package. I have maintained the guts of the current algorithm as it scales much better:

>>> test_data = {x:{x+n for n in range(100)} for x in range(1000)}

>>> %timeit list(toposort.toposort(test_data)) # The one in PyPi
910 ms ? 2.1 ms per loop (mean ? std. dev. of 7 runs, 1 loop each)

>>> %timeit list(functools.toposort(test_data)) # In this PR

69.3 ms ? 280 ?s per loop (mean ? std. dev. of 7 runs, 10 loops each)

>>> list(functools.toposort(l)) == list(toposort.toposort(l))
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 20 15:43:00 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 20:43:00 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1548016958.92.0.0561692386438.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have updated the PR to receive a dictionary of sets as in Eric V. Smith's package. I have maintained the guts of the current algorithm as it scales much better:

>>> test_data = {x:{x+n for n in range(100)} for x in range(1000)}

>>> %timeit list(toposort.toposort(test_data)) # The one in PyPi
910 ms ? 2.1 ms per loop (mean ? std. dev. of 7 runs, 1 loop each)

>>> %timeit list(functools.toposort(test_data)) # In this PR

69.3 ms ? 280 ?s per loop (mean ? std. dev. of 7 runs, 10 loops each)

>>> list(functools.toposort(l)) == list(toposort.toposort(l))
True

----------
Removed message: https://bugs.python.org/msg334099

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 20 16:11:48 2019
From: report at bugs.python.org (Oscar Benjamin)
Date: Sun, 20 Jan 2019 21:11:48 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <20190119063036.GR13616@ando.pearwood.info>
Message-ID: <CAHVvXxQFLpafZ+u5uyw-mN3OK=zfV7Y_CcgB9prOsrTDHZadcA@mail.gmail.com>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

> I would find it very helpful if somebody has time to do a survey of
> other statistics libraries or languages (e.g. numpy, R, Octave, Matlab,
> SAS etc) and see how they handle data with weights.

Numpy has only sporadic support for this. The standard mean function
does not have any way to provide weights but there is an alternative
called average that computes the mean and has an optional weights
argument. I've never heard of average before searching for "numpy
weighted mean" just now. Numpy's API often has bits of old cruft from
where various numerical packages were joined together so I'm not sure
they would recommend their current approach. I don't think there are
any other numpy functions for providing weighted statistics.

Statsmodels does provide an API for this as explained here:
https://stackoverflow.com/a/36464881/9450991
Their API is that you create an object with data and weights and can
then call methods/attributes for statistics.

Matlab doesn't support even weighted mean as far as I can tell. There
is wmean on the matlab file exchange:

>
> - what APIs do they provide?
> - do they require weights to be positive integers, or do they
>   support arbitrary float weights?
> - including negative weights?
>   (what physical meaning does a negative weight have?)
>
> At the moment, a simple helper function seems to do the trick for
> non-negative integer weights:
>
> def flatten(items):
>     for item in items:
>         yield from item
>
> py> data = [1, 2, 3, 4]
> py> weights = [1, 4, 1, 2]
> py> statistics.mean(flatten([x]*w for x, w in zip(data, weights)))
> 2.5
>
> In principle, the implementation could be as simple as a single
> recursive call:
>
> def mean(data, weights=None):
>     if weights is not None:
>         return mean(flatten([x]*w for x, w in zip(data, weights)))
>     # base case without weights is unchanged
>
> or perhaps it could be just a recipe in the docs.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue20479>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sun Jan 20 16:17:11 2019
From: report at bugs.python.org (Oscar Benjamin)
Date: Sun, 20 Jan 2019 21:17:11 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <CAHVvXxQFLpafZ+u5uyw-mN3OK=zfV7Y_CcgB9prOsrTDHZadcA@mail.gmail.com>
Message-ID: <CAHVvXxQQBaH2FKrSoc+=aoCS7+VjhWU+J11jpRKWzqvw6Z8z-w@mail.gmail.com>


Oscar Benjamin <oscar.j.benjamin at gmail.com> added the comment:

Sorry, sent too soon...

> Matlab doesn't support even weighted mean as far as I can tell. There
> is wmean on the matlab file exchange:
https://stackoverflow.com/a/36464881/9450991

This is a separate function `wmean(data, weights)`. It has to be a
separate function though because it's third party code so the author
couldn't change the main mean function.

R ships with a weighted.mean function but I think for standard
deviation you need third party libs.

A quick survey but the main impression I get is that providing API for
this is not that common. The only good-looking API is the statsmodel
one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Sun Jan 20 16:34:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 21:34:03 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1548020043.01.0.853766669534.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Although I think the API with the dictionary may be cleaner, I still do not like it completely.

1) One of the reasons is that implementing C3 directly with the topological sort is not straightforward as the different nodes that are at the same level are unordered and therefore any permutation of all these is a valid topological sort, while C3 comes from a stable sort. The version with pairs is stable on the other hand.

2) Topological sorting usually is well-defined on totally connected graphs, so I do not know what exactly it means to topologically sort two disjoint graphs. This was one of the main drawbacks of the tuple-based approach, but I think it may be a good property.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 20 16:42:33 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 20 Jan 2019 21:42:33 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1548020553.9.0.195786959369.issue17005@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

> 2) Topological sorting usually is well-defined on totally connected graphs, so I do not know what exactly it means to topologically sort two disjoint graphs. This was one of the main drawbacks of the tuple-based approach, but I think it may be a good property.

To give a use-case, I'm currently using topological sort to order a list of tasks where edges represent dependencies between tasks. Sometime a group of tasks does not share a dependency with another group any relative order between those two groups is correct:


A -> B

   C
  / \
 D   E
  \ /
   F

The order (A, B, C, D, E, F) would be correct in this example as would (C, A, E, B, D, F).

I think the general topological sort in Python should be able to handle such inputs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 20 16:43:41 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 21:43:41 +0000
Subject: [issue28607] C implementation of parts of copy.deepcopy
In-Reply-To: <1478214696.15.0.845599612142.issue28607@psf.upfronthosting.co.za>
Message-ID: <1548020621.06.0.37004234009.issue28607@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hy Rasmus,

would you like to make a PR with your patch and adding some tests?

Thanks!

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28607>
_______________________________________

From report at bugs.python.org  Sun Jan 20 17:04:15 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 22:04:15 +0000
Subject: [issue35786] get_lock() method is not present for Values created
 using multiprocessing.Manager()
In-Reply-To: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org>
Message-ID: <1548021855.98.0.884594362447.issue35786@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

You are not using multiprocessing.Value:

>>> import multiprocessing
>>> x = multiprocessing.Value("i", 0)
>>> x.get_lock()
<RLock(None, 0)>

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35786>
_______________________________________

From report at bugs.python.org  Sun Jan 20 17:43:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Jan 2019 22:43:24 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1548024204.09.0.361516142196.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

(A, B, C, D, E, F) would not be correct as B is order 2 and "C" and "A" is order 1. The correct orders are the inner-group permutations of:

[{'A', 'F'}, {'B', 'D', 'E'}, {'C'}]

(Assuming that the lower diagram goes from top to bottom)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 20 18:18:14 2019
From: report at bugs.python.org (Matej Cepl)
Date: Sun, 20 Jan 2019 23:18:14 +0000
Subject: [issue34656] memory exhaustion in Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548026294.0.0.00509030087283.issue34656@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

Does it even make sense to make a security patch for 2.7 for this one?

----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Sun Jan 20 18:47:31 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 20 Jan 2019 23:47:31 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548028051.47.0.279183297624.issue35722@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Sun Jan 20 18:49:17 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 20 Jan 2019 23:49:17 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548028157.09.0.0874323999143.issue35722@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Sun Jan 20 21:13:46 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 02:13:46 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1548036826.02.0.308030392702.issue35378@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +11392

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Sun Jan 20 21:13:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 02:13:57 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1548036837.53.0.710131264506.issue35378@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +11392, 11393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Sun Jan 20 21:14:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 02:14:07 +0000
Subject: [issue35378] multiprocessing.Pool.imaps iterators do not maintain
 alive the multiprocessing.Pool objects
In-Reply-To: <1543769012.57.0.788709270274.issue35378@psf.upfronthosting.co.za>
Message-ID: <1548036847.74.0.386797215438.issue35378@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +11392, 11393, 11394

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35378>
_______________________________________

From report at bugs.python.org  Sun Jan 20 21:34:39 2019
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 21 Jan 2019 02:34:39 +0000
Subject: [issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily
In-Reply-To: <1542822100.42.0.788709270274.issue35292@psf.upfronthosting.co.za>
Message-ID: <1548038079.91.0.580996106371.issue35292@roundup.psfhosted.org>


Change by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35292>
_______________________________________

From report at bugs.python.org  Sun Jan 20 21:59:19 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Mon, 21 Jan 2019 02:59:19 +0000
Subject: [issue35792] Specifying AbstractEventLoop.run_in_executor as a
 coroutine conflicts with implementation/intent
Message-ID: <1548039558.68.0.986540752255.issue35792@roundup.psfhosted.org>


New submission from Christopher Hunt <chrahunt at gmail.com>:

Currently AbstractEventLoop.run_in_executor is specified as a coroutine, while BaseEventLoop.run_in_executor is actually a non-coroutine that returns a Future object. The behavior of BaseEventLoop.run_in_executor would be significantly different if changed to align with the interface . If run_in_executor is a coroutine then the provided func will not actually be scheduled until the coroutine is awaited, which conflicts with the statement in PEP 3156 that it "is equivalent to `wrap_future(executor.submit(callback, *args))`".

There has already been an attempt in bpo-32327 to convert this function to a coroutine. We should change the interface specified in `AbstractEventLoop` to indicate that `run_in_executor` is not a coroutine, which should help ensure it does not get changed in the future without full consideration of the impacts.

----------
components: asyncio
messages: 334109
nosy: asvetlov, chrahunt, yselivanov
priority: normal
severity: normal
status: open
title: Specifying AbstractEventLoop.run_in_executor as a coroutine conflicts with implementation/intent
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35792>
_______________________________________

From report at bugs.python.org  Sun Jan 20 23:32:30 2019
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 21 Jan 2019 04:32:30 +0000
Subject: [issue20582] socket.getnameinfo() does not document flags
In-Reply-To: <1392042265.22.0.885252016144.issue20582@psf.upfronthosting.co.za>
Message-ID: <1548045150.47.0.0070050556537.issue20582@roundup.psfhosted.org>


Change by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20582>
_______________________________________

From report at bugs.python.org  Sun Jan 20 23:51:43 2019
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 21 Jan 2019 04:51:43 +0000
Subject: [issue20582] socket.getnameinfo() does not document flags
In-Reply-To: <1392042265.22.0.885252016144.issue20582@psf.upfronthosting.co.za>
Message-ID: <1548046303.7.0.102497556745.issue20582@roundup.psfhosted.org>


Demian Brecht <demianbrecht at gmail.com> added the comment:

What if the docs for socket functions that took system-level flag parameters had links to relevant online man pages? I don't think a single entry at the top of the page would be optimal. I know that I tend to skip the preamble and just go directly to the function I'm interested in.

I know that it's not a perfect solution because there's a good chance of those links going stale. I'm also relatively sure that we wouldn't want to have an exhaustive list. However, I think in this instance that /something/ would be better than nothing. Even if the link is stale or the target OS isn't included, it would give the reader a place to start, which is currently lacking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20582>
_______________________________________

From report at bugs.python.org  Sun Jan 20 23:59:19 2019
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 21 Jan 2019 04:59:19 +0000
Subject: [issue12707] Deprecate addinfourl getters
In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za>
Message-ID: <1548046759.26.0.106289342281.issue12707@roundup.psfhosted.org>


Change by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 00:29:02 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Jan 2019 05:29:02 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548048542.18.0.723928325164.issue35780@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Mon Jan 21 00:30:55 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Jan 2019 05:30:55 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548048655.33.0.986261497435.issue35699@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Merged on behalf of Steve.  Thanks, Marc!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Mon Jan 21 00:49:51 2019
From: report at bugs.python.org (Mingun Pak)
Date: Mon, 21 Jan 2019 05:49:51 +0000
Subject: [issue35793] round() doesn't return the right value when I put 0.5 in
 it.
Message-ID: <1548049790.29.0.46389192028.issue35793@roundup.psfhosted.org>


New submission from Mingun Pak <kaienmg at gmail.com>:

It should be 1, but it returns 0.

----------
components: Library (Lib)
files: Screen Shot 2019-01-20 at 9.40.52 PM.png
messages: 334112
nosy: Mingun Pak
priority: normal
severity: normal
status: open
title: round() doesn't return the right value when I put 0.5 in it.
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48069/Screen Shot 2019-01-20 at 9.40.52 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35793>
_______________________________________

From report at bugs.python.org  Mon Jan 21 00:55:54 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 21 Jan 2019 05:55:54 +0000
Subject: [issue35793] round() doesn't return the right value when I put 0.5 in
 it.
In-Reply-To: <1548049790.29.0.46389192028.issue35793@roundup.psfhosted.org>
Message-ID: <1548050154.18.0.993128566727.issue35793@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Please read the documentation of round builtin function.
https://docs.python.org/3/library/functions.html#round

For the built-in types supporting round(), values are rounded to the closest multiple of 10 to the power minus ndigits; if two multiples are equally close, rounding is done toward the even choice (so, for example, both round(0.5) and round(-0.5) are 0, and round(1.5) is 2).

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35793>
_______________________________________

From report at bugs.python.org  Mon Jan 21 01:00:06 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Jan 2019 06:00:06 +0000
Subject: [issue35793] round() doesn't return the right value when I put 0.5 in
 it.
In-Reply-To: <1548049790.29.0.46389192028.issue35793@roundup.psfhosted.org>
Message-ID: <1548050406.35.0.832291650834.issue35793@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35793>
_______________________________________

From report at bugs.python.org  Mon Jan 21 01:06:21 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 21 Jan 2019 06:06:21 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548050781.39.0.0313837989539.issue35766@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Mon Jan 21 03:57:58 2019
From: report at bugs.python.org (Chris Withers)
Date: Mon, 21 Jan 2019 08:57:58 +0000
Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes
In-Reply-To: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>
Message-ID: <1548061078.68.0.226664539365.issue20239@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 222d303ade8aadf0adcae5190fac603bdcafe3f0 by Chris Withers (Pablo Galindo) in branch 'master':
bpo-20239: Allow repeated deletion of unittest.mock.Mock attributes (#11057)
https://github.com/python/cpython/commit/222d303ade8aadf0adcae5190fac603bdcafe3f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20239>
_______________________________________

From report at bugs.python.org  Mon Jan 21 03:58:19 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 08:58:19 +0000
Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes
In-Reply-To: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>
Message-ID: <1548061099.74.0.0614044619307.issue20239@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20239>
_______________________________________

From report at bugs.python.org  Mon Jan 21 03:58:27 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 08:58:27 +0000
Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes
In-Reply-To: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>
Message-ID: <1548061107.12.0.919078185204.issue20239@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11395, 11396

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20239>
_______________________________________

From report at bugs.python.org  Mon Jan 21 03:58:32 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 08:58:32 +0000
Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes
In-Reply-To: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>
Message-ID: <1548061112.85.0.53768542549.issue20239@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11395, 11396, 11397

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20239>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:24:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 09:24:23 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1548062663.84.0.354734600524.issue35772@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b2385458ceddaf3d0d91456923716259d3915023 by Victor Stinner in branch 'master':
bpo-35772: Fix test_tarfile on ppc64 (GH-11606)
https://github.com/python/cpython/commit/b2385458ceddaf3d0d91456923716259d3915023


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:24:30 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 09:24:30 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1548062670.19.0.125799730063.issue35772@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11398

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:24:35 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 09:24:35 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1548062675.76.0.710727637843.issue35772@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11398, 11399

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:31:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 09:31:46 +0000
Subject: [issue35425] test_eintr fails randomly on AMD64 FreeBSD 10-STABLE
 Non-Debug 3.7: TypeError: 'int' object is not callable
In-Reply-To: <1544099308.26.0.788709270274.issue35425@psf.upfronthosting.co.za>
Message-ID: <1548063106.92.0.446019757964.issue35425@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Another recent failure:

https://buildbot.python.org/all/#/builders/167/builds/488

...
test_kqueue (__main__.SelectEINTRTest) ... ok
test_poll (__main__.SelectEINTRTest) ... ok
test_select (__main__.SelectEINTRTest) ... test_all (test.test_eintr.EINTRTests) ... 
--- run eintr_tester.py ---
--- eintr_tester.py completed: exit code -14 ---
FAIL

======================================================================
FAIL: test_all (test.test_eintr.EINTRTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test_eintr.py", line 31, in test_all
    self.fail("eintr_tester.py failed")
AssertionError: eintr_tester.py failed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35425>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:37:58 2019
From: report at bugs.python.org (Chris Withers)
Date: Mon, 21 Jan 2019 09:37:58 +0000
Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes
In-Reply-To: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>
Message-ID: <1548063478.2.0.601163927036.issue20239@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset d358a8cda75446a8e0b5d99149f709395d5eae19 by Chris Withers (Miss Islington (bot)) in branch '3.7':
bpo-20239: Allow repeated deletion of unittest.mock.Mock attributes (GH-11629)
https://github.com/python/cpython/commit/d358a8cda75446a8e0b5d99149f709395d5eae19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20239>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:39:37 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Jan 2019 09:39:37 +0000
Subject: [issue35168] shlex punctuation_chars inconsistency
In-Reply-To: <1541439134.06.0.788709270274.issue35168@psf.upfronthosting.co.za>
Message-ID: <1548063577.6.0.595318831474.issue35168@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11400
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35168>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:39:49 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Jan 2019 09:39:49 +0000
Subject: [issue35168] shlex punctuation_chars inconsistency
In-Reply-To: <1541439134.06.0.788709270274.issue35168@psf.upfronthosting.co.za>
Message-ID: <1548063589.06.0.857024992657.issue35168@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11400, 11401
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35168>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:40:00 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Jan 2019 09:40:00 +0000
Subject: [issue35168] shlex punctuation_chars inconsistency
In-Reply-To: <1541439134.06.0.788709270274.issue35168@psf.upfronthosting.co.za>
Message-ID: <1548063600.79.0.674243094902.issue35168@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11400, 11401, 11402
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35168>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:40:09 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Jan 2019 09:40:09 +0000
Subject: [issue35168] shlex punctuation_chars inconsistency
In-Reply-To: <1541439134.06.0.788709270274.issue35168@psf.upfronthosting.co.za>
Message-ID: <1548063609.67.0.588033177806.issue35168@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11400, 11401, 11402, 11403
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35168>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:44:33 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 09:44:33 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1548063873.82.0.361108561604.issue35772@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d1dd6be613381b996b9071443ef081de8e5f3aff by Miss Islington (bot) in branch '3.7':
bpo-35772: Fix test_tarfile on ppc64 (GH-11606)
https://github.com/python/cpython/commit/d1dd6be613381b996b9071443ef081de8e5f3aff


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Mon Jan 21 04:45:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 09:45:45 +0000
Subject: [issue35772] test_tarfile fails on ppc64le when using tmpfs filesystem
In-Reply-To: <1547810144.05.0.534595171139.issue35772@roundup.psfhosted.org>
Message-ID: <1548063945.42.0.0800321522389.issue35772@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35772>
_______________________________________

From report at bugs.python.org  Mon Jan 21 05:15:44 2019
From: report at bugs.python.org (Yuuji KAWAMATSU)
Date: Mon, 21 Jan 2019 10:15:44 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548065744.26.0.749911359748.issue35781@roundup.psfhosted.org>


Yuuji KAWAMATSU <kawamatsu_yuuji at kurusugawa.jp> added the comment:

Thank you!
I will create PR.

----------
nosy: +Yuuji KAWAMATSU

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Mon Jan 21 05:33:01 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 10:33:01 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548066781.25.0.445344491252.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

To avoid code duplication, it's tempting to merge _PyTime_FromObject and _PyTime_ObjectToDenominator

These two functions almost do the same, but not quite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 05:41:51 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 21 Jan 2019 10:41:51 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548067311.71.0.644768941704.issue35707@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

As a late response to msg333416 and msg333547, I don't agree with looking at __index__ in _PyTime_FromObject.  

The __index__ method is used when an object can be used as the index for a sequence, but should not silently convert to int or float.  See <https://www.python.org/dev/peps/pep-0357/>.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 05:48:34 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 10:48:34 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548067714.77.0.445921593222.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

The motivation for PEP 357 was certainly using an object as the index for a sequence, but that's not the only use case.

In fact PEP 357 states "For example, the slot can be used any time Python requires an integer internally"

So despite the name __index__, I think that this is now the de facto standard for "convert the object (which is some kind of integer) to a Python int without loss of precision".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 05:53:46 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 10:53:46 +0000
Subject: [issue35794] test_posix.py test failure
Message-ID: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

This test was recently added (PR 6332):

    def test_no_such_executable(self):
        no_such_executable = 'no_such_executable'
        try:
            pid = posix.posix_spawn(no_such_executable,
                                    [no_such_executable],
                                    os.environ)
        except FileNotFoundError as exc:
            self.assertEqual(exc.filename, no_such_executable)

On my system, it fails with

    PermissionError: [Errno 13] Permission denied: 'no_such_executable'

----------
messages: 334123
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: test_posix.py test failure

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 05:54:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 10:54:17 +0000
Subject: [issue35795] test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x
 and AMD64 Windows7 SP1 3.7 buildbots
Message-ID: <1548068055.8.0.250041418477.issue35795@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x and AMD64 Windows7 SP1 3.7 buildbots:

https://buildbot.python.org/all/#/builders/40/builds/1525
https://buildbot.python.org/all/#/builders/130/builds/636


======================================================================
ERROR: test_create_archive_filter_exclude_dir (test.test_zipapp.ZipAppTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\tempfile.py", line 806, in cleanup
    _shutil.rmtree(self.name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 681, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 569, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 567, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpe1ubc15t'
======================================================================
ERROR: test_create_archive_with_compression (test.test_zipapp.ZipAppTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\tempfile.py", line 806, in cleanup
    _shutil.rmtree(self.name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 681, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 569, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 567, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp5wemewtr'
======================================================================
ERROR: test_main_only_written_once (test.test_zipapp.ZipAppTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\tempfile.py", line 806, in cleanup
    _shutil.rmtree(self.name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 681, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 569, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 567, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp3am6ham9'
======================================================================
ERROR: test_main_written (test.test_zipapp.ZipAppTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\tempfile.py", line 806, in cleanup
    _shutil.rmtree(self.name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 681, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 569, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 567, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpyg_dqrb3'
----------------------------------------------------------------------

I have rebuilt older commits that succeded and they now fail, which points to a failure in the builder itself. These builders are on the same machine:

kloth-win64

----------
components: Tests
messages: 334124
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_pkgutil test_zipapp  fail in AMD64 Windows7 SP1 3.x and AMD64 Windows7 SP1 3.7 buildbots
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35795>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:04:25 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 21 Jan 2019 11:04:25 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548068665.86.0.891090931149.issue35707@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Using __index__ here doesn't feel right, although I can't explain why yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:07:13 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:07:13 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548068833.57.0.706679815823.issue35794@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hi,

Thank you for opening the issue. Without providing more information we cannot help debugging the issue. Can you provide more information like what is your system, What OS, version of python, architecture...etc

Is the only test that fails?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:07:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:07:21 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548068841.48.0.819944024642.issue35794@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:10:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:10:03 +0000
Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes
In-Reply-To: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za>
Message-ID: <1548069003.54.0.109143132904.issue20239@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20239>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:17:24 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 11:17:24 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548069444.18.0.750940711431.issue35794@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

It's a relatively old Gentoo GNU/Linux system:

Linux tamiyo 3.17.7-gentoo #2 SMP PREEMPT Fri Dec 23 18:13:49 CET 2016 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux

The problem occurs when there are directories on $PATH which are not accessible. For example, I can reproduce this as follows:

$ env PATH="/root" no_such_executable
env: no_such_executable: Permission denied

> Is the only test that fails?

At least it's the only test related to posix_spawnp() which fails.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:19:22 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 11:19:22 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548069562.29.0.0285064061378.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

If __index__ doesn't "feel" right, what do you propose then to fix this issue, keeping in mind the concerns of https://bugs.python.org/issue35707#msg333401

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:22:58 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 11:22:58 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548069778.84.0.764942177848.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

In other words: if we can only use __float__ and __int__, how do we know which one to use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:25:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:25:18 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548069918.86.0.346905875066.issue35794@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think that test should check for PermissionError as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:25:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:25:43 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548069943.55.0.154061241094.issue35794@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:30:32 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 11:30:32 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548070232.6.0.664868005674.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> If we want to support other numerical types with loss in double rounding

Looking at the existing code, I can already see several double-rounding "bugs" in the code, so I wouldn't be too much concerned here...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:31:02 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:31:02 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548070262.92.0.734112269435.issue35794@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +11404
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:31:09 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:31:09 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548070269.03.0.201338819742.issue35794@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11404, 11405
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:31:13 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 11:31:13 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548070273.71.0.308919475884.issue35794@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11404, 11405, 11406
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:32:21 2019
From: report at bugs.python.org (Mba)
Date: Mon, 21 Jan 2019 11:32:21 +0000
Subject: [issue35796] time.localtime returns error for negative values
Message-ID: <1548070339.94.0.0791021620364.issue35796@roundup.psfhosted.org>


New submission from Mba <mba.ogolny at gmail.com>:

Steps to reproduce the bug:
```
>>> import sys
>>> sys.version
'3.6.7 (v3.6.7:6ec5cf24b7, Oct 20 2018, 13:35:33) [MSC v.1900 64 bit (AMD64)]'

>>> import datetime
>>> print(datetime.datetime.now().astimezone().tzinfo)
datetime.timezone(datetime.timedelta(0, 3600), 'Central European Standard Time')

>>> import time
>>> time.localtime(0)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
>>> time.localtime(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
```

On Ubuntu it works fine:
```
>>> time.localtime(-1)
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=59, tm_sec=59, tm_wday=3, tm_yday=1, tm_isdst=0)
```

----------
components: Windows
messages: 334132
nosy: mba, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: time.localtime returns error for negative values
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35796>
_______________________________________

From report at bugs.python.org  Mon Jan 21 06:42:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 11:42:35 +0000
Subject: [issue35796] time.localtime returns error for negative values
In-Reply-To: <1548070339.94.0.0791021620364.issue35796@roundup.psfhosted.org>
Message-ID: <1548070955.1.0.714149098539.issue35796@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

It's a limitation of the Windows C library. I'm quite sure that Python 2 has a the same issue, it shouldn't be a regression.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35796>
_______________________________________

From report at bugs.python.org  Mon Jan 21 07:56:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 12:56:17 +0000
Subject: [issue35795] test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x
 and AMD64 Windows7 SP1 3.7 buildbots
In-Reply-To: <1548068055.8.0.250041418477.issue35795@roundup.psfhosted.org>
Message-ID: <1548075377.48.0.385639620068.issue35795@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Old fixed rmtree issue: bpo-22022, bpo-30334.

This one is different. tempfile calls shutil.rmtree(). The test doesn't call rmtree() directly.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35795>
_______________________________________

From report at bugs.python.org  Mon Jan 21 08:08:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 13:08:45 +0000
Subject: [issue34814] makesetup: must link C extensions to libpython when
 compiled in shared mode
In-Reply-To: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>
Message-ID: <1548076125.56.0.402888401395.issue34814@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Another Fedora on Python2:
https://bugzilla.redhat.com/show_bug.cgi?id=1667914

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34814>
_______________________________________

From report at bugs.python.org  Mon Jan 21 08:27:13 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 21 Jan 2019 13:27:13 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548077233.34.0.30519744952.issue35707@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

> In other words: if we can only use __float__ and __int__, how do we know which one to use?

I guess __index__. I've read the definition of object.__index__ in the data model documentation, and using __index__ for this conversion is fine. I need to educate my sense for when it's right to use this method...

Sorry about the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 08:47:19 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 13:47:19 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548078439.22.0.607112729953.issue35707@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +11407

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 08:47:34 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 13:47:34 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548078454.9.0.856043635199.issue35707@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +11407, 11408

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 08:47:50 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 13:47:50 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548078470.34.0.913511543142.issue35707@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +11407, 11408, 11409

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 21 08:55:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 13:55:49 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548078949.43.0.388878902559.issue35794@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

To be clear, only os.posix_spawnp() (with "P") fails:

$ PATH=/root ./python -m test -v test_posix 
...
ERROR: test_no_such_executable (test.test_posix.TestPosixSpawnP)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_posix.py", line 1522, in test_no_such_executable
    pid = self.spawn_func(no_such_executable,
PermissionError: [Errno 13] Permission denied: 'no_such_executable'


Test with os.posix_spawn() is fine:

$ PATH=/root ./python -m test -v test_posix -m test.test_posix.TestPosixSpawn.test_no_such_executable
...
test_no_such_executable (test.test_posix.TestPosixSpawn) ... ok
...
Tests result: SUCCESS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 09:00:29 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 14:00:29 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548079229.85.0.144183235745.issue35794@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Test with os.posix_spawn() is fine:

Indeed, the difference between posix_spawn() and posix_spawnp() is that only the latter uses $PATH to look up the executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 09:34:58 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 21 Jan 2019 14:34:58 +0000
Subject: [issue34294] re module: wrong capturing groups
In-Reply-To: <1533042665.14.0.56676864532.issue34294@psf.upfronthosting.co.za>
Message-ID: <1548081298.41.0.259852391421.issue34294@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Original post's bug was introduced in Python 3.7.0

When investigate the code, I found another bug about capturing groups. This bug exists since very early version.
regex module doesn't have this bug.

Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32 bit (Intel)] on win32
>>> import re
>>> re.search(r"\b(?=(\t)|(x))x", "a\tx").groups()
('', 'x')

Expected result: (None, 'x')

Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
>>> import regex
>>> regex.search(r"\b(?=(\t)|(x))x", "a\tx").groups()
(None, 'x')

----------
title: re.finditer and lookahead bug -> re module: wrong capturing groups

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34294>
_______________________________________

From report at bugs.python.org  Mon Jan 21 09:35:45 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 14:35:45 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548081345.93.0.673223042555.issue35794@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset e9b185f2a493cc54f0d49eac44bf21e8d7de2990 by Pablo Galindo in branch 'master':
bpo-35794: Catch PermissionError in test_no_such_executable (GH-11635)
https://github.com/python/cpython/commit/e9b185f2a493cc54f0d49eac44bf21e8d7de2990


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 09:36:00 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 14:36:00 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548081360.76.0.641344668184.issue35794@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 09:36:18 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 21 Jan 2019 14:36:18 +0000
Subject: [issue19660] decorator syntax: allow testlist instead of just
 dotted_name
In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za>
Message-ID: <1548081378.16.0.639768617847.issue19660@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

There is again some discussion about this at https://discuss.python.org/t/why-are-some-expressions-syntax-errors/420

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19660>
_______________________________________

From report at bugs.python.org  Mon Jan 21 10:10:42 2019
From: report at bugs.python.org (Christian Ullrich)
Date: Mon, 21 Jan 2019 15:10:42 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
Message-ID: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>


New submission from Christian Ullrich <chris at chrullrich.net>:

Using concurrent.futures.ProcessPoolExecutor on Windows fails immediately with a lot of exceptions of the "access denied", "file not found", and "invalid handle" varieties. Running the script that creates the ProcessPoolExecutor from the main system-wide installation works correctly.

Due to Windows' infamous lack of fork(), ProcessPoolExecutor launches its worker processes by setting up an inheritable handle to a pipe and passing the handle on the command line.

In a venv situation, it appears that the venv's python.exe internally launches the parent environment's python.exe and passes on its command line, but not its handle table. This sub-subprocess therefore does not have the original handle, and may have a different handle at the same index.


Output of the ProcessPoolExecutor example program from the docs when run with the main installation:

C:\Daten>py cft.py
112272535095293 is prime: True
112582705942171 is prime: True
112272535095293 is prime: True
115280095190773 is prime: True
115797848077099 is prime: True
1099726899285419 is prime: False


Output when run using a venv:

C:\Daten>pyv\v37\Scripts\python.exe cft.py
Process SpawnProcess-4:
Traceback (most recent call last):
  File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap
    self.run()
  File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker
    call_item = call_queue.get(block=True)
  File "C:\Program Files\Python37\lib\multiprocessing\queues.py", line 93, in get
    with self._rlock:
  File "C:\Program Files\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
PermissionError: [WinError 5] Access is denied
Process SpawnProcess-5:
Traceback (most recent call last):
  File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap
    self.run()
  File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker
    call_item = call_queue.get(block=True)
  File "C:\Program Files\Python37\lib\multiprocessing\queues.py", line 93, in get
    with self._rlock:
  File "C:\Program Files\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__
    return self._semlock.__enter__()
PermissionError: [WinError 5] Access is denied
Traceback (most recent call last):
  File "cft.py", line 28, in <module>
    main()
  File "cft.py", line 24, in main
    for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
  File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 476, in _chain_from_iterable_of_lists
    for element in iterable:
  File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 586, in result_iterator
    yield fs.pop().result()
  File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 432, in result
    return self.__get_result()
  File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 384, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.

----------
assignee: docs at python
components: Documentation, Library (Lib), Windows
messages: 334142
nosy: chrullrich, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: concurrent.futures.ProcessPoolExecutor does not work in venv on Windows
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 10:13:47 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 21 Jan 2019 15:13:47 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
Message-ID: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>


New submission from Jakub Wilk <jwilk at jwilk.net>:

$ python3.8 -c 'if object() is 42: pass'
<string>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
<string>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?

I'd like only one copy of this warning, not two.

Tested with git master (e9b185f2a493cc54f0d49eac44bf21e8d7de2990).

----------
components: Interpreter Core
messages: 334143
nosy: jwilk, serhiy.storchaka
priority: normal
severity: normal
status: open
title: duplicate SyntaxWarning: "is" with a literal
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 10:18:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 15:18:50 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548083930.71.0.529422106846.issue35798@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The warning has been introduced by bpo-34850: commit 3bcbedc9f1471d957a30a90f9d1251516b422416.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 10:19:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 15:19:17 +0000
Subject: [issue34850] Emit a syntax warning for "is" with a literal
In-Reply-To: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>
Message-ID: <1548083957.23.0.975515604193.issue34850@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The warning is emited twice, see: bpo-35798.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Mon Jan 21 10:27:56 2019
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 21 Jan 2019 15:27:56 +0000
Subject: [issue35795] test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x
 and AMD64 Windows7 SP1 3.7 buildbots
In-Reply-To: <1548068055.8.0.250041418477.issue35795@roundup.psfhosted.org>
Message-ID: <1548084476.18.0.0341003725241.issue35795@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

This is an old, but recurring issue with Windows and directory tree removal: see issue15496

Basically, for stable (Windows) buildbots, directory tree removal needs to go through support.rmtree, not any of the stdlib methods for doing so.  In a nutshell, the tests need to be changed to do this.  Or, I suppose, we finally bite the bullet and incorporate the support.rmtree logic into the stdlib somehow.

In other words, the buildbot is fine, the tests are broken.

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35795>
_______________________________________

From report at bugs.python.org  Mon Jan 21 10:31:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Jan 2019 15:31:56 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1547547794.3.0.264188583687.issue35633@roundup.psfhosted.org>
Message-ID: <22EC78DF-EF61-4382-BACF-0306988023F3@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Done.

> On 1/15/2019 11:23 AM, STINNER Victor wrote:
> I would prefer to simply skip the lockf() test rather than ignoring PermissionError for flock() and lockf() on all platforms. Can you please write a PR for that?
> 
> There is no need to add a NEWS entry, I will add "skip news". If you want to add a NEWS entry, mention at least the fixed test and AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35633>
_______________________________________

From report at bugs.python.org  Mon Jan 21 11:39:08 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Jan 2019 16:39:08 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1548088748.33.0.528106113542.issue35788@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is documented as deprecated, but only in the 'seealso' note at the top.  I think it would be reasonable to open an issue to add an actual 'deprecated' ReST tag to the docs.

For your 1 and 2, the stdlib smtpd forwarding is also blocking; that code appears to be copied verbatim from stdlib smtpd.  It needs to be replaced with calls to aiosmtplib.  Feel free to submit a PR :)

For your 3, that design is so that you can run the smtpd server as part of a non-asyncio application (eg: for testing, which has always been the main purpose of this module).  For an asyncio-only application you would not use a Controller (unless you wanted to offload the smtp traffic to a different thread, of course, then it would be useful :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Mon Jan 21 11:46:55 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Mon, 21 Jan 2019 16:46:55 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1548089215.18.0.0959041409496.issue35788@roundup.psfhosted.org>


Samuel Colvin <samcolvin at gmail.com> added the comment:

Thanks for the response.

I've created issues on aiosmtpd for both these things. There are much better ways of running the controller than threading, but that's a discussion for https://github.com/aio-libs/aiosmtpd/issues/160. I'll try and work on aiosmtpd in the future.

Regarding smtpd, please could you respond to:

> More generally I understand the idea of deprecated code that doesn't get updated to conform to latest conventions, but surely if the code exists in the standard lib. it should at least work as it was originally intended or be removed?

Of course, I know part of this is my wish to get my PR merged into cpython, but I really don't see any argument for leaving completely broken code in the standard library.

Surely either it should be removed before the next minor release or fixed?

I would say PureProxy could still be useful and should be left in place while MailmanProxy should be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Mon Jan 21 11:54:00 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 16:54:00 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548089640.94.0.77469224675.issue35699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

There is one buildbot (https://buildbot.python.org/all/#builders/40/builds/1524) that started randomly failing unrelated tests with this change - usually one of zipapp, pkgutil, or zipimport. I don't have any idea what the relationship here is, unless the distutils tests have stopped skipping on those machines and are affecting some sort of global state (which they shouldn't, and the other tests shouldn't be relying on, but here we are).

I haven't looked at the actual tests (from my phone) yet. Anyone have any better ideas?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:01:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 17:01:26 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548090086.66.0.734398413005.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Good catch! I'm surprised we don't have any tests for this, but I guess we don't really create any virtual environments in our test suite. A shame nobody hit it during RC.

I don't actually know the best fix for this. The venv python.exe script is the same as the py.exe launcher, which means neither is passing on inherited handles. Any ideas?

----------
assignee: docs at python -> 
components:  -Documentation
keywords: +3.7regression
nosy: +davin, eryksun, ned.deily, pitrou -docs at python
priority: normal -> release blocker
stage:  -> test needed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:06:59 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Jan 2019 17:06:59 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1548090419.01.0.521229717936.issue35788@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The mailman proxy has been abandoned for a long time now, so no fixes there.  I have some sympathy to fixing PureProxy, but since the stdlib itself doesn't use it, not a lot :)

At some point we will start cleaning up old code (probably a while after 2.7 is dead) after going through a release-deprecation-cycle, but that time hasn't arrived yet.  smtpd itself will stay because the stdlib test suite uses it, but you are right that MailmanProxy can be removed, as well as PrueProxy if we don't fix it.

We are not in general going to fix bugs in it that don't impact the stdlib itself, but if Barry (or someone else) wants to review and accept the PureProxy PR that's fine with me.  I don't myself have time to review it, I'm afraid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:08:24 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Mon, 21 Jan 2019 17:08:24 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1548090504.52.0.666684600817.issue35788@roundup.psfhosted.org>


Samuel Colvin <samcolvin at gmail.com> added the comment:

Ok. Thanks for your explanation. Makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:10:52 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jan 2019 17:10:52 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548090652.06.0.515305686127.issue35797@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm... Out of curiosity, why is the venv's python.exe not simply a symlink to the original python.exe?  What is the point of going through py.exe here?

Also, is this a regression? Otherwise I don't think it has to be a release blocker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:10:54 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Jan 2019 17:10:54 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1548090654.85.0.355477933481.issue35788@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, thinking about it some more, you are right.  If PureProxy doesn't at least function according to the current docs it should either be fixed or we should deprecate-and-remove it in 3.8 or 3.9 (depending on how strongly people feel about the deprecation cycle), and we should remove MailmanProxy.  Feel free to open new, targeted issues for these.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:25:16 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Mon, 21 Jan 2019 17:25:16 +0000
Subject: [issue35799] fix or remove smtpd.PureProxy
Message-ID: <1548091515.27.0.738178577175.issue35799@roundup.psfhosted.org>


New submission from Samuel Colvin <samcolvin at gmail.com>:

smtpd.PureProxy.process_message is defined to not receive the extra kwargs which it is called with.

It also expects "data" to be str when it's actually bytes.

PureProxy should either be removed for fixed. 

Personally, I think it should be fixed as the fix is pretty simple and PureProxy can be very useful.

Created from https://bugs.python.org/issue35788

Happy to create a PR if this is agreed.

----------
components: email
messages: 334156
nosy: barry, r.david.murray, samuelcolvin
priority: normal
severity: normal
status: open
title: fix or remove smtpd.PureProxy
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/issue35799>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:27:12 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Mon, 21 Jan 2019 17:27:12 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
Message-ID: <1548091630.84.0.140233087609.issue35800@roundup.psfhosted.org>


New submission from Samuel Colvin <samcolvin at gmail.com>:

smtpd.MailmanProxy is completely broken, it takes the wrong arguments but also assumes the existence of a "Mailman" module which doesn't exist.

It should be removed in 3.8 or 3.9.

Created from https://bugs.python.org/issue35788

Happy to create a PR if this is agreed.

----------
components: email
messages: 334157
nosy: barry, r.david.murray, samuelcolvin
priority: normal
severity: normal
status: open
title: remove smtpd.MailmanProxy
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:28:18 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Mon, 21 Jan 2019 17:28:18 +0000
Subject: [issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra
 kwargs, bytes and more
In-Reply-To: <1547982873.85.0.188578370535.issue35788@roundup.psfhosted.org>
Message-ID: <1548091698.22.0.923680966881.issue35788@roundup.psfhosted.org>


Samuel Colvin <samcolvin at gmail.com> added the comment:

Great, https://bugs.python.org/issue35799 and https://bugs.python.org/issue35800 created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35788>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:46:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 17:46:08 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548092768.81.0.395902756265.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You can't create symlinks on Windows without additional user permissions, and the old method of copying most of the binaries was slow and made DLL hell worse, as well as simply not working with the Windows Store model that does not let random executables load DLLs from within the app.

Because of the last one, I backported the fix (which is an independent executable that launches the correct one with additional context to know it's a venv) that was mostly there for 3.8 already. This also fixes the issue where upgrading Python would force you to recreate every virtual environment to avoid mismatched binary versions (which is also why it wasn't an incompatible change - the update was already incompatible).

So all in all, an overall positive change. It's unfortunate that this problem slipped through testing, and I assume it's going to exist for many cases using handle inheritance. When I get a chance I'll be looking up ways to simply flag the new Python process it creates as "inherit everything", but there may be other data structures that don't transfer automatically (such as file descriptors, which the OS knows nothing about and can't do automatically).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 12:52:31 2019
From: report at bugs.python.org (Christopher Hunt)
Date: Mon, 21 Jan 2019 17:52:31 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548093151.05.0.621602383926.issue27035@roundup.psfhosted.org>


Change by Christopher Hunt <chrahunt at gmail.com>:


----------
nosy: +chrahunt
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:15:53 2019
From: report at bugs.python.org (jez)
Date: Mon, 21 Jan 2019 18:15:53 +0000
Subject: [issue35777] mismatched eval() and ast.literal_eval() behavior with
 unicode_literals
In-Reply-To: <1547846800.05.0.589923940496.issue35777@roundup.psfhosted.org>
Message-ID: <1548094553.76.0.712322563821.issue35777@roundup.psfhosted.org>


jez <jezhill at gmail.com> added the comment:

I take the point about breaking backward compatibility. The problem, then, is in the `ast` documentation, and may not be confined to Python 2.7

The `literal_eval` doc <https://docs.python.org/2/library/ast.html#ast-helpers> states no more than that the function evaluates a "string containing a Python literal".  The future statement effectively changes the definition of "a Python literal" but of course, as the official `__future__` doc <https://docs.python.org/2/reference/simple_stmts.html#future> explains, this is done for the compilation of each "particular module" in isolation. The question is left open whether the occurrence of this term in `ast` documentation should be read as "a Python literal (as defined by the ast module itself at compile time)",  or "a Python literal (as defined by the caller at compile time)".

More generally, future statements effectively change the definition of the term "Python syntax", sometimes also simply referred to as "Python".  Unfortunately, the `ast` documentation uses these terms loosely throughout, without acknowledging that they are mutable. I propose that the `ast` module documentation flag cases in which the `ast` module's own definitions of "Python" and "Python syntax" may not match those of a caller who has included `__future__` statements, leading to unexpected behavior.

I am insufficiently familiar with the full functionality of `ast` to be able to identify where this is and is not an issue, except in `literal_eval`, but I can see it could in principle affect Python 3.x too.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35777>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:17:58 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 21 Jan 2019 18:17:58 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548094678.46.0.137707514606.issue35797@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The launchers have inheritance enabled (for the duplicated standard handles, which should be made inheritable via SetHandleInformation instead, but that's a separate issue). However, multiprocessing doesn't use inheritable handles. Spawning processes with inheritance would be a problem in a general-purpose library. Instead it depends on either the parent manually duplicating the handle to the child or vice versa (via the child opening the parent PID that's passed to it). The problem for a virtual environment that's using the launcher is the former, where the parent duplicates to the child (e.g. for the SemLock semaphore). We need a way to allow multiprocessing to spawn the real python.exe instead of the launcher executable that's set as sys.executable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:31:44 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 18:31:44 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548095504.93.0.275686947024.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> We need a way to allow multiprocessing to spawn the real python.exe instead of the launcher executable that's set as sys.executable.

Got to a computer and had just reached the same conclusion.

Given the environment is inherited, it's easy to do:

>>> import _winapi
>>> import multiprocessing.spawn
>>> multiprocessing.spawn.set_executable(_winapi.GetModuleFileName(0))

This may interfere with others who currently override sys.executable when hosting Python, since they'll get their override by default. But changing sys.executable to _not_ be the venv one will break anyone who doesn't correctly inherit environment variables (specifically, __PYVENV_LAUNCHER__, but this is deliberately not documented ;) ). 

Perhaps we just change the multiprocessing default on Windows when sys.base_prefix != sys.prefix?

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:35:22 2019
From: report at bugs.python.org (Christian Ullrich)
Date: Mon, 21 Jan 2019 18:35:22 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548095722.14.0.879932946285.issue35797@roundup.psfhosted.org>


Christian Ullrich <chris at chrullrich.net> added the comment:

I have two ideas, but no idea if either is remotely feasible:

1. Replicate the launcher's selection logic in multiprocessing and
   avoid the intermediate step via sys.executable. Perhaps put it
   into pythonXX.dll or export it from the launcher executable so
   the C implementation can be shared by both users.

2. Handle the command line argument(s) that control how 
   multiprocessing pulls the handle from the parent process in the
   launcher and perform the operation so the sub-subprocess can in
   turn get it from the launcher.

I had a third one, but it was so crazy I must have preemptively forgotten it.

Finally, I do not think this is a regression in 3.7 (although I have not tested it with anything earlier), but unless the implementation of multiprocessing has changed radically in 3.7 I cannot see how it could have (not) worked any differently before.

On the other hand, venv is essentially the "official" way of installing Python applications these days, so the issue should have a high priority for fixing anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:48:46 2019
From: report at bugs.python.org (Paul Watson)
Date: Mon, 21 Jan 2019 18:48:46 +0000
Subject: [issue35801] venv in 3.7 references python3 executable
Message-ID: <1548096524.26.0.673516861772.issue35801@roundup.psfhosted.org>


New submission from Paul Watson <paul.hermeneutic at gmail.com>:

The documentation for venv in Python 3.7 references using `python3` to run venv. I do not find a `python3` executable in the kit.

https://docs.python.org/3.7/library/venv.html#module-venv

----------
assignee: docs at python
components: Documentation
messages: 334165
nosy: Paul Watson, docs at python
priority: normal
severity: normal
status: open
title: venv in 3.7 references python3 executable
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35801>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:50:45 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Mon, 21 Jan 2019 18:50:45 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548096645.45.0.0471936319341.issue35699@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

I read a few of the logs, and all errors roots in the same place, when the test case tries to remove the tempdir during teardown/cleanup. The Windows (and other platforms not supporting directory fds) implementation of rmtree can have race conditions if files are added while the directory being walked, causing the error.

I don?t know the case of CPython, but Pipenv has a similar problem when running concurrent tests with subprocesses. We never solved it (but simply wrap the rmtree call inside a try block and look away).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Mon Jan 21 13:52:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 18:52:49 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548096769.38.0.723550573125.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The first idea makes sense, but because of how we've already architected things (and the direction we're trying to rearchitect things) it isn't really that feasible.

The second idea could be good. It isn't that hard to make globally named handles that can be reopened in the child process, and that avoids the need for a coherent inheritance chain of processes. Maybe it could break other scenarios that do rely on inheritance though? (But aren't those already broken? All this is *just* outside the edge of my experience, so I'd have to try them all out to be sure.)

It's a regression in 3.7.2, which is when the venv script changed. As I said, updating from 3.7.1 to 3.7.2 was going to change the venv "script" anyway (which was just the main Python executable and its binaries), so it should have been no more breaking than that. But it was, so I consider it a regression (in venv, to be clear, not in multiprocessing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:06:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jan 2019 19:06:24 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548097584.79.0.857202811098.issue35798@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +11410
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:06:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jan 2019 19:06:29 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548097589.21.0.0308230072.issue35798@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11410, 11411
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:06:34 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jan 2019 19:06:34 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548097594.85.0.287389581414.issue35798@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11410, 11411, 11412
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:20:12 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 19:20:12 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1548098412.79.0.228809504276.issue35782@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2433a2ab705e93f9a44f01c260d351b205a73e9d by Miss Islington (bot) (Kumar Akshay) in branch 'master':
bpo-35782: Fix error message in randrange (GH-11620)
https://github.com/python/cpython/commit/2433a2ab705e93f9a44f01c260d351b205a73e9d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:20:31 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 19:20:31 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1548098431.32.0.503711817477.issue35782@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:20:42 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 19:20:42 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1548098442.76.0.758761816995.issue35782@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11413, 11414

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:20:54 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Jan 2019 19:20:54 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1548098454.54.0.583062792591.issue35782@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11413, 11414, 11415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:41:38 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Mon, 21 Jan 2019 19:41:38 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548099698.41.0.90071395029.issue35798@roundup.psfhosted.org>


Kumar Akshay <k.akshay9721 at gmail.com> added the comment:

can I work on this?

----------
nosy: +kakshay

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:52:38 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jan 2019 19:52:38 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548100358.51.0.689100856472.issue35797@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, if multiprocessing exhibits the problem, I wouldn't be surprised if some third-party libraries also do.  I think `sys.executable` should really point to the proper executable.

> But changing sys.executable to _not_ be the venv one will break anyone who doesn't correctly inherit environment variables (specifically, __PYVENV_LAUNCHER__, but this is deliberately not documented ;) ). 

Well, it will also break if other environment variables are required, e.g. PYTHONPATH.  Usually you want to inherit environment variables (including such fundamental stuff such as HOME), because you don't know which ones are actually required for a given workload.

So I think "breaking if environment variables are not inherited" is a less severe failure mode than this issue is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 14:58:10 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 19:58:10 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548100690.07.0.798561148307.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> So I think "breaking if environment variables are not inherited" is a less severe failure mode than this issue is.

ISTR that having sys.executable point to a path outside of sys.prefix breaks the site module in some way, so that would move the fix over there. But again, going from memory - I'd have to try it (and doubtful that I'm getting to it today).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:06:05 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 21 Jan 2019 20:06:05 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548101165.38.0.889622149708.issue35797@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

multiprocessing could be redesigned to make the child process responsible for duplicating all handles from its logical parent (by PID passed on the command line -- regardless of whatever its real parent is). That avoids the problem of the parent mistakenly duplicating handles to a launcher child process that has no idea that the parent has done this and certainly doesn't have the architecture in place to deal with it. 

That said, inserting the launcher process as a middle man for every worker process is wasteful. Creating processes without fork is expensive. Also, relying on the "__PYVENV_LAUNCHER__" environment variable for this is problematic. Environment variables are inherited by default, so it leaks to a completely unrelated python.exe process. For example, if we run subprocess.call(r'C:\Program Files\Python37\python.exe') from a virtual environment, currently we end up with an overridden sys.executable. I would prefer a -X command-line option, such as "VIRTUAL_ENV". multiprocessing could propagate this option to worker processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:11:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jan 2019 20:11:16 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548101476.21.0.39558375364.issue35780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was the explanation of possible history, not the justification of bugs. Of course bugs should be fixed. Thank you for rechecking this code and for your fix.

As for the optimization in lru_cache_make_key(), consider the following example:

@lru_cache()
def f(x):
    return x

print(f(1))
print(f(1.0))

Currently the C implementation memoizes only one result, and f(1.0) returns 1. With the Python implementation and with the proposed changes  it will return 1.0. I do not say that any of answers is definitely wrong, but we should be aware of this, and it would be better if both implementation will be consistent. I am sure this example was already discussed, but I can not find it now.

I still did not analyze the new code for adding to the cache. The old code contains flaws, agree.

I am not sure about an addition _PyDict_GetItem_KnownHash(). Every of dict operations can cause executing an arbitrary code and re-entering the execution of bounded_lru_cache_wrapper(). Could not the API that atomically checks and updates the dict (like getdefault()/setdefault()) be useful here?

----------
assignee: serhiy.storchaka -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:13:50 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 21 Jan 2019 20:13:50 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1548101630.55.0.137725549341.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I've made the changes suggested by Brett to store the raw value instead of the formatted prompt.  

I also have been looking into issues Steve raised about using the prompt value from `pyvenv.cfg` instead of having the prompt hard-coded into the activate scripts.  Since these scripts are .bat, bash, Powershell, etc scripts, I didn't know if there was anything special that needed to be taken into account (such as encoding) to use the values from the config file.  As Steve said, I could see this being opened as a bug in the future, so I don't mind working on it now in this issue or a separate one, whichever is the better option.  I just don't have much experience with those types of scripts, so I'm sure any changes I make will require some time and a lot of code review.  Plus, those changes add complexity to this change that Brett said he doesn't really need for his initial request.  Because of the possibility of changing those scripts soon, I've left the key name as `prompt` for now.  Fixing the activate scripts seems to be the right way to go instead of changing the name so it's not misused.

One thing that I did find which may be a current bug is:
> PS N:\projects\cpython> python -m venv myvenv --prompt='this is my prompt'
> Running Release|Win32 interpreter...
> PS N:\projects\cpython> .\myvenv\Scripts\activate
> (this is my prompt) PS N:\projects\cpython> deactivate
> PS N:\projects\cpython> python -m venv myvenv --upgrade --prompt='new prompt'
> Running Release|Win32 interpreter...
> PS N:\projects\cpython> .\myvenv\Scripts\activate
> (this is my prompt) PS N:\projects\cpython>

--upgrade changes the prompt on `pyvenv.cfg`, but doesn't update activate scripts, so the prompt doesn't really change.

And for reference, there is another bug issue for storing the --prompt value in an environment variable (#35328).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:17:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Jan 2019 20:17:30 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548101850.22.0.20792117203.issue35780@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For the test you can use "nonlocal".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:41:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 20:41:36 +0000
Subject: [issue34656] [CVE-2018-20406] memory exhaustion in
 Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548103296.01.0.862436251026.issue34656@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: memory exhaustion in Modules/_pickle.c:1393 -> [CVE-2018-20406] memory exhaustion in Modules/_pickle.c:1393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:49:44 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jan 2019 20:49:44 +0000
Subject: [issue35758] Disable x87 control word for MSVC ARM compiler
In-Reply-To: <1547702162.77.0.571505556494.issue35758@roundup.psfhosted.org>
Message-ID: <1548103784.29.0.519658620118.issue35758@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 7a2368063f25746d4008a74aca0dc0b82f86ff7b by Antoine Pitrou (Minmin Gong) in branch 'master':
bpo-35758: Fix building on ARM + MSVC (gh-11531)
https://github.com/python/cpython/commit/7a2368063f25746d4008a74aca0dc0b82f86ff7b


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35758>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:51:00 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 21 Jan 2019 20:51:00 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1548103860.71.0.265574085378.issue14802@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in master branch.  Thank you, Minmin Gong!

I don't think this is a candidate for a 3.7 backport. If you think otherwise, though, please say so. You'll also need to check that the backport enables proper compilation on ARM.

----------
nosy: +ned.deily, pitrou
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:51:20 2019
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 21 Jan 2019 20:51:20 +0000
Subject: [issue31506] Improve the error message logic for object_new &
 object_init
In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za>
Message-ID: <1548103880.14.0.743460896485.issue31506@roundup.psfhosted.org>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +11416
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31506>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:51:29 2019
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 21 Jan 2019 20:51:29 +0000
Subject: [issue31506] Improve the error message logic for object_new &
 object_init
In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za>
Message-ID: <1548103889.37.0.707059727407.issue31506@roundup.psfhosted.org>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +11416, 11417
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31506>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:51:36 2019
From: report at bugs.python.org (Sanyam Khurana)
Date: Mon, 21 Jan 2019 20:51:36 +0000
Subject: [issue31506] Improve the error message logic for object_new &
 object_init
In-Reply-To: <1505727849.07.0.595214817996.issue31506@psf.upfronthosting.co.za>
Message-ID: <1548103896.69.0.258732109612.issue31506@roundup.psfhosted.org>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +11416, 11417, 11418
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31506>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:52:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 20:52:46 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1548103966.74.0.975464990875.issue35746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Does someone work on backporting the fix to 3.4 and 3.5 branches?

Note: I added the vulnerability to:
https://python-security.readthedocs.io/vuln/ssl-crl-dps-dos.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Mon Jan 21 15:58:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 20:58:29 +0000
Subject: [issue34656] [CVE-2018-20406] memory exhaustion in
 Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548104309.73.0.553089173622.issue34656@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 2.7 is not affected:

* Python 2.7 has no C accelerator _pickle (Modules/_pickle.c)
* Python 2.7 doesn't support protocol 4 (attached proof of concept)

I reopen the issue because the issue should be fixed in 3.4 and 3.5 as well, since it has been marked as a vulnerability (it got a CVE number).

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open
versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:14:04 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Mon, 21 Jan 2019 21:14:04 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548105244.48.0.505179279491.issue35798@roundup.psfhosted.org>


Change by Kumar Akshay <k.akshay9721 at gmail.com>:


----------
pull_requests: +11419

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:14:13 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Mon, 21 Jan 2019 21:14:13 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548105253.32.0.425609912582.issue35798@roundup.psfhosted.org>


Change by Kumar Akshay <k.akshay9721 at gmail.com>:


----------
pull_requests: +11419, 11420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:14:21 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Mon, 21 Jan 2019 21:14:21 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548105261.54.0.135162361212.issue35798@roundup.psfhosted.org>


Change by Kumar Akshay <k.akshay9721 at gmail.com>:


----------
pull_requests: +11419, 11420, 11421

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:19:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 21 Jan 2019 21:19:38 +0000
Subject: [issue35794] test_posix.py test failure
In-Reply-To: <1548068024.55.0.742068832525.issue35794@roundup.psfhosted.org>
Message-ID: <1548105578.53.0.990432045708.issue35794@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks for the quickfix Pablo ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35794>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:21:15 2019
From: report at bugs.python.org (bryan.koch)
Date: Mon, 21 Jan 2019 21:21:15 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1548105675.24.0.46031706189.issue35756@roundup.psfhosted.org>


bryan.koch <bbkoch94 at gmail.com> added the comment:

steven your generator example is exactly what I wanted to do; looks like I'm upgrading to Python 3.8 for the new assignment syntax.

I was actually expecting the SyntaxError to be raised at runtime which would be a pretty large behavior change (definitely required to go through python-ideas) but I think my use case is covered by 3.8 and just upgrading is simpler to do.

Some details of the implementation that stirred this is that I'm streaming output from a hierarchy of generated modules and I get what is essentially (final value, EOF) as the last result so I need to yield the final value but for external reasons I need to perform the clean-up of native resources before yielding.

Let's consider this as closed since what I need is supported in 3.8.  Thank you for your help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:42:36 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 21:42:36 +0000
Subject: [issue35802] os.stat / os.lstat always present,
 but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
Message-ID: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

Unless I'm reading incorrectly: 

https://github.com/python/cpython/blob/7a2368063f25746d4008a74aca0dc0b82f86ff7b/Modules/clinic/posixmodule.c.h#L30-L31

https://github.com/python/cpython/blob/7a2368063f25746d4008a74aca0dc0b82f86ff7b/Modules/clinic/posixmodule.c.h#L68-L69

----------
components: Library (Lib)
messages: 334182
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: os.stat / os.lstat always present, but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35802>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:47:40 2019
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 21 Jan 2019 21:47:40 +0000
Subject: [issue34656] [CVE-2018-20406] memory exhaustion in
 Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548107260.88.0.597706234824.issue34656@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

> * Python 2.7 has no C accelerator _pickle (Modules/_pickle.c)

And Modules/cPickle.c is that drastically different?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:50:09 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 21:50:09 +0000
Subject: [issue35802] os.stat / os.lstat always present,
 but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org>
Message-ID: <1548107409.63.0.157576984035.issue35802@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

looks true for os.chmod as well: https://github.com/python/cpython/blob/7a2368063f25746d4008a74aca0dc0b82f86ff7b/Modules/clinic/posixmodule.c.h#L327-L328

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35802>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:50:14 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Jan 2019 21:50:14 +0000
Subject: [issue14802] Python fails to compile with VC11 ARM configuration
In-Reply-To: <1336967845.45.0.147430912977.issue14802@psf.upfronthosting.co.za>
Message-ID: <1548107414.11.0.656516919198.issue14802@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Unless Steve thinks otherwise, I agree that this isn?t a candidate for backporting to 3.7 without all the work to fully support new platform configurations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14802>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:58:10 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Jan 2019 21:58:10 +0000
Subject: [issue35699] distutils cannot find Build Tools 2017 since 3.7.2
In-Reply-To: <1547038433.43.0.625372378947.issue35699@roundup.psfhosted.org>
Message-ID: <1548107890.53.0.604130175097.issue35699@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

@Steve, we are investigating and tracking this issue here:

https://bugs.python.org/issue35795

According to the buildbot owner "directory tree removal needs to go through support.rmtree, not any of the stdlib methods for doing so.  In a nutshell, the tests need to be changed to do this".

Not sure why this has happened now

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35699>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:58:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 21 Jan 2019 21:58:42 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548107922.45.0.692935335207.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I would prefer a -X command-line option, such as "VIRTUAL_ENV". multiprocessing could propagate this option to worker processes.

Right, so would I, but it needs to be propagated basically everywhere (unless "everywhere" all defers through multiprocessing, which would be great). I chose to go with the same solution as used on macOS for the same problem, though it had to be implemented in a different part of the code. Plenty of other environment variables will cause problems if they propagate to a totally different python.exe, so perhaps we should document __PYVENV_LAUNCHER__ as one to clear in this case (along with PYTHONHOME and PYTHONPATH)?

For future enhancement, there's also the stalled PEP 582 that would "fix" venv's reliance on shell/environment variables by having a different way to enable a separate package directory (FWIW, it stalled because the PEP doesn't fix *all* packaging problems, but only some). 

But as it stands, people rely on there being something they can launch in their venv directory, and that thing has to know (at least for a given terminal session) how to propagate the correct search paths to child processes. The current solution is the simplest one that ensures the most compatibility for the least amount of risk, even though that was not zero risk, as we've seen. And it also has to remain for 3.7 now, since venvs are no longer automatically broken when updating to 3.7.3.

Changing sys.executable to the final executable and trusting/relying/hoping that everyone who invokes it also allows environment variables to propagate is probably the best solution (including whatever site.py fixes are required, if any).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:59:41 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 21:59:41 +0000
Subject: [issue35802] os.stat / os.lstat always present,
 but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org>
Message-ID: <1548107981.39.0.349720532378.issue35802@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +11422
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35802>
_______________________________________

From report at bugs.python.org  Mon Jan 21 16:59:44 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 21:59:44 +0000
Subject: [issue35802] os.stat / os.lstat always present,
 but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org>
Message-ID: <1548107984.67.0.798552268316.issue35802@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch
pull_requests: +11422, 11423
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35802>
_______________________________________

From report at bugs.python.org  Mon Jan 21 17:07:03 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 22:07:03 +0000
Subject: [issue35803] Test and document that `dir=...` in tempfile may be
 PathLike
Message-ID: <1548108422.42.0.0789815194403.issue35803@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

This appears to be true in 3.6+ -- I'd like to add a test and documentation ensuring that going forward.

Related: https://github.com/python/typeshed/issues/2749

----------
assignee: docs at python
components: Documentation, Tests
messages: 334188
nosy: Anthony Sottile, docs at python
priority: normal
severity: normal
status: open
title: Test and document that `dir=...` in tempfile may be PathLike
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35803>
_______________________________________

From report at bugs.python.org  Mon Jan 21 17:29:28 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 21 Jan 2019 22:29:28 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
In-Reply-To: <1548091630.84.0.140233087609.issue35800@roundup.psfhosted.org>
Message-ID: <1548109768.24.0.76646731086.issue35800@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

Yes, it should be deprecated and removed.  TBH, IMHO smtpd.py should be entirely deprecated.  aiosmtpd (3rd party) is a much more modern approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Mon Jan 21 17:36:52 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 22:36:52 +0000
Subject: [issue35803] Test and document that `dir=...` in tempfile may be
 PathLike
In-Reply-To: <1548108422.42.0.0789815194403.issue35803@roundup.psfhosted.org>
Message-ID: <1548110212.96.0.174126482658.issue35803@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +11424
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35803>
_______________________________________

From report at bugs.python.org  Mon Jan 21 17:36:57 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 22:36:57 +0000
Subject: [issue35803] Test and document that `dir=...` in tempfile may be
 PathLike
In-Reply-To: <1548108422.42.0.0789815194403.issue35803@roundup.psfhosted.org>
Message-ID: <1548110217.08.0.447997629649.issue35803@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch
pull_requests: +11424, 11425
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35803>
_______________________________________

From report at bugs.python.org  Mon Jan 21 17:37:02 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 21 Jan 2019 22:37:02 +0000
Subject: [issue35803] Test and document that `dir=...` in tempfile may be
 PathLike
In-Reply-To: <1548108422.42.0.0789815194403.issue35803@roundup.psfhosted.org>
Message-ID: <1548110222.84.0.648052706966.issue35803@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch, patch
pull_requests: +11424, 11425, 11426
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35803>
_______________________________________

From report at bugs.python.org  Mon Jan 21 17:56:18 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Jan 2019 22:56:18 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1548105675.24.0.46031706189.issue35756@roundup.psfhosted.org>
Message-ID: <20190121225611.GW13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> steven your generator example is exactly what I wanted to do; looks 
> like I'm upgrading to Python 3.8 for the new assignment syntax.
Sorry to have mislead you, but I don't think it will do what I thought. 
After giving it some more thought, I decided to test it (at least as 
much of it as possible). There's no local assignment here but you can 
see that the behaviour is not what I had assumed:

py> def inner():
...     yield from (1, 2)
...     return -1
...
py> def outer():
...     for x in (yield from inner()):
...             yield 100+x
...
py> for x in outer():
...     print(x)
...
1
2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in outer
TypeError: 'int' object is not iterable

In hindsight, this behaviour is logical. But I think it means that there 
is no way to do what you want using a for-loop.

> I was actually expecting the SyntaxError to be raised at runtime which 
> would be a pretty large behavior change

Not *entirely* unprecedented though, as you can get runtime SyntaxErrors 
from calling compile(), eval() or exec(). But I think some other class 
of exception would be better, since the problem isn't actually a syntax 
error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Mon Jan 21 18:31:31 2019
From: report at bugs.python.org (bryan.koch)
Date: Mon, 21 Jan 2019 23:31:31 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1547682129.59.0.632977183775.issue35756@roundup.psfhosted.org>
Message-ID: <1548113491.67.0.399035937675.issue35756@roundup.psfhosted.org>


bryan.koch <bbkoch94 at gmail.com> added the comment:

Thanks for testing that.  I'm off to write an ugly `next()` wrapper then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Mon Jan 21 18:38:43 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Jan 2019 23:38:43 +0000
Subject: [issue35756] Using `return value` in a generator function skips the
 returned value on for-loop iteration
In-Reply-To: <1548113491.67.0.399035937675.issue35756@roundup.psfhosted.org>
Message-ID: <20190121233838.GZ13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> I'm off to write an ugly `next()` wrapper then.

Wouldn't it be simpler to re-design the generators to yield the final 
result instead of returning it? To process the final item differently 
from the rest, you just need something like this:

last = next(it)
for x in it:
    process(last)
    last = x
special_handling(last)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35756>
_______________________________________

From report at bugs.python.org  Mon Jan 21 19:09:46 2019
From: report at bugs.python.org (Tom Wilson)
Date: Tue, 22 Jan 2019 00:09:46 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1548115786.22.0.291986943302.issue35627@roundup.psfhosted.org>


Tom Wilson <tom.wilson66 at gmail.com> added the comment:

Hi there. I get this behavior as well, although only in a venv.

                      Main       Virtual      
v3.7.1:260ec2c36a  Completes    Completes
v3.7.2:9a3ffc0492  Completes      Hangs

Some other details of my setup:
 - Windows 10 Pro, Version 1803 (OS Build 17134.472)
 - Python platform is AMD64 on win32
 - Running from the command line (cmd.exe)
 - The virtual environment was created from the command line like this: 
     .\python -m venv c:\temp\Py-3.7.2b-Venv

----------
nosy: +tom.wilson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35627>
_______________________________________

From report at bugs.python.org  Mon Jan 21 19:17:34 2019
From: report at bugs.python.org (Tom Wilson)
Date: Tue, 22 Jan 2019 00:17:34 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1548116254.01.0.254426851199.issue35627@roundup.psfhosted.org>


Tom Wilson <tom.wilson66 at gmail.com> added the comment:

In case this is a clue - the attached script "mp_hang2.py" adds a call to qsize() and uses only a single consumer. When I run it from the command line it does one of two things:


Option 1:

C:\TEMP\Py-3.7.2b-Venv\Scripts>.\python.exe "C:\Users\Tom.Wilson\Documents\Python-Bugs\mp_hang2.py"
Creating 1 consumers
Putting
Poisoning
Joining
Process Consumer-1:
Traceback (most recent call last):
  File "C:\Users\Tom.Wilson\AppData\Local\Programs\Python\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap
    self.run()
  File "C:\Users\Tom.Wilson\Documents\Python-Bugs\mp_hang2.py", line 18, in run
    print(f'Queue size: {self.task_queue.qsize()}')
  File "C:\Users\Tom.Wilson\AppData\Local\Programs\Python\Python37\lib\multiprocessing\queues.py", line 117, in qsize
    return self._maxsize - self._sem._semlock._get_value()
PermissionError: [WinError 5] Access is denied


Option 2:

C:\TEMP\Py-3.7.2b-Venv\Scripts>.\python.exe "C:\Users\Tom.Wilson\Documents\Python-Bugs\mp_hang2.py"
Creating 1 consumers
Putting
Poisoning
Joining
Queue size: 2147483647
Getting task
 <<< Hangs here >>>


If I can provide anything else please let me know.

----------
Added file: https://bugs.python.org/file48070/mp_hang2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35627>
_______________________________________

From report at bugs.python.org  Mon Jan 21 19:37:17 2019
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 22 Jan 2019 00:37:17 +0000
Subject: [issue35795] test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x
 and AMD64 Windows7 SP1 3.7 buildbots
In-Reply-To: <1548068055.8.0.250041418477.issue35795@roundup.psfhosted.org>
Message-ID: <1548117437.96.0.559028826659.issue35795@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Also of note, a largish temporary directory (16K+ entries) seemed to be causing a slowdown in the cleanup of the tests, thus triggering the failures.  A quick purge later and the tests seem to run to completion.

Although the tests are currently passing, they are still broken from a Windows directory removal standpoint.  It is good to know that the failures can be recreated if needed by refilling the tempdir (at least on my buildbot).

This issue brings to light a few things:
1) tests MUST use the support.rmtree to prevent spurious failures
2) tests need to cleanup better; each run leaves ~10 entries in TEMP
3) a per-builder tempdir would mitigate the excessive tempdir issue

Note that addressing 2 wouldn't eliminate 3 as non-buildbot usage can still fill the tempdir, just not as fast as our buildbot seems to :)

I would really like to see #3 solved (maybe a `tmp` directory next to the `build` directory on the builders themselves?)  If it is in a fixed location, I would then be able to use a tmpfs-like solution for it, reducing test times 20+% (in my hacked up local testing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35795>
_______________________________________

From report at bugs.python.org  Mon Jan 21 19:40:36 2019
From: report at bugs.python.org (Lisa Roach)
Date: Tue, 22 Jan 2019 00:40:36 +0000
Subject: [issue35132] python-gdb error: Python Exception <class
 'RuntimeError'> Type does not have a target
In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za>
Message-ID: <1548117636.26.0.780649763839.issue35132@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

I experienced this bug as well and have tried to dig into it a little. 

I experimented with a service I have that uses shared libraries. If I compile with high level of optimizations for the C++ code (-O3) I don't experience the issue, but compiling without any optimizations I do. 

I also tried with a script that does not use any shared libraries and I do not see the issue.


Digging into it a little, when running with the optimized version I found:

gdb.lookup_type('PyUnicodeObject')

returns a gdb.TYPE_CODE_TYPEDEF, which is the correct type. Running with the non-optimized version instead returns a gdb.TYPE_CODE_STRUCT.


The struct type errors because it has no target(), but I actually think target() might be superfluous here. 

Both versions if I only call `fields = gdb.lookup_type('PyUnicodeObject').fields()` returns a list of fields, one of which is named `data` for the purposes of the pep check, so target() doesn't seem vital.

----------
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35132>
_______________________________________

From report at bugs.python.org  Mon Jan 21 20:12:21 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 22 Jan 2019 01:12:21 +0000
Subject: [issue20479] Efficiently support weight/frequency mappings in the
 statistics module
In-Reply-To: <CAHVvXxQFLpafZ+u5uyw-mN3OK=zfV7Y_CcgB9prOsrTDHZadcA@mail.gmail.com>
Message-ID: <20190122011141.GA13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Here is some further information on weights in statistics in general, 
and SAS and Stata specifically:

https://blogs.sas.com/content/iml/2017/10/02/weight-variables-in-statistics-sas.html

Quote:

    use the FREQ statement to specify integer frequencies for 
    repeated observations. Use the WEIGHT statement when you 
    want to decrease the influence that certain observations 
    have on the parameter estimates. 

http://support.sas.com/kb/22/600.html

https://www.stata.com/manuals13/u20.pdf#u20.23

Executive summary:

- Stata defines four different kinds of weights;

- SAS defines two, WEIGHT and FREQ (frequency);

- SAS truncates FREQ values to integers, with zero or 
  negative meaning that the data point is to be ignored;

- Using FREQ is equivalent to repeating the data points.
  In Python terms:

  mean([1, 2, 3, 4], freq=[1, 0, 3, 1])

  would be equivalent to mean([1, 3, 3, 3, 4]).

- Weights in SAS are implicitly normalised to sum to 1, 
  but some functions allow you to normalise to sum to the
  number of data points, because it sometimes makes a 
  difference.

- It isn't clear to me what the physical meaning of weights
  in SAS actually is. The documentation is unclear, it *could*
  as simple as the definition of weighted mean here:

https://en.wikipedia.org/wiki/Weighted_arithmetic_mean#Mathematical_definition

but how that extends to more complex SAS functions is unclear to me.

(And for what its worth, I don't think SAS's MEAN function supports 
weights at all. Any SAS users here that could comment?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20479>
_______________________________________

From report at bugs.python.org  Mon Jan 21 21:26:07 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Jan 2019 02:26:07 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548123967.92.0.91071585953.issue35766@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +11427
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Mon Jan 21 21:26:14 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Jan 2019 02:26:14 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548123974.75.0.841395192881.issue35766@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch, patch
pull_requests: +11427, 11428
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Mon Jan 21 21:26:21 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Jan 2019 02:26:21 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548123981.19.0.924860586853.issue35766@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch, patch, patch
pull_requests: +11427, 11428, 11429
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Mon Jan 21 21:55:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Jan 2019 02:55:03 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548125703.03.0.790279526787.issue35780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I am not sure about an addition _PyDict_GetItem_KnownHash().

It is a necessary check.  The user call is allowed to update the cache so we no longer know without checking whether the new key/result pair has already been added.  That is in fact the main bug that is being fixed.

> Every of dict operations can cause executing an arbitrary code 
> and re-entering the execution of bounded_lru_cache_wrapper().

FWIW, the new _PyDict_GetItem_KnownHash() call is made at the top of the post user call code path, before any modifications of the cache have occurred.  This is the safest possible time to allow reentry.  There's really nothing this call can do that couldn't have happened in the user function call.

Also, only the normal case (where the key is not present) proceeds to modify the cache state.  The other two paths exit immediately.

> Could not the API that atomically checks and updates the dict
> (like getdefault()/setdefault()) be useful here?

That seems tempting but our goal is a "contains" test.  We're not storing a new entry at this point.  Instead, we're just checking to see if any further work is necessary.

At some point in the future (not in this bug fix), we could further sync the C code and pure python code to use the rotating root entry.   That means that in the "self->full" path, we never need to extract, append, or prepend links.  Only the value fields and root pointer need to be updated.  That does less work and always leaves the structure in a consistent state.

> Currently the C implementation memoizes only one result, and 
> f(1.0) returns 1. With the Python implementation and with
> the proposed changes it will return 1.0.

When keyword argument sorting was dropped, we gained a speed improvement but came to treat f(a=1, b=2) and f(b=2, a=1) as distinct calls.  Here we cut memory overhead in half for common cases but will treat f(1) and f(1.0) as distinct calls.  I'm fine with that. It's also nice that the C and pure Python versions now match.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Mon Jan 21 23:42:30 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Tue, 22 Jan 2019 04:42:30 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1548132150.78.0.344312466476.issue33944@roundup.psfhosted.org>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

FYI I have 3 projects that use pth files to activate various features (an env var is usually the trigger):

https://pypi.org/project/pytest-cov - enables coverage measurement in any subprocess
https://pypi.org/project/manhole - installs a debug service
https://pypi.org/project/hunter - installs a tracer

I wouldn't like them being rendered almost or completely useless by such a hasty change. 

Running stuff during startup can be problematic and tricky, for example I have painfully found out that on python 2.7 you can completely hose up your codecs registry if you try to decode things during startup (before the registry is fully built) but I think it's a fair price for such a powerful feature.

----------
nosy: +ionelmc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Tue Jan 22 04:28:55 2019
From: report at bugs.python.org (Nasir Hussain)
Date: Tue, 22 Jan 2019 09:28:55 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1548149335.21.0.848179912819.issue24925@roundup.psfhosted.org>


Nasir Hussain <nasirhjafri at gmail.com> added the comment:

Hi, Should I convert patch into PR?
Thanks

----------
nosy: +nasirhjafri

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Jan 22 04:36:32 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jan 2019 09:36:32 +0000
Subject: [issue32146] multiprocessing freeze_support needed outside win32
In-Reply-To: <1511778835.66.0.213398074469.issue32146@psf.upfronthosting.co.za>
Message-ID: <1548149792.17.0.176363894198.issue32146@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

@bbayles Hopefully a Windows user could test if you give a step-by-step guide of what to check for.

----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32146>
_______________________________________

From report at bugs.python.org  Tue Jan 22 04:48:12 2019
From: report at bugs.python.org (Anselm Kruis)
Date: Tue, 22 Jan 2019 09:48:12 +0000
Subject: [issue35804] v3.6.8 _ctypes win32 compiled with pgo crash
Message-ID: <1548150488.57.0.992942838687.issue35804@roundup.psfhosted.org>


New submission from Anselm Kruis <a.kruis at science-computing.de>:

During the QA for Stackless 3.6.8 I observed a crash in _ctypes compiled for win32 with PGO, that also exists with plain C-Python v3.6.8. I didn't check other versions yet.

OS: Win7 (64bit)
Compiler: Visual Studio 2017 professional 15.9.5

How to reproduce

1. Checkout v3.6.8

I'm using the git-bash
$ git status
HEAD detached at v3.6.8
nothing to commit, working tree clean

2. Clean the sandbox and compile. It is sufficient to use a short pgo-job, but the default pgo-job works a well (but takes much more time).

$ cd PCbuild/
$ rm -rf obj win32 amd64
$ PYTHON=/e/Pythons/3.6.4-64/python.exe cmd //c build.bat --pgo-job "-m test --pgo test_ctypes" 2>&1 | tee build.log

The file "build.log" is attached. Nothing conspicuous in it.

3. Run the test case ctypes.test.test_win32.WindowsTestCase.test_callconv_1
Sometimes the test passes, sometimes it fails with a Segmentation Fault.

$ win32/python.exe -X faulthandler -m ctypes.test.test_win32 WindowsTestCase.test_callconv_1
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

$ win32/python.exe -X faulthandler -m ctypes.test.test_win32 WindowsTestCase.test_callconv_1
Windows fatal exception: access violation

Current thread 0x00001574 (most recent call first):
  File "C:\build\python36\lib\unittest\case.py", line 178 in handle
  File "C:\build\python36\lib\unittest\case.py", line 733 in assertRaises
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 20 in test_callconv_1
  File "C:\build\python36\lib\unittest\case.py", line 605 in run
  File "C:\build\python36\lib\unittest\case.py", line 653 in __call__
  File "C:\build\python36\lib\unittest\suite.py", line 122 in run
  File "C:\build\python36\lib\unittest\suite.py", line 84 in __call__
  File "C:\build\python36\lib\unittest\suite.py", line 122 in run
  File "C:\build\python36\lib\unittest\suite.py", line 84 in __call__
  File "C:\build\python36\lib\unittest\runner.py", line 176 in run
  File "C:\build\python36\lib\unittest\main.py", line 256 in runTests
  File "C:\build\python36\lib\unittest\main.py", line 95 in __init__
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 165 in <module>
  File "C:\build\python36\lib\runpy.py", line 85 in _run_code
  File "C:\build\python36\lib\runpy.py", line 193 in _run_module_as_main
Segmentation fault


4. I observed another variant of the crash, if I run all tests in test_ctypes

$ cmd //c rt.bat -q -v test_ctypes 2>&1 | tee test_ctypes.log

The file "test_ctypes.log" is attached. Relevant content:
test_callconv_1 (ctypes.test.test_win32.WindowsTestCase) ... XXX lineno: 124, opcode: 0
ERROR
test_callconv_2 (ctypes.test.test_win32.WindowsTestCase) ... XXX lineno: 124, opcode: 0
ERROR
test_variant_bool (ctypes.test.test_wintypes.WinTypesTest) ... test test_ctypes failed
ok

======================================================================
ERROR: test_callconv_1 (ctypes.test.test_win32.WindowsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 27, in test_callconv_1
    self.assertRaises(ValueError, IsWindow, 0, 0, 0)
  File "C:\build\python36\lib\unittest\case.py", line 733, in assertRaises
    return context.handle('assertRaises', args, kwargs)
  File "C:\build\python36\lib\unittest\case.py", line 157, in handle
    if not _is_subtype(self.expected, self._base_type):
  File "C:\build\python36\lib\unittest\case.py", line 124, in _is_subtype
    if isinstance(expected, tuple):
SystemError: unknown opcode

======================================================================
ERROR: test_callconv_2 (ctypes.test.test_win32.WindowsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\build\python36\lib\ctypes\test\test_win32.py", line 36, in test_callconv_2
    self.assertRaises(ValueError, IsWindow, None)
  File "C:\build\python36\lib\unittest\case.py", line 733, in assertRaises
    return context.handle('assertRaises', args, kwargs)
  File "C:\build\python36\lib\unittest\case.py", line 157, in handle
    if not _is_subtype(self.expected, self._base_type):
  File "C:\build\python36\lib\unittest\case.py", line 124, in _is_subtype
    if isinstance(expected, tuple):
SystemError: unknown opcode

----------------------------------------------------------------------


I had a quick look at  _call_function_pointer() in Modules/_ctypes/callproc.c, but I didn't see anything obvious. A very speculative first guess is the calling convention of ffi_call() or a related function written in (inline) assembly.

Work around: compile _ctypes for win32 without PGO.

----------
components: ctypes
files: build.log
messages: 334202
nosy: anselm.kruis
priority: normal
severity: normal
status: open
title: v3.6.8 _ctypes win32 compiled with pgo crash
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file48071/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35804>
_______________________________________

From report at bugs.python.org  Tue Jan 22 04:49:27 2019
From: report at bugs.python.org (Anselm Kruis)
Date: Tue, 22 Jan 2019 09:49:27 +0000
Subject: [issue35804] v3.6.8 _ctypes win32 compiled with pgo crash
In-Reply-To: <1548150488.57.0.992942838687.issue35804@roundup.psfhosted.org>
Message-ID: <1548150567.96.0.205123752714.issue35804@roundup.psfhosted.org>


Change by Anselm Kruis <a.kruis at science-computing.de>:


Added file: https://bugs.python.org/file48072/test_ctypes.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35804>
_______________________________________

From report at bugs.python.org  Tue Jan 22 04:52:17 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jan 2019 09:52:17 +0000
Subject: [issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was
 in 3.7.1
In-Reply-To: <1546256970.74.0.591831290501.issue35627@roundup.psfhosted.org>
Message-ID: <1548150737.84.0.377208682465.issue35627@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Hi there. I get this behavior as well, although only in a venv.

Ah, thanks for the clarification.  Then it's a duplicate of issue35797.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35627>
_______________________________________

From report at bugs.python.org  Tue Jan 22 04:57:13 2019
From: report at bugs.python.org (Anselm Kruis)
Date: Tue, 22 Jan 2019 09:57:13 +0000
Subject: [issue35804] v3.6.8 _ctypes win32 compiled with pgo crash
In-Reply-To: <1548150488.57.0.992942838687.issue35804@roundup.psfhosted.org>
Message-ID: <1548151033.06.0.323432591043.issue35804@roundup.psfhosted.org>


Change by Anselm Kruis <a.kruis at science-computing.de>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35804>
_______________________________________

From report at bugs.python.org  Tue Jan 22 05:53:49 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 22 Jan 2019 10:53:49 +0000
Subject: [issue15045] Make textwrap.dedent() and textwrap.indent() handle
 whitespace consistently
In-Reply-To: <1339421358.2.0.611530152115.issue15045@psf.upfronthosting.co.za>
Message-ID: <1548154429.58.0.660563053909.issue15045@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Putting some of my comments here rather than on the PR, as they're design questions related to "Is the current behaviour actually wrong?" and "Even if the current behaviour is deemed technically incorrect, is it worth the risk of changing it after all these years?".

I've also retitled the issue to describe the desired outcome of increased consistency between textwrap.dedent() and textwrap.indent(), without expressing a preference one way or the other.

1. Correctness & consistency

Quoting the textwrap.py comment about ASCII whitespace that Serhiy mentioned:

```
# Hardcode the recognized whitespace characters to the US-ASCII
# whitespace characters.  The main reason for doing this is that
# some Unicode spaces (like \u00a0) are non-breaking whitespaces.
_whitespace = '\t\n\x0b\x0c\r '
```

It's not clear whether or not non-breaking whitespace should actually be counted as an empty line, as it wouldn't be a candidate break point for line wrapping if that space appeared between two words (e.g. "first\N{NO-BREAK SPACE}second"), even though str.split() would split on it, and str.strip() would remove it from the beginning or end of a string (and that discrepancy is by design, since it's what "non-breaking" *means*).

So the interesting test cases from that perspective would be strings like:

"""\
    4 space indent
\N{NO-BREAK SPACE}   4 spaces, but first is no-break
    4 space indent
"""
-> textwrap.dedent() should do nothing

"""\
    4 space indent
\N{NO-BREAK SPACE}
    Previous line is just a single no-break space
"""
-> textwrap.dedent() should do nothing

"""\
    4 space indent
    \N{NO-BREAK SPACE}5 spaces, but last is no-break
    4 space indent
"""
-> textwrap.dedent() should strip the common 4-space prefix

"""\
    4 space indent
    \N{NO-BREAK SPACE}
    Previous line is indented with 4 spaces
"""
-> textwrap.dedent() should strip the common 4-space prefix

The potential inconsistency I cite above is with the then-new textwrap.indent() which *does* consider all lines consisting solely of whitespace (whether non-breaking or not) to be blank lines, and hence doesn't indent them. This means that the following test string wouldn't round trip correctly through a textwrap.indent/textwrap.dedent pair:

"""\
4 space indent
\N{NO-BREAK SPACE}
Previous line is indented as usual
"""

indent() would skip adding leading whitespace to the second line, which means dedent() would subsequently fail to detect a common leading prefix to be stripped.

However, that can easily be considered a bug in textwrap.indent() - it's the newer function, so it was a design error to make it inconsistent with the textwrap.dedent() precedent.

2. Performance

Since this issue was opened purely on design consistency grounds, it needs to offer really compelling benefits if we're going to risk a change that might make textwrap.dedent() slower.

I don't think we've reached that bar, as with universal newlines as the default text reading behaviour, it's going to be fairly rare for `textwrap.dedent()` to be applied to strings containing `\r` or `\r\n`, and if it is, it's a pretty straightforward prior normalisation step to convert both of those to `\n` via `text.sub('\r\n', '\n').sub('\r', '\n')` (or a comparable regex based on https://stackoverflow.com/questions/1331815/regular-expression-to-match-cross-platform-newline-characters)

So I think the most that can be argued for when it comes to the newline handling in dedent() is a *documentation* change that notes that textwrap.dedent() splits lines strictly on `\n`, and other line endings need to be normalized to `\n` before it will work correctly.

That leaves indent(), and I think the case can plausible be made there that it should be using _whitespace_only_re for its empty line detection  (the same as dedent(), instead of using str.strip().

----------
title: Make textwrap.dedent() consistent with str.splitlines(True) and str.strip() -> Make textwrap.dedent() and textwrap.indent() handle whitespace consistently

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15045>
_______________________________________

From report at bugs.python.org  Tue Jan 22 06:18:26 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 22 Jan 2019 11:18:26 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1548155906.98.0.0757973956557.issue33416@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 9932a22897ef9905161dac7476e6976370e13515 by Ivan Levkivskyi in branch 'master':
bpo-33416: Add end positions to Python AST (GH-11605)
https://github.com/python/cpython/commit/9932a22897ef9905161dac7476e6976370e13515


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Tue Jan 22 06:20:27 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 22 Jan 2019 11:20:27 +0000
Subject: [issue35486] subprocess module import hooks breaks back compatibility
In-Reply-To: <1544742855.44.0.788709270274.issue35486@psf.upfronthosting.co.za>
Message-ID: <1548156027.03.0.346625241991.issue35486@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, we can :)

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35486>
_______________________________________

From report at bugs.python.org  Tue Jan 22 06:47:52 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 22 Jan 2019 11:47:52 +0000
Subject: [issue35791] Unexpected exception with importlib
In-Reply-To: <1548005903.93.0.648072616722.issue35791@roundup.psfhosted.org>
Message-ID: <1548157672.05.0.470168570104.issue35791@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, that's a bug in `py`'s module interface emulation - see the last paragraph in https://docs.python.org/3/reference/import.html#module-spec

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35791>
_______________________________________

From report at bugs.python.org  Tue Jan 22 07:24:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 12:24:56 +0000
Subject: [issue34656] [CVE-2018-20406] memory exhaustion in
 Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548159896.52.0.709552546415.issue34656@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> And Modules/cPickle.c is that drastically different?

Stupid me. I was surprised that Python 2.7 had no C accelerator. I was looking for Modules/*pickle*.c on my case sensitive Linux filesystem...

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Tue Jan 22 07:34:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 12:34:09 +0000
Subject: [issue34656] [CVE-2018-20406] memory exhaustion in
 Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548160449.46.0.366589851428.issue34656@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

New changeset a4ae828ee416a66d8c7bf5ee71d653c2cc6a26dd by Benjamin Peterson in branch 'master':
closes bpo-34656: Avoid relying on signed overflow in _pickle memos. (GH-9261)
https://github.com/python/cpython/commit/a4ae828ee416a66d8c7bf5ee71d653c2cc6a26dd

It seems like this patch changes the implementation of the internal "memo" object which is a custom C type in Python 3.

In Python 2 cPickle, the memo is a regular dictionary and so I'm not sure that Python 2 is affected by this vulnerability.

Can someone please confirm?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Tue Jan 22 07:56:03 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Tue, 22 Jan 2019 12:56:03 +0000
Subject: [issue35805] email package folds msg-id identifiers using RFC2047
 encoded words where it must not
Message-ID: <1548161762.46.0.975813554813.issue35805@roundup.psfhosted.org>


New submission from Martijn Pieters <mj at python.org>:

When encountering identifier headers such as Message-ID containing a msg-id token longer than 77 characters (including the <...> angle brackets), the email package folds that header using RFC 2047 encoded words, e.g.

Message-ID: <154810422972.4.16142961424846318784 at aaf39fce-569e-473a-9453-6862595bd8da.prvt.dyno.rt.heroku.com>

becomes

Message-ID: =?utf-8?q?=3C154810422972=2E4=2E16142961424846318784=40aaf39fce-?=
 =?utf-8?q?569e-473a-9453-6862595bd8da=2Eprvt=2Edyno=2Ert=2Eheroku=2Ecom=3E?=

The msg-id token here is this long because Heroku Dyno machines use a UUID in the FQDN, but Heroku is hardly the only source of such long msg-id tokens. Microsoft's Outlook.com / Office365 email servers balk at the RFC2047 encoded word use here and attempt to wrap the email in a TNEF winmail.dat attachment, then may fail at this under some conditions that I haven't quite worked out yet and deliver an error message to the recipient with the helpful message "554 5.6.0 Corrupt message content", or just deliver the ever unhelpful winmail.dat attachment to the unsuspecting recipient (I'm only noting these symptom here for future searches).

I encountered this issue with long Message-ID values generated by email.util.make_msgid(), but this applies to all RFC 5322 section 3.6.4 Identification Fields headers, as well as the corresponding headers from RFC 822 section 4.6 (covered by section 4.5.4 in 5322).

What is happening here is that the email._header_value_parser module has no handling for the msg-id tokens *at all*, and email.headerregistry has no dedicated header class for identifier headers. So these headers are parsed as unstructured, and folded at will.

RFC2047 section 5 on the other hand states that the msg-id token is strictly off-limits, and no RFC2047 encoding should be used to encode such elements. Because headers *can* exceed 78 characters (RFC 5322 section 2.1.1 states that "Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters[.]") I think that RFC5322 msg-id tokens should simply not be folded, at all. The obsoleted RFC822 syntax for msg-id makes them equal to the addr-spec token, where the local-part (before the @) contains word tokens; those would be fair game but then at least apply the RFC2047 encoded word replacement only to those word tokens.

For now, I worked around the issue by using a custom policy that uses 998 as the maximum line length for identifier headers:

from email.policy import EmailPolicy

# Headers that contain msg-id values, RFC5322
MSG_ID_HEADERS = {'message-id', 'in-reply-to', 'references', 'resent-msg-id'}

class MsgIdExcemptPolicy(EmailPolicy):
    def _fold(self, name, value, *args, **kwargs):
        if name.lower() in MSG_ID_HEADERS and self.max_line_length - len(name) - 2 < len(value):
            # RFC 5322, section 2.1.1: "Each line of characters MUST be no
            # more than 998 characters, and SHOULD be no more than 78
            # characters, excluding the CRLF.". To avoid msg-id tokens from being folded
            # by means of RFC2047, fold identifier lines to the max length instead.
            return self.clone(max_line_length=998)._fold(name, value, *args, **kwargs)
        return super()._fold(name, value, *args, **kwargs)

This ignores the fact that In-Reply-To and References contain foldable whitespace in between each msg-id, but it at least let us send email through smtp.office365.com again without confusing recipients.

----------
components: email
messages: 334210
nosy: barry, mjpieters, r.david.murray
priority: normal
severity: normal
status: open
title: email package folds msg-id identifiers using RFC2047 encoded words where it must not
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35805>
_______________________________________

From report at bugs.python.org  Tue Jan 22 09:14:12 2019
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 22 Jan 2019 14:14:12 +0000
Subject: [issue24925] Allow doctest to find line number of __test__ strings if
 formatted as a triple quoted string.
In-Reply-To: <1440433204.72.0.951879790885.issue24925@psf.upfronthosting.co.za>
Message-ID: <1548166452.59.0.564755978186.issue24925@roundup.psfhosted.org>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

Yes. That would make me happy. In the meantime I learned how to use git, so maybe I'll do the pull request myself next time. Thanks for the work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Jan 22 09:53:59 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jan 2019 14:53:59 +0000
Subject: [issue35791] Unexpected exception with importlib
In-Reply-To: <1548005903.93.0.648072616722.issue35791@roundup.psfhosted.org>
Message-ID: <1548168839.71.0.78829903937.issue35791@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I expected as much. 

I've filed an issue with apipkg for this: https://github.com/pytest-dev/apipkg/issues/13. 

My next challenge is to find a way to work around this issue in my code.

BTW. Typing.io is a namespace added to sys.modules by the typing module that also does not have __spec__, and causes similar problems. I have an simple workaround for that on my side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35791>
_______________________________________

From report at bugs.python.org  Tue Jan 22 09:59:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 14:59:42 +0000
Subject: [issue35804] v3.6.8 _ctypes win32 compiled with pgo crash
In-Reply-To: <1548150488.57.0.992942838687.issue35804@roundup.psfhosted.org>
Message-ID: <1548169182.05.0.118663501247.issue35804@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

We already compile 32-bit CPython without PGO on Windows, so I don't think there's anything to do here apart from record the issue.

It's very likely that 3.8 will finally get an updated libffi, which should deal with this completely (or force us to take another look). 3.6 is not getting more binary releases though, and 3.7 would need a targeted fix if it repros there, so all we can really do is close this issue, unless you have additional info on its impact?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35804>
_______________________________________

From report at bugs.python.org  Tue Jan 22 10:16:28 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Tue, 22 Jan 2019 15:16:28 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
In-Reply-To: <1548091630.84.0.140233087609.issue35800@roundup.psfhosted.org>
Message-ID: <1548170188.96.0.157487450885.issue35800@roundup.psfhosted.org>


Samuel Colvin <samcolvin at gmail.com> added the comment:

Ok, if I create a PR, should it just remove MailmanProxy completely or mark it as deprecated in the docs to be removed in 3.9?

Personally, I think it should be ok to remove it completely since it hasn't been working at all for the last 4 minor versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Tue Jan 22 10:34:25 2019
From: report at bugs.python.org (Anselm Kruis)
Date: Tue, 22 Jan 2019 15:34:25 +0000
Subject: [issue35804] v3.6.8 _ctypes win32 compiled with pgo crash
In-Reply-To: <1548150488.57.0.992942838687.issue35804@roundup.psfhosted.org>
Message-ID: <1548171265.85.0.101375589956.issue35804@roundup.psfhosted.org>


Anselm Kruis <a.kruis at science-computing.de> added the comment:

Closing the issue is perfectly OK for me. I just want to document the problem, because there is no bpo ticket yet and Tools/msi/README.txt does not mention any problems with PGO either.

3.7 and master might be affected too, but I didn't observe this issue with 3.7.2, when I did the QA testing for Stackless 3.7.2 a few days ago.

Otherwise a PGO optimized build seems to work quite well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35804>
_______________________________________

From report at bugs.python.org  Tue Jan 22 10:44:49 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 22 Jan 2019 15:44:49 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
In-Reply-To: <1548170188.96.0.157487450885.issue35800@roundup.psfhosted.org>
Message-ID: <9832B353-F35B-4875-BF17-E76644D6AE43@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Jan 22, 2019, at 07:16, Samuel Colvin <report at bugs.python.org> wrote:
> 
> Ok, if I create a PR, should it just remove MailmanProxy completely or mark it as deprecated in the docs to be removed in 3.9?
> 
> Personally, I think it should be ok to remove it completely since it hasn't been working at all for the last 4 minor versions.

True, but I think we should stick to the normal deprecation process, just to be safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Tue Jan 22 10:51:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 15:51:52 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548172312.44.0.147394080505.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11430

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 10:51:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 15:51:59 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548172319.37.0.968439247121.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11430, 11431

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 10:52:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 15:52:05 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548172325.29.0.680443025031.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11430, 11431, 11432

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:15:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 16:15:05 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1548173705.81.0.34939486064.issue35720@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 35ca1820e19f81f69073f294503cdcd708fe490f by Victor Stinner (Lucas Cimon) in branch 'master':
bpo-35720: Fixing a memory leak in pymain_parse_cmdline_impl() (GH-11528)
https://github.com/python/cpython/commit/35ca1820e19f81f69073f294503cdcd708fe490f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:16:03 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Jan 2019 16:16:03 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1548173763.66.0.910186215327.issue35720@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11433

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:16:09 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Jan 2019 16:16:09 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1548173769.38.0.918927170291.issue35720@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11433, 11434

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:19:14 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Jan 2019 16:19:14 +0000
Subject: [issue35779] Print friendly version message in REPL
In-Reply-To: <1547865815.91.0.564607608514.issue35779@roundup.psfhosted.org>
Message-ID: <1548173954.92.0.792893728353.issue35779@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Hi Ma Lin!  Thanks for the suggestion.  We appreciate your interest in making Python better.

It's unclear from your messages what is motivating your request.  You mentioned middle school students, but that didn't sound like your actual motivator.  Knowing what problems the current message has caused will help us identify the appropriate solution (including potentially the one you've suggested).  So would you mind clarifying what would be the concrete value of simplifying the initial version message printed by the REPL?

As Steven noted, there are several valid reasons to keep the message as-is:

* it's pretty much the same as it's always been (this matters because, for better or worse, sometimes people rely on the format)
* the full information can be useful when a user submits a bug report here
* the code that produces that version string is simpler (granted, the maintenance burden wouldn't change much)
* any change introduces churn (though this wouldn't cause much, it's still something)
* "status quo wins a stalemate" [1]

Also note that the REPL version messages (along with `sys.version`) aren't particularly useful for programatically dealing with the Python version.  Here are better options for that:

* python3 --version
* sys.version_info

Finally, I'd strongly recommend that you submit a pull request to go along with this issue.  If we've done a good job then you should find the experience rewarding, even if the PR is rejected.  The change should be fairly small and localized to one place in one file.  Don't forget to add yourself to the Misc/ACKS file. :)  If you'd like some help then check out the "core mentorship" resources. [2]  The mailing list is a great place to start.  We'd love to add you to our growing list of contributors.


[1] https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
[2] https://www.python.org/dev/core-mentorship/

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:39:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 16:39:06 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548175146.12.0.265958228834.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset bf4ac2d2fd520c61306b2676db488adab9b5d8c5 by Victor Stinner in branch 'master':
bpo-35713: Rework Python initialization (GH-11647)
https://github.com/python/cpython/commit/bf4ac2d2fd520c61306b2676db488adab9b5d8c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:42:16 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Jan 2019 16:42:16 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1548175336.49.0.713527644149.issue35720@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f71e7433ebccb2e3a2665b93bb84de38f9c581c8 by Miss Islington (bot) in branch '3.7':
bpo-35720: Fixing a memory leak in pymain_parse_cmdline_impl() (GH-11528)
https://github.com/python/cpython/commit/f71e7433ebccb2e3a2665b93bb84de38f9c581c8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Tue Jan 22 11:43:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 16:43:52 +0000
Subject: [issue35720] Memory leak in Modules/main.c:pymain_parse_cmdline_impl
 when using the CLI flag
In-Reply-To: <1547234042.68.0.95184796304.issue35720@roundup.psfhosted.org>
Message-ID: <1548175432.01.0.632044513374.issue35720@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Lucas Cimon!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35720>
_______________________________________

From report at bugs.python.org  Tue Jan 22 12:16:43 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Jan 2019 17:16:43 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
Message-ID: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

tl;dr Should all objects in sys.modules look like module objects?

In #35791 Ronald described a problem with a "module" added to sys.modules that does not have all the attributes a module should have.  He also mentioned a similar problem with typing.io [1]:

    BTW. Typing.io is a namespace added to sys.modules by
    the typing module that also does not have __spec__, and
    causes similar problems. I have an simple workaround for
    that on my side.

I've verified the missing module attributes (using 3.8):

    >>> old = sorted(sys.modules)
    >>> import typing
    >>> new = sorted(sys.modules)
    >>> assert sorted(set(old) - set(new)) == []
    >>> sorted(set(new) - set(old))
    ['_collections', '_functools', '_heapq', '_locale',
     '_operator', '_sre', 'collections', 'collections.abc',
     'contextlib', 'copyreg', 'enum', 'functools', 'heapq',
     'itertools', 'keyword', 'operator', 're', 'reprlib',
     'sre_compile', 'sre_constants', 'sre_parse', 'types',
     'typing', 'typing.io', 'typing.re']
    >>> [name for name in vars(sys.modules['typing.io']) if name.startswith('__')]
    ['__module__', '__doc__', '__all__', '__dict__', '__weakref__']
    >>> [name for name in vars(sys.modules['typing.re']) if name.startswith('__')]
    ['__module__', '__doc__', '__all__', '__dict__', '__weakref__']

Per the language reference [2], modules should have the following attributes:

__name__
__loader__
__package__
__spec__

Modules imported from files also should have __file__ and __cached__.  (For the sake of completeness, packages also should have a __path__ attribute.)

As seen above, typing.io and typing.re don't have any of the import-related attributes.

So, should those two "modules" have all those attributes added?  I'm in favor of saying that every sys.modules entry must have all the appropriate import-related attributes (but doesn't have to be an actual module object).  Otherwise tools (e.g. importlib.reload(), Ronald's) making that (arguably valid) assumption break.  The right place for the change in the language reference is probably the "module cache" section. [3]  The actual entry for sys.modules [4] is probably fine as-is.


[1] https://bugs.python.org/issue35791#msg334212
[2] https://docs.python.org/3/reference/import.html#module-spec
[3] https://docs.python.org/3/reference/import.html#the-module-cache
[4] https://docs.python.org/3/library/sys.html#sys.modules

----------
components: Library (Lib)
messages: 334222
nosy: barry, brett.cannon, eric.snow, gvanrossum, ncoghlan, ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: typing module adds objects to sys.modules that don't look like modules
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Tue Jan 22 12:17:26 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 22 Jan 2019 17:17:26 +0000
Subject: [issue35791] Unexpected exception with importlib
In-Reply-To: <1548005903.93.0.648072616722.issue35791@roundup.psfhosted.org>
Message-ID: <1548177446.01.0.940817644136.issue35791@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I opened #35806 for typing.io.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35791>
_______________________________________

From report at bugs.python.org  Tue Jan 22 12:39:23 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Jan 2019 17:39:23 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548178763.84.0.106120607437.issue35806@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

It's been a somewhat well-known idiom for modules to replace themselves in sys.modules with an object that implements some special behaviors (e.g. dynamic loading). This "just works" and AFAIK people have been doing this for ages. Typically such classes just implement enough machinery so that "import foo; print(foo.bar)" works -- everything else (__file__, __doc__ etc.) is optional.

So I think tools should be robust when they inspect sys.modules and not crash or whine loudly when they find something that's missing a few advanced attributes.

That said, if there's something *useful* we could put in the special attributes for e.g. typing.io, I'm not against it. But I don't think this is a bug.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Tue Jan 22 12:43:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 17:43:44 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548179024.9.0.458164939514.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11435

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 12:43:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 17:43:52 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548179032.6.0.397513096607.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11435, 11436

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 12:44:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 17:44:00 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548179040.21.0.340605840547.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11435, 11436, 11437

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 13:26:44 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Jan 2019 18:26:44 +0000
Subject: [issue35805] email package folds msg-id identifiers using RFC2047
 encoded words where it must not
In-Reply-To: <1548161762.46.0.975813554813.issue35805@roundup.psfhosted.org>
Message-ID: <1548181604.7.0.778096414556.issue35805@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, the correct solution would be to write an actual parser for headers containing message ids.  All the pieces needed to do this already exist in _header_value_parser, it "just" needs a function that glues them together in the right order, and then apply that new top-level parser to the appropriate headers via headerregistry.

See also issue 34881.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35805>
_______________________________________

From report at bugs.python.org  Tue Jan 22 13:34:30 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 22 Jan 2019 18:34:30 +0000
Subject: [issue35802] os.stat / os.lstat always present,
 but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org>
Message-ID: <1548182070.32.0.157111615456.issue35802@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I suspect these conditionals are very old and came from times when we supported some platforms that did not have these APIs.

Are they present on all CPython supported platforms today?

Windows is probably the only one left to verify.

BSD/Linux/Un*xes and modern macOS are POSIX.

macOS <= 9 (classic) has long since died.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35802>
_______________________________________

From report at bugs.python.org  Tue Jan 22 13:50:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 18:50:04 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1548183004.93.0.868372762505.issue35683@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 28f6cb34f602b9796987904a607dceaf2e4a9e78 by Steve Dower in branch 'master':
bpo-35683: Improve Azure Pipelines steps (GH-11493)
https://github.com/python/cpython/commit/28f6cb34f602b9796987904a607dceaf2e4a9e78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan 22 13:54:21 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 22 Jan 2019 18:54:21 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1548183261.25.0.982424953756.issue33416@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Buildbots are green, this can be now closed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:23:36 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 22 Jan 2019 19:23:36 +0000
Subject: [issue35802] os.stat / os.lstat always present,
 but code checks hastattr(os, 'stat') / hasattr(os, 'lstat')
In-Reply-To: <1548106954.23.0.477810476155.issue35802@roundup.psfhosted.org>
Message-ID: <1548185016.48.0.725594923085.issue35802@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

yep! did my due diligence there, you can check my work on https://github.com/python/cpython/pull/11643

all platforms have these functions since `posixmodule.c` is always compiled and the functions in question are not guarded by preprocessor directives in any way

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35802>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:25:45 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 19:25:45 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1548185145.36.0.758369926526.issue35683@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +11438

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:25:56 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 19:25:56 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1548185156.17.0.630510658322.issue35683@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +11438, 11439

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:26:06 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 19:26:06 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1548185166.08.0.645783123386.issue35683@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +11438, 11439, 11440

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:37:04 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Tue, 22 Jan 2019 19:37:04 +0000
Subject: [issue35807] Update bundled pip to 19.0
Message-ID: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>


New submission from Pradyun Gedam <pradyunsg at gmail.com>:

In line with https://bugs.python.org/issue35277.

Will also update setuptools while I do this. (if no one else gets to it, I'll file a PR tomorrow morning)

----------
components: Library (Lib)
messages: 334230
nosy: dstufft, ncoghlan, paul.moore, pradyunsg
priority: normal
severity: normal
status: open
title: Update bundled pip to 19.0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35807>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:38:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 19:38:49 +0000
Subject: [issue35804] v3.6.8 _ctypes win32 compiled with pgo crash
In-Reply-To: <1548150488.57.0.992942838687.issue35804@roundup.psfhosted.org>
Message-ID: <1548185929.1.0.86548772327.issue35804@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35804>
_______________________________________

From report at bugs.python.org  Tue Jan 22 14:51:32 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jan 2019 19:51:32 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548186692.37.0.530469084463.issue35806@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The reason I filed #35791 is that I'm rewriting modulegraph[1] using importlib and run into some problems due to importlib.util.find_spec() failing for names that are already imported. 

Working around that in general probably will require reimplementing bits of importlib in my own code and that's something I'd prefer to avoid. The alternative appears to be messing with sys.modules when I run into this problem, which might cause other problem.

BTW. The lack of __spec__ on typing.io and typing.re is not a problem for me, I can use the machinery I already have to insert edges for C extensions to do the right thing for these modules as well. 

[1] https://modulegraph.readthedocs.io/en/latest/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:05:15 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Jan 2019 20:05:15 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548187515.39.0.272637138781.issue35806@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

In response to my previous message: "Messing" with sys.modules appears to be good enough work around for me, at least in the limited testing I've done so far. The new version of modulegraph hasn't seen any testing beyond a largish set of unit tests though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:18:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 22 Jan 2019 20:18:20 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548188300.93.0.888079062135.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 6d43f6f081023b680d9db4542d19b9e382149f0a by Victor Stinner in branch 'master':
bpo-35713: Split _Py_InitializeCore into subfunctions (GH-11650)
https://github.com/python/cpython/commit/6d43f6f081023b680d9db4542d19b9e382149f0a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:30:48 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 20:30:48 +0000
Subject: [issue35795] test_pkgutil test_zipapp fail in AMD64 Windows7 SP1 3.x
 and AMD64 Windows7 SP1 3.7 buildbots
In-Reply-To: <1548068055.8.0.250041418477.issue35795@roundup.psfhosted.org>
Message-ID: <1548189048.43.0.498550467464.issue35795@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I recently added (and even more recently fixed) the "--tempdir" option for libregrtest, so that can be used to specify a temporary location for *most* tests. Some still ignore that setting (notably distutils), but it's a starting point.

I agree that tests need to be cleaning up completely after themselves, but when they fail it's often better to leave the files behind for investigation. Having buildbots clean up completely seems fine to me.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35795>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:31:34 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 20:31:34 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1548189094.27.0.404709763103.issue35683@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 128efcade63480b5860a6d045a41ba4abf5eea2f by Steve Dower in branch '3.7':
bpo-35683: Improve Azure Pipelines steps (GH-11493)
https://github.com/python/cpython/commit/128efcade63480b5860a6d045a41ba4abf5eea2f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:33:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 22 Jan 2019 20:33:21 +0000
Subject: [issue35683] Enable manylinux1 builds on Pipelines for CI testing
In-Reply-To: <1546921151.97.0.533946172892.issue35683@roundup.psfhosted.org>
Message-ID: <1548189201.38.0.606877263823.issue35683@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

As mentioned above, those changes are other improvements that were worth taking, and about half of the required manylinux1 changes. But we probably need to maintain our own manylinux image for building/running CPython tests, if we want to do it. The existing images are all designed for having CPython already present to build a range of binaries, which is not at all our use case.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35683>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:36:13 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Tue, 22 Jan 2019 20:36:13 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548189373.41.0.170782931743.issue27035@roundup.psfhosted.org>


Kumar Akshay <k.akshay9721 at gmail.com> added the comment:

Can I work on this?
I noticed the same behaviour as python3.7 in python3.8 from master branch.

----------
nosy: +kakshay

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Tue Jan 22 15:44:57 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Jan 2019 20:44:57 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548189897.42.0.335997842187.issue35806@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

OK, I don't see a bug here. The docs for sys.modules are pretty vague -- I don't believe they imply that all values in sys.modules must have every attribute of a Module object.

----------
resolution:  -> wont fix
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Tue Jan 22 16:18:04 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 22 Jan 2019 21:18:04 +0000
Subject: [issue35779] Print friendly version message in REPL
In-Reply-To: <1547890513.5.0.413501733867.issue35779@roundup.psfhosted.org>
Message-ID: <20190122211757.GC13616@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> We only print simplified message in official binary release, any 
> Linux/private builds still using the current message. We know enough 
> information about official binary release.

Who is "we" in this sentence?

Are you saying that the Python.org binary releases here:

https://www.python.org/downloads/release/python-372/

for example don't print the same information as source releases? I 
don't have either Windows or Mac and so cannot test it for myself.

> Junior users are people such as students learning programming in 
> middle school, I think git information will confuse them, maybe many 
> of them will never know git knowledges.

Why is this important? Surely they won't be tested on their 
understanding of the git tag information printed at startup. They can 
just ignore the information.

If you are really going to push this idea that the information currently 
printed at startup is confusing to beginners, then we can ask educators 
like Raymond Hettinger and others who have been teaching Python for many 
years and see what their experience has been.

But for what it is worth, in 15+ years of asking questions from 
beginners on various mailing lists, I don't believe I have ever seen 
anyone ask about that information. If it happens, it happens rarely.

> Another problem is indicating 32bit or 64bit build, IMHO this is an 
> useful information.

And that information is currently printed at startup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Tue Jan 22 16:55:33 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 22 Jan 2019 21:55:33 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548194133.09.0.253843937071.issue35797@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The current solution is the simplest one that ensures the most 
> compatibility for the least amount of risk, even though that 
> was not zero risk, as we've seen. 

How about making the py[w].exe launcher unset __PYVENV_LAUNCHER__ whenever it runs a registered version explicitly?

We could also modify the embedded-script (entry-point) launchers, which would be simpler if we had them in core instead of distlib. They could be updated to look for pyvenv.cfg. If found, it would override the shebang and set the __PYVENV_LAUNCHER__ environment variable. This would eliminate the interjected process in a 3.7.2 virtual environment, e.g. pip.exe -> python.exe (venv launcher) -> python.exe (installed) would become pip.exe -> python.exe (installed). More importantly, it would unset __PYVENV_LAUNCHER__ in case it's not a virtual environment script. 

This way running pip.exe for an installed Python won't end up installing into a virtual environment, as can happen now in 3.7.2. For example:

    >>> print(os.environ['__PYVENV_LAUNCHER__'])
    C:\Temp\env37\Scripts\python.exe

    >>> import requests
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ModuleNotFoundError: No module named 'requests'

    >>> pip = 'Scripts\\pip.exe'
    >>> out = subprocess.check_output('{} install requests'.format(pip))

    >>> import requests
    >>> requests.__version__
    '2.21.0'

Note that "Scripts\\pip.exe" in a CreateProcess command line gets resolved first relative to the application directory, before trying the current directory, system directories, and PATH directories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Tue Jan 22 17:55:33 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 22 Jan 2019 22:55:33 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548197733.55.0.479479966701.issue27035@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think this is a documentation issue today. The docs say:

>If an exception is raised during execution of the exit handlers, a traceback
>is printed (unless SystemExit is raised) and the exception 
>information is saved. After all exit handlers have had a chance to run the
>last exception to be raised is re-raised.

Which is true except for two things:

- SystemExit is not covered by the paragraph (it just says that SystemExit will not print a traceback but what actually happens is that is ignored).
- The last exception is not re-raised (as it was on Python2.7).

I think we should update the docs to reflect that SystemExit is ignored and to remove that the last exception is re-raised.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Tue Jan 22 17:56:19 2019
From: report at bugs.python.org (Emily Morehouse)
Date: Tue, 22 Jan 2019 22:56:19 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1548197779.71.0.673024741073.issue33416@roundup.psfhosted.org>


Change by Emily Morehouse <emilyemorehouse at gmail.com>:


----------
pull_requests: +11441

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Tue Jan 22 17:59:32 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 22 Jan 2019 22:59:32 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548197972.33.0.469450815314.issue27035@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The behaviour regarding printing SytemExit was changed by Serhiy in 3fd54d4a7e604067e2bc0f8cfd58bdbdc09fa7f4 and in bpo-28994.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Tue Jan 22 18:00:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 22 Jan 2019 23:00:43 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548198043.3.0.936259555958.issue27035@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

@ Kumar Do you want to make a PR fixing the docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Tue Jan 22 19:57:19 2019
From: report at bugs.python.org (David Heiberg)
Date: Wed, 23 Jan 2019 00:57:19 +0000
Subject: [issue5038] urrlib2/httplib doesn't reset file position between
 requests
In-Reply-To: <1232730438.9.0.904675957675.issue5038@psf.upfronthosting.co.za>
Message-ID: <1548205039.65.0.0543756633182.issue5038@roundup.psfhosted.org>


Change by David Heiberg <dhdavvie at gmail.com>:


----------
nosy: +dheiberg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5038>
_______________________________________

From report at bugs.python.org  Tue Jan 22 20:00:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 23 Jan 2019 01:00:20 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548205220.66.0.253300636744.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> How about making the py[w].exe launcher unset __PYVENV_LAUNCHER__ whenever it runs a registered version explicitly?

I think this is a good idea, though it can be unset unconditionally. If we're in a virtual environment, then it will run the intermediate process which will set the variable again (this is unavoidable unless we include specialized knowledge in the launcher to find the base python.exe from the pyvenv.cfg, which I'd rather not duplicate in so many places, when you consider that the script launcher will need it too).

As for updating the script launchers, on one hand I'd love to have them, but on the other it's more for us to maintain and there's definitely been benefit from it being backported for us. As long as they run the correct python.exe, I think it's fine.

I think that CreateProcess oddity where it searches the current process's directory first is going to catch people out regardless (I'm surprised it hasn't come up before), but I guess most people play it safe and use full paths.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Tue Jan 22 20:41:19 2019
From: report at bugs.python.org (Yuuji KAWAMATSU)
Date: Wed, 23 Jan 2019 01:41:19 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548207679.22.0.0978590536986.issue35781@roundup.psfhosted.org>


Change by Yuuji KAWAMATSU <kawamatsu_yuuji at kurusugawa.jp>:


----------
keywords: +patch
pull_requests: +11442
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Tue Jan 22 20:41:30 2019
From: report at bugs.python.org (Yuuji KAWAMATSU)
Date: Wed, 23 Jan 2019 01:41:30 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548207690.47.0.428480508322.issue35781@roundup.psfhosted.org>


Change by Yuuji KAWAMATSU <kawamatsu_yuuji at kurusugawa.jp>:


----------
keywords: +patch, patch
pull_requests: +11442, 11443
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Tue Jan 22 20:41:41 2019
From: report at bugs.python.org (Yuuji KAWAMATSU)
Date: Wed, 23 Jan 2019 01:41:41 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548207701.08.0.0101722071367.issue35781@roundup.psfhosted.org>


Change by Yuuji KAWAMATSU <kawamatsu_yuuji at kurusugawa.jp>:


----------
keywords: +patch, patch, patch
pull_requests: +11442, 11443, 11444
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Tue Jan 22 22:02:48 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 23 Jan 2019 03:02:48 +0000
Subject: [issue35779] Print friendly version message in REPL
In-Reply-To: <1547865815.91.0.564607608514.issue35779@roundup.psfhosted.org>
Message-ID: <1548212568.58.0.0159404750711.issue35779@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Hi, thanks for your replies.

To be honest, the reason is I fell it's a bit ugly, this line is very long at REPL startup. And the information is not very clear [1].

I'm not strongly pushing this idea, just raise my feeling, keep it easy. :)

Yes, after this discussion, I suppose simplified message only printed in Windows/Mac official binary releases. Just print at REPL startup, don't change sys.version.

Python 3.7.2 (64 bit, Dec 23 2018) on Windows
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.version
'3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)]'


[1] How do I determine if my python shell is executing in 32bit or 64bit mode on OS X?
[1] https://stackoverflow.com/questions/1405913/how-do-i-determine-if-my-python-shell-is-executing-in-32bit-or-64bit-mode-on-os

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Tue Jan 22 22:50:39 2019
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 23 Jan 2019 03:50:39 +0000
Subject: [issue20911] urllib 'headers' is not a well defined data type
In-Reply-To: <1394724454.41.0.246031763328.issue20911@psf.upfronthosting.co.za>
Message-ID: <1548215439.25.0.425298810259.issue20911@roundup.psfhosted.org>


Demian Brecht <demianbrecht at gmail.com> added the comment:

@R. David Murray

Is this issue still valid? Running 3.6 it seems that http and ftp are consistent at any rate (http returns http.client.HTTPMessage and ftp returns email.message.Message). If it's still an issue, could you please elaborate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20911>
_______________________________________

From report at bugs.python.org  Wed Jan 23 00:32:20 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Jan 2019 05:32:20 +0000
Subject: [issue35808] Let's retire pgen
Message-ID: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

Pgen is literally the oldest piece of technology in the CPython repo -- it was the first thing I wrote for Python over 29 years ago. It's not aged well, and building it requires various #if[n]def PGEN hacks in other parts of the code; it also depends more and more on CPython internals. There already is a replacement written in pure Python (Lib/lib2to3/pgen/), it just needs some glue to actually generate the graminit.[ch] files. Note that several other essential generation steps (everything listed for regen-all except regen-importlib and clinic) already depend on having a working Python interpreter around, so let's not worry about the bootstrapping process.

----------
components: Build
messages: 334247
nosy: gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: Let's retire pgen
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35808>
_______________________________________

From report at bugs.python.org  Wed Jan 23 00:54:47 2019
From: report at bugs.python.org (Ethan Smith)
Date: Wed, 23 Jan 2019 05:54:47 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1548222887.19.0.857629433955.issue35808@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
nosy: +Ethan Smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35808>
_______________________________________

From report at bugs.python.org  Wed Jan 23 00:55:42 2019
From: report at bugs.python.org (Ethan Smith)
Date: Wed, 23 Jan 2019 05:55:42 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548222942.29.0.187473761311.issue35766@roundup.psfhosted.org>


Change by Ethan Smith <ethan at ethanhs.me>:


----------
nosy: +Ethan Smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:08:41 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:08:41 +0000
Subject: [issue35726] QueueHandler formating affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1548227321.95.0.912093272154.issue35726@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset da6424e96ada72c15c91bddb0a411acf7119e10a by Vinay Sajip (Manjusaka) in branch 'master':
bpo-35726: Prevented QueueHandler formatting from affecting other handlers (GH-11537)
https://github.com/python/cpython/commit/da6424e96ada72c15c91bddb0a411acf7119e10a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:10:58 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:10:58 +0000
Subject: [issue35726] QueueHandler formatting affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1548227458.35.0.728145415946.issue35726@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Merged for 3.8, will add backport labels to PR in due course.

----------
title: QueueHandler formating affects other handlers -> QueueHandler formatting affects other handlers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:12:42 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:12:42 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227562.99.0.188317800767.issue35722@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset f0c743604fc841d35a48822b936ef2e5919e43c1 by Vinay Sajip (G?ry Ogam) in branch 'master':
bpo-35722: Updated the documentation for the 'disable_existing_loggers' parameter (GH-11525)
https://github.com/python/cpython/commit/f0c743604fc841d35a48822b936ef2e5919e43c1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:13:46 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:13:46 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227626.03.0.808419587302.issue35722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +11445

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:13:59 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:13:59 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227639.58.0.708155203708.issue35722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11445, 11446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:14:11 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:14:11 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227651.86.0.0101982367056.issue35722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11445, 11446, 11447

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:14:22 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:14:22 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227662.66.0.750931739928.issue35722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11445, 11446, 11447, 11449

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:14:31 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:14:31 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227671.88.0.778413568958.issue35722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: 
pull_requests: +11446, 11447, 11449, 11450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:14:42 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:14:42 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548227682.97.0.453013091626.issue35722@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch, patch, patch, patch, patch
pull_requests: +11445, 11446, 11447, 11448, 11449, 11450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:17:20 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:17:20 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548227840.1.0.439167677003.issue35781@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11444

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:17:39 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:17:39 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548227859.74.0.881942759791.issue35781@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11443

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:21:38 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:21:38 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548228098.23.0.321076112642.issue35722@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 552478bb1086ef371e4f1da0b430b90eba4785d5 by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-35722: Updated the documentation for the 'disable_existing_loggers' parameter (GH-11525) (GH-11655)
https://github.com/python/cpython/commit/552478bb1086ef371e4f1da0b430b90eba4785d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:22:09 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:22:09 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548228129.51.0.876205702836.issue35722@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:22:32 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:22:32 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548228152.45.0.941143363818.issue35722@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11447

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:22:50 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:22:50 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548228170.36.0.473741117608.issue35722@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:23:21 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:23:21 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548228201.93.0.405619604284.issue35722@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11449

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:24:42 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:24:42 +0000
Subject: [issue35722] disable_existing_loggers does not apply to the root
 logger
In-Reply-To: <1547235149.9.0.274775552253.issue35722@roundup.psfhosted.org>
Message-ID: <1548228282.29.0.686587846196.issue35722@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35722>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:27:17 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:27:17 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548228437.92.0.23457050071.issue35781@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset cda73a5af2ff064ca82140342b3158851d43868f by Vinay Sajip (yuji38kwmt) in branch 'master':
bpo-35781: Changed references to deprecated 'warn' method in logging documentation in favour of 'warning' (GH-11654)
https://github.com/python/cpython/commit/cda73a5af2ff064ca82140342b3158851d43868f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:27:27 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:27:27 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548228437.92.0.23457050071.issue35781@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset cda73a5af2ff064ca82140342b3158851d43868f by Vinay Sajip (yuji38kwmt) in branch 'master':
bpo-35781: Changed references to deprecated 'warn' method in logging documentation in favour of 'warning' (GH-11654)
https://github.com/python/cpython/commit/cda73a5af2ff064ca82140342b3158851d43868f


----------
pull_requests: +11451

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:27:29 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 07:27:29 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548228449.25.0.528970455659.issue35781@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11451, 11453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:27:38 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:27:38 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548228437.92.0.23457050071.issue35781@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset cda73a5af2ff064ca82140342b3158851d43868f by Vinay Sajip (yuji38kwmt) in branch 'master':
bpo-35781: Changed references to deprecated 'warn' method in logging documentation in favour of 'warning' (GH-11654)
https://github.com/python/cpython/commit/cda73a5af2ff064ca82140342b3158851d43868f


----------
pull_requests: +11451, 11452, 11453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:27:45 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:27:45 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548228465.17.0.672068152439.issue35781@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:29:24 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:29:24 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548228564.15.0.699409199043.issue35781@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests:  -11452

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:43:41 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:43:41 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548229421.61.0.325897135612.issue35781@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 3be19c082b7f0ba3cf6c28922d3577126871788e by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-35781: Changed references to deprecated 'warn' method in logging documentation in favour of 'warning' (GH-11654) (GH-11657)
https://github.com/python/cpython/commit/3be19c082b7f0ba3cf6c28922d3577126871788e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 02:44:17 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 23 Jan 2019 07:44:17 +0000
Subject: [issue35781] `logger.warn` method is used in "Logging HOWTO"
 documentation though `logger.warn` method is deprecated in Python 3.7
In-Reply-To: <1547873452.27.0.124013164829.issue35781@roundup.psfhosted.org>
Message-ID: <1548229457.15.0.0396672908637.issue35781@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35781>
_______________________________________

From report at bugs.python.org  Wed Jan 23 05:10:39 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 23 Jan 2019 10:10:39 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1548238239.64.0.724917507669.issue10915@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Wed Jan 23 05:44:03 2019
From: report at bugs.python.org (Richard Whitehead)
Date: Wed, 23 Jan 2019 10:44:03 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>
Message-ID: <1548240243.42.0.0518978406614.issue18078@roundup.psfhosted.org>


Richard Whitehead <richard.whitehead at ieee.org> added the comment:

Condition.wait_for_any is still a desirable feature, e.g. to wait on multiple command queues, or a work queue and a command queue.
Is there any chance of pulling this into the latest version?

----------
nosy: +richardnwhitehead

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18078>
_______________________________________

From report at bugs.python.org  Wed Jan 23 06:48:52 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 23 Jan 2019 11:48:52 +0000
Subject: [issue20911] urllib 'headers' is not a well defined data type
In-Reply-To: <1394724454.41.0.246031763328.issue20911@psf.upfronthosting.co.za>
Message-ID: <1548244132.34.0.876507538668.issue20911@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20911>
_______________________________________

From report at bugs.python.org  Wed Jan 23 07:30:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 12:30:17 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548246617.81.0.299984470459.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11454

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Wed Jan 23 07:30:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 12:30:24 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548246624.66.0.499722292684.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11454, 11455

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Wed Jan 23 07:30:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 12:30:30 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548246630.74.0.0257274159932.issue35713@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11454, 11455, 11456

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:15:17 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 23 Jan 2019 13:15:17 +0000
Subject: [issue35726] QueueHandler formatting affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1548249317.41.0.797911486781.issue35726@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11457

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:15:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 23 Jan 2019 13:15:26 +0000
Subject: [issue35726] QueueHandler formatting affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1548249326.36.0.827324870585.issue35726@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11457, 11458

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:15:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 23 Jan 2019 13:15:34 +0000
Subject: [issue35726] QueueHandler formatting affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1548249334.72.0.697998599298.issue35726@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11457, 11458, 11459

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:15:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 23 Jan 2019 13:15:41 +0000
Subject: [issue35726] QueueHandler formatting affects other handlers
In-Reply-To: <1547301313.72.0.148950825212.issue35726@roundup.psfhosted.org>
Message-ID: <1548249341.79.0.490371768408.issue35726@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +11457, 11458, 11459, 11460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35726>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:48:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 23 Jan 2019 13:48:23 +0000
Subject: [issue35809]
 test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest fails
 intermittently on Travis and passes in verbose mode
Message-ID: <1548251301.46.0.302427080079.issue35809@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I can see this test failing intermittently many times on Travis during the first run and to pass later during a verbose run hence the failure is not visible. I don't know the exact cause and haven't checked the buildbots. Search also didn't bring up anything so I thought to file a new issue for this.

Stack trace : 

======================================================================
FAIL: test_crash (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) [crash at task unpickle]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 958, in test_crash
    res.result(timeout=self.TIMEOUT)
  File "/home/travis/build/python/cpython/Lib/concurrent/futures/_base.py", line 438, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 962, in test_crash
    self._fail_on_deadlock(executor)
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 910, in _fail_on_deadlock
    self.fail(f"Executor deadlock:\n\n{tb}")
AssertionError: Executor deadlock:
Thread 0x00002b5105ca3700 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/threading.py", line 296 in wait
  File "/home/travis/build/python/cpython/Lib/multiprocessing/queues.py", line 227 in _feed
  File "/home/travis/build/python/cpython/Lib/threading.py", line 865 in run
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/travis/build/python/cpython/Lib/threading.py", line 885 in _bootstrap
Thread 0x00002b510584c700 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/selectors.py", line 415 in select
  File "/home/travis/build/python/cpython/Lib/multiprocessing/connection.py", line 930 in wait
  File "/home/travis/build/python/cpython/Lib/concurrent/futures/process.py", line 354 in _queue_management_worker
  File "/home/travis/build/python/cpython/Lib/threading.py", line 865 in run
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/travis/build/python/cpython/Lib/threading.py", line 885 in _bootstrap
Current thread 0x00002b50fe39c9c0 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 901 in _fail_on_deadlock
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 962 in test_crash
  File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 642 in run
  File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 702 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/runner.py", line 176 in run
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 1935 in _run_suite
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 2031 in run_unittest
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 1241 in test_main
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 2163 in decorator
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 182 in runtest_inner
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 127 in runtest
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest_mp.py", line 68 in run_tests_worker
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 600 in _main
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 586 in main
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 640 in main
  File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 46 in _main
  File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 50 in <module>
  File "/home/travis/build/python/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/travis/build/python/cpython/Lib/runpy.py", line 192 in _run_module_as_main


Sample crash : https://travis-ci.org/python/cpython/jobs/483394585#L2781

----------
components: Tests
messages: 334255
nosy: bquinlan, pablogsal, pitrou, vstinner, xtreak
priority: normal
severity: normal
status: open
title: test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest fails intermittently on Travis and passes in verbose mode
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35809>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:53:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 23 Jan 2019 13:53:51 +0000
Subject: [issue28890] logging.handlers: Document that QueueListener is a
 daemon thread
Message-ID: <1548251631.42.0.573822466432.issue28890@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip, xtreak
versions: +Python 3.7, Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28890>
_______________________________________

From report at bugs.python.org  Wed Jan 23 08:59:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 13:59:22 +0000
Subject: [issue35809]
 test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest fails
 intermittently on Travis and passes in verbose mode
In-Reply-To: <1548251301.46.0.302427080079.issue35809@roundup.psfhosted.org>
Message-ID: <1548251962.67.0.890856598573.issue35809@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Sample crash : https://travis-ci.org/python/cpython/jobs/483394585#L2781

Some info from pythoninfo, not sure if they are relevant:

CC.version: clang version 5.0.0 (tags/RELEASE_500/final)
platform.libc_ver: glibc 2.19
platform.platform: Linux-4.4.0-104-generic-x86_64-with-glibc2.17
sys.thread_info: sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.19')
sys.version: 3.8.0a0 (heads/master-2-g5b3e8e9:5b3e8e9, Jan 23 2019, 13:18:30)  [Clang 5.0.0 (tags/RELEASE_500/final)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35809>
_______________________________________

From report at bugs.python.org  Wed Jan 23 09:00:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 14:00:22 +0000
Subject: [issue33686] test_concurrent_futures: test_pending_calls_race()
 failed on x86 Windows7 3.6
In-Reply-To: <1527626766.22.0.682650639539.issue33686@psf.upfronthosting.co.za>
Message-ID: <1548252022.49.0.275952223669.issue33686@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Should be fixed by bpo-33716.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33686>
_______________________________________

From report at bugs.python.org  Wed Jan 23 09:04:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 14:04:42 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548252282.59.0.601107626157.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset ab67281e95de1a88c4379a75a547f19a8ba5ec30 by Victor Stinner in branch 'master':
bpo-35713: Reorganize sys module initialization (GH-11658)
https://github.com/python/cpython/commit/ab67281e95de1a88c4379a75a547f19a8ba5ec30


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Wed Jan 23 09:06:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 14:06:29 +0000
Subject: [issue35713] Fatal Python error: _PySys_BeginInit: can't initialize
 sys module
In-Reply-To: <1547159731.63.0.590496502832.issue35713@roundup.psfhosted.org>
Message-ID: <1548252389.97.0.700683020313.issue35713@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

"""
> Fatal Python error: _PySys_BeginInit: can't initialize sys module

I have no idea why you get this error. You should try to run this function in a debugger like gdb and run the code step by step to see what happens.
"""

I pushed 3 changes to get working exceptions and working sys.stderr earlier during Python initialization. It should help to display the current exceptions when Py_FatalError() is called during early stage of the Python initialization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35713>
_______________________________________

From report at bugs.python.org  Wed Jan 23 09:17:24 2019
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 23 Jan 2019 14:17:24 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za>
Message-ID: <1548253044.41.0.0491501602206.issue18078@roundup.psfhosted.org>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

Don't keep your hopes up. People here don't like implementing features they don't understand about even if they could verify elsewhere it works well.

My solution at the time was to create a decent "Condition" class based on the original one (subclassing this one is not safe). Feel free to use my patch above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18078>
_______________________________________

From report at bugs.python.org  Wed Jan 23 10:47:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 15:47:02 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
 not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1548258422.69.0.871078061976.issue10112@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Wed Jan 23 10:52:57 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 23 Jan 2019 15:52:57 +0000
Subject: [issue35680] [2.7] Coverity scan: Passing freed pointer "name" as an
 argument to "Py_BuildValue" in _bsddb module.
In-Reply-To: <1546879265.59.0.976013250068.issue35680@roundup.psfhosted.org>
Message-ID: <1548258777.13.0.854037783603.issue35680@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Closing this as it's not really a bug in the code, and I don't think spending too much time on python2 is worth it.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35680>
_______________________________________

From report at bugs.python.org  Wed Jan 23 11:07:08 2019
From: report at bugs.python.org (Eric Snow)
Date: Wed, 23 Jan 2019 16:07:08 +0000
Subject: [issue35779] Print friendly version message in REPL
In-Reply-To: <1547865815.91.0.564607608514.issue35779@roundup.psfhosted.org>
Message-ID: <1548259628.28.0.41493646888.issue35779@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for clarifying, Ma Lin.  At this point there just isn't enough strong justification for making any change here.  So I'm closing the issue.

Also, making a PR for this likely wouldn't be the best use of your time.  However, if you're interested in contributing to Python there are plenty of interesting problems to solve in open tracker issues.  I'd be glad to help you get started if you're interested. :)

----------
components: +Interpreter Core
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35779>
_______________________________________

From report at bugs.python.org  Wed Jan 23 11:38:28 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Wed, 23 Jan 2019 16:38:28 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548261508.8.0.921260440399.issue27035@roundup.psfhosted.org>


Kumar Akshay <k.akshay9721 at gmail.com> added the comment:

Sure, I would love to!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Wed Jan 23 11:56:51 2019
From: report at bugs.python.org (George King)
Date: Wed, 23 Jan 2019 16:56:51 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548262611.65.0.103117115802.issue27035@roundup.psfhosted.org>


George King <george.w.king at gmail.com> added the comment:

I agree that regardless of the underlying issue, the docs should match the behavior. Additionally, I hope the docs will note the exact release at which the behavior changed.

@serhiy-storchaka do you have any opinion on this? I took a brief look at your commit cited above, and it appears that you were trying to suppress an unwanted stack trace display. Did you intend for the exit status behavior to also change?

I stand by my original assessment, as a somewhat dissatisfied user of the `atexit` feature. However I also acknowledge that at this point, CPython already has a subtle backwards-compatibility issue and further change might not be so welcome. I'm happy to discuss this further if people are interested, but I'm not going to lobby hard :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Wed Jan 23 12:17:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 17:17:27 +0000
Subject: [issue35711] Print information about an unexpectedly pending error
 before crashing
In-Reply-To: <1547153879.73.0.173283479509.issue35711@roundup.psfhosted.org>
Message-ID: <1548263847.83.0.832359686926.issue35711@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> A failure (crash) from such asserts provides no information on its own about the unhandled exception itself to help the developer track down the C API use error that led to this state.

Maybe someone should try to modify faulthandler to display the current exception?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35711>
_______________________________________

From report at bugs.python.org  Wed Jan 23 12:19:30 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 23 Jan 2019 17:19:30 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1548263970.27.0.292255429801.issue10915@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch probably doesn't apply anymore.

----------
stage: patch review -> needs patch
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Wed Jan 23 12:24:30 2019
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 23 Jan 2019 17:24:30 +0000
Subject: [issue34656] [CVE-2018-20406] memory exhaustion in
 Modules/_pickle.c:1393
In-Reply-To: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>
Message-ID: <1548264270.98.0.575380619828.issue34656@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

Python 3.4 doesn't allow C99 constructs, so I had to update the patch to reorder iterator declarations. Just if any future colleague Python Linux distro maintainer needs it.

----------
Added file: https://bugs.python.org/file48073/CVE-2018-20406-pickle_LONG_BINPUT.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34656>
_______________________________________

From report at bugs.python.org  Wed Jan 23 13:00:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jan 2019 18:00:43 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548266443.78.0.441985743481.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f6243ac1e4828299fe5a8e943d7bd41cab1f34cd by Victor Stinner in branch 'master':
bpo-35537: subprocess can use posix_spawn with pipes (GH-11575)
https://github.com/python/cpython/commit/f6243ac1e4828299fe5a8e943d7bd41cab1f34cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 23 13:13:59 2019
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 23 Jan 2019 18:13:59 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1548267239.55.0.251229073104.issue23903@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Wed Jan 23 13:29:44 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 23 Jan 2019 18:29:44 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548268184.32.0.157955807934.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Another problem with posix_spawn() on glibc: it doesn't report errors to the parent process when run under QEMU user-space emulation and Windows Subsystem for Linux. This is because starting with commit [1] (glibc 2.25) posix_spawn()  relies on address space sharing semantics of clone(CLONE_VM) to report errors, but it's not implemented in QEMU and WSL, so clone(CLONE_VM) and vfork() behave like fork(). See also [2], [3].

This can be easily demonstrated:
$ cat test.c
#include <spawn.h>

int main(int argc, char *argv[], char *envp[]) {
    return posix_spawn(0, "non-existing", 0, 0, argv, envp);
}

$ gcc test.c
$ ./a.out
$ echo $?
2
$ aarch64-linux-gnu-gcc -static test.c
$ qemu-aarch64 ./a.out
$ echo $?
0

There is no problem with musl (it doesn't rely on address space sharing).

[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=4b4d4056bb154603f36c6f8845757c1012758158
[2] https://bugs.launchpad.net/qemu/+bug/1673976
[3] https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04890.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:18:43 2019
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jan 2019 20:18:43 +0000
Subject: [issue20911] urllib 'headers' is not a well defined data type
In-Reply-To: <1394724454.41.0.246031763328.issue20911@psf.upfronthosting.co.za>
Message-ID: <1548274723.27.0.0181314717834.issue20911@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

There has been considerable rewriting of the header handling code since I filed this.  I would not be surprised if the issue is no longer valid.  If you want to double check, look for the places that the headers attribute is created in the various handlers.  Otherwise you can just close this as out of date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20911>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:35:54 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Wed, 23 Jan 2019 20:35:54 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
Message-ID: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

Heap-allocated Types initializing instances through `PyObject_{,GC}_New{Var}` will *NOT* not have their refcnt increased. This was totally fine under the assumption that static types are immortal. However, heap-allocated types MUST participate in refcounting. Furthermore, their deallocation routine should also make sure to decrease their refcnt to provide the incref/decref pair.

----------
components: Library (Lib)
messages: 334271
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Object Initialization Bug with Heap-allocated Types
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:40:20 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Wed, 23 Jan 2019 20:40:20 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1548276020.01.0.341097319197.issue35810@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch
pull_requests: +11461
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:40:23 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Wed, 23 Jan 2019 20:40:23 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1548276023.39.0.722729854318.issue35810@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11461, 11462
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:40:27 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Wed, 23 Jan 2019 20:40:27 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1548276027.31.0.215871493033.issue35810@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11461, 11462, 11463
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:57:36 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 23 Jan 2019 20:57:36 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1548277056.72.0.474320514558.issue35767@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset fd628cf5adaeee73eab579393cdff71c8f70cdf2 by ?ukasz Langa (Jason Fried) in branch 'master':
bpo-35767: Fix unittest.loader to allow partials as test_functions (#11600)
https://github.com/python/cpython/commit/fd628cf5adaeee73eab579393cdff71c8f70cdf2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:58:12 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 20:58:12 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1548277092.32.0.93624568857.issue35767@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:58:20 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 20:58:20 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1548277100.2.0.184029437463.issue35767@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11464, 11465

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Wed Jan 23 15:58:30 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Jan 2019 20:58:30 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1548277110.01.0.337217857738.issue35767@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11464, 11465, 11466

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Wed Jan 23 16:37:03 2019
From: report at bugs.python.org (Terrence Brannon)
Date: Wed, 23 Jan 2019 21:37:03 +0000
Subject: [issue33342] urllib IPv6 parsing fails with special characters in
 passwords
In-Reply-To: <1524491070.85.0.682650639539.issue33342@psf.upfronthosting.co.za>
Message-ID: <1548279423.94.0.408412599396.issue33342@roundup.psfhosted.org>


Terrence Brannon <metaperl at gmail.com> added the comment:

I would like to add to this bug - the password field on the URL cannot contain a pound sign or question mark or the parser incorrectly parses the URL, as this gist demonstrates - https://gist.github.com/metaperl/fc6f43bf6b9a9f874b8f27e29695e68c

----------
nosy: +metaperl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33342>
_______________________________________

From report at bugs.python.org  Wed Jan 23 17:45:26 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Jan 2019 22:45:26 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
 line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1548283526.51.0.667880039994.issue5028@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
components: +Documentation -Library (Lib)
keywords: +easy
stage:  -> needs patch
versions: +Python 3.8 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Wed Jan 23 18:34:41 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Jan 2019 23:34:41 +0000
Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly
 one arg
In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>
Message-ID: <1548286481.78.0.279633900825.issue18610@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +11467
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18610>
_______________________________________

From report at bugs.python.org  Wed Jan 23 18:34:50 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Jan 2019 23:34:50 +0000
Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly
 one arg
In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>
Message-ID: <1548286490.9.0.369783146426.issue18610@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +11467, 11468
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18610>
_______________________________________

From report at bugs.python.org  Wed Jan 23 18:34:59 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Jan 2019 23:34:59 +0000
Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly
 one arg
In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>
Message-ID: <1548286499.79.0.0894875006003.issue18610@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +11467, 11468, 11469
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18610>
_______________________________________

From report at bugs.python.org  Wed Jan 23 18:51:44 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Jan 2019 23:51:44 +0000
Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly
 one arg
In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>
Message-ID: <1548287504.28.0.623676073447.issue18610@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -11468

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18610>
_______________________________________

From report at bugs.python.org  Wed Jan 23 18:51:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Jan 2019 23:51:54 +0000
Subject: [issue18610] wsgiref.validate expects wsgi.input read to give exactly
 one arg
In-Reply-To: <1375310901.82.0.276465395742.issue18610@psf.upfronthosting.co.za>
Message-ID: <1548287514.99.0.154753138278.issue18610@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests:  -11469

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18610>
_______________________________________

From report at bugs.python.org  Wed Jan 23 19:06:12 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 24 Jan 2019 00:06:12 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1548288372.85.0.941153810554.issue33166@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Added #32592 as a dependency since that is removing the Vista code mentioned here.  Once that change is merged, then this would be a simpler change to make.

----------
dependencies: +Drop support of Windows Vista in Python 3.7
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Jan 23 19:08:39 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 24 Jan 2019 00:08:39 +0000
Subject: [issue33166] os.cpu_count() returns wrong number of processors on
 specific systems
Message-ID: <1548288519.85.0.514410404608.issue33166@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33166>
_______________________________________

From report at bugs.python.org  Wed Jan 23 19:48:17 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 24 Jan 2019 00:48:17 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
Message-ID: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

In 3.7.2 on Windows, venv now uses a redirecting launcher 'script' for python[w].exe. This replaces (on Windows only) the setup requirement to copy or symlink the interpreter binaries (i.e. python[w].exe, python37.dll, and vcruntime140.dll). Apparently this is required to be able to install Python as a Windows Store app. I haven't experimented with it yet, so I'll just accept that as a given. I'm curious to find out whether using symlinks would still work, and even if it doesn't work for the app installation, whether we could still support that option for desktop installations. I've used `--symlinks` for a while now, since I grant the required privilege to the authenticated users group and thus don't have to elevate to create symlinks. (I know it's not so easy for many Windows users.)

The new launcher reads pyvenv.cfg to locate and execute the real python.exe. Since the process image is no longer in the virtual environment's "Scripts" directory (which has various consequences), we need a way to communicate the launcher's path to make Python use the virtual environment. A -X command-line option could work, but then all packages and tools that spawn worker processes, such as multiprocessing, would need to be updated to look for this option in sys._xoptions and propagate it. Instead the launcher sets a special "__PYVENV_LAUNCHER__" environment variable. This is reasonable because processes are usually created with a copy of the parent's environment. Some environment variables may be added or modified, but it's rare for a child process to get a completely new environment. (One example of the latter would be creating a process that runs as a different user.)

An oversight in the current ecosystem is that py.exe and the distlib entry-point launchers do not unset "__PYVENV_LAUNCHER__". Thus, when executing a script from a virtual environment (e.g. either directly via py.exe or via the .py file association), it will mistakenly be pinned into the virtual environment if it runs in Python 3.7. Similarly, pip.exe for an installed Python 3.7 will mistakenly install into the virtual environment. However, the latter is out of scope here since the entry-point launchers are in distlib. 

It's also a problem if we run the fully-qualified path for an installed Python 3.7, e.g. from shutil.which('python'). We can't automatically address this since it's exactly the reason "__PYVENV_LAUNCHER__" exists. We have to know to manually unset "__PYVENV_LAUNCHER__" in the environment that's passed to the child. This should be documented somewhere -- maybe in the venv docs.

It's not a problem if a script runs unqualified "python.exe" since the final result is usually the same, but for different reasons. With the launcher, it's locked down by inheriting "__PYVENV_LAUNCHER__". With the previous design, the application directory was the virtual environment's "Scripts" directory. Unqualified "python.exe" was thus pinned for CreateProcessW, which checks the application directory first. It's also not a problem if we run sys.executable, since previously that was the virtual environment's executable. (In 3.7.2, sys.executable gets set to the virtual environment's launcher, but that breaks multiprocessing. See issue 35797.)

----------
components: Windows
messages: 334275
nosy: eryksun, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: py.exe should unset the __PYVENV_LAUNCHER__ environment variable
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Wed Jan 23 19:58:53 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 24 Jan 2019 00:58:53 +0000
Subject: [issue35812] Don't log an exception from the main coroutine in
 asyncio.run()
Message-ID: <1548291532.01.0.358121522852.issue35812@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

We use `asyncio.run()` (well, a backported to python3.6 private copy) in our application.

The problem is: when `asyncio.run(main_coro(args))` raises an exception it is both raised to a caller and passed to `loop.call_exception_handler()` by `_cancel_all_tasks()` as *unhandled exception*.

I believe that the logging of unhandled exceptions is a very useful feature but the logging should be skipped for the main coroutine passed to `asyncio.run()` because it is handled by outer code anyway.

The fix is trivial, the attached file shows how to do it.
But the fix needs tests also.

If somebody wishes to pick up the issue and make it done -- it would be awesome. I will help with review and commit, sure.

Another question is should the changing land into 3.7?
I think yes but feedback from Yuri Selivanov is very welcome.

----------
components: asyncio
files: utils.py
keywords: easy
messages: 334276
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Don't log an exception from the main coroutine in asyncio.run()
versions: Python 3.8
Added file: https://bugs.python.org/file48074/utils.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35812>
_______________________________________

From report at bugs.python.org  Wed Jan 23 21:17:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 24 Jan 2019 02:17:12 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548296232.98.0.945804757952.issue35811@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

FWIW, a symlink should be able to launch the Store Python - the problem with the old approach was it never tried to launch the original Python, but only load it's DLLs which won't work (maybe there's a way to enable the app context, but that would still require a new redirector and so wasn't any simpler than a direct launch).

Otherwise, I agree with this analysis and proposal. Just needs a patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Wed Jan 23 23:02:06 2019
From: report at bugs.python.org (Davin Potts)
Date: Thu, 24 Jan 2019 04:02:06 +0000
Subject: [issue35813] shared memory construct to avoid need for serialization
 between processes
Message-ID: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org>


New submission from Davin Potts <python at discontinuity.net>:

A facility for using shared memory would permit direct, zero-copy access to data across distinct processes (especially when created via multiprocessing) without the need for serialization, thus eliminating the primary performance bottleneck in the most common use cases for multiprocessing.

Currently, multiprocessing communicates data from one process to another by first serializing it (by default via pickle) on the sender's end then de-serializing it on the receiver's end.  Because distinct processes possess their own process memory space, no data in memory is common across processes and thus any information to be shared must be communicated over a socket/pipe/other mechanism.  Serialization via tools like pickle is convenient especially when supporting processes on physically distinct hardware with potentially different architectures (which multiprocessing does also support).  Such serialization is wasteful and potentially unnecessary when multiple multiprocessing.Process instances are running on the same machine.  The cost of this serialization is believed to be a non-trivial drag on performance when using multiprocessing on multi-core and/or SMP machines.

While not a new concept (System V Shared Memory has been around for quite some time), the proliferation of support for shared memory segments on modern operating systems (Windows, Linux, *BSDs, and more) provides a means for exposing a consistent interface and api to a shared memory construct usable across platforms despite technical differences in the underlying implementation details of POSIX shared memory versus Native Shared Memory (Windows).

For further reading/reference:  Tools such as the posix_ipc module have provided fairly mature apis around POSIX shared memory and seen use in other projects.  The "shared-array", "shared_ndarray", and "sharedmem-numpy" packages all have interesting implementations for exposing NumPy arrays via shared memory segments.  PostgreSQL has a consistent internal API for offering shared memory across Windows/Unix platforms based on System V, enabling use on NetBSD/OpenBSD before those platforms supported POSIX shared memory.

At least initially, objects which support the buffer protocol can be most readily shared across processes via shared memory.  From a design standpoint, the use of a Manager instance is likely recommended to enforce access rules in different processes via proxy objects as well as cleanup of shared memory segments once an object is no longer referenced.  The documentation around multiprocessing's existing sharedctypes submodule (which uses a single  memory segment through the heap submodule with its own memory management implementation to "malloc" space for allowed ctypes and then "free" that space when no longer used, recycling it for use again from the shared memory segment) will need to be updated to avoid confusion over concepts.

Ultimately, the primary motivation is to provide a path for better parallel execution performance by eliminating the need to transmit data between distinct processes on a single system (not for use in distributed memory architectures).  Secondary use cases have been suggested including a means for sharing data across concurrent Python interactive shells, potential use with subinterpreters, and other traditional uses for shared memory since the first introduction of System V Shared Memory onwards.

----------
assignee: davin
components: Library (Lib)
messages: 334278
nosy: davin, eric.snow, lukasz.langa, ned.deily, rhettinger, yselivanov
priority: normal
severity: normal
status: open
title: shared memory construct to avoid need for serialization between processes
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________

From report at bugs.python.org  Wed Jan 23 23:09:14 2019
From: report at bugs.python.org (Davin Potts)
Date: Thu, 24 Jan 2019 04:09:14 +0000
Subject: [issue35813] shared memory construct to avoid need for serialization
 between processes
In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org>
Message-ID: <1548302954.55.0.317572952253.issue35813@roundup.psfhosted.org>


Change by Davin Potts <python at discontinuity.net>:


----------
keywords: +patch
pull_requests: +11470
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________

From report at bugs.python.org  Wed Jan 23 23:09:26 2019
From: report at bugs.python.org (Davin Potts)
Date: Thu, 24 Jan 2019 04:09:26 +0000
Subject: [issue35813] shared memory construct to avoid need for serialization
 between processes
In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org>
Message-ID: <1548302966.47.0.819561276248.issue35813@roundup.psfhosted.org>


Change by Davin Potts <python at discontinuity.net>:


----------
keywords: +patch, patch
pull_requests: +11470, 11471
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________

From report at bugs.python.org  Wed Jan 23 23:09:35 2019
From: report at bugs.python.org (Davin Potts)
Date: Thu, 24 Jan 2019 04:09:35 +0000
Subject: [issue35813] shared memory construct to avoid need for serialization
 between processes
In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org>
Message-ID: <1548302975.2.0.932911513736.issue35813@roundup.psfhosted.org>


Change by Davin Potts <python at discontinuity.net>:


----------
keywords: +patch, patch, patch
pull_requests: +11470, 11471, 11472
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________

From report at bugs.python.org  Wed Jan 23 23:39:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 04:39:08 +0000
Subject: [issue25522] IDLE: warn if save-as name matches stdlib name
In-Reply-To: <1446270102.89.0.424617028731.issue25522@psf.upfronthosting.co.za>
Message-ID: <1548304748.24.0.802039477195.issue25522@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Beginners import stdlib files such as random.  And they save scripts with such name, and accidentally import the script when not desired.

Beginners should learn how to test a script by running a test file provided by an instructor or written themselves.  In either case, they *will* have to import the script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25522>
_______________________________________

From report at bugs.python.org  Thu Jan 24 00:45:41 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Jan 2019 05:45:41 +0000
Subject: [issue35814] Syntax quirk with variable annotations
Message-ID: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Am not sure how much we care about this, but parenthesis around tuples stops being optional when there is a variable annotation. 

>>> from typing import Tuple
>>> t = 10, 'hello'                     # Parens not normally required
>>> t: Tuple[int, str] = (10, 'hello')  # Annotated allows parens
>>> t: Tuple[int, str] = 10, 'hello'    # Annotated w/o parens fails
SyntaxError: invalid syntax

----------
components: Interpreter Core
messages: 334280
nosy: rhettinger
priority: low
severity: normal
status: open
title: Syntax quirk with variable annotations
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 00:52:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 24 Jan 2019 05:52:15 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548309135.12.0.321700146148.issue35814@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 00:52:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 05:52:47 +0000
Subject: [issue24776] IDLE: Improve config dialog font change user interface
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1548309167.2.0.298747475745.issue24776@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I now think that the proper widget for font resizing might be a ttk.Spinbox (but see below).  #33962 discusses issues around using this widget. 

#33397 is about adding local font resizing with hot key or mousewheel to text and help viewers via a new FontSizer class. Font Sizer should be usable with the sample Text instance.  Size changes in the sample should propagate to the size widget.  When done, it might suffice to use a simple entry box for font size.  We already use them for counts on the General tab.

Since we do not want to encourage indent changes, I think the indent widget should be an entry box with bounds check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24776>
_______________________________________

From report at bugs.python.org  Thu Jan 24 00:53:06 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 05:53:06 +0000
Subject: [issue24776] IDLE: Improve config dialog font change user interface
In-Reply-To: <1438463567.56.0.28070163335.issue24776@psf.upfronthosting.co.za>
Message-ID: <1548309186.54.0.964064424259.issue24776@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24776>
_______________________________________

From report at bugs.python.org  Thu Jan 24 00:53:29 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 05:53:29 +0000
Subject: [issue33397] IDLE help viewer: let users control font size
In-Reply-To: <1525153596.77.0.682650639539.issue33397@psf.upfronthosting.co.za>
Message-ID: <1548309209.42.0.162444612793.issue33397@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The configdialog font tab sample could also use font resizing.  #24776.

----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33397>
_______________________________________

From report at bugs.python.org  Thu Jan 24 01:43:33 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 24 Jan 2019 06:43:33 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548312213.85.0.779714193672.issue35811@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

It's worth noting the consequences of changing the application directory (i.e. the "%__APPDIR__%" dynamic variable from GetEnvironmentVariableW).
This is the first directory checked in most cases when Windows searches for a file, including the CreateProcess[AsUser]W EXE search path, the default LoadLibrary[Ex]W DLL search path, and the default SearchPathW generic search path. In NT 6.2+, these search paths respectively come from the runtime library functions RtlGetExePath, LdrGetDllPath, and RtlGetSearchPath. The search itself is implemented by RtlDosSearchPath_Ustr, except LoadLibraryExW uses it only when loading a DLL as a data file. (Loading as a module is implemented by LdrLoadDll, which uses a private search function, LdrpSearchPath; resolves API-set names; and reserves known system DLLs.) This search supports file redirection [1], but it's unlikely that Python scripts are creating their own activation contexts.

In practice maybe no scripts will be affected by this change. I'm just noting potential problems.

Changing the application directory will break scripts that depend on the environment's "Scripts" directory being in one of the above search paths. It will also break scripts that depend on it being the first directory searched in order to shadow system files that aren't otherwise reserved.

We can lessen the impact of this change by prepending the "Scripts" directory to PATH. However, some directories will unavoidably have precedence over it now. Specifically, for the CreateProcessW EXE search, it's any of the following directories:

    * "%__APPDIR__%"
        This is now the installed location of python.exe.
    * "%__CD__%"
        The current directory is searched if a name has a 
        backslash in it, and also if the environment variable
        NoDefaultCurrentDirectoryInExePath is not defined.
    * "%SystemRoot%\System32" (GetSystemDirectory)
    * "%SystemRoot%\System"
    * "%SystemRoot%" (GetWindowsDirectory)

Also, applications that call SetDefaultDllDirectories get a secure DLL search path that can only reference "%__APPDIR__%", "%SystemRoot%\System32", and directories added via AddDllDirectory or SetDllDirectory. They no longer use "%__CD__%", "%SystemRoot%\System", "%SystemRoot%", or PATH. An affected script will have to manually add the "Scripts" directory to the DLL search path via AddDllDirectory or SetDllDirectory. 

Scripts that wish to restrict searches to PATH should use shutil.which(). It also works more predictably for relative filenames. In particular, a relative filename that has a path separator in it (e.g. r"eggs\spam.txt") is only searched relative to the process current directory. In contrast, searches based on RtlDosSearchPath_Ustr handle all relative filenames, whether or not they contain a path separator, by trying every directory in the search path (e.g. it will look for r"%__APPDIR__%\eggs\spam.txt", and so on).


[1] If enabled by the call flags, searching for a relative filename
    can be redirected by an activation context or (in the absence 
    of a manifest) an "<exename>.local" directory in the application 
    directory, via RtlDosApplyFileIsolationRedirection_Ustr. 
    CreateProcessW does not enable redirection. SearchPathW enables 
    it for the default search path. LoadLibraryExW / LdrLoadDll needs 
    to redirect even fully-qualified filenames, so it directly calls
    RtlDosApplyFileIsolationRedirection_Ustr.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 02:57:06 2019
From: report at bugs.python.org (Jazeps Basko)
Date: Thu, 24 Jan 2019 07:57:06 +0000
Subject: [issue35815] Able to instantiate a subclass with abstract methods
 from __init_subclass__ of the ABC
Message-ID: <1548316625.2.0.852101004839.issue35815@roundup.psfhosted.org>


New submission from Jazeps Basko <jazeps.basko at gmail.com>:

I am creating and registering singleton instances of subclasses of ABC in the ABC's __init_subclass__ and I just noticed that I am able to instantiate even the classes which have abstract methods.



import abc


class Base(abc.ABC):
    def __init_subclass__(cls, **kwargs):
        instance = cls()
        print(f"Created instance of {cls} easily: {instance}")


    @abc.abstractmethod
    def do_something(self):
        pass


class Derived(Base):
    pass


Actual Output:

Created instance of <class '__main__.Derived'> easily: <__main__.Derived object at 0x10a6dd6a0>

Expected Output:

TypeError: Can't instantiate abstract class Derived with abstract methods do_something

----------
messages: 334284
nosy: jbasko
priority: normal
severity: normal
status: open
title: Able to instantiate a subclass with abstract methods from __init_subclass__ of the ABC
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35815>
_______________________________________

From report at bugs.python.org  Thu Jan 24 03:56:05 2019
From: report at bugs.python.org (=?utf-8?b?TWlyb3NsYXYgTWF0xJtqxa8=?=)
Date: Thu, 24 Jan 2019 08:56:05 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548320165.79.0.966411651958.issue27035@roundup.psfhosted.org>


Miroslav Mat?j? <melebius at gmail.com> added the comment:

I completely support @gwk?s opinion expressed in his comments. My original intention has been to set the exit code in an atexit callback. I tried a way and found that it was working in Python 2.7 but not in 3.x (without notice), so I filed this bug report. (See also the Stack Overflow link in my first post.)

I don?t find this just a documentation issue since it prevents the user from setting the exit code, although (as correctly stated by @gwk): ?Ultimately, it is the responsibility of the application programmer to return an appropriate code for all execution paths? and ?returning the correct code is the most critical behavior of a process?.

My use case is a testing library. The user calls assertions from my library and when their script finishes, my library is responsible for deciding whether the test has passed (and finishing the log). Before porting the library to Python (3.5 initially), I used to indicate successfulness by the exit code. With Python 3.x, I am forced to either:
1) print a result message and let the parent process parse it (implemented currently), or
2) force the user of my library to include something like
     sys.exit(testlib.result())
   as the last line of their scripts which I find annoying and error-prone.

I cannot decide whether calling sys.exit() in an atexit callback means breaking the contract as @r.david.murray states. However, the user shall be able to set the exit code of their application when it finishes and atexit should support some way to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Thu Jan 24 04:06:13 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 24 Jan 2019 09:06:13 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1548320773.14.0.787221132169.issue27035@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

You can always set the exit code calling sys.exit from outside the atexit handlers. I concur with R. David Murray in that calling sys.exit and expect anything sounds like a bad idea and an abuse if the atexit system.

A normal application would call sys.exit, some cleanup code will be called in the atexit handlers and finally the program will exit with the code originally set in the first call.

How and when your application will be calling sys.exit is an application architecture problem, and IMHO it should not be a CPython provided functionality to guarantee that you can do this in the atexit handlers.

It also violates the contract that right now is in the documentation: SystemExit exceptions are not printed or reraiaed in atexit handlers. Changing this (specially the second part) will be backwards incompatible, although that is a second order argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27035>
_______________________________________

From report at bugs.python.org  Thu Jan 24 04:55:51 2019
From: report at bugs.python.org (Richard Whitehead)
Date: Thu, 24 Jan 2019 09:55:51 +0000
Subject: [issue18078] threading.Condition to allow notify on a specific waiter
In-Reply-To: <1548253044.41.0.0491501602206.issue18078@roundup.psfhosted.org>
Message-ID: <005b01d4b3ca$fb85e990$f291bcb0$@ieee.org>


Richard Whitehead <richard.whitehead at ieee.org> added the comment:

Thanks Jo?o.

We are working on a medical prototype, and I wouldn't want to rely on our own version of something so fundamental without having a thorough test harness for it, which would obviously be quite time-consuming, and something of a dead-end.

I've worked around the issue now (the system pushing to a queue has to be given a Condition to set when they push, so that if a system listens on multiple queues it can give all the senders the same Condition), but it makes the architecture quite messy, just being able to wait on one of several Conditions would have been neater and less error-prone.

I suppose I expected to see this method because I'm familiar with the Windows API. But I checked and it is not present in the posix threading API, so there is some justification for peoples' reluctance to implement it in Python.

Thanks again,

Richard

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18078>
_______________________________________

From report at bugs.python.org  Thu Jan 24 05:24:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jan 2019 10:24:43 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548325483.27.0.853518629281.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Another problem with posix_spawn() on glibc: it doesn't report errors to the parent process when run under QEMU user-space emulation and Windows Subsystem for Linux. This is because starting with commit [1] (glibc 2.25) posix_spawn()  relies on address space sharing semantics of clone(CLONE_VM) to report errors, but it's not implemented in QEMU and WSL, so clone(CLONE_VM) and vfork() behave like fork(). See also [2], [3].

Oh, you know a lot of stuff about vfork and posix_spawn, you are impressive :-)

Is sys.platform equal to 'linux' on WSL? Sorry, I don't know WSL. If it's equal, is it possible to explicitly exclude WSL in the subprocess test, _use_posix_spawn()?

For QEMU, I was very surprised that a full VM wouldn't implement vfork. So I tried Fedora Rawhide and I didn't notice the bug that you described.

---
$ cat test.c
#include <spawn.h>

int main(int argc, char *argv[], char *envp[]) {
    return posix_spawn(0, "non-existing", 0, 0, argv, envp);
}

$ gcc test.c
$ ./a.out
$ echo $?
2
---

In the VM, I get exit status 2 as expected.

You wrote:

---
$ aarch64-linux-gnu-gcc -static test.c
$ qemu-aarch64 ./a.out
$ echo $?
0
---

So the bug only affects "QEMU User Space". I never used that before. I understand that it's a bug in the glibc and in "QEMU User Emulation" which doesn't implement vfork "properly".


> There is no problem with musl (it doesn't rely on address space sharing).

I'm not interested to support musl at this point because I don't see any obvious way to detect that we are running musl nor get the musl version.

The history of this issue shows the posix_spawn() only works in some very specific cases, so we have to be careful and only opt-in for specific libc, on specific platform with specific libc version (read at runtime if possible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 24 05:28:36 2019
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Lehmann?=)
Date: Thu, 24 Jan 2019 10:28:36 +0000
Subject: [issue35816] csv.DictReader, skipinitialspace does not ignore tabs
Message-ID: <1548325714.32.0.972508693176.issue35816@roundup.psfhosted.org>


New submission from Andr? Lehmann <andre.lehmann at siemens.com>:

When using the csv.DictReader a dialect can be given to change the behavior of interpretation of the csv file.

The Dialect has an option "skipinitialspace" which shall ignore the whitespace after the delimiter according to the documentation (https://docs.python.org/3/library/csv.html).

Unfortunately this works only for spaces but not for tabs which are also whitespaces.

See the following code snippet applied on the attached file:

with open("conf-csv", "r") as csvfile:
    csv.register_dialect("comma_and_ws", skipinitialspace=True)
    csv_dict_reader = csv.DictReader(csvfile, dialect="comma_and_ws")
    for line in csv_dict_reader:
        print(line)

The second line shall not contain "\t" chars.

----------
files: conf.csv
messages: 334289
nosy: andre.lehmann
priority: normal
severity: normal
status: open
title: csv.DictReader, skipinitialspace does not ignore tabs
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file48075/conf.csv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35816>
_______________________________________

From report at bugs.python.org  Thu Jan 24 05:59:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 24 Jan 2019 10:59:29 +0000
Subject: [issue35816] csv.DictReader, skipinitialspace does not ignore tabs
In-Reply-To: <1548325714.32.0.972508693176.issue35816@roundup.psfhosted.org>
Message-ID: <1548327569.88.0.592665570063.issue35816@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://bugs.python.org/issue21297#msg216907 to be related and has a patch. It refers to whitespace as only space ('U+0020') with tabs being ignored.

Current code where only space is taken into account : https://github.com/python/cpython/blob/fd628cf5adaeee73eab579393cdff71c8f70cdf2/Modules/_csv.c#L621

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35816>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:00:27 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Thu, 24 Jan 2019 11:00:27 +0000
Subject: [issue35317] test_email: test_localtime_daylight_false_dst_true()
 fails depending on the timezone
In-Reply-To: <1543244008.28.0.788709270274.issue35317@psf.upfronthosting.co.za>
Message-ID: <1548327627.03.0.643749948889.issue35317@roundup.psfhosted.org>


Andreas Schwab <schwab at linux-m68k.org> added the comment:

The test still fails if the timezone database is not available.

----------
nosy: +schwab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35317>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:03:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jan 2019 11:03:21 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548327801.71.0.300946506964.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I discussed the following issue with Florian Weimer (who works on the glibc):
---
$ cat test.c
#include <spawn.h>

int main(int argc, char *argv[], char *envp[]) {
    return posix_spawn(0, "non-existing", 0, 0, argv, envp);
}

$ aarch64-linux-gnu-gcc -static test.c
$ qemu-aarch64 ./a.out
$ echo $?
0
---

While the parent gets a "success", in subprocess we get the pid and later read the exit status of the child process. Even if posix_spawn() doesn't report a failure, waitpid() will still report a failure. It's a subtle behavior change. I'm not sure yet if it's acceptable for Python in term of semantics:

* without posix_spawn(), subprocess.Popen constructor raises FileNotFoundError: the parent knows that the execution failed because the program doesn't exist
* with posix_spawn() with the vfork bug, subprocess.Popen succeed but Popen.wait() returns something like exit code 127. The parent doesn't know if the child process explcitly used exit(127) or if execv() failed.

Does the difference matters? The bug only occurs in some very specific cases:

* WSL
* QEMU User Emulation

Are these use cases common enough to block the whole idea of using posix_spawn() on Linux. I don't think so. I really want to use posix_spawn() for best performances! Moreover, I expect that glibc implementation of posix_spawn() is safer than Python _posixsubprocess. The glibc has access to low-level stuff like it's internal signals, cancellation points, etc. _posixsubprocess is more generic and doesn't worry about such low-level stuff, whereas they might cause bad surprised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:04:14 2019
From: report at bugs.python.org (Audric)
Date: Thu, 24 Jan 2019 11:04:14 +0000
Subject: [issue35817] IDLE 2.713 on debian 9.6 over WSL W10 IdentationError
Message-ID: <1548327852.82.0.278103847412.issue35817@roundup.psfhosted.org>


New submission from Audric <audric.dhoest at protonmail.com>:

Hello,

The screenshot attached is a clear repro.

Environment:
Surface Pro 3 Win 10 1803 Python 2.7.14
WSL Debian 9.6 with Python 2.7.13

Code:
>>elements = []
>>for i in range(0, 6):
>>...elements.append(i)

-------------------------------

Working:
>>print elements
>>[0, 1, 2, 3, 4, 5]

Non working:
  File "<stdin>", line 2
    elements.append(i)
           ^
IndentationError: expected an indented block

----------
assignee: terry.reedy
components: IDLE
files: py27debian9wslw10indentationerror.PNG
messages: 334293
nosy: audricd, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE 2.713 on debian 9.6 over WSL W10 IdentationError
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file48076/py27debian9wslw10indentationerror.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35817>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:15:09 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Thu, 24 Jan 2019 11:15:09 +0000
Subject: [issue35818] test_email: test_localtime_daylight_false_dst_true()
 fails if timezone database is missing
Message-ID: <1548328508.2.0.57014982778.issue35818@roundup.psfhosted.org>


New submission from Andreas Schwab <schwab at linux-m68k.org>:

bpo-35317 solution is incomplete, the test needs to be skipped if the timezone database is unavailable.

----------
messages: 334294
nosy: barry, miss-islington, p-ganssle, r.david.murray, schwab, vstinner, xtreak
priority: normal
severity: normal
status: open
title: test_email: test_localtime_daylight_false_dst_true() fails if timezone database is missing
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35818>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:21:24 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 24 Jan 2019 11:21:24 +0000
Subject: [issue35816] csv.DictReader, skipinitialspace does not ignore tabs
In-Reply-To: <1548325714.32.0.972508693176.issue35816@roundup.psfhosted.org>
Message-ID: <1548328884.39.0.331036372003.issue35816@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, I overlooked the patch. The issue reported is the same in issue21297 but the patch was about changing whitespace to space in the doc instead of changing the behavior as I can see from the discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35816>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:30:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jan 2019 11:30:21 +0000
Subject: [issue35818] test_email: test_localtime_daylight_false_dst_true()
 fails if timezone database is missing
In-Reply-To: <1548328508.2.0.57014982778.issue35818@roundup.psfhosted.org>
Message-ID: <1548329421.96.0.632397789673.issue35818@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

How can I reproduce the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35818>
_______________________________________

From report at bugs.python.org  Thu Jan 24 06:32:00 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Thu, 24 Jan 2019 11:32:00 +0000
Subject: [issue35818] test_email: test_localtime_daylight_false_dst_true()
 fails if timezone database is missing
In-Reply-To: <1548328508.2.0.57014982778.issue35818@roundup.psfhosted.org>
Message-ID: <1548329520.9.0.366146412598.issue35818@roundup.psfhosted.org>


Andreas Schwab <schwab at linux-m68k.org> added the comment:

rpm -e timezone

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35818>
_______________________________________

From report at bugs.python.org  Thu Jan 24 07:31:10 2019
From: report at bugs.python.org (=?utf-8?q?Alexandre_D=C3=A9fossez?=)
Date: Thu, 24 Jan 2019 12:31:10 +0000
Subject: [issue35621] asyncio.create_subprocess_exec() only works with main
 event loop
In-Reply-To: <1546210778.19.0.43686311162.issue35621@roundup.psfhosted.org>
Message-ID: <1548333070.02.0.697138945934.issue35621@roundup.psfhosted.org>


Alexandre D?fossez <alexandre.defossez at gmail.com> added the comment:

Also impacted.

A fix I found is to add `watcher.attach_loop(self)` just after `with events.get_child_watcher() as watcher:` in `_make_subprocess_transport` in `asyncio/unix_events.py`.

----------
nosy: +adfz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35621>
_______________________________________

From report at bugs.python.org  Thu Jan 24 08:20:56 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 24 Jan 2019 13:20:56 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548336056.64.0.517877684846.issue35814@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Good catch!

I think it was just overlooked rather than a conscious decision (unlike the left hand side, that generated lots of debates)

I will make a PR to allow everything that is allowed on r.h.s. of a normal assignment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 08:22:58 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 24 Jan 2019 13:22:58 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548336178.29.0.154867572466.issue35814@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch
pull_requests: +11473
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 08:23:05 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 24 Jan 2019 13:23:05 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548336185.95.0.161420555197.issue35814@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11473, 11474
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 08:23:13 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 24 Jan 2019 13:23:13 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548336193.31.0.517894863468.issue35814@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11473, 11474, 11475
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 08:33:56 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 24 Jan 2019 13:33:56 +0000
Subject: [issue33416] Add endline and endcolumn to every AST node
In-Reply-To: <1525342525.55.0.682650639539.issue33416@psf.upfronthosting.co.za>
Message-ID: <1548336836.41.0.598204175631.issue33416@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Re-opening to track renaming of potentially public PyNode_AddChild() and PyParser_AddToken().

----------
nosy: +vstinner
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33416>
_______________________________________

From report at bugs.python.org  Thu Jan 24 10:44:22 2019
From: report at bugs.python.org (Paul Moore)
Date: Thu, 24 Jan 2019 15:44:22 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548344662.74.0.219982302807.issue35811@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

I'm not particularly happy with the statement that "However, the latter is out of scope here since the entry-point launchers are in distlib."

If Python is changing the semantics of __PYVENV_LAUNCHER__ in such a way that it breaks 3rd party code, it seems to me that this is a bug, which should be addressed by reverting or fixing the change so that the 3rd party code does not need to change. Either that, or the change is publicised as a backward compatibility break, so that tools are given a chance to update.

Having said all of that, I appreciate that __PYVENV_LAUNCHER__ is not exactly a public API, so there should be some leeway here. But I think that whatever solution we propose here needs to address how we manage the change required of third parties.

I still need to fully read and understand this discussion - I've not really followed any of the work around publishing Python as a Store application, taking the view that I won't use it myself, so "it won't affect me". But now I'm starting to worry about whether I'll see pip bug reports being filed because pip's installing things in the wrong places ("Similarly, pip.exe for an installed Python 3.7 will mistakenly install into the virtual environment.") If that sort of thing does happen, it harms our credibility and we need to be able to clearky explain what's going on, and how to fix it.

Can I clarify 2 things:

1. Is there a possibility that 3rd party applications like pip could see bugs with Python 3.7.2?
2. Is there a workaround or fix for those issues, and how are we making sure the relevant 3rd parties know what to do?

(Again, apologies if I've misunderstood something here - there's quite a lot of technical detail that I haven't had time to understand yet).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 10:55:55 2019
From: report at bugs.python.org (Terrence Brannon)
Date: Thu, 24 Jan 2019 15:55:55 +0000
Subject: [issue33342] urllib IPv6 parsing fails with special characters in
 passwords
In-Reply-To: <1524491070.85.0.682650639539.issue33342@psf.upfronthosting.co.za>
Message-ID: <1548345355.09.0.933170117293.issue33342@roundup.psfhosted.org>


Terrence Brannon <metaperl at gmail.com> added the comment:

Also note, if SQLAlchemy gives any guidance, then note that SA unquotes both the username and password of the URL:

https://github.com/sqlalchemy/sqlalchemy/blob/master/lib/sqlalchemy/engine/url.py#L274

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33342>
_______________________________________

From report at bugs.python.org  Thu Jan 24 10:59:49 2019
From: report at bugs.python.org (Terrence Brannon)
Date: Thu, 24 Jan 2019 15:59:49 +0000
Subject: [issue33342] urllib IPv6 parsing fails with special characters in
 passwords
In-Reply-To: <1524491070.85.0.682650639539.issue33342@psf.upfronthosting.co.za>
Message-ID: <1548345589.91.0.769486014418.issue33342@roundup.psfhosted.org>


Terrence Brannon <metaperl at gmail.com> added the comment:

Regarding "RFC 2396 explicitly excludes the use of [ and ] in URLs. RFC 2732 <https://www.ietf.org/rfc/rfc2732.txt> defines the syntax for IPv6 URLs, and allows [ and ] ONLY in the host part.

So I'd say that the behaviour is arguably correct (if somewhat unfortunate)"

I would say that a square bracket CAN be used in the password, but that it should be urlencoded and that this library should perform a urldecode for both username and password, just as SQLAlchemy does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33342>
_______________________________________

From report at bugs.python.org  Thu Jan 24 11:06:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 24 Jan 2019 16:06:05 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548345965.36.0.374632991031.issue35811@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It might be worth adding a summary of that to the porting notes, but I think the actual impact will be minimal. Launching processes by relative path has been a bad decision for long enough now that I'd expect it to be rare, and the Scripts directory layout being slightly different helps.

The launcher scripts used by pip also changed somewhat recently (between 12.x and 18.x IIRC) with something along these lines without causing significant issues.

Ultimately, there isn't much of an alternative. Those who have been following good practices and supported patterns in their code will be okay, and those who have not (e.g. Numpy putting DLLs on PATH) will be bitten sooner or later anyway. 

So let's suppress the variable in the launcher to deal with that particular issue. It's fairly minor compared to the multiprocessing one.

For Paul: Yes, there's a chance of pip issues. This is why I sent you all a heads-up email before anything was released. But pip is certainly the best tested package and I've even been doing pip development using the Store package and a venv without trouble. Everything here is severe edge cases.

Also, the __PYVENV_LAUNCHER__ variable is totally new - previously it only ever existed on macOS (since some of the same launch restrictions apply there). It's not the same as the VIRTUALENV variable that you added support to py.exe to detect. That one is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 11:49:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jan 2019 16:49:50 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548348590.46.0.846077238625.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 24 11:50:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jan 2019 16:50:05 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548348605.79.0.760819863737.issue35537@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11476, 11477

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 24 11:51:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jan 2019 16:51:30 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548348690.31.0.714027127705.issue35537@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote PR 11668 to propose to *document* the subtle behavior change when posix_spawn() is used on QEMU User Emulation and WSL platforms, rather than trying to opt-out for posix_spawn() on these platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 24 12:06:24 2019
From: report at bugs.python.org (Mayank Singhal)
Date: Thu, 24 Jan 2019 17:06:24 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1548349584.25.0.109755935846.issue15248@roundup.psfhosted.org>


Mayank Singhal <17mayanksinghal at gmail.com> added the comment:

Hey, if nobody is working on this can I go for it?

----------
nosy: +storymode7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Thu Jan 24 12:10:00 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 24 Jan 2019 17:10:00 +0000
Subject: =?utf-8?q?=5Bissue31982=5D_8=2E3=2E_collections_=E2=80=94_Container_datat?=
 =?utf-8?q?ypes?=
In-Reply-To: <1510157451.94.0.213398074469.issue31982@psf.upfronthosting.co.za>
Message-ID: <1548349800.14.0.11693434194.issue31982@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

This is a duplicate of issue 31075, which was closed as 'Not a bug'.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31982>
_______________________________________

From report at bugs.python.org  Thu Jan 24 12:29:52 2019
From: report at bugs.python.org (Abdallah)
Date: Thu, 24 Jan 2019 17:29:52 +0000
Subject: [issue35819] Fatal Python error
Message-ID: <MN2PR12MB31663E9A5347BDE77ABE43B7B39A0@MN2PR12MB3166.namprd12.prod.outlook.com>


New submission from Abdallah <abdallahadham1998 at gmail.com>:

,He,
i am having this problem for about 2 weeks , I can't do anything , so please give me some instructions so i can solve .it

Fatal Python error: initfsencoding: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

:Current thread 0x00003c7c (most recent call first

Process finished with exit code -1073740791 (0xC0000409)

 Thanks

----------
messages: 334308
nosy: abdallahadham
priority: normal
severity: normal
status: open
title: Fatal Python error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35819>
_______________________________________

From report at bugs.python.org  Thu Jan 24 12:29:54 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 24 Jan 2019 17:29:54 +0000
Subject: [issue35520] Python won't build with dtrace enabled on some systems.
In-Reply-To: <1545047330.52.0.788709270274.issue35520@psf.upfronthosting.co.za>
Message-ID: <1548350994.28.0.73056856348.issue35520@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 5c8f537669d3379fc50bb0a96accac756e43e281 by ?ukasz Langa (Jakub Kul?k) in branch 'master':
bpo-35520: Fix build with dtrace support on certain systems. (#11194)
https://github.com/python/cpython/commit/5c8f537669d3379fc50bb0a96accac756e43e281


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35520>
_______________________________________

From report at bugs.python.org  Thu Jan 24 12:31:03 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 24 Jan 2019 17:31:03 +0000
Subject: [issue35767] unittest loader doesn't work with partial test functions
In-Reply-To: <1547774719.89.0.274196426974.issue35767@roundup.psfhosted.org>
Message-ID: <1548351063.92.0.718327658452.issue35767@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 841387dd43e67b1800d10e4d7ce1f8cedc9f3706 by ?ukasz Langa (Miss Islington (bot)) in branch '3.7':
bpo-35767: Fix unittest.loader to allow partials as test_functions (GH-11600) (#11662)
https://github.com/python/cpython/commit/841387dd43e67b1800d10e4d7ce1f8cedc9f3706


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35767>
_______________________________________

From report at bugs.python.org  Thu Jan 24 12:37:49 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 24 Jan 2019 17:37:49 +0000
Subject: [issue35819] Fatal Python error
In-Reply-To: <MN2PR12MB31663E9A5347BDE77ABE43B7B39A0@MN2PR12MB3166.namprd12.prod.outlook.com>
Message-ID: <1548351469.27.0.0569063140916.issue35819@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Hi Abdallah,

This tracker is for reporting bugs in the CPython interpreter or standard library, not for general help; as such I'm closing this issue.  For help, it's better to ask on the main python mailing list (python-list at python.org), in the #python IRC channel on Freenode, or in the #general/help stream on python.zulipchat.com.

That said, this is usually caused by having the PYTHONHOME or PYTHONPATH environment variables set incorrectly; try unsetting *all* environment variables that start with PYTHON and see if that helps.

If that doesn't fix it, ask for help on one of the forums I mentioned above, but include more details about what you're actually doing and what's not working so that folks can help you effectively.  Also include your operating system, OS version, Python version, and anything else that you feel might be relevant.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35819>
_______________________________________

From report at bugs.python.org  Thu Jan 24 13:00:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 18:00:42 +0000
Subject: [issue35817] IDLE 2.713 on debian 9.6 over WSL W10 IdentationError
In-Reply-To: <1548327852.82.0.278103847412.issue35817@roundup.psfhosted.org>
Message-ID: <1548352842.59.0.470961222413.issue35817@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the Debian screenshot with the traceback, you run interactive Python, not IDLE, in the system terminal, with the command-line entry 'python'.  Notice the secondary ... prompt.

The bug in the code you entered is indicated by the error message.  In interactive Python you have to indent the bodies of compound statements yourself.  (IDLE does this for you with its 'smart indent' feature.)  In the future, please ask questions about exception messages (and Python in general) on python-list or elsewhere.  Perhaps you should also reread the Python Tutorial.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35817>
_______________________________________

From report at bugs.python.org  Thu Jan 24 13:16:12 2019
From: report at bugs.python.org (Paul Moore)
Date: Thu, 24 Jan 2019 18:16:12 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548353772.8.0.353911032913.issue35811@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Steve - thanks for the clarification. If it's only affecting launching with relative paths, then agreed it's minor (although I do recall recent discussions somewhere about using launchers with relative paths - that use case may need checking, but we can deal with that when it comes up).

And I hadn't appreciated that __PYVENV_LAUNCHER__ was MACOS only before now. So again, thanks forthe reassurance there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 13:44:32 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 24 Jan 2019 18:44:32 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548355472.53.0.626317311978.issue35811@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> 1. Is there a possibility that 3rd party applications like pip 
> could see bugs with Python 3.7.2?

A bug occurs when running an entry-point script, such as pip.exe, for a system- or user-installed Python 3.7.2+ from the context of a virtual environment for 3.7.2+. The script executable redirects to run `"path\to\python.exe" "path\to\<script_name>.exe"`. This will inherit __PYVENV_LAUNCHER__ and thus run in the virtual environment. The environment doesn't have to be activated. People use inactive virtual environments for various purposes, so it doesn't defy my expectations that someone may have a problem. I think the distlib launchers should make the same change to unset __PYVENV_LAUNCHER__, which is why I nosied Vinay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 13:49:27 2019
From: report at bugs.python.org (Paul Moore)
Date: Thu, 24 Jan 2019 18:49:27 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548355767.77.0.98822065436.issue35811@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

> The script executable redirects to run `"path\to\python.exe" "path\to\<script_name>.exe"`.

But if I understood what Steve said, only if path\to\python.exe is a *relative* pathname?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 14:20:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 19:20:34 +0000
Subject: [issue34857] IDLE: SyntaxWarning not handled properly
In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za>
Message-ID: <1548357634.23.0.810875171028.issue34857@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In 3.7.2, the statement in a file results in the SyntaxError being printed in Shell *before* the restart.  It should be after, but before the code object is sent to the restarted execution process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34857>
_______________________________________

From report at bugs.python.org  Thu Jan 24 14:26:27 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 24 Jan 2019 19:26:27 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548357987.14.0.246110301265.issue35811@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> But if I understood what Steve said, only if path\to\python.exe is 
> a *relative* pathname?

I believe Steve is referring to behavior changes for applications that relied on a virtual environment's "Scripts" directory always being in the EXE and default DLL and generic search paths because it was the application directory (i.e. "%__APPDIR__%"), which I had discussed in a follow-up note. I suggested that this could be mitigated by having the new venv launchers also prepend their directory to PATH. It wouldn't help in all cases, but it's the best we can do. 

The issue with __PYVENV_LAUNCHER__ and the py.exe and entry-point launchers is unrelated to relative paths. Perhaps it will clarify the situation to show how this variable is actually used in PC/getpathp.c. It's a pretty simple change:

    /* The launcher may need to force the executable path to a
     * different environment, so override it here. */
    pyvenv_launcher = _wgetenv(L"__PYVENV_LAUNCHER__");
    if (pyvenv_launcher && pyvenv_launcher[0]) {
        wcscpy_s(program_full_path, MAXPATHLEN+1, pyvenv_launcher);
    } else if (!GetModuleFileNameW(NULL, program_full_path, MAXPATHLEN)) {
        /* GetModuleFileName should never fail when passed NULL */
        return _Py_INIT_ERR("Cannot determine program path");
}

https://github.com/python/cpython/blob/v3.7.2/PC/getpathp.c#L535

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 14:43:17 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Jan 2019 19:43:17 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548358997.37.0.700621677584.issue35717@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1fd06f1eca80dcbf3a916133919482a8327f3da4 by Miss Islington (bot) (R?mi Lapeyre) in branch 'master':
bpo-35717: Fix KeyError exception raised when using enums and compile (GH-11523)
https://github.com/python/cpython/commit/1fd06f1eca80dcbf3a916133919482a8327f3da4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Thu Jan 24 14:43:33 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Jan 2019 19:43:33 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548359013.31.0.587088969795.issue35717@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11478

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Thu Jan 24 14:43:43 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Jan 2019 19:43:43 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548359023.21.0.838031504747.issue35717@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11478, 11479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Thu Jan 24 14:43:52 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Jan 2019 19:43:52 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548359032.83.0.866578334351.issue35717@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11478, 11479, 11480

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:01:31 2019
From: report at bugs.python.org (Tinu Tomson)
Date: Thu, 24 Jan 2019 20:01:31 +0000
Subject: [issue35820] Inconsistent behavior when parsing IP address
Message-ID: <1548360089.92.0.137181767325.issue35820@roundup.psfhosted.org>


New submission from Tinu Tomson <tinutomson at yahoo.com>:

ip = '23.00.021.002'
ipaddress.IPv4Address(ip)
throw error:
  File "/usr/lib/python3.4/ipaddress.py", line 1271, in __init__                                                                                             
    self._ip = self._ip_int_from_string(addr_str)                                                                                                            
  File "/usr/lib/python3.4/ipaddress.py", line 1122, in _ip_int_from_string                                                                                  
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None                                                                                            
ipaddress.AddressValueError: Ambiguous (octal/decimal) value in '021' not permitted in '23.00.021.002'          


ip = '23.00.21.002'
ipaddress.IPv4Address(ip)

parses correctly.

----------
components: Library (Lib)
messages: 334319
nosy: tinutomson
priority: normal
severity: normal
status: open
title: Inconsistent behavior when parsing IP address

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35820>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:02:34 2019
From: report at bugs.python.org (Tinu Tomson)
Date: Thu, 24 Jan 2019 20:02:34 +0000
Subject: [issue35820] Inconsistent behavior when parsing IP address
In-Reply-To: <1548360089.92.0.137181767325.issue35820@roundup.psfhosted.org>
Message-ID: <1548360154.93.0.941561690461.issue35820@roundup.psfhosted.org>


Change by Tinu Tomson <tinutomson at yahoo.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35820>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:07:20 2019
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 24 Jan 2019 20:07:20 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
Message-ID: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Currently, the logging docs are a bit ambiguous or at least not completely clear as to when events are propagated when Logger.propagate is true. The docs currently say [1]--

"If [the `propagate`] attribute evaluates to true, events logged to this logger will be passed to the handlers of higher level (ancestor) loggers, in addition to any handlers attached to this logger."

But it's not clear if "logged to this logger" means (1) a log method like info() or error() was called on the logger, or (2) the event was passed to the logger's handlers (i.e. satisfied the logger's log level threshold and any filters).

Empirically, I found that the meaning is (2).

[1]: https://docs.python.org/3/library/logging.html#logging.Logger.propagate

----------
assignee: docs at python
components: Documentation
messages: 334320
nosy: chris.jerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify when logging events are propagated when propagate is true
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:23:30 2019
From: report at bugs.python.org (Thomas Waldmann)
Date: Thu, 24 Jan 2019 20:23:30 +0000
Subject: [issue35686] BufferError with memory.release()
In-Reply-To: <1546967000.66.0.594887800159.issue35686@roundup.psfhosted.org>
Message-ID: <1548361410.52.0.507207160807.issue35686@roundup.psfhosted.org>


Thomas Waldmann <thomas.j.waldmann at gmail.com> added the comment:

https://github.com/borgbackup/borg/pull/4247/files

this is the current code i have for this (it is not as simple there as in the minimal code samples i attached here).

i meanwhile think i can not use a contextmanager there.

do you think this is as good as it gets for this kind of code?

if you all think this is expected behaviour for the python contextmanagers and can't be done better, this issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35686>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:31:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 24 Jan 2019 20:31:19 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548361879.13.0.537799041332.issue35811@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I think that snippet may have to change to accommodate the multiprocessing issue, where we need to stop replacing sys.executable with the venv launcher and have it point to the base python.exe (and then anyone launching sys.executable needs to preserve __PYVENV_LAUNCHER__, which is the default behavior).

Having done a code scan, there are quite a few places where we explicitly choose __PYVENV_LAUNCHER__ on macOS over sys.executable, so I guess we need to do those on Windows now as well. But that's a discussion for issue 35797

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:37:03 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 24 Jan 2019 20:37:03 +0000
Subject: [issue35820] Inconsistent behavior when parsing IP address
In-Reply-To: <1548360089.92.0.137181767325.issue35820@roundup.psfhosted.org>
Message-ID: <1548362223.05.0.644204291919.issue35820@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

>From the documentation of IPv4Address:

The following constitutes a valid IPv4 address:

1. A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0?255, separated by dots (e.g. 192.168.0.1). Each integer represents an octet (byte) in the address. Leading zeroes are tolerated only for values less than 8 (as there is no ambiguity between the decimal and octal interpretations of such strings).

21 is not less than 8, so you get this error. I think this is working as it's documented.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35820>
_______________________________________

From report at bugs.python.org  Thu Jan 24 15:45:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jan 2019 20:45:11 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1548362711.76.0.430781336529.issue15248@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am not sure what you could do at the moment.  We have not yet settled whether this is a documentation or interpreter core issue.

I posted "Add more SyntaxWarnings?" to pydev to get more comments on Serhiy's patch, especially for other core developers.  Depending on what people think, that *might* result in someone converting the diff (with the typo corrected) into a PR.

I already posted here a prototype doc entry for TypeError messages.  I decided that I should take time out from IDLE to post my idea for a separate error message doc.  I will include a fleshed-out TypeError entry (with code example) as an example entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Thu Jan 24 17:24:19 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Jan 2019 22:24:19 +0000
Subject: [issue15248] Better explain "TypeError: 'tuple' object is not
 callable"
In-Reply-To: <1341379722.78.0.0866285571225.issue15248@psf.upfronthosting.co.za>
Message-ID: <1548368659.24.0.213023955073.issue15248@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15248>
_______________________________________

From report at bugs.python.org  Thu Jan 24 18:50:00 2019
From: report at bugs.python.org (Emily Morehouse)
Date: Thu, 24 Jan 2019 23:50:00 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548373800.75.0.575121410519.issue35224@roundup.psfhosted.org>


Emily Morehouse <emilyemorehouse at gmail.com> added the comment:


New changeset 8f59ee01be3d83d5513a9a3f654a237d77d80d9a by Emily Morehouse in branch 'master':
bpo-35224: PEP 572 Implementation (#10497)
https://github.com/python/cpython/commit/8f59ee01be3d83d5513a9a3f654a237d77d80d9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 18:50:34 2019
From: report at bugs.python.org (Abdallah)
Date: Thu, 24 Jan 2019 23:50:34 +0000
Subject: [issue35819] Fatal Python error
In-Reply-To: <1548351469.27.0.0569063140916.issue35819@roundup.psfhosted.org>
Message-ID: <CADVp01gnMYfYhk+qK=0o+t3bqvX7oJ15c3C3LKDOuqKd7tJXNQ@mail.gmail.com>


Abdallah <abdallahadham1998 at gmail.com> added the comment:

Thank you alot

On Thu, 24 Jan 2019, 19:37 Zachary Ware <report at bugs.python.org wrote:

>
> Zachary Ware <zachary.ware at gmail.com> added the comment:
>
> Hi Abdallah,
>
> This tracker is for reporting bugs in the CPython interpreter or standard
> library, not for general help; as such I'm closing this issue.  For help,
> it's better to ask on the main python mailing list (python-list at python.org),
> in the #python IRC channel on Freenode, or in the #general/help stream on
> python.zulipchat.com.
>
> That said, this is usually caused by having the PYTHONHOME or PYTHONPATH
> environment variables set incorrectly; try unsetting *all* environment
> variables that start with PYTHON and see if that helps.
>
> If that doesn't fix it, ask for help on one of the forums I mentioned
> above, but include more details about what you're actually doing and what's
> not working so that folks can help you effectively.  Also include your
> operating system, OS version, Python version, and anything else that you
> feel might be relevant.
>
> ----------
> nosy: +zach.ware
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35819>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35819>
_______________________________________

From report at bugs.python.org  Thu Jan 24 18:51:33 2019
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 24 Jan 2019 23:51:33 +0000
Subject: [issue20911] urllib 'headers' is not a well defined data type
In-Reply-To: <1394724454.41.0.246031763328.issue20911@psf.upfronthosting.co.za>
Message-ID: <1548373893.82.0.614017647199.issue20911@roundup.psfhosted.org>


Demian Brecht <demianbrecht at gmail.com> added the comment:

>>> urlopen('https://example.com').info()
<http.client.HTTPMessage object at 0x111528da0>
>>> urlopen('http://example.com').info()
<http.client.HTTPMessage object at 0x111528be0>
>>> urlopen('ftp://speedtest.tele2.net').info()
<email.message.Message object at 0x111531080>
>>> urlopen('file:///path/to/setup.py').info()
<email.message.Message object at 0x111528f60>

I've taken a look at the rest of the handlers in urllib.request and they all build headers consistently with email.message_from_string().

Closing as out of date.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20911>
_______________________________________

From report at bugs.python.org  Thu Jan 24 18:54:48 2019
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 24 Jan 2019 23:54:48 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
In-Reply-To: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>
Message-ID: <1548374088.69.0.446956232056.issue17251@roundup.psfhosted.org>


Change by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy:  -demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Thu Jan 24 18:57:14 2019
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 24 Jan 2019 23:57:14 +0000
Subject: [issue3430] httplib.HTTPResponse documentations inconsistent
In-Reply-To: <1216747880.73.0.0581734704537.issue3430@psf.upfronthosting.co.za>
Message-ID: <1548374234.3.0.294738663285.issue3430@roundup.psfhosted.org>


Change by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy:  -demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3430>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:01:04 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Jan 2019 00:01:04 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548374464.6.0.862160609542.issue35224@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This is huge!

I do recall there are some minor edge cases where the implementation currently doesn't match the PEP. Could you summarize those here, and add your recommendation (e.g. change the PEP, fix the code, wait and see) with motivation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:08:53 2019
From: report at bugs.python.org (Igor Z)
Date: Fri, 25 Jan 2019 00:08:53 +0000
Subject: [issue35822] _queue _queuemodule.c is missing inside the Setup file
Message-ID: <1548374932.46.0.67529287669.issue35822@roundup.psfhosted.org>


New submission from Igor Z <igorzy.694 at gmail.com>:

I had to install manually new urllib3 (zip archive) module inside python 3.7 and got and error that module "_queue" is missing.
I did not find anything related to such module inside the Setup file.
Then I found this module in the github and manually added:
_queue _queuemodule.c and did "make" once again to get new "libpython3.7m.so.1.0" that I needed for the project. The problem was solved.

----------
assignee: docs at python
components: Build, Documentation, Library (Lib)
messages: 334329
nosy: Igor Z, docs at python
priority: normal
severity: normal
status: open
title: _queue _queuemodule.c is missing inside the Setup file
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35822>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:27:27 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 00:27:27 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548376047.25.0.391676794573.issue35821@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:27:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 00:27:38 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548376058.48.0.304569775249.issue35224@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:27:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 00:27:47 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548376067.05.0.803037563392.issue35224@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11481, 11482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:27:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 00:27:54 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548376074.74.0.601457946274.issue35224@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11481, 11482, 11483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:29:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 00:29:27 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548376167.4.0.308819377805.issue35224@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The change broke most buildbots: congrats Emily, each core dev has to do their as part of their training ;-) Don't worry, it's fine.

I wrote PR #11670 which should fix test_tools.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:36:34 2019
From: report at bugs.python.org (Emily Morehouse)
Date: Fri, 25 Jan 2019 00:36:34 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548376594.27.0.861161799255.issue35224@roundup.psfhosted.org>


Emily Morehouse <emilyemorehouse at gmail.com> added the comment:

@vstinner Is there something I could/should have checked other than the CI displayed in GitHub before merging? Let me know if I can help.



Here's a brief summary of the differences between the PEP spec and implementation:

>From the "Scope of the target" section of the PEP, there are two cases that should raise a TargetScopeError: when an assignment expression is used in a comprehension inside a class body or for special cases in comprehensions.

Invalid examples for the latter include:

    [i := i+1 for i in range(5)]
    [[(j := j) for i in range(5)] for j in range(5)]
    [i := 0 for i, j in stuff]
    [i+1 for i in i := stuff]

However, the following work in the implementation,though the PEP states they should be invalid:

    >>> [i := i+1 for i in range(5)]
    [1, 2, 3, 4, 5]
    >>> i
    5

    >>> [i := 0 for i, j in [(1, 2)]]
    [0]

The following does not work in the implementation (as desired), but does not throw a TargetScopeError as defined in the PEP:

    >>> [i+1 for i in i := range(5)]
    File "<stdin>", line 1
        [i+1 for i in i := range(5)]
                        ^
    SyntaxError: invalid syntax


IMO, I was leaning towards advocating for changing the PEP to match the implementation. I think the error messages are clear and expected, and restricting what already works would require significant special cases. I'm open to discussion though.

There's also documentation that should certainly be added (and I believe a spot where assignment expressions are explicitly mentioned as not being included in the language, which is no longer the case)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:39:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 00:39:46 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548376786.48.0.426322805737.issue35224@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> @vstinner Is there something I could/should have checked other than the CI displayed in GitHub before merging? Let me know if I can help.

It wasn't your fault. Our pre-commit checks on pull requests is incomplete on purpose: it has to be fast. It's fine to break buildbots sometimes. It's a tradeoff.

If you want to help, please merge https://github.com/python/cpython/pull/11670 as soon as the CI test pass since I'm going to bed :-)

You are the victim of a very very specific annoying test, test_unparse with its annoying "randomly pick 10 files from the stdlib" feature...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:42:00 2019
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 25 Jan 2019 00:42:00 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548376920.1.0.951958240975.issue35821@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Also, does "logged to this logger" include events propagated to it from a child logger? For example, if an event is logged to logger "A.B.C" and propagated to "A.B", will the propagate attribute of the latter effect whether logger "A" (or its handlers) sees it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Thu Jan 24 19:50:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 00:50:09 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548377409.52.0.980923545021.issue35224@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1396d8fab4d0ae830d45f4937322bbb43ce0c30e by Victor Stinner in branch 'master':
bpo-35224: Add support for NamedExpr to unparse.py (GH-11670)
https://github.com/python/cpython/commit/1396d8fab4d0ae830d45f4937322bbb43ce0c30e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Thu Jan 24 20:39:25 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 25 Jan 2019 01:39:25 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548380365.81.0.606816568065.issue35814@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 62c35a8a8ff5854ed470b1c16a7a14f3bb80368c by Ivan Levkivskyi in branch 'master':
bpo-35814: Allow same r.h.s. in annotated assignments as in normal ones (GH-11667)
https://github.com/python/cpython/commit/62c35a8a8ff5854ed470b1c16a7a14f3bb80368c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 21:03:27 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 25 Jan 2019 02:03:27 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
Message-ID: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

This issue is to propose a (complementary) alternative to the usage of posix_spawn() in subprocess (see bpo-35537).

As mentioned by Victor Stinner in msg332236, posix_spawn() has the potential of being faster and safer than fork()/exec() approach. However, some of the currently available implementations of posix_spawn() have technical problems (this mostly summarizes discussions in bpo-35537):

* In glibc < 2.24 on Linux, posix_spawn() doesn't report errors to the parent properly, breaking existing subprocess behavior.

* In glibc >= 2.25 on Linux, posix_spawn() doesn't report errors to the parent in certain environments, such as QEMU user-mode emulation and Windows subsystem for Linux.

* In FreeBSD, as of this writing, posix_spawn() doesn't block signals in the child process, so a signal handler executed between vfork() and execve() may change memory shared with the parent [1].

Regardless of implementation, posix_spawn() is also unsuitable for some subprocess use cases:

* posix_spawnp() can't be used directly to implement file searching logic of subprocess because of different semantics, requiring workarounds.

* posix_spawn() has no standard way to specify the current working directory for the child.

* posix_spawn() has no way to close all file descriptors > 2 in the child, which is the *default* mode of operation of subprocess.Popen().

May be even more importantly, fundamentally, posix_spawn() will always be less flexible than fork()/exec() approach. Any additions will have to go through POSIX standardization or be unportable. Even if approved, a change will take years to get to actual users because of the requirement to update the C library, which may be more than a decade behind in enterprise Linux distros. This is in contrast to having an addition implemented in CPython. For example, a setrlimit() action for posix_spawn() is currently rejected in POSIX[2], despite being trivial to add.

I'm interested in avoiding posix_spawn() problems on Linux while still delivering comparable performance and safety. To that end I've studied implementations of posix_spawn() in glibc[3] and musl[4], which use vfork()/execve()-like approach, and investigated challenges of using vfork() safely on Linux (e.g. [5]) -- all of that for the purpose of using vfork()/exec() instead of fork()/exec() or posix_spawn() in subprocess where possible.

The unique property of vfork() is that the child shares the address space (including heap and stack) as well as thread-local storage with the parent, which means that the child must be very careful not to surprise the parent by changing the shared resources under its feet. The parent is suspended until the child performs execve(), _exit() or dies in any other way.

The most safe way to use vfork() is if one has access to the C library internals and can do the the following:

1) Disable thread cancellation before vfork() to ensure that the parent thread is not suddenly cancelled by another thread with pthread_cancel() while being in the middle of child creation.

2) Block all signals before vfork(). This ensures that no signal handlers are run in the child. But the signal mask is preserved by execve(), so the child must restore the original signal mask. To do that safely, it must reset dispositions of all non-ignored signals to the default, ensuring that no signal handlers are executed in the window between restoring the mask and execve().

Note that libc-internal signals should be blocked too, in particular, to avoid "setxid problem"[5].

3) Use a separate stack for the child via clone(CLONE_VM|CLONE_VFORK), which has exactly the same semantics as vfork(), but allows the caller to provide a separate stack. This way potential compiler bugs arising from the fact that vfork() returns twice to the same stack frame are avoided.

4) Call only async-signal-safe functions in the child.

In an application, only (1) and (4) can be done easily.

One can't disable internal libc signals for (2) without using syscall(), which requires knowledge of the kernel ABI for the particular architecture.

clone(CLONE_VM) can't be used at least before glibc 2.24 because it corrupts the glibc pid/tid cache in the parent process[6,7]. (As may be guessed, this problem was solved by glibc developers when they implemented posix_spawn() via clone()). Even now, the overall message seems to be that clone() is a low-level function not intended to be used by applications.

Even with the above, I still think that in context of subprocess/CPython the sufficient vfork()-safety requirements are provided by the following.

Despite being easy, (1) seems to be not necessary: CPython never uses pthread_cancel() internally, so Python code can't do that. A non-Python thread in an embedding app could try, but cancellation, in my knowledge, is not supported by CPython in any case (there is no way for an app to cleanup after the cancelled thread), so subprocess has no reason to care.

For (2), we don't have to worry about the internal signal used for thread cancellation because of the above. The only other internal signal is used for setxid syncronization[5]. The "setxid problem" is mitigated in Python because the spawning thread holds GIL, so Python code can't call os.setuid() concurrently. Again, a non-Python thread could, but I argue that an application that spawns a child and calls setuid() in non-synchronized manner is not worth supporting: a child will have "random" privileges depending on who wins the race, so this is hardly a good security practice. Even if such apps are considered worthy to support, we may limit vfork()/exec() path only to the non-embedded use case.

For (3), with production-quality compilers, using vfork() should be OK. Both GCC and Clang recognize it and handle in a special way (similar to setjmp(), which also has "returning twice" semantics). The supporting evidence is that Java has been using vfork() for ages, Go has migrated to vfork(), and, coincidentally, dotnet is doing it right now[8].

(4) is already done in _posixsubprocess on Linux.

I've implemented a simple proof-of-concept that uses vfork() in subprocess on Linux by default in all cases except if preexec_fn is not None. It passes all tests on OpenSUSE (Linux 4.15, glibc 2.27) and Ubuntu 14.04 (Linux 4.4, glibc 2.19), but triggers spurious GCC warnings, probably due to a long-standing GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161

I've also run a variant of subprocess_bench.py (by Victor Stinner from bpo-35537) with close_fds=False and restore_signals=False removed on OpenSUSE:

$ env/bin/python -m perf compare_to fork.json vfork.json
Mean +- std dev: [fork] 154 ms +- 18 ms -> [vfork] 1.23 ms +- 0.04 ms: 125.52x faster (-99%)

Compared to posix_spawn, the results on the same machine are similar:

$ env/bin/python -m perf compare_to posix_spawn.json vfork.json
Mean +- std dev: [posix_spawn] 1.24 ms +- 0.04 ms -> [vfork] 1.22 ms +- 0.05 ms: 1.02x faster (-2%)

Note that my implementation should work even for QEMU user-mode (and probably WSL) because it doesn't rely on address space sharing.

Things to do:

* Decide whether pthread_setcancelstate() should be used. I'd be grateful for opinions from Python threading experts.

* Decide whether "setxid problem"[5] is important enough to worry about.

* Deal with GCC warnings.

* Test in user-mode QEMU and WSL.

[1] https://svnweb.freebsd.org/base/head/lib/libc/gen/posix_spawn.c?view=markup&pathrev=326193
[2] http://austingroupbugs.net/view.php?id=603
[3] https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/spawni.c;h=353bcf5b333457d191320e358d35775a2e9b319b;hb=HEAD
[4] http://git.musl-libc.org/cgit/musl/log/src/process/posix_spawn.c
[5] https://ewontfix.com/7
[6] https://sourceware.org/bugzilla/show_bug.cgi?id=10311
[7] https://sourceware.org/bugzilla/show_bug.cgi?id=18862
[8] https://github.com/dotnet/corefx/pull/33289

----------
components: Extension Modules
messages: 334336
nosy: gregory.p.smith, izbyshev, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Use vfork() in subprocess on Linux
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Thu Jan 24 21:07:49 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 25 Jan 2019 02:07:49 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548382069.67.0.323407198559.issue35823@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +11484
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Thu Jan 24 21:07:56 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 25 Jan 2019 02:07:56 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548382076.36.0.179683605971.issue35823@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch, patch
pull_requests: +11484, 11485
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Thu Jan 24 21:08:02 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 25 Jan 2019 02:08:02 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548382082.19.0.428269114959.issue35823@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch, patch, patch
pull_requests: +11484, 11485, 11486
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Thu Jan 24 21:37:20 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 25 Jan 2019 02:37:20 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548383840.5.0.103013531452.issue35537@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Is sys.platform equal to 'linux' on WSL? Sorry, I don't know WSL. If it's equal, is it possible to explicitly exclude WSL in the subprocess test, _use_posix_spawn()?

I don't have immediate access to WSL right now, but I'll try to get one and investigate what we have there wrt. posix_spawn() and vfork().

> So the bug only affects "QEMU User Space". I never used that before. 

Yes, I was specifically referring to QEMU user-space. One use case that heavily relies on it is Tizen. Its packages are built in a chroot jail containing the build environment with binaries native to the target architecture, making an illusion that packages are built on the target system and are not cross-compiled. So the binaries are run under QEMU user-space emulation. But in reality, because of unacceptable performance of binary translation, many frequently-used binaries, like coreutils and compilers, are replaced with host-native binaries in a way transparent to the build system (so it has no idea whether it runs host-native or target-native binaries).

> Does the difference matters? The bug only occurs in some very specific cases:

> * WSL
> * QEMU User Emulation

> Are these use cases common enough to block the whole idea of using posix_spawn() on Linux. I don't think so. I really want to use posix_spawn() for best performances! Moreover, I expect that glibc implementation of posix_spawn() is safer than Python _posixsubprocess. The glibc has access to low-level stuff like it's internal signals, cancellation points, etc. _posixsubprocess is more generic and doesn't worry about such low-level stuff, whereas they might cause bad surprised.

It's true that a C library is in a better position to implement something like posix_spawn(), but I still think that vfork()/exec() is worth to consider at least on Linux. See bpo-35823, which should also work under QEMU user-mode and WSL (but needs testing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Thu Jan 24 21:48:43 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 25 Jan 2019 02:48:43 +0000
Subject: [issue35814] Syntax quirk with variable annotations
In-Reply-To: <1548308739.94.0.144807070146.issue35814@roundup.psfhosted.org>
Message-ID: <1548384523.48.0.0629212829451.issue35814@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35814>
_______________________________________

From report at bugs.python.org  Thu Jan 24 22:08:25 2019
From: report at bugs.python.org (MeiK)
Date: Fri, 25 Jan 2019 03:08:25 +0000
Subject: [issue35824] http.cookies._CookiePattern modifying regular expressions
Message-ID: <1548385704.31.0.124133284281.issue35824@roundup.psfhosted.org>


Change by MeiK <meik2333 at gmail.com>:


----------
components: Extension Modules
nosy: MeiK
priority: normal
severity: normal
status: open
title: http.cookies._CookiePattern modifying regular expressions
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35824>
_______________________________________

From report at bugs.python.org  Thu Jan 24 22:11:05 2019
From: report at bugs.python.org (MeiK)
Date: Fri, 25 Jan 2019 03:11:05 +0000
Subject: [issue35824] http.cookies._CookiePattern modifying regular expressions
Message-ID: <1548385865.75.0.22198302427.issue35824@roundup.psfhosted.org>


New submission from MeiK <meik2333 at gmail.com>:

http.cookies.BaseCookie[1] can't parse Expires in this format like Expires=Thu,31 Jan 2019 05:56:00 GMT;(Less space after Thu,).

I encountered this problem in actual use, Chrome, IE and Firefox can parse this string normally. Many languages, such as JavaScript, can also parse this data automatically.

I built a test site using Flask: https://paste.ubuntu.com/p/K7Z4K4KH7Z/, Use curl and requests to get cookies correctly, but not with aiohttp (because it uses http.cookies.BaseCookie).

Looking at MDN[2] and rfc[3](Thanks tirkarthi), this doesn't seem to be a canonical behavior, But some Java WEB frameworks will produce this behavior (such as the one that caused me to find the problem).

This problem can be solved by modifying a regular expression[4], but I don't know if it should be compatible with this non-standard way of writing.

English is not my native language; please excuse typing errors.


[1] https://github.com/python/cpython/blob/master/Lib/http/cookies.py#L457
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives
[3] https://tools.ietf.org/html/rfc6265#section-4.1.1
[4] https://github.com/python/cpython/blob/master/Lib/http/cookies.py#L444

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35824>
_______________________________________

From report at bugs.python.org  Thu Jan 24 22:29:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 03:29:47 +0000
Subject: [issue35824] http.cookies._CookiePattern modifying regular expressions
In-Reply-To: <1548385865.75.0.22198302427.issue35824@roundup.psfhosted.org>
Message-ID: <1548386987.79.0.108597218768.issue35824@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the MDN cookie directive link. I didn't know it links to Date link in the GitHub PR. I don't see space optional in the sane-date format specified for expires attribute. I could be reading the grammar wrong. I will wait for others thoughts on this.

----------
nosy: +xtreak
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35824>
_______________________________________

From report at bugs.python.org  Fri Jan 25 00:46:06 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Jan 2019 05:46:06 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548395166.02.0.436157345563.issue35821@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I believe the information is clear from this link in the documentation:

https://docs.python.org/3/howto/logging.html#logging-flow

However, if you can suggest alternative wording which you think is clearer, I'll certainly take a look at it. Perhaps a link could be added to this section from the logging.Logger.propagate section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Fri Jan 25 01:18:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 06:18:34 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548397114.32.0.0165205859503.issue35224@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I don't know if this is the correct issue for questions/clarifications but it seems parens are mandatory while using named expressions in while statement which makes some of the examples invalid like https://www.python.org/dev/peps/pep-0572/#sysconfig-py . From my limited knowledge while statement Grammar was not modified at https://github.com/python/cpython/pull/10497/files#diff-cb0b9d6312c0d67f6d4aa1966766ceddR73 and no tests for while statement which made me assume it's intentional. I haven't followed the full discussion about PEP 572 so feel free to correct me if it's a conscious decision and in that case the PEP 572 can be updated.

# python info

?  cpython git:(master) ./python.exe
Python 3.8.0a0 (heads/bpo35113-dirty:49329a217e, Jan 25 2019, 09:57:53)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

# Example as in PEP 572 to create a simple file that reads itself and prints lines that matches "foo"

?  cpython git:(master) cat /tmp/foo.py
import re

with open("/tmp/foo.py") as f:
    while line := f.readline():
        if match := re.search(r"foo", line):
            print(match.string.strip("\n"))
?  cpython git:(master) ./python.exe /tmp/foo.py
  File "/tmp/foo.py", line 4
    while line := f.readline():
               ^
SyntaxError: invalid syntax

# Wrapping named expression with parens for while makes this valid

?  cpython git:(master) cat /tmp/foo.py
import re

with open("/tmp/foo.py") as f:
    while (line := f.readline()):
        if match := re.search(r"foo", line):
            print(match.string.strip("\n"))
?  cpython git:(master) ./python.exe /tmp/foo.py
with open("/tmp/foo.py") as f:
        if match := re.search(r"foo", line):


As a user I think parens shouldn't be mandatory in while statement since if statement works fine. Parens can cause while statement to be superfluous in some cases and an extra case to remember while teaching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Jan 25 01:58:45 2019
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 25 Jan 2019 06:58:45 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548399525.45.0.682804342841.issue35821@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for the diagram. How about the following as a replacement?

"If this attribute is true and the event isn't rejected by the logger's level and filters, an event passed to this logger will recursively be passed to its parent logger and handled by the parent logger's handlers (after being handled by the original logger's handlers). The logger level and filters only come into play for the very first logger in this chain. For subsequent loggers, only the propagate attribute determines whether the event is passed to the parent."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Fri Jan 25 02:05:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 07:05:25 +0000
Subject: [issue35666] Update design FAQ about assignment expression
In-Reply-To: <1546704480.61.0.245493701505.issue35666@roundup.psfhosted.org>
Message-ID: <1548399925.29.0.0449631710051.issue35666@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> I believe a spot where assignment expressions are explicitly mentioned as not being included in the language, which is no longer the case

Emily, I guess you were referring to this issue in https://bugs.python.org/issue35224#msg334331 . Now that PEP 572 implementation is merged this can be updated.

Thanks

----------
nosy: +emilyemorehouse, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35666>
_______________________________________

From report at bugs.python.org  Fri Jan 25 02:10:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 07:10:04 +0000
Subject: [issue35666] Update design FAQ about assignment expression
In-Reply-To: <1546704480.61.0.245493701505.issue35666@roundup.psfhosted.org>
Message-ID: <1548400204.4.0.871240425701.issue35666@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ah sorry I think this could be a duplicate of issue34237 where you have added an update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35666>
_______________________________________

From report at bugs.python.org  Fri Jan 25 02:41:52 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 25 Jan 2019 07:41:52 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548402112.47.0.406024778106.issue35823@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Issue #34663 contains some earlier discussion about vfork, in the context of supporting a specific posix_spawn flag on Linux.

W.r.t. closing all file descriptors > 2: posix_spawn_file_actions_addclose can do this when using posix_spawn. That would have a performance cost, you'd basically have to resort to closing all possible file descriptors and cannot use the smarter logic used in _posixsubprocess. However, the smarter closing code in _posixsubprocess is not safe w.r.t. vfork according to the comment above _close_open_fds_maybe_unsafe: that function uses some functions that aren't async-safe and one of those calls malloc.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Fri Jan 25 02:43:35 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 25 Jan 2019 07:43:35 +0000
Subject: [issue34397] remove redundant overflow checks in tuple and list
 implementations
In-Reply-To: <1534189134.26.0.56676864532.issue34397@psf.upfronthosting.co.za>
Message-ID: <1548402215.69.0.450916772646.issue34397@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I reviewed the patch months ago, maybe we need a core developer review this path?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34397>
_______________________________________

From report at bugs.python.org  Fri Jan 25 03:26:56 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 25 Jan 2019 08:26:56 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1548404816.79.0.338991456936.issue35810@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

It seems right that a heap allocate object owns a reference to its (non-static) type. But the mere fact that you had to adapt stdlib code makes it obvious that this will also break existing user code out there. And such breakage is very likely to remain undetected for a while, since leaking types is unlikely to have a big enough memory impact in most application to be easily detected.

This is a tough call. Any ideas for reducing the chance of breakage or increasing the chance of detecting it in user code would help.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Fri Jan 25 05:31:18 2019
From: report at bugs.python.org (Kristof Niederholtmeyer)
Date: Fri, 25 Jan 2019 10:31:18 +0000
Subject: [issue35825] Py_UNICODE_SIZE=4 fails to link on Windows
Message-ID: <1548412277.74.0.133748802246.issue35825@roundup.psfhosted.org>


New submission from Kristof Niederholtmeyer <kristof.niederholtmeyer at synopsys.com>:

When I change Py_UNICODE_SIZE from 2 (default) to 4 in PC/pyconfig.h, msvc-14 gives the following error:
  _winreg.obj : error LNK2001: unresolved external symbol PyUnicode_DecodeMBCS [e:\kristof\SDR\sdrsandbox\w64\msvc140\Python-2.7.15\PCbuild\pythoncore.vcxproj]
  e:\kristof\SDR\sdrsandbox\w64\msvc140\Python-2.7.15\PCBuild\\amd64\python27_snps_vp.dll : fatal error LNK1120: 1 unresolved externals [e:\kristof\SDR\sdrsandbox\w64\msvc140\Python-2.7.15\PCbuild\pythoncore.vcxproj]

The problem appears to be that the missing function gets disabled in unicodeobject.c with
#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)
...
#endif

while _winreg.c does not check the availability of this function.

Thanks,
Kristof

----------
components: Build, Windows
messages: 334348
nosy: kristof, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Py_UNICODE_SIZE=4 fails to link on Windows
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35825>
_______________________________________

From report at bugs.python.org  Fri Jan 25 05:44:14 2019
From: report at bugs.python.org (Kevin Mai-Hsuan Chia)
Date: Fri, 25 Jan 2019 10:44:14 +0000
Subject: [issue35826] Typo in example for async with statement with condition
Message-ID: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>


New submission from Kevin Mai-Hsuan Chia <kevin at mhchia.com>:

In the [example](https://docs.python.org/3.8/library/asyncio-sync.html#asyncio.Condition) of the equivalent code to the `async with statement`:
```python
cond = asyncio.Condition()

# ... later
await lock.acquire()
try:
    await cond.wait()
finally:
    lock.release()
```

`lock.acquire()` should be replaced by `cond.acquire()`, and `lock.release()` replaced by `cond.release()`. So the resulting code snippet becomes:

```python
cond = asyncio.Condition()

# ... later
await cond.acquire()
try:
    await cond.wait()
finally:
    cond.release()
```

----------
assignee: docs at python
components: Documentation
messages: 334349
nosy: docs at python, mhchia
priority: normal
severity: normal
status: open
title: Typo in example for async with statement with condition
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Fri Jan 25 05:45:14 2019
From: report at bugs.python.org (Kevin Mai-Hsuan Chia)
Date: Fri, 25 Jan 2019 10:45:14 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548413114.61.0.24849994852.issue35826@roundup.psfhosted.org>


Kevin Mai-Hsuan Chia <kevin at mhchia.com> added the comment:

In the [example](https://docs.python.org/3.8/library/asyncio-sync.html#asyncio.Condition) of the equivalent code to the `async with` statement:
```python
cond = asyncio.Condition()

# ... later
await lock.acquire()
try:
    await cond.wait()
finally:
    lock.release()
```

`lock.acquire()` should be replaced by `cond.acquire()`, and `lock.release()` replaced by `cond.release()`. So the resulting code snippet becomes:

```python
cond = asyncio.Condition()

# ... later
await cond.acquire()
try:
    await cond.wait()
finally:
    cond.release()
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Fri Jan 25 05:50:04 2019
From: report at bugs.python.org (Barry Davis)
Date: Fri, 25 Jan 2019 10:50:04 +0000
Subject: [issue31171] multiprocessing.BoundedSemaphore of 32-bit python could
 not work while cross compiling on linux platform
In-Reply-To: <1502349716.95.0.155037219321.issue31171@psf.upfronthosting.co.za>
Message-ID: <1548413404.09.0.724248584674.issue31171@roundup.psfhosted.org>


Barry Davis <barry_davis at stormagic.com> added the comment:

I've just hit this issue using Python-2.7.9, gcc-8.1.0, glibc-2.23.

The patch I made to fix the issue based on comments in this issue:

--- Python-2.7.9/setup.py       2019-01-25 09:30:39.049501423 +0000
+++ Python-2.7.9/setup.py       2019-01-25 09:30:55.369609646 +0000
@@ -1670,7 +1670,7 @@

         else:                                   # Linux and other unices
             macros = dict()
-            libraries = ['rt']
+            libraries = ['rt', 'pthread']

         if host_platform == 'win32':
             multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
@@ -1690,6 +1690,7 @@

         if sysconfig.get_config_var('WITH_THREAD'):
             exts.append ( Extension('_multiprocessing', multiprocessing_srcs,
+                                    libraries = libraries,
                                     define_macros=macros.items(),
                                     include_dirs=["Modules/_multiprocessing"]))
         else:

----------
nosy: +Barry Davis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31171>
_______________________________________

From report at bugs.python.org  Fri Jan 25 05:58:47 2019
From: report at bugs.python.org (Barry Davis)
Date: Fri, 25 Jan 2019 10:58:47 +0000
Subject: [issue31171] multiprocessing.BoundedSemaphore of 32-bit python could
 not work while cross compiling on linux platform
In-Reply-To: <1502349716.95.0.155037219321.issue31171@psf.upfronthosting.co.za>
Message-ID: <1548413927.16.0.935728629479.issue31171@roundup.psfhosted.org>


Barry Davis <barry_davis at stormagic.com> added the comment:

The behaviour I saw (32-bit only) was a python process getting stuck.

I got this from strace:
...
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL)  = -1 EAGAIN (Resource temporarily unavailable)
...

And this from gdb:
(gdb) bt
#0  0xb76fbc5d in __kernel_vsyscall ()
#1  0xb74af2a4 in sem_wait () from /lib/libpthread.so.0
#2  0xb69a5429 in ?? () from /usr/lib/python2.7/lib-dynload/_multiprocessing.so
#3  0xb75a262e in call_function (oparg=<optimized out>, pp_stack=0xbfb7f038) at Python/ceval.c:4033
#4  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2679
#5  0xb75a2f7d in PyEval_EvalCodeEx (co=<optimized out>, globals=
    {'Queue': <type at remote 0xb69c43dc>, 'atexit': <module at remote 0xb6d369bc>, 'Semaphore': <type at remote 0xb69b978c>, 'Empty': <type at remote 0xb69b902c>, 'Full': <type at remote 0xb69b9204>, 'SimpleQueue': <type at remote 0xb69c478c>, 'assert_spawning': <function at remote 0xb69ba684>, '__all__': ['Queue', 'SimpleQueue', 'JoinableQueue'], '_multiprocessing': <module at remote 0xb6c16944>, '_sentinel': <object at remote 0xb726f4d0>, '__package__': 'multiprocessing', 'collections': <module at remote 0xb71bce3c>, '__doc__': None, 'Condition': <type at remote 0xb69c402c>, 'JoinableQueue': <type at remote 0xb69c45b4>, '__builtins__': {'bytearray': <type at remote 0xb76c27e0>, 'IndexError': <type at remote 0xb76c6900>, 'all': <built-in function all>, 'help': <_Helper at remote 0xb71f824c>, 'vars': <built-in function vars>, 'SyntaxError': <type at remote 0xb76c6c80>, 'unicode': <type at remote 0xb76d6c00>, 'UnicodeDecodeError': <type at remote 0xb76c6420>, 'memoryview': <type at remote 0xb76cdda0>, 'isinstance...(truncated), locals=0x0, args=0xb535f5cc, argcount=2, kws=0xb535f5d4, kwcount=0, defs=0xb69b6058, defcount=2, closure=0x0) at Python/ceval.c:3265
#6  0xb75a0f3d in fast_function (nk=0, na=<optimized out>, n=2, pp_stack=0xbfb7f178, func=<function at remote 0xb69c51b4>) at Python/ceval.c:4129
#7  call_function (oparg=<optimized out>, pp_stack=0xbfb7f178) at Python/ceval.c:4054
#8  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2679
...
(gdb) py-bt
#4 Frame 0xb536602c, for file /usr/lib/python2.7/multiprocessing/queues.py, line 101, in put (self=<Queue(_writer=<_multiprocessing.Connection at remote 0x96878c8>, _recv=<built-in method recv of _multiprocessing.Connection object at remote 0x967ddc8>, _thread=None, _sem=<BoundedSemaphore(release=<built-in method release of _multiprocessing.SemLock object at remote 0xb53427c0>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0xb53427c0>, _semlock=<_multiprocessing.SemLock at remote 0xb53427c0>) at remote 0xb53425cc>, _buffer=<collections.deque at remote 0xb533f844>, _closed=False, _send=<built-in method send of _multiprocessing.Connection object at remote 0x96878c8>, _jointhread=None, _reader=None, _opid=3752, _rlock=<Lock(release=<built-in method release of _multiprocessing.SemLock object at remote 0xb5342420>, acquire=<built-in method acquire of _multiprocessing.SemLock object at remote 0xb5342420>, _semlock=<_multiprocessing.SemLock at remote 0xb5342420>) at remote 0xb534240c>, _...(truncated)
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31171>
_______________________________________

From report at bugs.python.org  Fri Jan 25 06:03:32 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 25 Jan 2019 11:03:32 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548414212.29.0.117756128765.issue35823@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Fri Jan 25 06:17:10 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 25 Jan 2019 11:17:10 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548415030.91.0.111428002674.issue35823@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> W.r.t. closing all file descriptors > 2: posix_spawn_file_actions_addclose can do this when using posix_spawn. That would have a performance cost, you'd basically have to resort to closing all possible file descriptors and cannot use the smarter logic used in _posixsubprocess.

This is costly to the point of people reporting bugs: bpo-35757. If that really causes 0.1s delay like the reporter said, it would defeat the purpose of using posix_spawn() in the first place.

> However, the smarter closing code in _posixsubprocess is not safe w.r.t. vfork according to the comment above _close_open_fds_maybe_unsafe: that function uses some functions that aren't async-safe and one of those calls malloc.

No, it's not so on Linux: https://github.com/python/cpython/blob/62c35a8a8ff5854ed470b1c16a7a14f3bb80368c/Modules/_posixsubprocess.c#L314

Moreover, as I already argued in msg332235, using malloc() after vfork() should be *safer* than after fork() for a simple reason: all memory-based locks will still work as though the child is merely a thread in the parent process. This is true even for things like futex(FUTEX_WAKE_PRIVATE), despite that this operation is mistakenly documented as "process-private" in man pages. It's actually more like "private to tasks sharing the same address space".

This is in contrast with fork(): if it's called while another thread is holding some mutex in malloc(), nobody would unlock it in the child unless the C library has precautions against that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:01:45 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jan 2019 12:01:45 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548417705.53.0.32960901235.issue34134@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 3bab40db96efda2e127ef84e6501fda0cdc4f5b8 by Antoine Pitrou (Windson yang) in branch 'master':
bpo-34134: Advise to use imap or imap_unordered when handling long iterables. (gh-8324)
https://github.com/python/cpython/commit/3bab40db96efda2e127ef84e6501fda0cdc4f5b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:02:12 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 12:02:12 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548417732.76.0.220104523505.issue34134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11487

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:02:20 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 12:02:20 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548417740.82.0.156049655879.issue34134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11487, 11488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:04:26 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 12:04:26 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548417866.44.0.62992139559.issue34134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11489

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:04:35 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 12:04:35 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548417875.05.0.880578707767.issue34134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11489, 11490

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:04:44 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 12:04:44 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548417884.49.0.598435394643.issue34134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11489, 11490, 11491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:05:06 2019
From: report at bugs.python.org (Ori Avtalion)
Date: Fri, 25 Jan 2019 12:05:06 +0000
Subject: [issue35827] C API dictionary views type checkers are not documented
Message-ID: <1548417904.67.0.718119168094.issue35827@roundup.psfhosted.org>


New submission from Ori Avtalion <ori at avtalion.name>:

dictobject.h defines several helpers to ease checking of dictionary view types. If they are meant to be part of the API, they should be documented.

PyDictKeys_Check
PyDictItems_Check
PyDictValues_Check
PyDictViewSet_Check

Should they be added to dict.rst, or a separate file?

----------
assignee: docs at python
components: Documentation
messages: 334355
nosy: docs at python, salty-horse
priority: normal
severity: normal
status: open
title: C API dictionary views type checkers are not documented
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35827>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:08:16 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jan 2019 12:08:16 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548418096.53.0.243390465092.issue34134@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset c2674bf11036af1e06c1be739f0eebcc72dfbf7a by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
bpo-34134: Advise to use imap or imap_unordered when handling long iterables. (gh-8324) (gh-11673)
https://github.com/python/cpython/commit/c2674bf11036af1e06c1be739f0eebcc72dfbf7a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:17:21 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 25 Jan 2019 12:17:21 +0000
Subject: [issue34134] multiprocessing memory huge usage
In-Reply-To: <1531800230.72.0.56676864532.issue34134@psf.upfronthosting.co.za>
Message-ID: <1548418641.46.0.0443092547802.issue34134@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is basically fixed, except that I'll let the Release Manager choose whether 3.6 gets the fix as well. Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34134>
_______________________________________

From report at bugs.python.org  Fri Jan 25 07:36:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 12:36:00 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1548419760.36.0.441253282076.issue35224@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Note: I checked and 3.x buildbots are back to green (ignoring the ones which already failed previously). Good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Jan 25 08:06:48 2019
From: report at bugs.python.org (Michael Felt)
Date: Fri, 25 Jan 2019 13:06:48 +0000
Subject: [issue35828] test_multiprocessing_* tests - success versus fail
 varies over time
Message-ID: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Last August I started running a bot for AIX using xlc_r as the compiler, rather than gcc that the other AIX bot uses.

Initially, I had no issues with the test_multiprocess* tests, but of late (last two+ months I am guessing) I have been having regular issues when the bot builds, but not when I would run the tests (all 418) or individually - when run manually.

The last two weeks I have invested time - and have been repaid - in that I can now get a regular failure when running the tests.

Your assistance is appreciated. I'll continue to work on this when I have time.


Short version:

This looks like there is a statement "crafted" to cause a crash:
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"
_PyDict_GetItemId(dp = 0xdbdbdbdb, key = 0xdbdbdbdb), line 3276 in "dictobject.c"
...

This is based on bot run that failed (Python 3.8.0a0 (heads/master:0785889468)).

The test message that comes back is:

test_multiprocessing_fork failed
Process Process-94:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/process.py", line 302, in _bootstrap
    self.run()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/_test_multiprocessing.py", line 2847, in _putter
    manager.connect()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/managers.py", line 512, in connect
    conn = Client(self._address, authkey=self._authkey)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py", line 796, in XmlClient
    return ConnectionWrapper(Client(*args, **kwds), _xml_dumps, _xml_loads)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py", line 502, in Client
    c = SocketClient(address)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py", line 629, in SocketClient
    s.connect(address)
ConnectionRefusedError: [Errno 79] Connection refused
test test_multiprocessing_fork failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/_test_multiprocessing.py", line 2865, in test_rapid_restart
    queue = manager.get_queue()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/managers.py", line 701, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/managers.py", line 584, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py", line 796, in XmlClient
    return ConnectionWrapper(Client(*args, **kwds), _xml_dumps, _xml_loads)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py", line 502, in Client
    c = SocketClient(address)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/multiprocessing/connection.py", line 629, in SocketClient
    s.connect(address)
ConnectionRefusedError: [Errno 79] Connection refused

I had a hard time finding anything - because I was looking for a permission issue in the Socket "domain", but what seems more likely is that the "server" thread/process is crashing with a segmentation fault and a "client" thread is getting "refused" because the server no longer exists and/or never got successfully started.

I finally managed to capture a core dump and I hope that this will help you help me with getting deeper and closer to a resolution/understanding on what is going on.

buildbot at x064:[/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue]area/coredumps/core.12582914.25123239                        <
Type 'help' for help.
warning: The core file is not a fullcore. Some info may
not be available.
[using memory image in /home/buildbot/buildarea/coredumps/core.12582914.25123239]
reading symbolic information ...

Segmentation fault in PyDict_GetItem at line 1320 in file "Objects/dictobject.c"
 1320       if (!PyDict_Check(op))
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"

>From other data about the program I expect the segmentation error is caused by the key value. Unless the program has done a mmap/shmap request for memory allocation (something not done by default) the address 0x30000000-0x3fffffff is not a valid address.

Summary:

This looks like there is a statement "crafted" to cause a crash:
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"
_PyDict_GetItemId(dp = 0xdbdbdbdb, key = 0xdbdbdbdb), line 3276 in "dictobject.c"
...

Gory details:
(dbx) where
PyDict_GetItem(op = 0x2002ddc8, key = 0x30061e68), line 1320 in "dictobject.c"
_PyDict_GetItemId(dp = 0xdbdbdbdb, key = 0xdbdbdbdb), line 3276 in "dictobject.c"
unnamed block in _PyEval_EvalFrameDefault(f = 0x1000eb04, throwflag = 807503860), line 957 in "ceval.c"
unnamed block in _PyEval_EvalFrameDefault(f = 0x1000eb04, throwflag = 807503860), line 957 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1000eb04, throwflag = 807503860), line 957 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100111d0, throwflag = 537350752), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x1009f4b0, globals = 0x202f476c, locals = (nil), args = (nil), argcount = 24, kwnames = 0x30211d88, kwargs = 0x202f4700, kwcount = -2013255516, kwstep = 2, defs = 0x302187f4, defcount = 1, kwdefs = (nil), closure = (nil), name = 0x300022e8, qualname = 0x30214928), line 3969 in "ceval.c"
_PyFunction_FastCallDict(func = 0x1010ac50, args = 0x20021c28, nargs = 539970704, kwargs = 0x820028af), line 380 in "call.c"
_PyObject_FastCallDict(callable = 0x10209a1c, args = 0x30a17028, nargs = 539969536, kwargs = 0x2820424f), line 100 in "call.c"
_PyObject_Call_Prepend(callable = 0x100206ac, obj = 0x20077e84, args = 0x202f4880, kwargs = 0x20088734), line 906 in "call.c"
slot_tp_init(self = 0x100de870, args = 0x00000074, kwds = 0x20126740), line 6638 in "typeobject.c"
unnamed block in type_call(type = 0x100d9ed8, args = 0x20021c28, kwds = 0x202f4940), line 954 in "typeobject.c"
type_call(type = 0x100d9ed8, args = 0x20021c28, kwds = 0x202f4940), line 954 in "typeobject.c"
_PyObject_FastCallKeywords(callable = 0x30665450, stack = 0x3008c1b0, nargs = 805573048, kwnames = 0x103521ac), line 201 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 807520936), line 4658 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de870, throwflag = 813135108), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3021dbf8, globals = 0x2008d708, locals = 0xcfb98979, args = 0x30037e30, argcount = 807520936, kwnames = 0x3021a4f0, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = 0x30218a04, defcount = 1, kwdefs = (nil), closure = (nil), name = 0x3021caa8, qualname = 0x3021caa8), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x202f50b8, stack = 0x300d3ef8, nargs = 539971696, kwnames = 0x222022cf), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x20089a38, throwflag = 807373136), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = (nil), throwflag = 807476128), line 581 in "ceval.c"
function_code_fastcall(co = 0x3021df78, args = 0x2008d708, nargs = 538317872, globals = 0x00000034), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x3091f5a0, stack = 0x30041b50, nargs = 815894632, kwnames = 0x30142e64), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 807366808), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100cc074, throwflag = 806932108), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x202f61bc, globals = 0x3021a570, locals = 0x202f5d10, args = 0x30037e30, argcount = 269083832, kwnames = 0x301f49f0, kwargs = 0x202f5d10, kwcount = 537429812, kwstep = 1, defs = 0x3022123c, defcount = 2, kwdefs = (nil), closure = (nil), name = 0x301f7098, qualname = 0x301f7098), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x1018c538, stack = 0x30a158e8, nargs = 537037592, kwnames = 0x30142e64), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805546776), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100cc074, throwflag = 807787624), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x202f686c, globals = 0x301f4c70, locals = 0x202f63c0, args = 0x30037e30, argcount = 269083832, kwnames = 0x301edbf0, kwargs = 0x202f63c0, kwcount = 537429812, kwstep = 1, defs = 0x30218464, defcount = 1, kwdefs = (nil), closure = (nil), name = 0x3003ab18, qualname = 0x3003ab18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x1003470c, stack = 0x200058f8, nargs = 539976896, kwnames = 0x20088734), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100c3c64, throwflag = 807867476), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x301f19e0, throwflag = 807867476), line 581 in "ceval.c"
function_code_fastcall(co = 0x301f5418, args = 0x2008d708, nargs = -796895527, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x1018c538, stack = 0x3096a9b8, nargs = 814795680, kwnames = 0x20088734), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x3091e488, throwflag = 805546776), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100cc074, throwflag = 810945964), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x202f758c, globals = 0x301edc70, locals = 0x202f70e0, args = 0x15e8c00d, argcount = 269083832, kwnames = 0x309ec970, kwargs = 0x202f70e0, kwcount = 537429812, kwstep = 1, defs = 0x301f3884, defcount = 1, kwdefs = (nil), closure = (nil), name = 0x3003ab18, qualname = 0x3003ab18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x3091f540, stack = 0x30005840, nargs = 815871240, kwnames = 0x42204842), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100c1d90, throwflag = 537410828), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 814835560), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x309ec970, locals = 0x202f7770, args = 0x20088734, argcount = 269346004, kwnames = 0x20021c28, kwargs = 0x202f7770, kwcount = 815881976, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x2007d04c, locals = 0x202f77e0, args = 0x200058f8, argcount = 269237348, kws = 0x300ba1a8, kwcount = 539981808, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x30a15f00, globals = 0x300ba1ac, locals = 0x202f7820), line 558 in "ceval.c"
builtin_exec(module = 0x1000eb04, args = (nil), nargs = 539981952, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x100c6724, args = 0x300ba1ac, nargs = 0), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x100a0d3c, self = 0x103461d0, args = (nil), nargs = 815035112, kwargs = 0x309435f0), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x3007f8a8, args = 0x309ec9b0, nargs = 539982304, kwargs = 0x220048cf), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = (nil), kwargs = 0x300927d0), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 815019488), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x100c1d90, stack = 0x200058f8, nargs = 539984160, kwnames = 0x4420228f), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 814745524), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 815712688), line 581 in "ceval.c"
function_code_fastcall(co = 0x202f8bdc, args = 0x3096ecf0, nargs = 539985712, globals = 0x309007ac), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x3096ed20, stack = 0x30055ea8, nargs = 537028192, kwnames = 0x00000049), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 815253484), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 815253488), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x10010cf8, stack = 0x300cf030, nargs = 805768508, kwnames = 0x4420228f), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 814745132), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 814745132), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x00000030, stack = 0x202dc120, nargs = -260629964, kwnames = 0x202d8840), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x00000008, throwflag = 815253044), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 537009192), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = 0x200058f8, nargs = 539990624, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x3002dfa8, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 539990896, kwargs = 0x302dc830), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = "0-\307\3600-\307\260"), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x302beee8, 0x3003a7a0, 0x0, 0x4ea54, 0xdb, 0x30828de0), line 1250 in "call.c"
import_find_and_load(abs_name = 0x309044f8), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x302dc428, globals = 0x309ecaf0, locals = 0x202f9d20, fromlist = 0x300bc190, level = 269346004), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x302dc428, globals = 0x309ecaf0, locals = 0x202f9d20, fromlist = 0x300bc190, level = 269346004), line 1748 in "import.c"
import_name(f = 0x100c5e54, name = 0x10338aa8, fromlist = 0x202f9d80, level = 0x20088734), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x10010cf8, throwflag = 537410828), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 815072624), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x309ecaf0, locals = 0x202fa3b0, args = 0x20088734, argcount = 269346004, kwnames = 0x10338aa8, kwargs = 0x309e8e60, kwcount = 537434348, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x200058f8, locals = 0x202fa450, args = 0x20088734, argcount = 269246788, kws = (nil), kwcount = 539993120, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x00000003, globals = 0x300ba1ac, locals = (nil)), line 558 in "ceval.c"
builtin_exec(module = 0x10337030, args = (nil), nargs = 539993344, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x00000003, args = 0x307bbe28, nargs = 805795944), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x3007df24, self = 0x103461d0, args = (nil), nargs = 815035480, kwargs = 0x30943478), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x00000004, args = 0x0000008d, nargs = 806068652, kwargs = 0x30089ad8), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = 0x300ba1a8, kwargs = 0x30031290), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 815019112), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x100c1d90, stack = 0x200058f8, nargs = 539995488, kwnames = 0x4420228f), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 814744724), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 815713072), line 581 in "ceval.c"
function_code_fastcall(co = 0x202fb81c, args = 0x3096e990, nargs = 539997040, globals = 0x3090048c), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x3096e900, stack = 0x30055ea8, nargs = 537028192, kwnames = 0x0000004f), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 815252260), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 815252264), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x10010cf8, stack = 0x300cf030, nargs = 805768508, kwnames = 0x4420228f), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 814744332), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 814744332), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x00000002, stack = (nil), nargs = 538317872, kwnames = 0x304e9d30), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x00000006, throwflag = 815035836), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 537028216), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = 0x20161430, nargs = 540001952, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x30828de0, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 540002224, kwargs = 0x20088734), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = "0N\235\2600N\235p"), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x304a86e8, 0x3003a7a0, 0x0, 0x4e71c, 0xdb, 0x30828de0), line 1250 in "call.c"
import_find_and_load(abs_name = 0x3097dbf8), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30286ee8, globals = 0x309ecc70, locals = 0x202fc960, fromlist = 0x300bc190, level = 269346004), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30286ee8, globals = 0x309ecc70, locals = 0x202fc960, fromlist = 0x300bc190, level = 269346004), line 1748 in "import.c"
import_name(f = 0x100c5e54, name = 0x10338aa8, fromlist = 0x202fc9c0, level = 0x20088734), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x10010cf8, throwflag = 537410828), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 815071504), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x309ecc70, locals = 0x202fcff0, args = 0x20088734, argcount = 269346004, kwnames = 0x10338aa8, kwargs = 0x309e8f78, kwcount = 537434348, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x200058f8, locals = 0x202fd090, args = 0x20088734, argcount = 269246788, kws = (nil), kwcount = 540004448, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x00000003, globals = 0x300ba1ac, locals = (nil)), line 558 in "ceval.c"
builtin_exec(module = 0x10337030, args = (nil), nargs = 540004672, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x00000003, args = 0x307bbca8, nargs = 805795944), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x3007df24, self = 0x103461d0, args = (nil), nargs = 815036216, kwargs = 0x306a9bd0), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x00000004, args = 0x0000008d, nargs = 806068652, kwargs = 0x30089ad8), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = 0x300ba1a8, kwargs = 0x30031290), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 812293056), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x100c1d90, stack = 0x200058f8, nargs = 540006816, kwnames = 0x4420228f), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 812375540), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 815713456), line 581 in "ceval.c"
function_code_fastcall(co = 0x202fe45c, args = 0x3096e3c0, nargs = 540008368, globals = 0x306bddec), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x3096e270, stack = 0x30055ea8, nargs = 537028192, kwnames = 0x0000004e), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 815251852), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 815251856), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x10010cf8, stack = 0x300cf030, nargs = 805768508, kwnames = 0x4420228f), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812375148), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 812375148), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x00000002, stack = (nil), nargs = 538317872, kwnames = 0x304e9d30), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x00000005, throwflag = 812342084), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 537028216), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = 0x20161430, nargs = 540013280, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x3082e5a0, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 540013552, kwargs = 0x20088734), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = "0N\235\2600N\235p"), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x3091cfa0, 0x3003a7a0, 0x0, 0x4e40f, 0xdb, 0x3082e5a0), line 1250 in "call.c"
import_find_and_load(abs_name = 0x30977e28), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30097df0, globals = 0x309ecdf0, locals = 0x202ff5a0, fromlist = 0x442042c4, level = 269346004), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30097df0, globals = 0x309ecdf0, locals = 0x202ff5a0, fromlist = 0x442042c4, level = 269346004), line 1748 in "import.c"
import_name(f = 0x1000eb04, name = 0x10338aa8, fromlist = 0x202ff600, level = 0x200898ec), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x10010cf8, throwflag = 537410828), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 815011856), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x309ecdf0, locals = 0x202ffc30, args = 0x20088734, argcount = 269346004, kwnames = 0x10338aa8, kwargs = 0x309e8e60, kwcount = 537434348, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x200058f8, locals = 0x202ffcd0, args = 0x20088734, argcount = 269246788, kws = (nil), kwcount = 540015776, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x00000003, globals = 0x300ba1ac, locals = (nil)), line 558 in "ceval.c"
builtin_exec(module = 0x10337030, args = (nil), nargs = 540016000, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x00000003, args = 0x307bbb28, nargs = 805795944), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x3007df24, self = 0x103461d0, args = (nil), nargs = 812148536, kwargs = 0x306a9a58), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x00000004, args = 0x0000008d, nargs = 806068652, kwargs = 0x30089ad8), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = 0x300ba1a8, kwargs = 0x30031290), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 812292680), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x100c1d90, stack = 0x200058f8, nargs = 540018144, kwnames = 0x4420228f), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 812374340), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 815713840), line 581 in "ceval.c"
function_code_fastcall(co = 0x2030109c, args = 0x30973f30, nargs = 540019696, globals = 0x306bd93c), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x30973f60, stack = 0x30055ea8, nargs = 537028192, kwnames = 0x0000004a), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812358836), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 812358840), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x10010cf8, stack = 0x300cf030, nargs = 805768508, kwnames = 0x4420228f), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812373948), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 812373948), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x100c6724, stack = 0x00000311, nargs = 540023088, kwnames = 0x6f636e65), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x00000005, throwflag = 812195788), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 806149408), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = (nil), nargs = 540024608, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x3082e5a0, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 540024880, kwargs = 0x20088734), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = "0^N^Z00^Mop"), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x3091cf58, 0x3003a7a0, 0x0, 0x4e09d, 0xdb, 0x3082e5a0), line 1250 in "call.c"
import_find_and_load(abs_name = 0x30977338), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x3009d568, globals = 0x309ecf70, locals = 0x203021e0, fromlist = 0x482042c4, level = 269346004), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x3009d568, globals = 0x309ecf70, locals = 0x203021e0, fromlist = 0x482042c4, level = 269346004), line 1748 in "import.c"
import_name(f = 0x203022f0, name = 0x300652f8, fromlist = 0x20302250, level = 0x4220422f), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x10010cf8, throwflag = 537410828), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 815201728), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x309ecf70, locals = 0x20302870, args = 0x20088734, argcount = 269346004, kwnames = 0x10338aa8, kwargs = 0x309e87a8, kwcount = 537434348, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x200058f8, locals = 0x20302910, args = 0x20088734, argcount = 269246788, kws = (nil), kwcount = 540027104, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x00000003, globals = 0x300ba1ac, locals = (nil)), line 558 in "ceval.c"
builtin_exec(module = 0x10337030, args = (nil), nargs = 540027328, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x00000003, args = 0x307bba28, nargs = 805795944), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x3007df24, self = 0x103461d0, args = (nil), nargs = 809333848, kwargs = 0x306bd188), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x00000004, args = 0x0000008d, nargs = 806068652, kwargs = 0x30089ad8), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = 0x300ba1a8, kwargs = 0x30031290), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 812372344), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x102097b0, stack = 0x300b9770, nargs = 537028768, kwnames = 0x20088734), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 812356772), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 815714224), line 581 in "ceval.c"
function_code_fastcall(co = 0x20303cdc, args = 0x30946720, nargs = 540031024, globals = 0x306b949c), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x309469c0, stack = 0x30055ea8, nargs = 537028192, kwnames = 0x20088734), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812355980), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 812355984), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x100c6084, stack = 0x00000001, nargs = 540032768, kwnames = 0x20088734), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812325596), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 812325596), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x000084b1, stack = 0x0000405d, nargs = 540164848, kwnames = 0x000084a1), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x00000001, throwflag = 812314220), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 537009192), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = 0x309b7d50, nargs = 814817192, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x100c30bc, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 540036208, kwargs = 0x0000014d), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = warning: Unable to access address 0xdbdbdbdb from core
(invalid char ptr (0xdbdbdbdb))), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x304e9fa8, 0x3003a7a0, 0x0, 0x4deb7, 0xcb, 0x306aee88), line 1250 in "call.c"
import_find_and_load(abs_name = 0x3097abf8), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30005840, globals = 0x306bc9f0, locals = 0x20304e20, fromlist = 0x20088734, level = 269346004), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30005840, globals = 0x306bc9f0, locals = 0x20304e20, fromlist = 0x20088734, level = 269346004), line 1748 in "import.c"
import_name(f = 0x000083df, name = 0x20304f6c, fromlist = 0x20304e80, level = 0x42204842), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x100c1d90, throwflag = 537410828), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 815247744), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x306bc9f0, locals = 0x203054b0, args = 0x20088734, argcount = 269346004, kwnames = 0x20021c28, kwargs = 0x203054b0, kwcount = 815697696, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x2007d04c, locals = 0x20305520, args = 0x200058f8, argcount = 269237348, kws = 0x300ba1a8, kwcount = 540038448, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x309e8f28, globals = 0x300ba1ac, locals = 0x20305560), line 558 in "ceval.c"
builtin_exec(module = 0x1000eb04, args = (nil), nargs = 540038592, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x0000001a, args = 0x20077e84, nargs = 815031568), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x100a0d3c, self = 0x103461d0, args = (nil), nargs = 812326392, kwargs = 0x306a9d48), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x3007f8a8, args = 0x306bca70, nargs = 540038944, kwargs = 0x220048cc), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = (nil), kwargs = 0x300927d0), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 812293432), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x1018c538, stack = 0x300b9770, nargs = 540040960, kwnames = 0x20088734), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 812373140), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 812370544), line 581 in "ceval.c"
function_code_fastcall(co = 0x2030691c, args = 0x30946510, nargs = 540042352, globals = 0x306bd48c), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x309466c0, stack = 0x30055ea8, nargs = 537028192, kwnames = 0x300553e8), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812357204), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 812357208), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x100a0d3c, stack = 0x3002c958, nargs = 540044096, kwnames = 0x20088734), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 812372748), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 812372748), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x202d2e20, stack = 0x202d6130, nargs = 805955712, kwnames = 0x20161430), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x00000007, throwflag = 812345196), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 814615216), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = (nil), nargs = 540047264, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x30055b68, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 540047536, kwargs = 0x22de5185), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = "0k\312\2600k\312\360"), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x304a8ba8, 0x3003a7a0, 0x0, 0x4d0b7, 0xdb, 0x30653a40), line 1250 in "call.c"
import_find_and_load(abs_name = 0x30960178), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x309a5418, globals = 0x306acf30, locals = 0x20307a60, fromlist = 0x20088734, level = 269346004), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x309a5418, globals = 0x306acf30, locals = 0x20307a60, fromlist = 0x20088734, level = 269346004), line 1748 in "import.c"
import_name(f = 0x00008505, name = 0x20307bac, fromlist = 0x20307ac0, level = 0x42204242), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x100c1d90, throwflag = 537410828), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x00000001, throwflag = 815384032), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x30061e28, globals = 0x306acf30, locals = 0x203080f0, args = 0x20088734, argcount = 269346004, kwnames = 0x20021c28, kwargs = 0x203080f0, kwcount = 814950664, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 3969 in "ceval.c"
PyEval_EvalCodeEx(_co = 0x10109cb0, globals = 0x2007d04c, locals = 0x20308160, args = 0x200058f8, argcount = 269237348, kws = 0x300ba1a8, kwcount = 540049776, defs = 0x20088734, defcount = 0, kwdefs = (nil), closure = (nil)), line 4000 in "ceval.c"
PyEval_EvalCode(co = 0x30932910, globals = 0x300ba1ac, locals = 0x203081a0), line 558 in "ceval.c"
builtin_exec(module = 0x1000eb04, args = (nil), nargs = 540049920, ??), line 1040 in "bltinmodule.c"
builtin_exec(module = 0x100c6724, args = 0x300ba1ac, nargs = 0), line 317 in "bltinmodule.c.h"
_PyMethodDef_RawFastCallDict(method = 0x100a0d3c, self = 0x103461d0, args = (nil), nargs = 812195432, kwargs = 0x30798a58), line 532 in "call.c"
_PyCFunction_FastCallDict(func = 0x3007f8a8, args = 0x306ac730, nargs = 540050272, kwargs = 0x220042cf), line 585 in "call.c"
PyCFunction_Call(func = 0x100da54c, args = (nil), kwargs = 0x300927d0), line 791 in "call.c"
do_call_core(func = 0x200af330, callargs = 0x300ba1a8, kwdict = 0x30031290), line 4681 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x1034b668, throwflag = 805419800), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1009f9b0, throwflag = 813271624), line 581 in "ceval.c"
_PyEval_EvalCodeWithName(_co = 0x3007bbf8, globals = 0x2008d708, locals = 0x055abdc8, args = 0x30037e30, argcount = 805547336, kwnames = 0x2008d708, kwargs = 0x20161430, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x3001bb18, qualname = 0x3001bb18), line 3969 in "ceval.c"
_PyFunction_FastCallKeywords(func = 0x100c3dc4, stack = (nil), nargs = 540052288, kwnames = 0x30600d78), line 437 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 814590276), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30055ce8, throwflag = 812304176), line 581 in "ceval.c"
function_code_fastcall(co = 0x2030955c, args = 0x308e0b70, nargs = 540053680, globals = 0x308da93c), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x308e0f30, stack = 0x30055ea8, nargs = 537028192, kwnames = 0xcbcbcbcb), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 815270276), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x3006e348, throwflag = 815270280), line 581 in "ceval.c"
function_code_fastcall(co = 0x30062568, args = 0x2008d708, nargs = 135563570, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x100c6724, stack = 0x30831cf0, nargs = 540055440, kwnames = 0x20088734), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x1009f88c, throwflag = 814588684), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x1011900c, throwflag = 814588684), line 581 in "ceval.c"
function_code_fastcall(co = 0x300625d8, args = 0x2008d708, nargs = 1019748152, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x30061e28, stack = 0x30998070, nargs = 540057104, kwnames = 0x306b2480), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = (nil), throwflag = 812195060), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100de860, throwflag = 812316976), line 581 in "ceval.c"
function_code_fastcall(co = 0x1009f88c, args = 0xcbcbcbcb, nargs = 540058576, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x100a0d3c, args = (nil), nargs = 537556816, kwargs = (nil)), line 324 in "call.c"
_PyObject_FastCallDict(callable = (nil), args = 0x2008bf70, nargs = 540058864, kwargs = 0x306ac8a0), line 100 in "call.c"
object_vacall(callable = 0x100de658, vargs = ""), line 1200 in "call.c"
_PyObject_CallMethodIdObjArgs(obj = 0x30061db0, name = 0x20039710, ... = 0x307a6a28, 0x3003a7a0, 0x0, 0x4b651, 0xcb, 0x30691ba8), line 1250 in "call.c"
import_find_and_load(abs_name = 0x3061ee50), line 1652 in "import.c"
unnamed block in PyImport_ImportModuleLevelObject(name = 0x30691bb0, globals = 0x20021c28, locals = 0x2030a6a0, fromlist = 0x880042c4, level = 269329740), line 1748 in "import.c"
PyImport_ImportModuleLevelObject(name = 0x30691bb0, globals = 0x20021c28, locals = 0x2030a6a0, fromlist = 0x880042c4, level = 269329740), line 1748 in "import.c"
import_name(f = 0x100c1d90, name = 0xffffffff, fromlist = 0x2030a710, level = 0x42002224), line 4836 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x100de860, throwflag = 812215736), line 2722 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30344060, throwflag = 812151856), line 581 in "ceval.c"
function_code_fastcall(co = 0x2030b1bc, args = 0x30621c00, nargs = 540060944, globals = 0x30696dac), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x100fe3d4, stack = 0x305608a4, nargs = 540061056, kwnames = 0x20088734), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x10109334, throwflag = 812316528), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x100fc8d0, throwflag = -889192245), line 581 in "ceval.c"
function_code_fastcall(co = 0x30022868, args = 0x20077e84, nargs = 807677136, globals = (nil)), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x200009f0, args = 0x20077e84, nargs = 537028216, kwargs = 0x3024c82e), line 324 in "call.c"
_PyObject_FastCallDict(callable = 0x00000002, args = 0x20077e84, nargs = 16, kwargs = (nil)), line 100 in "call.c"
_PyObject_Call_Prepend(callable = 0x30245e00, obj = 0x306ac5b0, args = (nil), kwargs = 0x306acfb0), line 906 in "call.c"
method_call(method = 0x1021f5ac, args = (nil), kwargs = 0x2030b570), line 304 in "classobject.c"
PyObject_Call(callable = 0x100a2254, args = 0x20021c28, kwargs = 0x2030b570), line 247 in "call.c"
do_call_core(func = 0x308ddf90, callargs = 0x30250ca0, kwdict = 0x20026660), line 4709 in "ceval.c"
_PyEval_EvalFrameDefault(f = 0x300bae00, throwflag = 812198764), line 3285 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30048aa8, throwflag = 812306352), line 581 in "ceval.c"
function_code_fastcall(co = 0x2030c08c, args = 0x308dd090, nargs = 540064736, globals = 0x30037e30), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = (nil), stack = (nil), nargs = 0, kwnames = (nil)), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = 0x100c6144, throwflag = 812196632), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x30254658, throwflag = 812306352), line 581 in "ceval.c"
function_code_fastcall(co = 0x2030c6fc, args = 0x308dd090, nargs = 540066384, globals = 0x20088734), line 285 in "call.c"
_PyFunction_FastCallKeywords(func = 0x30825b80, stack = 0x200058f8, nargs = 540066496, kwnames = 0x308ddb08), line 410 in "call.c"
_PyEval_EvalFrameDefault(f = (nil), throwflag = -875836469), line 4655 in "ceval.c"
PyEval_EvalFrameEx(f = 0x10144cb8, throwflag = 812131072), line 581 in "ceval.c"
function_code_fastcall(co = 0x202d2110, args = 0x202d2118, nargs = 1548420902, globals = 0x0005e716), line 285 in "call.c"
_PyFunction_FastCallDict(func = 0x10010cf8, args = 0x2030c9d0, nargs = 1548420902, kwargs = 0x0005e715), line 324 in "call.c"
_PyObject_FastCallDict(callable = 0xd0127034, args = 0xcbcbcbcb, nargs = 540068256, kwargs = 0xf0766408), line 100 in "call.c"
_PyObject_Call_Prepend(callable = 0x1000f0f0, obj = 0x175a9b70, args = 0x2030ca20, kwargs = 0x20088734), line 906 in "call.c"
method_call(method = 0x100fd6d4, args = 0x200058c8, kwargs = 0x2030ca70), line 304 in "classobject.c"
PyObject_Call(callable = 0x20081d14, args = 0x3082ab90, kwargs = 0x2030cab0), line 247 in "call.c"
t_bootstrap(boot_raw = 0xcbcbcbcb), line 994 in "_threadmodule.c"
pythread_wrapper(arg = (nil)), line 174 in "thread_pthread.h"
(dbx)

----------
messages: 334359
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_multiprocessing_* tests - success versus fail varies over time
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35828>
_______________________________________

From report at bugs.python.org  Fri Jan 25 08:32:40 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Jan 2019 13:32:40 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548423160.6.0.115582801338.issue35821@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

That isn't quite accurate. A logger's attached handlers will always be offered a chance to handle an event if the logger's level and filters allow. However, the event is not actually passed to ancestor loggers - it is directly offered to any handlers attached to ancestor loggers, until a logger is encountered where propagate is false - and that is the last logger whose handlers are offered the event. All handlers have their own levels and filters and may or may not process an event according to those levels and filters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Fri Jan 25 08:45:00 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 25 Jan 2019 13:45:00 +0000
Subject: [issue30548] typo in documentation for create_autospec
In-Reply-To: <1496394381.09.0.91116482689.issue30548@psf.upfronthosting.co.za>
Message-ID: <1548423900.23.0.759804680211.issue30548@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Mario is right that this isn't a typo.  Here's a code example to illustrate what he said:

>>> class MyClass:
...     a = 3
...     def foo(self): pass
...
>>> mock_class = create_autospec(MyClass)
>>> mock_class
<MagicMock spec='MyClass' id='16678696'>
>>> mock_class()
<NonCallableMagicMock name='mock()' spec='MyClass' id='16752016'>
>>> mock_class.foo
<MagicMock name='mock.foo' spec='function' id='16751032'>

>>> mock_instance = create_autospec(MyClass, instance=True)
>>> mock_instance
<NonCallableMagicMock spec='MyClass' id='16757832'>
>>> mock_instance()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NonCallableMagicMock' object is not callable
>>> mock_instance.foo
<MagicMock name='mock.foo' spec='function' id='16750024'>

As per the docs, the instance object uses the class as the spec and it isn't callable, whereas the mock class is.  Would adding this example to the docs help or would a different code example help make this less misleading?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30548>
_______________________________________

From report at bugs.python.org  Fri Jan 25 09:00:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 14:00:46 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548424846.07.0.976398187561.issue35823@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11492

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Fri Jan 25 09:00:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Jan 2019 14:00:59 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548424859.8.0.298500764212.issue35823@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +11492, 11493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Fri Jan 25 09:15:35 2019
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 25 Jan 2019 14:15:35 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548425735.77.0.951546919363.issue35821@roundup.psfhosted.org>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I'm not sure which part of what I wrote you think is inaccurate. All of what you wrote matches what I was trying to convey.

For example, my saying "pass to the parent logger" corresponds to the "set current logger to parent" box in the diagram. And by "handled by the parent logger's handlers" I meant "directly offered to any handlers attached to ancestor loggers." And "only the propagate attribute determines whether the event is passed" matches your "until a logger is encountered where propagate is false."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Fri Jan 25 10:03:35 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 25 Jan 2019 15:03:35 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548428615.45.0.590011097105.issue35707@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Fri Jan 25 10:49:25 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 25 Jan 2019 15:49:25 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548431365.16.0.240407848456.issue35823@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. I hadn't noticed _close_open_fds_safe, that should be safe when using vfork(). 

Finally: I have no strong opinion on this patch, your explanation looks fine and I'm not up-to-speed w.r.t. implementation details of vfork and the like to feel comfortable about giving a proper review without spending a lot more time on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Fri Jan 25 12:16:32 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Fri, 25 Jan 2019 17:16:32 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
In-Reply-To: <1548091630.84.0.140233087609.issue35800@roundup.psfhosted.org>
Message-ID: <1548436592.88.0.321996997488.issue35800@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch
pull_requests: +11494
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Fri Jan 25 12:16:40 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Fri, 25 Jan 2019 17:16:40 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
In-Reply-To: <1548091630.84.0.140233087609.issue35800@roundup.psfhosted.org>
Message-ID: <1548436600.79.0.249787542019.issue35800@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11494, 11495
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Fri Jan 25 12:16:48 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Fri, 25 Jan 2019 17:16:48 +0000
Subject: [issue35800] remove smtpd.MailmanProxy
In-Reply-To: <1548091630.84.0.140233087609.issue35800@roundup.psfhosted.org>
Message-ID: <1548436608.53.0.671185137145.issue35800@roundup.psfhosted.org>


Change by Samuel Colvin <samcolvin at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11494, 11495, 11496
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35800>
_______________________________________

From report at bugs.python.org  Fri Jan 25 13:26:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 18:26:55 +0000
Subject: [issue35815] Able to instantiate a subclass with abstract methods
 from __init_subclass__ of the ABC
In-Reply-To: <1548316625.2.0.852101004839.issue35815@roundup.psfhosted.org>
Message-ID: <1548440815.16.0.328642180074.issue35815@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35815>
_______________________________________

From report at bugs.python.org  Fri Jan 25 13:40:28 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 25 Jan 2019 18:40:28 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1548441628.34.0.0805835200065.issue35808@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35808>
_______________________________________

From report at bugs.python.org  Fri Jan 25 14:07:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jan 2019 19:07:42 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1548443262.59.0.0733703229509.issue35782@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

We usually don't backport exception message changes, for the reason given, unless the content is wrong or misleading.  Unless Raymond says otherwise, I think the backport should be closed as too trivial and this issue closed as fixed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35782>
_______________________________________

From report at bugs.python.org  Fri Jan 25 14:36:48 2019
From: report at bugs.python.org (rdb)
Date: Fri, 25 Jan 2019 19:36:48 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
Message-ID: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>


New submission from rdb <rddeblois at gmail.com>:

The fromisoformat() function added in 3.7 is a very welcome addition.  But one quite noticeable absence was the inability to parse Z instead of +00:00 as the timezone suffix.

Its absence is particularly noticeable given how ubiquitous use of Z is in ISO 8601 timestamps on the web; it is also part of the RFC 3339 subset.  In particular, JavaScript produces it in its canonical ISO 8601 format and is therefore quite common in JSON APIs; this would be the only piece missing to parse ISO dates produced by JavaScript correctly.

I realise that the function was not intended to be able to parse *all* timestamps.  But given the triviality of this change, the ubiquity of this particular formatting feature, and the fact that this change is designed in particular for operability with the widely-used JavaScript date format, I don't think this is a slippery slope, and I would personally see no harm in accepting a 'Z' instead of a timezone.

I am happy to follow up with a patch for this, but would first like confirmation that there is any chance that such a change would be accepted.  Thanks for your consideration!

----------
components: Library (Lib)
messages: 334365
nosy: rdb
priority: normal
severity: normal
status: open
title: datetime: parse "Z" timezone suffix in fromisoformat()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Fri Jan 25 14:55:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 25 Jan 2019 19:55:56 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1548446156.53.0.790338538265.issue35829@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:30:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 20:30:20 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548448220.94.0.179874885324.issue35797@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +11497
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:30:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 20:30:36 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548448236.18.0.0591905298283.issue35797@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch
pull_requests: +11497, 11498
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:30:55 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 20:30:55 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548448255.15.0.225127382673.issue35797@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch, patch
pull_requests: +11497, 11498, 11499
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:35:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jan 2019 20:35:08 +0000
Subject: [issue35798] duplicate SyntaxWarning: "is" with a literal
In-Reply-To: <1548083625.41.0.59098075844.issue35798@roundup.psfhosted.org>
Message-ID: <1548448508.21.0.170421895943.issue35798@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified that master on Windows (which requires " instead of ')
> python -c "if object() is 42: pass"
results in the doubled messsage, and that after applying PR 11639 and recompiling, there is only 1 message.

We should test that exactly 1 warning is emitted.  The following fails on master and passes with the parch:

import unittest, warnings

class SyntaxWarningTest(unittest.TestCase):
    def test_syntax_warning_once(self):
        with warnings.catch_warnings(record=True) as w:
            warnings.simplefilter("always")
            compile('if object() is 42: pass\n', '', 'single')
            self.assertEqual(len(w), 1)  # Not 2, see issue 35798

if __name__ == '__main__':
    unittest.main()
    
The original patch added test_comparison_is_literal() in test_grammar.  The 'with' block above could be added at the end.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35798>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:45:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Jan 2019 20:45:26 +0000
Subject: [issue35825] Py_UNICODE_SIZE=4 fails to link on Windows
In-Reply-To: <1548412277.74.0.133748802246.issue35825@roundup.psfhosted.org>
Message-ID: <1548449126.32.0.205335997795.issue35825@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think this falls in the category of "don't do that", because Windows does not support wide builds.  If so, this issue should be closed as 'not a bug'.  If not, some Windows expert should enlighten me.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35825>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:47:14 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 20:47:14 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548449234.71.0.436482599329.issue35811@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +11500
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:47:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 20:47:26 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548449246.77.0.685607125631.issue35811@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch
pull_requests: +11500, 11501
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:47:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 20:47:40 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548449260.06.0.455088422988.issue35811@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch, patch
pull_requests: +11500, 11501, 11502
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 15:59:32 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 25 Jan 2019 20:59:32 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1548449972.67.0.304605594308.issue35829@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

You can see the discussion in bpo-15873 for the full rationale of why "Z" was omitted - to quote from https://bugs.python.org/issue15873#msg307607 :

> We can have further discussion later about what exactly should be supported in Python 3.8,
> but even in the pre-release discussions I'm already seeing pushback about some of the more
> unusual 8601 formats, and it's a *lot* easier to explain (in documentation) that `fromisoformat()`
> is intended to be the inverse of `isoformat()` than it is to explain which variations of ISO 8601
> are and are not supported (fractional minutes? if you're following the standard, the separator has
> to be a T, so what other variations of the standard are allowed?)

With the current implementation, the contract of the function is very simple to explain: datetime.fromisoformat() is the inverse operation of datetime.isoformat(), which is to say that every valid input to datetime.fromisoformat() is a possible output of datetime.isoformat(), and every possible output of datetime.isoformat() is a valid input to datetime.fromisoformat().

With that as the background - fromisoformat() was designed to be a conservative API because scope is a one-way ratchet, and it's better to under-commit than over-commit. We do have the option going forward of widening the scope of the function in a backwards-compatible way. The main problem I see is that I think we should maintain the property that it should be dead simple to explain what a function does, and having to enumerate edge cases is a code smell. So "it is the inverse operation of fromisoformat(), but it also supports specifying using Z for UTC" fails that test in my opinion.

I see a few rational choices here:

1. Supports the full ISO 8601 datetime spec and all outputs from datetime.isoformat() (these inputs mostly but not completely overlap). We would then just have to decide on a simple policy for how to deal with the optional portions of the spec.

2. Support only the rfc3339 standard + the outputs of datetime.isoformat(), with the option to switch to #1 later.

3. Add the ability for `datetime.isoformat()` to output 'Z' instead of `00:00`, which would allow us to support it as an input and also keep the scope of `datetime.fromisoformat` unchanged.

4. Add a separate function (either a classmethod or a bare function) for parsing exactly the ISO 8601 standard, maybe `parse_iso8601`, so both `parse_iso8601` and `fromisoformat` have a clean, rational explanation for what they do.

5. Leave the current scope alone and don't add anything.

5a. Leave the current scope alone and point people in the direction of `dateutil.parser.isoparse` in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Fri Jan 25 16:09:57 2019
From: report at bugs.python.org (Matej Cepl)
Date: Fri, 25 Jan 2019 21:09:57 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1548450597.75.0.178853689547.issue34623@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

> Will this change be backported to 3.5 and 3.4? It applied cleanly on both however on 3.4 there is a test failure:

It actually haven't applied cleanly to me on Python 3.4.6 (SLE-12 package). Apparently self->parser has to be changed into self_xp->parser. Then all tests passed for me.

If any Linux maintainer wants to take this patch.

----------
nosy: +mcepl
Added file: https://bugs.python.org/file48077/CVE-2018-14647_XML_SetHashSalt-in_elementtree.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34623>
_______________________________________

From report at bugs.python.org  Fri Jan 25 17:15:22 2019
From: report at bugs.python.org (rdb)
Date: Fri, 25 Jan 2019 22:15:22 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1548454522.74.0.92696908658.issue35829@roundup.psfhosted.org>


rdb <rddeblois at gmail.com> added the comment:

I'm a fan of "be lenient in what you accept" but I can see your point in not causing confusion about what this method is meant to be used for.

Because what I'm trying to use it for technically falls outside the intended use, I say it would make the most sense to expand the intended use a bit.  From a cursory glance at the RFC3339 spec it looks like the only other change needed to fully support RFC3339 would be to support an arbitrary number of sub-second digits, whereas fromisoformat() currently requires either exactly 3 or 6.

So, I can bundle this together with a change making it more lenient about the number of decimal places for seconds, and we can change the docs for `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those generated by isoformat()".

Does this seem acceptable?  We can always expand further to allow any ISO 8601 timestamp later, but RFC3339 would already make this function immensely more useful.  I really think that parsing RFC3339 dates is a feature Python needs to have in the standard library given their ubiquity on the web.

Alternatively I am happy to consider adding something like a utc=True flag to isoformat(), but I would personally feel reluctant to add any features that I can't think of a solid use case for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Fri Jan 25 17:26:54 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Jan 2019 22:26:54 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548455214.6.0.0854882064228.issue35766@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The PR is ready for reviews now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Fri Jan 25 17:35:52 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 25 Jan 2019 22:35:52 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1548455752.27.0.463718076079.issue35829@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

>  I can see your point in not causing confusion about what this method is meant to be used for.

In this case, making it easy to explain what it does is less important than making the scope and contract of the function clear so that we don't have to argue about what should and should not be supported. Having a narrowly-scoped function is also useful for other reasons:

1. The API is clearer - there are no options to configure on this function, if you start supporting a bunch of features, people will inevitably want to turn some of them *off*, because they only want to accept a subset of the valid inputs.

2. The interface to test is clear - we can exhaustively test the entire contract of the function if desired.

3. Development will not get stalled in decision-making about which features to support or how they might interfere with one another.

> From a cursory glance at the RFC3339 spec it looks like the only other change needed to fully support RFC3339 would be to support an arbitrary number of sub-second digits, whereas fromisoformat() currently requires either exactly 3 or 6.

There are other differences, for example a comma can be used in place of a dot as the delimiter for fractional seconds. Looking at the grammar in the RFC, it seems that it might also support datetimes like 2018-W03-D4, but I don't see any mention of that in the text.

> So, I can bundle this together with a change making it more lenient about the number of decimal places for seconds, and we can change the docs for `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those generated by isoformat()".

No, because the isoformat outputs are not a subset of RFC 3339. For example, 2015-01-01T00:00:00 is not a valid RFC 3339 datetime string, nor is 2015-01-01Q00:00:00, but they are valid outputs of datetime.isoformat(). datetime.fromisoformat() also supports fractional seconds on time zone offsets, which is not part of ISO 8601.

> Because what I'm trying to use it for technically falls outside the intended use, I say it would make the most sense to expand the intended use a bit. 

Is there a reason you can't use `dateutil.parser.isoparse`? The contract of that function is to parse any valid ISO8601 datetime, and fromisoformat is adapted from it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Fri Jan 25 17:59:17 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 22:59:17 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548457157.6.0.429608327666.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 4e02f8f8b4baab63f927cfd87b401200ba2969e9 by Steve Dower in branch 'master':
bpo-35797: Fix default executable used by the multiprocessing module (GH-11676)
https://github.com/python/cpython/commit/4e02f8f8b4baab63f927cfd87b401200ba2969e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 17:59:39 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 22:59:39 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548457179.11.0.585529267167.issue35797@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11503

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 17:59:56 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 22:59:56 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548457196.42.0.729806229973.issue35797@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11503, 11504

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:00:00 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 23:00:00 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548457200.88.0.158585380047.issue35811@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset adad9e68013aac166c84ffe4e23f3a5464f41840 by Steve Dower in branch 'master':
bpo-35811: Avoid propagating venv settings when launching via py.exe (GH-11677)
https://github.com/python/cpython/commit/adad9e68013aac166c84ffe4e23f3a5464f41840


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:00:15 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 23:00:15 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548457215.81.0.574497574449.issue35811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11506

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:00:15 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 23:00:15 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548457215.58.0.864438158695.issue35797@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11503, 11504, 11505

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:00:29 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 23:00:29 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548457229.35.0.160650228024.issue35811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11506, 11507

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:00:42 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 23:00:42 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548457242.77.0.557422852881.issue35811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11506, 11507, 11508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:05:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Jan 2019 23:05:21 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548457521.97.0.783142575671.issue35797@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I realised while doing the fix that changing sys.executable to point to the "real" python.exe would break scenarios that involve generating scripts. All of those have been relying on sys.executable launching the venv, which would break if we changed it there.

Instead, we now just load the direct executable name in multiprocessing as I posted earlier when we detect that __PYVENV_LAUNCHER__ was set on Windows. Having a "sys.base_executable" property might have been valuable here, but as we don't need it for all platforms I just used the _winapi module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:10:28 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 25 Jan 2019 23:10:28 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548457828.64.0.253737031509.issue35826@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Please submit a PR!

----------
components: +asyncio -Documentation
keywords: +easy
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:14:45 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 23:14:45 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548458085.65.0.279140924256.issue35797@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6a9c0fca3f2f93681468b51929472f4433753f25 by Miss Islington (bot) in branch '3.7':
bpo-35797: Fix default executable used by the multiprocessing module (GH-11676)
https://github.com/python/cpython/commit/6a9c0fca3f2f93681468b51929472f4433753f25


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:17:55 2019
From: report at bugs.python.org (rdb)
Date: Fri, 25 Jan 2019 23:17:55 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548455752.27.0.463718076079.issue35829@roundup.psfhosted.org>
Message-ID: <CABOkLvRgyHQ9edFuj3MOGRdadBE3OJ8S4LEOdtzpMRV6rrAPZg@mail.gmail.com>


rdb <rddeblois at gmail.com> added the comment:

> > From a cursory glance at the RFC3339 spec it looks like the only other change needed to fully support RFC3339 would be to support an arbitrary number of sub-second digits, whereas fromisoformat() currently requires either exactly 3 or 6.
>
> There are other differences, for example a comma can be used in place of a dot as the delimiter for fractional seconds. Looking at the grammar in the RFC, it seems that it might also support datetimes like 2018-W03-D4, but I don't see any mention of that in the text.

I think you're looking at the appendix, which collects the ABNF from
ISO 8601, but this is not part of RFC3339.  The grammar for RFC3339 is
purposefully very restrictive to make parsing it simple.  The comma
for delimiter is in though, good catch; also a trivial change.

> > So, I can bundle this together with a change making it more lenient about the number of decimal places for seconds, and we can change the docs for `fromisoformat()` to be "it accepts any RFC3339 timestamp, including those generated by isoformat()".
>
> No, because the isoformat outputs are not a subset of RFC 3339. For example, 2015-01-01T00:00:00 is not a valid RFC 3339 datetime string, nor is 2015-01-01Q00:00:00, but they are valid outputs of datetime.isoformat(). datetime.fromisoformat() also supports fractional seconds on time zone offsets, which is not part of ISO 8601.

Fair enough (though I'd say "isoformat()" is a misnomer then).  I was
just going by your option #2.  We would change the wording to imply
"supports RFC 3339 or anything produced by isoformat()"

>
> > Because what I'm trying to use it for technically falls outside the intended use, I say it would make the most sense to expand the intended use a bit.
>
> Is there a reason you can't use `dateutil.parser.isoparse`? The contract of that function is to parse any valid ISO8601 datetime, and fromisoformat is adapted from it.

It seems a little odd to need to pull in a third-party library for
this; it seems far more tempting for me to just do
"datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I
know my dates are produced by a JSON API.

I don't intend to get argumentative about whether supporting RFC3339
belongs in the standard library; that is clearly a decision for the
Python maintainers, and I'm not sure what criteria they follow on
this.  I just find it odd to point people to a third-party library for
parsing a simple but ubiquitous date standard when there are many
modules in the standard library for far more specific use cases.

FWIW, I do think that fromisoformat() is the right function to provide
RFC3339 support.  I don't think users would benefit from having to
choose between several different functions that parse similar but
subtly different date formats; this seems likely to cause confusion.

Thanks for your consideration!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:30:19 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Fri, 25 Jan 2019 23:30:19 +0000
Subject: [issue35656] More matchers in unittest.mock
In-Reply-To: <1546599891.86.0.0577370914139.issue35656@roundup.psfhosted.org>
Message-ID: <1548459019.37.0.0223445753492.issue35656@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

> due to floating-point inexactness
+1 Its not easy to predict when calculated value will not be equal to expected theoretical value. for example math.cos(radians(90)) is something like 6e-17 rather than 0.
Testing for this exact value would be just awkward.
assertAlmostEqual() is already there in unittest for such comparisons so it wouldn't be completely nonsensical to have something like APPROX

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35656>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:31:23 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Jan 2019 23:31:23 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548459083.47.0.360080382642.issue35811@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a6a8524bb1c78c7425346ec20ecffc02d1d02a79 by Miss Islington (bot) in branch '3.7':
bpo-35811: Avoid propagating venv settings when launching via py.exe (GH-11677)
https://github.com/python/cpython/commit/a6a8524bb1c78c7425346ec20ecffc02d1d02a79


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:45:50 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 25 Jan 2019 23:45:50 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548459950.87.0.406460812496.issue35826@roundup.psfhosted.org>


Change by Carol Willing <willingc at gmail.com>:


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Fri Jan 25 18:47:32 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 25 Jan 2019 23:47:32 +0000
Subject: [issue34691] _contextvars missing in xmaster branch Windows build?
In-Reply-To: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>
Message-ID: <1548460052.08.0.222290186423.issue34691@roundup.psfhosted.org>


Change by Carol Willing <willingc at gmail.com>:


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34691>
_______________________________________

From report at bugs.python.org  Fri Jan 25 19:55:34 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Sat, 26 Jan 2019 00:55:34 +0000
Subject: [issue35830] building multiple (binary) packages from a single project
Message-ID: <1548464133.32.0.379789250574.issue35830@roundup.psfhosted.org>


New submission from Stefan Seefeld <stefan at seefeld.name>:

I'm working on a project that I'd like to split into multiple separately installable components. The main component is a command-line tool without any external dependencies. Another component is a GUI frontend that adds some third-party dependencies.
Therefore, I'd like to distribute the code in a single source package, but separate binary packages (so users can install only what they actually need).

I couldn't find any obvious way to support such a scenario with either `distutils` nor `setuptools`. Is there an easy solution to this ? (I'm currently thinking of adding two `setup()` calls to my `setup.py` script. That would then call all commands twice, so I'd need to override the `sdist` command to only build a single (joint) source package.
Is there a better way to achieve what I want ?

----------
assignee: docs at python
components: Distutils, Documentation
messages: 334381
nosy: docs at python, dstufft, eric.araujo, stefan
priority: normal
severity: normal
status: open
title: building multiple (binary) packages from a single project
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35830>
_______________________________________

From report at bugs.python.org  Fri Jan 25 20:10:52 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Jan 2019 01:10:52 +0000
Subject: [issue35830] building multiple (binary) packages from a single project
In-Reply-To: <1548464133.32.0.379789250574.issue35830@roundup.psfhosted.org>
Message-ID: <1548465052.66.0.195175263975.issue35830@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is a bug tracker for reporting bugs and enhancement requests, not a help desk.

Do you have a *specific* feature request or a bug to report? If not, you should ask this on a community forum such as Stackoverflow, Reddit's r/learnpython, the Python-list mailing list or the Python IRC channel.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35830>
_______________________________________

From report at bugs.python.org  Fri Jan 25 20:14:00 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Sat, 26 Jan 2019 01:14:00 +0000
Subject: [issue35830] building multiple (binary) packages from a single project
In-Reply-To: <1548464133.32.0.379789250574.issue35830@roundup.psfhosted.org>
Message-ID: <1548465240.46.0.626000646076.issue35830@roundup.psfhosted.org>


Stefan Seefeld <stefan at seefeld.name> added the comment:

Yes. Depending on the answer to my question(s), the request either becomes: "please add support for this use-case", or "this use-case isn't documented properly", i.e. a feature request or a bug report. You choose. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35830>
_______________________________________

From report at bugs.python.org  Fri Jan 25 20:44:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 26 Jan 2019 01:44:05 +0000
Subject: [issue35797] concurrent.futures.ProcessPoolExecutor does not work in
 venv on Windows
In-Reply-To: <1548083441.54.0.942305079713.issue35797@roundup.psfhosted.org>
Message-ID: <1548467045.11.0.460679299642.issue35797@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35797>
_______________________________________

From report at bugs.python.org  Fri Jan 25 20:44:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 26 Jan 2019 01:44:38 +0000
Subject: [issue35811] py.exe should unset the __PYVENV_LAUNCHER__ environment
 variable
In-Reply-To: <1548290896.4.0.108661661457.issue35811@roundup.psfhosted.org>
Message-ID: <1548467078.57.0.554615599628.issue35811@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35811>
_______________________________________

From report at bugs.python.org  Fri Jan 25 21:28:41 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Jan 2019 02:28:41 +0000
Subject: [issue35830] building multiple (binary) packages from a single project
In-Reply-To: <1548464133.32.0.379789250574.issue35830@roundup.psfhosted.org>
Message-ID: <1548469721.97.0.477736234133.issue35830@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

The way to achieve this is to make sure your two components live in two separate directories, each with its setup.py.

This is the simple way that works with distutils/setuptools and pip install-from-vcs (you can install from a subdir of a repo).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35830>
_______________________________________

From report at bugs.python.org  Fri Jan 25 23:06:01 2019
From: report at bugs.python.org (Mitchell L Model)
Date: Sat, 26 Jan 2019 04:06:01 +0000
Subject: [issue35831] Format Spec example says limited to 3.1+ but works in 2.7
Message-ID: <1548475560.75.0.51760850853.issue35831@roundup.psfhosted.org>


New submission from Mitchell L Model <mlm at users.sourceforge.net>:

https://docs.python.org/3/library/string.html#format-examples includes this line:

    '{}, {}, {}'.format('a', 'b', 'c')  # 3.1+ only

This does in fact work in 2.7. I don't see anything special about this -- seems an entirely straightforward format.

----------
messages: 334385
nosy: mlm
priority: normal
severity: normal
status: open
title: Format Spec example says limited to 3.1+ but works in 2.7
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/issue35831>
_______________________________________

From report at bugs.python.org  Fri Jan 25 23:06:30 2019
From: report at bugs.python.org (Mitchell L Model)
Date: Sat, 26 Jan 2019 04:06:30 +0000
Subject: [issue35831] Format Spec example says limited to 3.1+ but works in 2.7
In-Reply-To: <1548475560.75.0.51760850853.issue35831@roundup.psfhosted.org>
Message-ID: <1548475590.66.0.606676383554.issue35831@roundup.psfhosted.org>


Change by Mitchell L Model <mlm at users.sourceforge.net>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35831>
_______________________________________

From report at bugs.python.org  Fri Jan 25 23:12:43 2019
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 26 Jan 2019 04:12:43 +0000
Subject: [issue35831] Format Spec example says limited to 3.1+ but works in 2.7
In-Reply-To: <1548475560.75.0.51760850853.issue35831@roundup.psfhosted.org>
Message-ID: <1548475963.28.0.805560598266.issue35831@roundup.psfhosted.org>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

The 3.X docs generally don't refer to the 2.X series.

What that comment is pointing out is that leaving the field identifier out (the number inside the {...} placeholder syntax) was not in the 3.0, but added in 3.1.

Unfortunately, I don't have a 3.0 interpreter available to show the exception that's raised.

No change is required.

----------
nosy: +fdrake
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35831>
_______________________________________

From report at bugs.python.org  Fri Jan 25 23:57:24 2019
From: report at bugs.python.org (Alan Huang)
Date: Sat, 26 Jan 2019 04:57:24 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1548478644.5.0.874729341275.issue35045@roundup.psfhosted.org>


Change by Alan Huang <Alan.Huang at utdallas.edu>:


----------
pull_requests: +11509

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Fri Jan 25 23:57:37 2019
From: report at bugs.python.org (Alan Huang)
Date: Sat, 26 Jan 2019 04:57:37 +0000
Subject: [issue35045] test_min_max_version (test.test_ssl.ContextTests) fails
 on Fedora 29+ and openssl 1.1.1
In-Reply-To: <1540218627.92.0.788709270274.issue35045@psf.upfronthosting.co.za>
Message-ID: <1548478657.91.0.142440130778.issue35045@roundup.psfhosted.org>


Change by Alan Huang <Alan.Huang at utdallas.edu>:


----------
pull_requests: +11509, 11510

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35045>
_______________________________________

From report at bugs.python.org  Sat Jan 26 00:54:41 2019
From: report at bugs.python.org (Kevin Mai-Hsuan Chia)
Date: Sat, 26 Jan 2019 05:54:41 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548482081.5.0.615094700398.issue35826@roundup.psfhosted.org>


Change by Kevin Mai-Hsuan Chia <kevin at mhchia.com>:


----------
keywords: +patch
pull_requests: +11511
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Sat Jan 26 00:54:50 2019
From: report at bugs.python.org (Kevin Mai-Hsuan Chia)
Date: Sat, 26 Jan 2019 05:54:50 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548482090.06.0.34496394056.issue35826@roundup.psfhosted.org>


Change by Kevin Mai-Hsuan Chia <kevin at mhchia.com>:


----------
keywords: +patch, patch
pull_requests: +11511, 11512
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Sat Jan 26 00:54:58 2019
From: report at bugs.python.org (Kevin Mai-Hsuan Chia)
Date: Sat, 26 Jan 2019 05:54:58 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548482098.3.0.158928592034.issue35826@roundup.psfhosted.org>


Change by Kevin Mai-Hsuan Chia <kevin at mhchia.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11511, 11512, 11514
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Sat Jan 26 00:55:05 2019
From: report at bugs.python.org (Kevin Mai-Hsuan Chia)
Date: Sat, 26 Jan 2019 05:55:05 +0000
Subject: [issue35826] Typo in example for async with statement with condition
In-Reply-To: <1548413052.91.0.387178410518.issue35826@roundup.psfhosted.org>
Message-ID: <1548482105.56.0.578952446833.issue35826@roundup.psfhosted.org>


Change by Kevin Mai-Hsuan Chia <kevin at mhchia.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11511, 11512, 11513, 11514
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35826>
_______________________________________

From report at bugs.python.org  Sat Jan 26 01:22:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 26 Jan 2019 06:22:16 +0000
Subject: [issue34766] BaseProxy cache should be cleaned when Manager client is
 reconnected
In-Reply-To: <1537900896.87.0.545547206417.issue34766@psf.upfronthosting.co.za>
Message-ID: <1548483736.89.0.969795237578.issue34766@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34766>
_______________________________________

From report at bugs.python.org  Sat Jan 26 01:52:01 2019
From: report at bugs.python.org (Aivar Annamaa)
Date: Sat, 26 Jan 2019 06:52:01 +0000
Subject: [issue35101] inspect.findsource breaks on class frame objects
In-Reply-To: <1540786670.85.0.788709270274.issue35101@psf.upfronthosting.co.za>
Message-ID: <1548485521.13.0.87779413109.issue35101@roundup.psfhosted.org>


Change by Aivar Annamaa <aivar.annamaa at gmail.com>:


----------
nosy: +Aivar.Annamaa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35101>
_______________________________________

From report at bugs.python.org  Sat Jan 26 03:02:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Jan 2019 08:02:05 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548489725.16.0.57642660699.issue35780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset d8080c01195cc9a19af752bfa04d98824dd9fb15 by Raymond Hettinger in branch 'master':
bpo-35780: Fix errors in lru_cache() C code (GH-11623)
https://github.com/python/cpython/commit/d8080c01195cc9a19af752bfa04d98824dd9fb15


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 26 03:02:13 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 26 Jan 2019 08:02:13 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548489733.27.0.908345280887.issue35780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 26 03:02:18 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 26 Jan 2019 08:02:18 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548489738.11.0.607397913238.issue35780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11515, 11516

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 26 03:23:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Jan 2019 08:23:44 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548491024.13.0.569010660498.issue35780@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset b2b023c657ba8c3f4a24d0c847d10fe8e2a73d44 by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-35780: Fix errors in lru_cache() C code (GH-11623) (GH-11682)
https://github.com/python/cpython/commit/b2b023c657ba8c3f4a24d0c847d10fe8e2a73d44


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 26 03:25:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Jan 2019 08:25:21 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548491121.4.0.843767488466.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Sat Jan 26 07:15:10 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Jan 2019 12:15:10 +0000
Subject: [issue23930] http.cookies.SimpleCookie doesn't parse comma-only
 separated cookies correctly
In-Reply-To: <1428931053.68.0.491418357539.issue23930@psf.upfronthosting.co.za>
Message-ID: <1548504910.63.0.772572825822.issue23930@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I think making a comma start a new cookie is dangerous, and perhaps this proposal should be rejected.

I?m not an expert on web programming, but this reminds me of some security problems that already affected Python: <https://translate.google.com/translate?u=https://habr.com/en/post/272187/>. In a web page, Java Script could set a cookie with a single name and a comma in the value.

document.cookie = 'a=b,csrftoken=INJECTED'

Currently, Python in the server would parse that the way the script intended:

>>> C = BaseCookie('a=b,csrftoken=INJECTED')
>>> C['a'].value
'b,csrftoken=INJECTED'
>>> C['csrftoken'].value
KeyError: 'csrftoken'

But with the proposed change, Python would be tricked into parsing it as two separate ?morsels?:

>>> C['csrftoken'].value
'INJECTED'

----------
nosy: +martin.panter
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23930>
_______________________________________

From report at bugs.python.org  Sat Jan 26 07:20:47 2019
From: report at bugs.python.org (Michael Felt)
Date: Sat, 26 Jan 2019 12:20:47 +0000
Subject: [issue35828] test_multiprocessing_* - crash in PyDict_GetItem -
 segmentation error
In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>
Message-ID: <1548505247.02.0.760081040387.issue35828@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
title: test_multiprocessing_* tests - success versus fail varies over time -> test_multiprocessing_* - crash in PyDict_GetItem - segmentation error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35828>
_______________________________________

From report at bugs.python.org  Sat Jan 26 07:21:38 2019
From: report at bugs.python.org (Stefano Bonalumi)
Date: Sat, 26 Jan 2019 12:21:38 +0000
Subject: [issue35832] Installation error
Message-ID: <1548505296.29.0.442399484637.issue35832@roundup.psfhosted.org>


New submission from Stefano Bonalumi <stefano.bonalumi at gmail.com>:

Hi
i get the following installation error code when i try to install python 3.7.2 version on Windows 10
See the attached files

----------
components: Installation
files: Annotazione 2019-01-26 132044.jpg
messages: 334390
nosy: Stefano Bonalumi
priority: normal
severity: normal
status: open
title: Installation error
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48078/Annotazione 2019-01-26 132044.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35832>
_______________________________________

From report at bugs.python.org  Sat Jan 26 07:57:58 2019
From: report at bugs.python.org (Michael Felt)
Date: Sat, 26 Jan 2019 12:57:58 +0000
Subject: [issue35828] test_multiprocessing_* - crash in PyDict_GetItem -
 segmentation error
In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>
Message-ID: <1548507478.7.0.863105799643.issue35828@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

OK, I have gone as far back as "where" in dbx can bring me.

Could this, somehow, be related with changes made in issue-33015 ?

In any case, does it seem correct that "pthread_wrapper(void *arg) can be correct if arg is nil?

  +155  /* bpo-33015: pythread_callback struct and pythread_wrapper() cast
  +156     "void func(void *)" to "void* func(void *)": always return NULL.
  +157
  +158     PyThread_start_new_thread() uses "void func(void *)" type, whereas
  +159     pthread_create() requires a void* return value. */
  +160  typedef struct {
  +161      void (*func) (void *);
  +162      void *arg;
  +163  } pythread_callback;
  +164
  +165  static void *
  +166  pythread_wrapper(void *arg)
  +167  {
  +168      /* copy func and func_arg and free the temporary structure */
  +169      pythread_callback *callback = arg;
  +170      void (*func)(void *) = callback->func;
  +171      void *func_arg = callback->arg;
  +172      PyMem_RawFree(arg);
  +173
  +174      func(func_arg);
  +175      return NULL;
  +176  }

(dbx) print boot
0x2030cab0
(dbx) which boot
_threadmodule.t_bootstrap.boot
(dbx) print boot
0x2030cab0
(dbx) print *boot
(interp = 0x2030cb00, func = 0xcbcbcbcb, args = 0x1018c460, keyw = 0xcbcbcbcb, tstate = 0xcbcbcbcb)
(dbx) which arg
thread.pythread_wrapper.arg
(dbx) print arg
(nil)
(dbx) print *arg
reference through nil pointer
(dbx) which callback
thread.pythread_wrapper.callback
(dbx) print callback
0x2030cb00
(dbx) print *callback
(func = 0x2030cb50, arg = 0x35000000)

I am "nervous" when it comes to accepting a value such as 0xcbcbcbcb or 0xdbdbdbdb as values for pointers to objects - or even "int" or unsigned values - look so "specific pattern" like.

Suggestions on how to look at this "better" would be appreciated.

Michael

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35828>
_______________________________________

From report at bugs.python.org  Sat Jan 26 08:03:14 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Jan 2019 13:03:14 +0000
Subject: [issue35824] http.cookies._CookiePattern modifying regular expressions
In-Reply-To: <1548385865.75.0.22198302427.issue35824@roundup.psfhosted.org>
Message-ID: <1548507794.8.0.248964888356.issue35824@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I presume MeiK wants to use BaseCookie to parse the Set-Cookie header field, as in

>>> BaseCookie('Hello=World; Expires=Thu, 31 Jan 2019 05:56:00 GMT;')
<BaseCookie: Hello='World'>
>>> BaseCookie('Hello=World; Expires=Thu,31 Jan 2019 05:56:00 GMT;')
<BaseCookie: >

Karthikeyan, if you meant the ?sane-cookie-date? format (https://tools.ietf.org/html/rfc6265#page-9), that is just the IETF?s recommended date format. I suspect MeiK is trying to _parse_ the date rather than generate it, in which case the procedure in <https://tools.ietf.org/html/rfc6265#section-5.1.1> may be more relevant. Spaces and commas are both treated as delimiters, so the problematic Expires attribute should parse fine.

BTW, this special handling of Set-Cookie attributes like Expires is not documented, though it does seem intentional. According to the documentation they should be treated as new Morsels.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35824>
_______________________________________

From report at bugs.python.org  Sat Jan 26 08:43:36 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 26 Jan 2019 13:43:36 +0000
Subject: [issue35824] http.cookies._CookiePattern modifying regular expressions
In-Reply-To: <1548385865.75.0.22198302427.issue35824@roundup.psfhosted.org>
Message-ID: <1548510216.97.0.545726982298.issue35824@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Yes, sorry I thought it was the format used for parsing too. Thanks for the example Martin. I am linking @MeiK PR to the issue where I asked them to open an issue for this.

----------
keywords: +patch
pull_requests: +11517
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35824>
_______________________________________

From report at bugs.python.org  Sat Jan 26 08:48:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 26 Jan 2019 13:48:41 +0000
Subject: [issue35832] Installation error
In-Reply-To: <1548505296.29.0.442399484637.issue35832@roundup.psfhosted.org>
Message-ID: <1548510521.47.0.696781038519.issue35832@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35832>
_______________________________________

From report at bugs.python.org  Sat Jan 26 09:52:51 2019
From: report at bugs.python.org (Dude Roast)
Date: Sat, 26 Jan 2019 14:52:51 +0000
Subject: [issue35833] Backspace not working
Message-ID: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org>


New submission from Dude Roast <akshayd917 at gmail.com>:

Whenever I try to use Backspace(\b) it always prints square boxes instead of deleting previous string.

Code Down:- 

import pyautogui
print("Press Ctrl+c to quit")

try:
    while True:
        x,y = pyautogui.position();
        positionStr = "X: " + str(x).rjust(4) + " Y: " + str(y).rjust(4)
        print(positionStr,end ='')
        print('\b'*len(positionStr),end='',flush=True)
        
except KeyboardInterrupt:
    print("\nDone")


O/P:- 

Press Ctrl+c to quit
X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261X:  317 Y:  261
Done

----------
assignee: terry.reedy
components: IDLE
files: mousenow.py
messages: 334394
nosy: Dude Roast, terry.reedy
priority: normal
severity: normal
status: open
title: Backspace not working
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48079/mousenow.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35833>
_______________________________________

From report at bugs.python.org  Sat Jan 26 10:21:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 26 Jan 2019 15:21:42 +0000
Subject: [issue35832] Installation error
In-Reply-To: <1548505296.29.0.442399484637.issue35832@roundup.psfhosted.org>
Message-ID: <1548516102.75.0.92824244554.issue35832@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You should have a set of log files in your %TEMP% directory. Their names will start with Python and end in .log. If you could collect these into a zip file and post them here, that would be very helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35832>
_______________________________________

From report at bugs.python.org  Sat Jan 26 12:00:20 2019
From: report at bugs.python.org (Lincoln Quirk)
Date: Sat, 26 Jan 2019 17:00:20 +0000
Subject: [issue35834] get_type_hints exposes an instance of ForwardRef
 (internal class) in its result,
 with `from __future__ import annotations` enabled
Message-ID: <1548522018.14.0.654103456004.issue35834@roundup.psfhosted.org>


New submission from Lincoln Quirk <lincoln at wave.com>:

Consider this code:

```
from __future__ import annotations

import typing

class A:
    f: 'Undef'

hints = typing.get_type_hints(A)
```

Since Undef is not defined, I should get an exception when calling get_type_hints, something like "NameError: name 'Undef' is not defined". But instead, get_type_hints returns {'f': ForwardRef('Undef')}.

If I remove the `from __future__ import annotations` line, get_type_hints correctly raises this exception.

I think the behavior should be to raise an exception in both cases.

----------
messages: 334396
nosy: Lincoln Quirk
priority: normal
severity: normal
status: open
title: get_type_hints exposes an instance of ForwardRef (internal class) in its result, with `from __future__ import annotations` enabled
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35834>
_______________________________________

From report at bugs.python.org  Sat Jan 26 12:32:24 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Jan 2019 17:32:24 +0000
Subject: [issue35834] get_type_hints exposes an instance of ForwardRef
 (internal class) in its result,
 with `from __future__ import annotations` enabled
In-Reply-To: <1548522018.14.0.654103456004.issue35834@roundup.psfhosted.org>
Message-ID: <1548523944.1.0.753132959816.issue35834@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Since Undef is not defined, I should get an exception when calling get_type_hints


One of the motives of PEP-563 is to make it easier to use forward references. I'm not sure, but it seems to me that given that, we should not get an exception. So I think the only issue here is that the ForwardReference class is not documented, and should be.

But I admit I'm not confident about my understanding of PEP-563 so I could be wrong.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35834>
_______________________________________

From report at bugs.python.org  Sat Jan 26 12:44:17 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Jan 2019 17:44:17 +0000
Subject: [issue35834] get_type_hints exposes an instance of ForwardRef
 (internal class) in its result,
 with `from __future__ import annotations` enabled
In-Reply-To: <1548522018.14.0.654103456004.issue35834@roundup.psfhosted.org>
Message-ID: <1548524657.97.0.526286858639.issue35834@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Wait, I just noticed that PEP563 says:

"Note: if an annotation was a string literal already, it will still be wrapped in a string."

https://www.python.org/dev/peps/pep-0563/#id5

In 3.8.0a I get this:

py> from __future__ import annotations
py>
py> class A:
...     f: 'Undef'
...
py> A.__annotations__
{'f': "'Undef'"}

which matches what the PEP says. So I expect that when calling get_type_hints it should return the unquoted string, rather than a ForwardReference.

get_type_hints(A)

expected {'f': 'Undef'}
actually got {'f': ForwardRef('Undef')}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35834>
_______________________________________

From report at bugs.python.org  Sat Jan 26 12:52:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 26 Jan 2019 17:52:11 +0000
Subject: [issue35834] get_type_hints exposes an instance of ForwardRef
 (internal class) in its result,
 with `from __future__ import annotations` enabled
In-Reply-To: <1548522018.14.0.654103456004.issue35834@roundup.psfhosted.org>
Message-ID: <1548525131.96.0.292866519185.issue35834@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35834>
_______________________________________

From report at bugs.python.org  Sat Jan 26 13:12:47 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Jan 2019 18:12:47 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
 line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1548526367.66.0.664415139752.issue5028@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11518
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Sat Jan 26 13:12:57 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Jan 2019 18:12:57 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
 line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1548526377.37.0.118125068805.issue5028@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11518, 11519
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Sat Jan 26 13:13:07 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Jan 2019 18:13:07 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
 line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1548526387.04.0.733813779647.issue5028@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11518, 11519, 11520
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Sat Jan 26 13:13:16 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Jan 2019 18:13:16 +0000
Subject: [issue5028] tokenize.generate_tokens doesn't always return logical
 line
In-Reply-To: <1232588343.15.0.723713394492.issue5028@psf.upfronthosting.co.za>
Message-ID: <1548526396.95.0.857224849313.issue5028@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11518, 11519, 11520, 11521
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5028>
_______________________________________

From report at bugs.python.org  Sat Jan 26 13:13:30 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 26 Jan 2019 18:13:30 +0000
Subject: [issue35834] get_type_hints exposes an instance of ForwardRef
 (internal class) in its result,
 with `from __future__ import annotations` enabled
In-Reply-To: <1548522018.14.0.654103456004.issue35834@roundup.psfhosted.org>
Message-ID: <1548526410.1.0.691367950385.issue35834@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35834>
_______________________________________

From report at bugs.python.org  Sat Jan 26 15:58:17 2019
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 26 Jan 2019 20:58:17 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1548536297.09.0.828111861926.issue31299@roundup.psfhosted.org>


Dmitry Kazakov <waultah+py at gmail.com> added the comment:

It would seem no one is actually interested in this proposed enhancement. I'm closing my PR, since I'm not interested in resolving the file conflict. I'll probably submit a traceback-mutating patch to the issue 16217. This issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Sat Jan 26 15:58:53 2019
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 26 Jan 2019 20:58:53 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1548536333.3.0.668405083538.issue31299@roundup.psfhosted.org>


Change by Dmitry Kazakov <waultah+py at gmail.com>:


----------
pull_requests:  -5065

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Sat Jan 26 15:59:04 2019
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 26 Jan 2019 20:59:04 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1548536344.5.0.120210150286.issue31299@roundup.psfhosted.org>


Change by Dmitry Kazakov <waultah+py at gmail.com>:


----------
pull_requests: +11522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Sat Jan 26 15:59:35 2019
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 26 Jan 2019 20:59:35 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1548536375.56.0.52148887972.issue31299@roundup.psfhosted.org>


Change by Dmitry Kazakov <waultah+py at gmail.com>:


----------
pull_requests:  -11522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Sat Jan 26 16:00:08 2019
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 26 Jan 2019 21:00:08 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1548536408.34.0.0335911160356.issue31299@roundup.psfhosted.org>


Change by Dmitry Kazakov <waultah+py at gmail.com>:


----------
nosy:  -vaultah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Sat Jan 26 16:12:37 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Jan 2019 21:12:37 +0000
Subject: [issue35833] Backspace not working
In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org>
Message-ID: <1548537157.35.0.945285808209.issue35833@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I suspect Idle just passes control characters directly to an underlying Text or similar TK widget. As far as I know, TK only documents behaviour for tabs and newlines, not other control characters.

Last time this was brought up, Terry added a sentence under <https://docs.python.org/3.7/library/idle.html#user-output-in-shell>, third paragraph, about this:

?Newline characters cause following text to appear on a new line, but other control characters are either replaced with a box or deleted.?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35833>
_______________________________________

From report at bugs.python.org  Sat Jan 26 16:15:37 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Jan 2019 21:15:37 +0000
Subject: [issue35833] Backspace not working
In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org>
Message-ID: <1548537337.36.0.933919543414.issue35833@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Ment to point to previous bug report: Issue 23220

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35833>
_______________________________________

From report at bugs.python.org  Sat Jan 26 16:51:18 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 26 Jan 2019 21:51:18 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548539478.29.0.204558480235.issue35823@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I've checked subprocess.Popen() error reporting in QEMU user-mode and WSL and confirm that it works both with my patch (vfork/exec) and the traditional fork/exec, but doesn't work with glibc's posix_spawn.

The first command below uses posix_spawn() internally because close_fds=False. Under QEMU posix_spawn() from glibc doesn't report errors because it relies on address-space sharing of clone(CLONE_VM|CLONE_VFORK), which is not emulated by QEMU. The second command uses vfork()/exec() in _posixsubprocess, but lack of address-space sharing doesn't matter because the error data is transferred via a pipe.

$ qemu-x86_64 --version
qemu-x86_64 version 2.11.1
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
$ ldd --version
ldd (GNU libc) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
$ qemu-x86_64 ./python3 -c 'import subprocess; subprocess.call("/xxx", close_fds=False)'
$ qemu-x86_64 ./python3 -c 'import subprocess; subprocess.call("/xxx")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/izbyshev/install/python-3.8a/lib/python3.8/subprocess.py", line 324, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/home/izbyshev/install/python-3.8a/lib/python3.8/subprocess.py", line 830, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/home/izbyshev/install/python-3.8a/lib/python3.8/subprocess.py", line 1648, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'xxx'

For WSL, I've tested Ubuntu 18.04 (glibc 2.27) on Windows 10 1709 (Fall Creators Update) and 1803.

In 1709, the result is the same as for QEMU (i.e. the first command silently succeeds). In 1803, both commands raise the exception because address-space sharing was fixed for clone(CLONE_VM|CLONE_VFORK) and vfork() in WSL: https://github.com/Microsoft/WSL/issues/1878

I've also run all subprocess tests under QEMU user-mode (by making sys.executable to point to a wrapper that runs python under QEMU) for the following code bases:
* current master (fork/exec or posix_spawn can be used)
* classic (fork/exec always)
* my patch + master (vfork/exec or posix_spawn)
* vfork/exec always
 All tests pass in all four flavors, which indicates that we don't have a test for error reporting with close_fds=False :)

Out of curiosity I also did the same on WSL in 1803. Only 3 groups of tests fail, all because of WSL bugs:

* It's not possible to send signals to zombies, e.g.:
======================================================================
ERROR: test_terminate_dead (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/test/cpython/Lib/test/test_subprocess.py", line 1972, in test_terminate_dead
    self._kill_dead_process('terminate')
  File "/home/test/cpython/Lib/test/test_subprocess.py", line 1941, in _kill_dead_process
    getattr(p, method)(*args)
  File "/home/test/cpython/Lib/subprocess.py", line 1877, in terminate
    self.send_signal(signal.SIGTERM)
  File "/home/test/cpython/Lib/subprocess.py", line 1872, in send_signal
    os.kill(self.pid, sig)
ProcessLookupError: [Errno 3] No such process
----------------------------------------------------------------------

* getdents64 syscall doesn't work properly (doesn't return the rest of entries on the second call, so close_fds=True doesn't fully work with large number of open descriptors).

======================================================================
FAIL: test_close_fds_when_max_fd_is_lowered (test.test_subprocess.POSIXProcessTestCase)
Confirm that issue21618 is fixed (may fail under valgrind).
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/test/cpython/Lib/test/test_subprocess.py", line 2467, in test_close_fds_when_max_fd_is_lowered
    self.assertFalse(remaining_fds & opened_fds,
AssertionError: {34, 35, 36, 37, 38, 39, 40, 41, 42} is not false : Some fds were left open.
----------------------------------------------------------------------

* Signal masks in /proc/self/status are not correct (always zero)

======================================================================
FAIL: test_restore_signals (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/test/cpython/Lib/test/test_subprocess.py", line 1643, in test_restore_signals
    self.assertNotEqual(default_sig_ign_mask, restored_sig_ign_mask,
AssertionError: b'SigIgn:\t0000000000000000' == b'SigIgn:\t0000000000000000' : restore_signals=True should've unblocked SIGPIPE and friends.

----------------------------------------------------------------------

None of the above is related to fork/vfork/posix_spawn -- the set of failing tests is the same in all four flavors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Sat Jan 26 17:14:56 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jan 2019 22:14:56 +0000
Subject: [issue35833] IDLE: revise doc for control chars sent to Shell
In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org>
Message-ID: <1548540896.13.0.0143928262673.issue35833@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Example code for the tracker should not use 3rd-party modules unless essential.  It should be reduced to the minimum testcase needed to show the behavior.  In this case, "print('a\b')", resulting, on Windows 10, in "a", is enough. (On macOS Mohave, the result is just 'a'.) These results are not a bug. The IDLE chapter of the doc, viewable with Help => IDLE Doc, has a section 'User output in Shell', added for 3.6.8 and 3.7.2, that explains.  The full relevant text with the key line Martin posted is

"When a program outputs text, the result is determined by the corresponding output device.  When IDLE executes user code, sys.stdout and sys.stderr are connected to the display area of IDLE?s Shell.  Some of its features are inherited from the underlying Tk Text widget.  Others are programmed additions.  Where it matters, Shell is designed for development rather than production runs. 
...
Text widgets display a subset of Unicode, the Basic Multilingual Plane (BMP). Which characters get a proper glyph instead of a replacement box depends on the operating system and installed fonts.  Newline characters cause following text to appear on a new line, but other control characters are either replaced with a box or deleted.  However, repr(), which is used for interactive echo of expression values, replaces control characters, some BMP codepoints, and all non-BMP characters with escape codes before they are output."

In reviewing this and doing more experiments, I realized that this needs revision. A. tabs jump to the next 8-char tabstop.  B. Display replacements for control chars can include spaces and other things.  C. Display replacements depend on the operating system (as noted above) and possibly the font. D. Display replacements only occur when the string is displayed, not when stored in the text widget.  Selecting and copying a string on the screen copies what is stored in the widget, not what is displayed on the screen.  E. Trying to insert non-BMP characters ('\U000nnnnn') in a text widget is an error.  (Preventing this even when a user implicitly requests is a separate issue.)  F. Printing null and return characters may cause problems.  Null (\0, \x00) hands IDLE on Mac.  Return (\r, \x0D) is ignored by tk but interpreted and converted to \n when pasted into code.

I want to add a code block example that illustrate some of these points.

>>> s = 'abc\t\a<\x02><\r>\b'
>>> len(s)
12
>>> s
'abc\t\x07<\x02><\r>\x08'  # This is repr(s).
>>> print(s)  # In IDLE, inserts s into text widget.
# Visible result varies; try it.

PS: On hard-copy terminals, where control characters originated, \b only means 'Move the print position back a character.'  On 'soft-copy' terminals and consoles, it may or may not also mean 'erase the previous character'.

----------
nosy:  -martin.panter
stage:  -> needs patch
title: Backspace not working -> IDLE: revise doc for control chars sent to Shell
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35833>
_______________________________________

From report at bugs.python.org  Sat Jan 26 17:45:04 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Jan 2019 22:45:04 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548542704.37.0.702132684995.issue35823@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for your _extremely detailed_ analysii of the (often sad) state of posix_spawn() on platforms in the world today.

My first reaction to this was "but then we'll be owning our own custom posix_spawn-like implementation as if we'll do better at it than every individual libc variant."

After reading this through and looking at your PR... I now consider that a good thing. =)  We clearly can do better.  vfork() is pretty simple and allows us to keep our semantics; providing benefits to existing users at no cost.

The plethora of libc bugs surrounding posix_spawn() seem likely to persist within various environments in the world for years to come.  No sense in us waiting for that to settle.

As for your PR... a configure check for vfork, a news entry, and whatever other documentation updates seem appropriate.

With this in place we may want to make the _use_posix_spawn() logic in subprocess.py stricter?  That could be its own followup PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Sat Jan 26 17:49:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jan 2019 22:49:44 +0000
Subject: [issue35833] IDLE: revise doc for control chars sent to Shell
In-Reply-To: <1548514370.87.0.460753518023.issue35833@roundup.psfhosted.org>
Message-ID: <1548542984.13.0.201195039952.issue35833@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin, your suspicion is correct, as verified by selecting and copying the string and pasting into code between quotes.  I strongly suspect that tk just sends the string as is to the OS graphics system insert text function, that the latter decides what to display.  I ran
  for i in range(1,33): print(f'<{chr(i)}>')
on Windows console, Windows IDLE, and Mac IDLE (omitting '1' crashes on Mac) and there are multiple inconsistencies.  I believe tcl/tk only documents \t and \n because those are the only two control chars whose behavior is consistent across graphics systems.  Thanks for digging up the previous issue.  I would close as a duplicate if I did not see a need for doc revision.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35833>
_______________________________________

From report at bugs.python.org  Sat Jan 26 17:52:45 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Jan 2019 22:52:45 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548543165.46.0.90624064044.issue35537@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +11523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Sat Jan 26 17:53:01 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Jan 2019 22:53:01 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548543181.05.0.21477665015.issue35537@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +11523, 11524

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Sat Jan 26 17:53:16 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Jan 2019 22:53:16 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548543196.79.0.446551392889.issue35537@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +11523, 11524, 11525

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Sat Jan 26 18:09:10 2019
From: report at bugs.python.org (jcrmatos)
Date: Sat, 26 Jan 2019 23:09:10 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
Message-ID: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>


New submission from jcrmatos <jcrmatos at gmail.com>:

In the Pdb documentation, found at
https://docs.python.org/3.7/library/pdb.html?highlight=pdb#module-pdb
there is no mention of breakpoint().

In my opinion, this text

import pdb; pdb.set_trace()

should be replaced with

import pdb; pdb.set_trace()
New in version 3.7: breakpoint() replaces the previous line.

Thanks,

JM

----------
messages: 334406
nosy: jcrmatos
priority: normal
severity: normal
status: open
title: There is no mention of breakpoint() in the pdb documentation
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sat Jan 26 18:18:52 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 26 Jan 2019 23:18:52 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548544732.82.0.378349963545.issue35823@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

> * Decide whether "setxid problem"[5] is important enough to worry about.
> [5] https://ewontfix.com/7

This is a scary issue.  But I think a reasonable approach could be to never use vfork when running as whatever we choose to define a "privileged user" to be.

getuid() or geteuid() return 0?  don't use vfork.

the concept of "privileged user" can obviously mean a lot more than that and likely goes beyond what we should attempt to ascertain ourselves.

How about also providing a disable-only global setting so that someone writing code they consider to have elevated privileges can prevent its use entirely.  subprocess.disable_use_of_vfork() and subprocess.is_vfork_enabled() calls perhaps (just setting/reading a static int vfork_disallowed = 0 flag within _posixsubprocess.c).

If we did that, on systems where posix_spawn() _might_ be implemented using vfork() we'd want to avoid using it based on is_vfork_enabled().

True setuid vs vfork attack security would suggest code needs to opt-in to vfork() or posix_spawn() rather than opt-out.  Which would destroy the benefit for most users (who won't bother) for the sake of an issue that just is not what most code ever does (setuid/setgid/etc. calls are very uncommon for most software).

I think documenting "HEY, if you are running as with elevated privileges, here's a reason why you might want to disable vfork, and how to do it." should be enough.  Hopefully not famous last words.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Sat Jan 26 18:54:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Jan 2019 23:54:55 +0000
Subject: [issue32129] Icon on macOS
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1548546895.87.0.282586140986.issue32129@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A Branch Seidenman posted 'Retina Icons' on idle-dev.  He posted a screenshot similar to Kevin's.  He says Apple recommends having all these sizes:
1024px ? 1024px
512px ? 512px
256px ? 256px
128px ? 128px
64px ? 64px
32px ? 32px
16px ? 16px

Creating new icons larger that 48px is beyond me.  Besides which, I believe these are copies of files elsewhere in the repository.  (The icons directory should have a README explaining the files and their origin.  How many of these sizes would actually be useful?  Would larger icons be useful on hi-rex Linux (or even Windows) systems?

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32129>
_______________________________________

From report at bugs.python.org  Sat Jan 26 19:48:36 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Jan 2019 00:48:36 +0000
Subject: [issue19670] SimpleCookie Generates Non-RFC6265-Compliant Cookies
In-Reply-To: <1384979004.61.0.0353093814459.issue19670@psf.upfronthosting.co.za>
Message-ID: <1548550116.99.0.0523359139814.issue19670@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I think the solution here is to document what ?SimpleCookie.value_encode? really does: RFC 2109 quoted-string escaping. If you want to a generate RFC-6265-compliant Set-Cookie string, do not include non-compliant characters in the cookie value, and consider using BaseCookie rather than SimpleCookie, especially if your ?morsel? values are enclosed in double quotes.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19670>
_______________________________________

From report at bugs.python.org  Sat Jan 26 21:00:35 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Jan 2019 02:00:35 +0000
Subject: [issue11315] unicode support in Cookie module
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1548554435.57.0.131596624782.issue11315@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Sorry, but changing to bytes after ten years of using str in this module in Python 3 is not going to happen. Let?s just document the state of Python 2 (see ?ric: https://bugs.python.org/issue11315#msg129448).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ezio.melotti, martin.panter, vstinner
title: Fix type regression in http.cookies.load (want bytes, not str) -> unicode support in Cookie module
versions: +Python 2.7 -Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Sat Jan 26 21:03:56 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Jan 2019 02:03:56 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1548554636.49.0.18895415725.issue2212@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Same as Issue 11315, where ?ric suggested documenting the behaviour.

----------
nosy: +martin.panter
resolution:  -> duplicate
superseder:  -> unicode support in Cookie module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Sat Jan 26 21:04:48 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Jan 2019 02:04:48 +0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1548554688.44.0.780017737224.issue2212@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Sat Jan 26 21:48:28 2019
From: report at bugs.python.org (Kevin Walzer)
Date: Sun, 27 Jan 2019 02:48:28 +0000
Subject: [issue32129] Icon on macOS
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1548557308.08.0.437463862587.issue32129@roundup.psfhosted.org>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Making the icon 512x512 pixels will make it look correct on Retina displays on the Mac.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32129>
_______________________________________

From report at bugs.python.org  Sat Jan 26 22:53:16 2019
From: report at bugs.python.org (Windson Yang)
Date: Sun, 27 Jan 2019 03:53:16 +0000
Subject: [issue34628] urllib.request.urlopen fails when userinfo is present in
 URL
In-Reply-To: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>
Message-ID: <1548561196.88.0.407143801542.issue34628@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Why requests library didn't raise an error because urllib3 (the library requests using) ignore the auth part right now

> Currently we expect our users to handle authentication headers themselves. It's unfortunate that we silently strip this information though...

The discuss also in https://github.com/urllib3/urllib3/issues/1530

Should we ignore the userinfo part of raising an error here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34628>
_______________________________________

From report at bugs.python.org  Sat Jan 26 22:56:33 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Jan 2019 03:56:33 +0000
Subject: [issue31456] SimpleCookie fails to parse any cookie if an entry has
 whitespace in the name
In-Reply-To: <1505328383.45.0.696771060303.issue31456@psf.upfronthosting.co.za>
Message-ID: <1548561393.01.0.662471894413.issue31456@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

The main cause of this behaviour is that whitespace (matching the ASCII RE ?\s?) is treated as separation between cookie ?morsels?. It looks like this has always been the behaviour, but I?m not sure it was intended.

>>> print(BaseCookie('first=morsel second=morsel'))
Set-Cookie: first=morsel
Set-Cookie: second=morsel

This could be a security problem, if an attacker managed to inject a CSRF token as the second ?morsel?. This was mentioned in <https://translate.google.com/translate?u=https://habr.com/en/post/272187/>.

IMO it would be better to not split off a second morsel. Either keep it as one long morsel value with spaces in, or skip over it to the next semicolon (;).

The reason why the whole cookie string is lost is due to the behaviour of cookie morsels without equals signs:

>>> BaseCookie('cookie=lost; ignore').items()
dict_items([])

IMO it would be better to skip over these to the next semicolon as well. It looks like this is a regression in Python 3.5+ caused by Issue 22796.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31456>
_______________________________________

From report at bugs.python.org  Sun Jan 27 05:24:58 2019
From: report at bugs.python.org (jcrmatos)
Date: Sun, 27 Jan 2019 10:24:58 +0000
Subject: [issue35836] ZeroDivisionError class should have a __name__ attr
Message-ID: <1548584697.69.0.29003071368.issue35836@roundup.psfhosted.org>


New submission from jcrmatos <jcrmatos at gmail.com>:

Hello,

When trying this
try:
    1/0
except Exception as exc:
    print(type(exc))  # returns <class 'ZeroDivisionError'>
    print(exc.__name__)  # returns AttributeError: 'ZeroDivisionError' object has no attribute '__name__'

I believe all classes should have a __name__ attr, correct?

It would be nice to check all the other exceptions to see if any other is also missing the __name__ attr.

Thanks,

JM

----------
messages: 334416
nosy: jcrmatos
priority: normal
severity: normal
status: open
title: ZeroDivisionError class should have a __name__ attr
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35836>
_______________________________________

From report at bugs.python.org  Sun Jan 27 05:31:35 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 27 Jan 2019 10:31:35 +0000
Subject: [issue35834] get_type_hints exposes an instance of ForwardRef
 (internal class) in its result,
 with `from __future__ import annotations` enabled
In-Reply-To: <1548522018.14.0.654103456004.issue35834@roundup.psfhosted.org>
Message-ID: <1548585095.7.0.353453574644.issue35834@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

It looks like an opposite side of https://github.com/python/typing/issues/508 (I wanted to work on it, but never had time to, sorry).

This question appeared couple times before, and I think there are pros and cons for both returning a ForwardRef() and for raising a NameError. So as I proposed in the issue above, there should be a flag to `get_type_hints()` that controls what to do (the name of the flag, and the default are of course debatable).

Of course, we should try to make `get_type_hints()` behave as much similar as possible with and without PEP 563, regardless. But my point is that currently we have this "in-between" behavior, and it is harder to maintain this "in-between" behavior against PEP 563, than two clearly defined extremes.

> So I expect that when calling get_type_hints it should return the unquoted string, rather than a ForwardReference.

I think the values in the returned dictionary should always be types, either fully evaluated, or ForwardRefs (expecting two options is easier than expecting three).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35834>
_______________________________________

From report at bugs.python.org  Sun Jan 27 06:20:00 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 27 Jan 2019 11:20:00 +0000
Subject: [issue35836] ZeroDivisionError class should have a __name__ attr
In-Reply-To: <1548584697.69.0.29003071368.issue35836@roundup.psfhosted.org>
Message-ID: <1548588000.04.0.196718695134.issue35836@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You are not looking at the class, you are looking at an instance:

py> exc = ZeroDivisionError('divide by zero')
py> type(exc).__name__
'ZeroDivisionError'
py> exc.__name__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ZeroDivisionError' object has no attribute '__name__'

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35836>
_______________________________________

From report at bugs.python.org  Sun Jan 27 06:23:59 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 27 Jan 2019 11:23:59 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548588239.54.0.869014850902.issue35835@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 06:32:51 2019
From: report at bugs.python.org (jcrmatos)
Date: Sun, 27 Jan 2019 11:32:51 +0000
Subject: [issue35836] ZeroDivisionError class should have a __name__ attr
In-Reply-To: <1548584697.69.0.29003071368.issue35836@roundup.psfhosted.org>
Message-ID: <1548588771.64.0.536860048542.issue35836@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

You are correct. My bad.

Thanks,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35836>
_______________________________________

From report at bugs.python.org  Sun Jan 27 07:02:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 12:02:14 +0000
Subject: [issue32834] test_gdb fails with Posix locale in 3.7
In-Reply-To: <1518464593.71.0.467229070634.issue32834@psf.upfronthosting.co.za>
Message-ID: <1548590534.39.0.189005908906.issue32834@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Possibly fixed with issue34537 ?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32834>
_______________________________________

From report at bugs.python.org  Sun Jan 27 07:13:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 12:13:47 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548591227.99.0.750411969903.issue35835@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> New in version 3.7: breakpoint() replaces the previous line.

replaces sounds little more like removed or deprecated to me. How about the below under pdb.set_trace() doc and example using it in the beginning?

New in version 3.7: breakpoint() is a convenience function that internally calls pdb.set_trace()

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 07:19:01 2019
From: report at bugs.python.org (jcrmatos)
Date: Sun, 27 Jan 2019 12:19:01 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548591541.89.0.328366873762.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

What about like this
import pdb; pdb.set_trace()
New in version 3.7: breakpoint() is preferable to using the previous line.

Thanks,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 07:26:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 12:26:29 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548591989.61.0.713441565141.issue35835@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I didn't want the doc to sound like breakpoint() is encouraged since it's optional and a shortcut. Hence my personal preference to just add a note with link to breakpoint() that it does the same thing. I will wait for someone else to rephrase it better since I am not a native speaker myself.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 07:56:39 2019
From: report at bugs.python.org (Sjoerd)
Date: Sun, 27 Jan 2019 12:56:39 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
Message-ID: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>


New submission from Sjoerd <sjoerd-python at linuxonly.nl>:

According to https://python.readthedocs.io/en/stable/whatsnew/3.5.html:

The SMTPServer class now advertises the 8BITMIME extension (RFC 6152) if decode_data has been set True. If the client specifies BODY=8BITMIME on the MAIL command, it is passed to SMTPServer.process_message() via the mail_options keyword. (Contributed by Milan Oberkirch and R. David Murray in bpo-21795.)

This means that process_message gets a mail_options kwarg. However, the smtpd PureProxy and MailmanProxy don't take keyword arguments, which results in an exception.

One way to trigger this is to run a debug mailserver and send a mail to it:

$ python3 -m smtpd -n
error: uncaptured python exception, closing channel <__main__.SMTPChannel connected ('::1', 52007, 0, 0) at 0x10e7eddd8> (<class 'TypeError'>:process_message() got an unexpected keyword argument 'mail_options' [/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncore.py|read|83] [/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncore.py|handle_read_event|422] [/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asynchat.py|handle_read|171] [/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/smtpd.py|found_terminator|386])

----------
components: Library (Lib)
messages: 334424
nosy: Sjoerder, giampaolo.rodola, r.david.murray
priority: normal
severity: normal
status: open
title: smtpd PureProxy breaks on mail_options keyword argument
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 08:21:10 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 27 Jan 2019 13:21:10 +0000
Subject: [issue11315] unicode support in Cookie module
In-Reply-To: <1298606703.83.0.56959729812.issue11315@psf.upfronthosting.co.za>
Message-ID: <1548595270.0.0.668650326278.issue11315@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11315>
_______________________________________

From report at bugs.python.org  Sun Jan 27 08:23:37 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Jan 2019 13:23:37 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548595417.84.0.443922376748.issue35837@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11526
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 08:23:43 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Jan 2019 13:23:43 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548595423.1.0.9630282592.issue35837@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11526, 11527
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 08:51:25 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 27 Jan 2019 13:51:25 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548597085.24.0.0326589091436.issue35835@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I agree with Karthikeyan.  If it's added to the pdb doc page, I think the existing text should stay as it is, but a 'New in 3.7' added after it.

Something like:

The typical usage to break into the debugger from a running program is to insert

import pdb; pdb.set_trace()

at the location you want to break into the debugger. You can then step through the code following this statement, and continue running without the debugger using the continue command.

New in version 3.7: The built-in :func:`breakpoint()`, when called with defaults, can be used instead of ``import pdb; pdb.set_trace()``.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 08:58:02 2019
From: report at bugs.python.org (jcrmatos)
Date: Sun, 27 Jan 2019 13:58:02 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548597482.35.0.232398514917.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

In my first message I said exactly that (the replacement used the previous text, if you check it).

I'm ok with the wording from Cheryl. How about you Karthikeyan?

Thanks,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 09:32:48 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 14:32:48 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548599568.57.0.275837213565.issue35835@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am ok with Cheryl's idea too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 09:45:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 14:45:22 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548600322.93.0.309857688736.issue35837@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. smtpd is deprecated in favor of aiosmtpd. Some of the fixes were closed in the past as won't fix. Please see https://bugs.python.org/issue35788#msg334088 and the discussion for deprecation and removal.

----------
nosy: +barry, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 09:50:21 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Jan 2019 14:50:21 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548600621.45.0.645312277596.issue35806@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Closing this without any changes contradicts the answer we gave Ronald on #35791 that it's expected behaviour for importlib.find_spec() to throw an exception for already loaded modules without a __spec__ attribute.

So if this stays closed, then we should reopen #35791, and treat it as a feature request to either:

1. add a "ignore_module_cache" option to bypass sys.modules; or
2. revert to searching for the original spec in cases where the sys.modules entry has no __spec__ attribute (which has the virtue of just working for cases of the "replace yourself in sys.modules" idiom)

That said, the typing pseudo submodules *can* populate their __spec__ with useful information by copying most of their attributes from  `typing.__spec__`, but setting their __spec__.loader attribute to one that throws an ImportError with a message saying to import `typing` instead of attempting to reload the submodule directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Sun Jan 27 09:53:16 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 27 Jan 2019 14:53:16 +0000
Subject: [issue35537] use os.posix_spawn in subprocess
In-Reply-To: <1545238079.48.0.788709270274.issue35537@psf.upfronthosting.co.za>
Message-ID: <1548600796.42.0.749439310576.issue35537@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
pull_requests: +11528

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35537>
_______________________________________

From report at bugs.python.org  Sun Jan 27 11:07:48 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 27 Jan 2019 16:07:48 +0000
Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org>
Message-ID: <1548605268.87.0.653260384766.issue35829@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> It seems a little odd to need to pull in a third-party library for this; it seems far more tempting for me to just do "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my dates are produced by a JSON API.

Yes, this is also a viable solution. Generally speaking, third party libraries are less onerous these days than they have been in the past, and there are many things that are delegated to third party libraries because staying out of the standard library gives more flexibility in release cycles and the APIs don't need to be quite as stable.

> FWIW, I do think that fromisoformat() is the right function to provide RFC3339 support.  I don't think
> users would benefit from having to choose between several different functions that parse similar but
> subtly different date formats; this seems likely to cause confusion.

This is in fact one of the reasons to proceed with caution here, because ISO 8601, RFC 3339 and datetime.isoformat() are three slightly different and in some senses *incompatible* datetime serialization formats. If I had the choice, I would probably either not have named `isoformat` the way it is named, or I would have stuck to the standard, but what's done is done. As it is now, all the "fromX" alternate constructors are simply the inverse operation of the corresponding "X" method. If we make fromisoformat accept the RFC 3339 subset of ISO 8601, people will find it confusing that it doesn't support even some of the most common *other* ISO 8601 formats, considering it's called `fromisoformat` not `fromrfcformat`.

To give you an idea of why this sort of thing is a problem, it's that with each minor change, expanding the scope a little sounds reasonable, but along with that comes maintenance burdens. People start to rely on the specific behavior of the function, and eventually you get into a position where someone asks for a very reasonable expansion of the scope that is incompatible with the way people are already using the function. This leads you to either stop developing the function at some arbitrary point or to start tacking on a configuration API to resolve these incompatibilities.

If instead we design the function from the beginning with a very clear scope, we can also design the configuration API (and the default values) from the beginning as well. I definitely believe there is a place for a function that parses at least the timestamp portions of the ISO 8601 spec in CPython. I think I would prefer it to be a separate function from fromisoformat. I also think that it's worth letting it marinate in dateutil a bit, so that we can get a sense of what works and what doesn't work as a configuration API so that it's at least *easier* for people to select which of the subtly different datetime formats they're intending to parse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35829>
_______________________________________

From report at bugs.python.org  Sun Jan 27 11:53:47 2019
From: report at bugs.python.org (Sjoerd)
Date: Sun, 27 Jan 2019 16:53:47 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548608027.46.0.826517510979.issue35837@roundup.psfhosted.org>


Change by Sjoerd <sjoerd-python at linuxonly.nl>:


----------
nosy: +samuelcolvin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 11:54:58 2019
From: report at bugs.python.org (Samuel Colvin)
Date: Sun, 27 Jan 2019 16:54:58 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548608098.1.0.257771727719.issue35837@roundup.psfhosted.org>


Samuel Colvin <samcolvin at gmail.com> added the comment:

Hi, did you see https://bugs.python.org/issue35788#msg334155 later in the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 12:00:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 17:00:12 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548608412.08.0.0296725836688.issue35837@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, I overlooked that one. While searching for other smtpd issues many of them were closed as won't fix and hence my message. Thanks for the link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Sun Jan 27 12:22:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Jan 2019 17:22:30 +0000
Subject: [issue32834] test_gdb fails with Posix locale in 3.7
In-Reply-To: <1518464593.71.0.467229070634.issue32834@psf.upfronthosting.co.za>
Message-ID: <1548609750.4.0.646844545092.issue32834@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Possibly fixed with issue34537 ?

"LC_ALL=C ./python -We -m test -vuall -m test_strings test_gdb" still fails for me on Fedora 29.

======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 380, in test_strings
    check_repr('\u2620')
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 372, in check_repr
    self.assertGdbRepr(text)
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 302, in assertGdbRepr
    gdb_repr, gdb_output = self.get_gdb_repr('id(' + ascii(val) + ')')
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 269, in get_gdb_repr
    gdb_output = self.get_stack_trace(source, breakpoint=BREAKPOINT_FN,
  File "/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 249, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ["Python Exception <class 'UnicodeEncodeEr[231 chars]): "] != []

First list contains 2 additional elements.
First extra element 0:
"Python Exception <class 'UnicodeEncodeError'> 'ascii' codec can't encode character '\\u2620' in position 1: ordinal not in range(128): "

+ []
- ["Python Exception <class 'UnicodeEncodeError'> 'ascii' codec can't encode "
-  "character '\\u2620' in position 1: ordinal not in range(128): ",
-  "Python Exception <class 'UnicodeEncodeError'> 'ascii' codec can't encode "
-  "character '\\u2620' in position 1: ordinal not in range(128): "]


Note: "LC_ALL=C ./python -m test -m test_strings test_gdb" (simpler command) also fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32834>
_______________________________________

From report at bugs.python.org  Sun Jan 27 04:03:06 2019
From: report at bugs.python.org (Stefano Bonalumi)
Date: Sun, 27 Jan 2019 09:03:06 +0000
Subject: [issue35832] Installation error
In-Reply-To: <1548516102.75.0.92824244554.issue35832@roundup.psfhosted.org>
Message-ID: <CALO7bexmxkRzdNWyF=FnMKN_w4j7fCCm8X_TmNH_YiK-b_Fe-g@mail.gmail.com>


Stefano Bonalumi <stefano.bonalumi at gmail.com> added the comment:

Hi
plesaes find these files attached
Please give me further instructions

Thanks a lot

Il giorno sab 26 gen 2019 alle ore 16:21 Steve Dower <report at bugs.python.org>
ha scritto:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> You should have a set of log files in your %TEMP% directory. Their names
> will start with Python and end in .log. If you could collect these into a
> zip file and post them here, that would be very helpful.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35832>
> _______________________________________
>

----------
Added file: https://bugs.python.org/file48080/Python 3.7.0 (64-bit)_20190127100020.log
Added file: https://bugs.python.org/file48081/Python 3.7.2 (32-bit)_20190127100056.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35832>
_______________________________________
-------------- next part --------------
[1AC8:289C][2019-01-27T10:00:20]i001: Burn v3.11.1.2318, Windows v10.0 (Build 17763: Service Pack 0), path: C:\Users\Admin\AppData\Local\Temp\{8B2A7EA8-B5D7-44A3-856A-444429C72168}\.cr\python-3.7.0-amd64.exe
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'ActionLikeInstalling' to value 'Installing'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'ActionLikeInstallation' to value 'Setup'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'ShortVersion' to value '3.7'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'ShortVersionNoDot' to value '37'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'WinVer' to value '3.7'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'WinVerNoDot' to value '37'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'InstallAllUsers' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'InstallLauncherAllUsers' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'TargetDir' to value ''
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'DefaultAllUsersTargetDir' to value '[ProgramFiles64Folder]Python[WinVerNoDot]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'TargetPlatform' to value 'x64'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'DefaultJustForMeTargetDir' to value '[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'OptionalFeaturesRegistryKey' to value 'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'TargetDirRegistryKey' to value 'Software\Python\PythonCore\[WinVer]\InstallPath'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'DefaultCustomTargetDir' to value ''
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'InstallAllUsersState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'InstallLauncherAllUsersState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'TargetDirState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'CustomBrowseButtonState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_core' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_exe' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_dev' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_lib' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_test' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_doc' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_tools' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_tcltk' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_pip' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_launcher' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'Include_launcherState' to value 'enabled'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_symbols' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Include_debug' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'LauncherOnly' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'DetectedLauncher' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'DetectedOldLauncher' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'AssociateFiles' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'Shortcuts' to value '1'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'PrependPath' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'CompileAll' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing numeric variable 'SimpleInstall' to value '0'
[1AC8:289C][2019-01-27T10:00:20]i000: Initializing string variable 'SimpleInstallDescription' to value ''
[1AC8:289C][2019-01-27T10:00:20]i009: Command Line: '-burn.clean.room=C:\Users\Admin\Downloads\python-3.7.0-amd64.exe -burn.filehandle.attached=620 -burn.filehandle.self=704'
[1AC8:289C][2019-01-27T10:00:20]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\Admin\Downloads\python-3.7.0-amd64.exe'
[1AC8:289C][2019-01-27T10:00:20]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\Admin\Downloads\'
[1AC8:289C][2019-01-27T10:00:20]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020.log'
[1AC8:289C][2019-01-27T10:00:20]i000: Setting string variable 'WixBundleName' to value 'Python 3.7.0 (64-bit)'
[1AC8:289C][2019-01-27T10:00:20]i000: Setting string variable 'WixBundleManufacturer' to value 'Python Software Foundation'
[1AC8:289C][2019-01-27T10:00:20]i000: Setting numeric variable 'CRTInstalled' to value 1
[1AC8:2960][2019-01-27T10:00:20]i000: Did not find C:\Users\Admin\Downloads\unattend.xml
[1AC8:2960][2019-01-27T10:00:20]i000: Setting string variable 'ActionLikeInstalling' to value 'Installing'
[1AC8:2960][2019-01-27T10:00:20]i000: Setting string variable 'ActionLikeInstallation' to value 'Setup'
[1AC8:2960][2019-01-27T10:00:20]i000: Setting version variable 'WixBundleFileVersion' to value '3.7.150.0'
[1AC8:2960][2019-01-27T10:00:20]i000: Target OS is Windows 7 SP1 or later
[1AC8:289C][2019-01-27T10:00:20]i100: Detect begin, 52 packages
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: ucrt_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: ucrt_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: core_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: core_AllUsers_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: core_AllUsers_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: core_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: core_JustForMe_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: core_JustForMe_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: dev_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: dev_AllUsers_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: dev_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: dev_JustForMe_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: exe_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: exe_AllUsers, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: exe_AllUsers, feature: Shortcuts, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: exe_AllUsers_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: exe_AllUsers_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: exe_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: exe_JustForMe, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: exe_JustForMe, feature: Shortcuts, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: exe_JustForMe_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: exe_JustForMe_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: lib_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: lib_AllUsers_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: lib_AllUsers_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: lib_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: lib_JustForMe_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: lib_JustForMe_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: test_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: test_AllUsers_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: test_AllUsers_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: test_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: test_JustForMe_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: test_JustForMe_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: doc_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: doc_AllUsers, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: doc_AllUsers, feature: Shortcuts, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: doc_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: doc_JustForMe, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: doc_JustForMe, feature: Shortcuts, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tools_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tools_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tcltk_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_AllUsers, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_AllUsers, feature: AssociateFiles, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_AllUsers, feature: Shortcuts, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tcltk_AllUsers_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_AllUsers_pdb, feature: Symbols, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tcltk_AllUsers_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_AllUsers_d, feature: DebugBinaries, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tcltk_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_JustForMe, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_JustForMe, feature: AssociateFiles, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_JustForMe, feature: Shortcuts, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tcltk_JustForMe_pdb, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_JustForMe_pdb, feature: Symbols, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: tcltk_JustForMe_d, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: tcltk_JustForMe_d, feature: DebugBinaries, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: launcher_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: launcher_AllUsers, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: launcher_AllUsers, feature: AssociateFiles, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: launcher_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: launcher_JustForMe, feature: DefaultFeature, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i104: Detected package: launcher_JustForMe, feature: AssociateFiles, state: Absent
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: pip_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: pip_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: path_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: path_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: compileall_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: compileallO_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: compileallOO_AllUsers, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: compileall_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: compileallO_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i101: Detected package: compileallOO_JustForMe, state: Absent, cached: None
[1AC8:289C][2019-01-27T10:00:20]i000: Setting string variable 'TargetDir' to value 'C:\Users\Admin\AppData\Local\Programs\Python\Python37'
[1AC8:289C][2019-01-27T10:00:20]i199: Detect complete, result: 0x0
[1AC8:2960][2019-01-27T10:00:20]i052: Condition 'not WixBundleElevated and (InstallAllUsers or (Include_launcher and InstallLauncherAllUsers and not DetectedLauncher))' evaluates to true.
[1AC8:2960][2019-01-27T10:00:24]i000: Setting numeric variable 'InstallLauncherAllUsers' to value 1
[1AC8:2960][2019-01-27T10:00:24]i000: Setting numeric variable 'PrependPath' to value 0
[1AC8:2960][2019-01-27T10:00:24]i000: Setting numeric variable 'CompileAll' to value 0
[1AC8:2960][2019-01-27T10:00:24]i000: Setting string variable 'ActionLikeInstalling' to value 'Installing'
[1AC8:2960][2019-01-27T10:00:24]i000: Setting string variable 'ActionLikeInstallation' to value 'Setup'
[1AC8:289C][2019-01-27T10:00:24]i200: Plan begin, 52 packages, action: Install
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: ucrt_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: core_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: core_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: core_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_core_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_000_core_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_core_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_000_core_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_dev and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_dev and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: dev_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: dev_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_dev and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_dev and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_dev_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_001_dev_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_dev_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_001_dev_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 2 msi features for package: exe_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: exe_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: exe_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: exe_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 2 msi features for package: exe_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_exe_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_002_exe_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_exe_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_002_exe_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_lib and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_lib and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: lib_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: lib_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: lib_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_lib and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_lib and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_lib_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_003_lib_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_lib_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_003_lib_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_test and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_test and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: test_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: test_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: test_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_test and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_test and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_test_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_004_test_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_test_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_004_test_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_doc and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_doc and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 2 msi features for package: doc_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: doc_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_doc and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_doc and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 2 msi features for package: doc_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_doc_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_005_doc_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_doc_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_005_doc_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tools and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tools and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: tools_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tools and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tools and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_tools_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_006_tools_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_tools_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_006_tools_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 3 msi features for package: tcltk_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 1 msi features for package: tcltk_AllUsers_pdb
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 1 msi features for package: tcltk_AllUsers_d
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DebugBinaries, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 3 msi features for package: tcltk_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_tcltk_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_007_tcltk_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_tcltk_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_007_tcltk_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 1 msi features for package: tcltk_JustForMe_pdb
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 1 msi features for package: tcltk_JustForMe_d
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DebugBinaries, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i052: Condition '(InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition '(InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 2 msi features for package: launcher_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: launcher_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_launcher_AllUsers' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_008_launcher_AllUsers.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not (InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not (InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i204: Plan 2 msi features for package: launcher_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_pip and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and Include_pip and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: pip_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_pip and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and Include_pip and not LauncherOnly' evaluates to true.
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleRollbackLog_pip_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_009_pip_JustForMe_rollback.log'
[1AC8:289C][2019-01-27T10:00:24]i000: Setting string variable 'WixBundleLog_pip_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.0 (64-bit)_20190127100020_009_pip_JustForMe.log'
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w322: Skipping cross-scope dependency registration on package: path_AllUsers, bundle scope: PerUser, package scope: PerMachine
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w321: Skipping dependency registration on package with no dependency providers: compileall_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w321: Skipping dependency registration on package with no dependency providers: compileallO_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w321: Skipping dependency registration on package with no dependency providers: compileallOO_AllUsers
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w321: Skipping dependency registration on package with no dependency providers: compileall_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w321: Skipping dependency registration on package with no dependency providers: compileallO_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[1AC8:289C][2019-01-27T10:00:24]w321: Skipping dependency registration on package with no dependency providers: compileallOO_JustForMe
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: ucrt_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: ucrt_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: core_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: core_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: core_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: core_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: core_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: core_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: dev_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: dev_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: dev_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: dev_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: exe_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: exe_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: exe_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: exe_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: exe_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: exe_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: lib_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: lib_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: lib_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: lib_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: lib_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: lib_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: test_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: test_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: test_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: test_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: test_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: test_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: doc_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: doc_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tools_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tools_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tcltk_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tcltk_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tcltk_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tcltk_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tcltk_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: tcltk_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: launcher_AllUsers, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: None, cache: Yes, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: launcher_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: pip_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: pip_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: path_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: path_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: compileall_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: compileallO_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: compileallOO_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: compileall_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: compileallO_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i201: Planned package: compileallOO_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[1AC8:289C][2019-01-27T10:00:24]i299: Plan complete, result: 0x0
[1AC8:289C][2019-01-27T10:00:24]i300: Apply begin
[1AC8:289C][2019-01-27T10:00:24]i010: Launching elevated engine process.
[1AC8:289C][2019-01-27T10:00:25]i011: Launched elevated engine process.
[1AC8:289C][2019-01-27T10:00:25]i012: Connected to elevated engine.
[05AC:1808][2019-01-27T10:00:25]i358: Pausing automatic updates.
[05AC:1808][2019-01-27T10:00:25]i359: Paused automatic updates.
[05AC:1808][2019-01-27T10:00:25]i360: Creating a system restore point.
[05AC:1808][2019-01-27T10:00:25]w363: Could not create system restore point, error: 0x80070422. Continuing...
[1AC8:289C][2019-01-27T10:00:25]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{f684de81-73c2-4924-ad43-e7ae400d47b5}, options: 0x7, disable resume: No
[1AC8:289C][2019-01-27T10:00:25]i000: Caching bundle from: 'C:\Users\Admin\AppData\Local\Temp\{67DFF709-BC50-4FCC-B91E-A2820D8CF31E}\.be\python-3.7.0-amd64.exe' to: 'C:\Users\Admin\AppData\Local\Package Cache\{f684de81-73c2-4924-ad43-e7ae400d47b5}\python-3.7.0-amd64.exe'
[1AC8:289C][2019-01-27T10:00:25]i320: Registering bundle dependency provider: CPython-3.7, version: 3.7.150.0
[1AC8:289C][2019-01-27T10:00:25]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{f684de81-73c2-4924-ad43-e7ae400d47b5}, resume: Active, restart initiated: No, disable resume: No
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: core_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\core_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{F046BD5A-33F4-4ABA-BD2D-0227F6291EC9}v3.7.150.0\core.msi.
[1AC8:289C][2019-01-27T10:00:26]i323: Registering package dependency provider: {F046BD5A-33F4-4ABA-BD2D-0227F6291EC9}, version: 3.7.150.0, package: core_JustForMe
[1AC8:289C][2019-01-27T10:00:26]i301: Applying execute package: core_JustForMe, action: Install, path: C:\Users\Admin\AppData\Local\Package Cache\{F046BD5A-33F4-4ABA-BD2D-0227F6291EC9}v3.7.150.0\core.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Users\Admin\AppData\Local\Programs\Python\Python37" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.7\InstalledFeatures"'
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: dev_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\dev_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{61246987-8D99-44A9-8FF5-E2E3F503B72D}v3.7.150.0\dev.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: exe_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\exe_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{84B7971A-F59F-4247-AD34-BEC02CF85FBD}v3.7.150.0\exe.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: lib_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\lib_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{18D93BBC-06F6-449D-96FB-CD473CFC6A6D}v3.7.150.0\lib.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: test_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\test_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{E4266358-1C9B-4AF0-ABF7-72BE136904CF}v3.7.150.0\test.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: doc_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\doc_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{E7C56E72-C80E-453B-9345-FAEAE5DB51A4}v3.7.150.0\doc.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: tools_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\tools_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{9E24E01B-CBD8-4558-A56D-6188F1A3C822}v3.7.150.0\tools.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: tcltk_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\tcltk_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{A2FC01E0-059E-4D21-AFD2-B63A7E1EF3CD}v3.7.150.0\tcltk.msi.
[05AC:10A4][2019-01-27T10:00:26]i305: Verified acquired payload: launcher_AllUsers at path: C:\ProgramData\Package Cache\.unverified\launcher_AllUsers, moving to: C:\ProgramData\Package Cache\{D6BDDB48-938A-4384-A7BE-2B4E4931B111}v3.7.6386.0\launcher.msi.
[1AC8:10D4][2019-01-27T10:00:26]i305: Verified acquired payload: pip_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\pip_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{8A6F7991-1955-4C46-8C0C-8D7C6F7042FA}v3.7.150.0\pip.msi.
[1AC8:289C][2019-01-27T10:00:32]e000: Error 0x80070643: Failed to install MSI package.
[1AC8:289C][2019-01-27T10:00:32]e000: Error 0x80070643: Failed to configure per-user MSI package.
[1AC8:289C][2019-01-27T10:00:32]i319: Applied execute package: core_JustForMe, result: 0x80070643, restart: None
[1AC8:289C][2019-01-27T10:00:32]e000: Error 0x80070643: Failed to execute MSI package.
[1AC8:289C][2019-01-27T10:00:32]i318: Skipped rollback of package: core_JustForMe, action: Uninstall, already: Absent
[1AC8:289C][2019-01-27T10:00:32]i319: Applied rollback package: core_JustForMe, result: 0x0, restart: None
[1AC8:289C][2019-01-27T10:00:32]i329: Removed package dependency provider: {F046BD5A-33F4-4ABA-BD2D-0227F6291EC9}, package: core_JustForMe
[1AC8:289C][2019-01-27T10:00:32]i351: Removing cached package: core_JustForMe, from path: C:\Users\Admin\AppData\Local\Package Cache\{F046BD5A-33F4-4ABA-BD2D-0227F6291EC9}v3.7.150.0\
[1AC8:289C][2019-01-27T10:00:32]i329: Removed package dependency provider: {A37820E7-4E89-4B6E-B584-B13E703B26F7}, package: ucrt_JustForMe
[1AC8:289C][2019-01-27T10:00:32]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{f684de81-73c2-4924-ad43-e7ae400d47b5}, resume: None, restart: None, disable resume: No
[1AC8:289C][2019-01-27T10:00:32]i330: Removed bundle dependency provider: CPython-3.7
[1AC8:289C][2019-01-27T10:00:32]i352: Removing cached bundle: {f684de81-73c2-4924-ad43-e7ae400d47b5}, from path: C:\Users\Admin\AppData\Local\Package Cache\{f684de81-73c2-4924-ad43-e7ae400d47b5}\
[1AC8:289C][2019-01-27T10:00:32]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{f684de81-73c2-4924-ad43-e7ae400d47b5}, resume: None, restart initiated: No, disable resume: No
[1AC8:289C][2019-01-27T10:00:33]i399: Apply complete, result: 0x80070643, restart: None, ba requested restart:  No
-------------- next part --------------
[2B50:173C][2019-01-27T10:00:56]i001: Burn v3.11.1.2318, Windows v10.0 (Build 17763: Service Pack 0), path: C:\Users\Admin\AppData\Local\Temp\{414A7554-D7CE-446D-AF67-D67E7A432999}\.cr\python-3.7.2.exe
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'ActionLikeInstalling' to value 'Installing'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'ActionLikeInstallation' to value 'Setup'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'ShortVersion' to value '3.7'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'ShortVersionNoDot' to value '37'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'WinVer' to value '3.7-32'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'WinVerNoDot' to value '37-32'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'InstallAllUsers' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'InstallLauncherAllUsers' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'TargetDir' to value ''
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'DefaultAllUsersTargetDir' to value '[ProgramFilesFolder]Python[WinVerNoDot]'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'TargetPlatform' to value 'x86'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'DefaultJustForMeTargetDir' to value '[LocalAppDataFolder]Programs\Python\Python[WinVerNoDot]'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'OptionalFeaturesRegistryKey' to value 'Software\Python\PythonCore\[WinVer]\InstalledFeatures'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'TargetDirRegistryKey' to value 'Software\Python\PythonCore\[WinVer]\InstallPath'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'DefaultCustomTargetDir' to value ''
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'InstallAllUsersState' to value 'enabled'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'InstallLauncherAllUsersState' to value 'enabled'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'CustomInstallLauncherAllUsersState' to value '[InstallLauncherAllUsersState]'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'TargetDirState' to value 'enabled'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'CustomBrowseButtonState' to value 'enabled'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_core' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_exe' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_dev' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_lib' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_test' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_doc' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_tools' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_tcltk' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_pip' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_launcher' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'Include_launcherState' to value 'enabled'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_symbols' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Include_debug' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'LauncherOnly' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'DetectedLauncher' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'DetectedOldLauncher' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'AssociateFiles' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'Shortcuts' to value '1'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'PrependPath' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'CompileAll' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing numeric variable 'SimpleInstall' to value '0'
[2B50:173C][2019-01-27T10:00:56]i000: Initializing string variable 'SimpleInstallDescription' to value ''
[2B50:173C][2019-01-27T10:00:56]i009: Command Line: '-burn.clean.room=C:\Users\Admin\Downloads\python-3.7.2.exe -burn.filehandle.attached=684 -burn.filehandle.self=696'
[2B50:173C][2019-01-27T10:00:56]i000: Setting string variable 'WixBundleOriginalSource' to value 'C:\Users\Admin\Downloads\python-3.7.2.exe'
[2B50:173C][2019-01-27T10:00:56]i000: Setting string variable 'WixBundleOriginalSourceFolder' to value 'C:\Users\Admin\Downloads\'
[2B50:173C][2019-01-27T10:00:56]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056.log'
[2B50:173C][2019-01-27T10:00:56]i000: Setting string variable 'WixBundleName' to value 'Python 3.7.2 (32-bit)'
[2B50:173C][2019-01-27T10:00:56]i000: Setting string variable 'WixBundleManufacturer' to value 'Python Software Foundation'
[2B50:173C][2019-01-27T10:00:56]i000: Setting numeric variable 'CRTInstalled' to value 1
[2B50:18B4][2019-01-27T10:00:56]i000: Did not find C:\Users\Admin\Downloads\unattend.xml
[2B50:18B4][2019-01-27T10:00:56]i000: Setting string variable 'ActionLikeInstalling' to value 'Installing'
[2B50:18B4][2019-01-27T10:00:56]i000: Setting string variable 'ActionLikeInstallation' to value 'Setup'
[2B50:18B4][2019-01-27T10:00:56]i000: Setting version variable 'WixBundleFileVersion' to value '3.7.2150.0'
[2B50:18B4][2019-01-27T10:00:57]i000: Target OS is Windows 7 SP1 or later
[2B50:173C][2019-01-27T10:00:57]i100: Detect begin, 52 packages
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: ucrt_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: ucrt_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: core_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: core_AllUsers_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: core_AllUsers_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: core_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: core_JustForMe_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: core_JustForMe_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: dev_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: dev_AllUsers_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: dev_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: dev_JustForMe_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: exe_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: exe_AllUsers, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: exe_AllUsers, feature: Shortcuts, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: exe_AllUsers_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: exe_AllUsers_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: exe_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: exe_JustForMe, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: exe_JustForMe, feature: Shortcuts, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: exe_JustForMe_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: exe_JustForMe_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: lib_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: lib_AllUsers_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: lib_AllUsers_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: lib_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: lib_JustForMe_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: lib_JustForMe_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: test_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: test_AllUsers_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: test_AllUsers_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: test_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: test_JustForMe_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: test_JustForMe_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: doc_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: doc_AllUsers, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: doc_AllUsers, feature: Shortcuts, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: doc_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: doc_JustForMe, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: doc_JustForMe, feature: Shortcuts, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tools_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tools_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tcltk_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_AllUsers, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_AllUsers, feature: AssociateFiles, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_AllUsers, feature: Shortcuts, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tcltk_AllUsers_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_AllUsers_pdb, feature: Symbols, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tcltk_AllUsers_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_AllUsers_d, feature: DebugBinaries, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tcltk_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_JustForMe, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_JustForMe, feature: AssociateFiles, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_JustForMe, feature: Shortcuts, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tcltk_JustForMe_pdb, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_JustForMe_pdb, feature: Symbols, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: tcltk_JustForMe_d, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: tcltk_JustForMe_d, feature: DebugBinaries, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: launcher_AllUsers, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: launcher_AllUsers, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: launcher_AllUsers, feature: AssociateFiles, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: launcher_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: launcher_JustForMe, feature: DefaultFeature, state: Absent
[2B50:173C][2019-01-27T10:00:57]i104: Detected package: launcher_JustForMe, feature: AssociateFiles, state: Absent
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: pip_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: pip_JustForMe, state: Absent, cached: Complete
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: path_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: path_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: compileall_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: compileallO_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: compileallOO_AllUsers, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: compileall_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: compileallO_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i101: Detected package: compileallOO_JustForMe, state: Absent, cached: None
[2B50:173C][2019-01-27T10:00:57]i000: Setting string variable 'TargetDir' to value 'C:\Users\Admin\AppData\Local\Programs\Python\Python37-32'
[2B50:173C][2019-01-27T10:00:57]i199: Detect complete, result: 0x0
[2B50:18B4][2019-01-27T10:00:57]i052: Condition 'not WixBundleElevated and (InstallAllUsers or (Include_launcher and InstallLauncherAllUsers and not DetectedLauncher))' evaluates to true.
[2B50:18B4][2019-01-27T10:00:59]i000: Setting numeric variable 'InstallLauncherAllUsers' to value 1
[2B50:18B4][2019-01-27T10:00:59]i000: Setting numeric variable 'PrependPath' to value 0
[2B50:18B4][2019-01-27T10:00:59]i000: Setting numeric variable 'CompileAll' to value 0
[2B50:18B4][2019-01-27T10:00:59]i000: Setting string variable 'ActionLikeInstalling' to value 'Installing'
[2B50:18B4][2019-01-27T10:00:59]i000: Setting string variable 'ActionLikeInstallation' to value 'Setup'
[2B50:173C][2019-01-27T10:00:59]i200: Plan begin, 52 packages, action: Install
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: ucrt_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and not CRTInstalled and (Include_core or Include_exe or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: core_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: core_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: core_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_core_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_000_core_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_core_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_000_core_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_core or Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_dev and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_dev and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: dev_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: dev_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_dev and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_dev and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_dev_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_001_dev_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_dev_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_001_dev_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_dev and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 2 msi features for package: exe_AllUsers
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: exe_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: exe_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: exe_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 2 msi features for package: exe_JustForMe
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_exe_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_002_exe_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_exe_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_002_exe_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and (Include_exe or Include_launcher or Include_pip) and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_lib and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_lib and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: lib_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: lib_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: lib_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_lib and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_lib and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_lib_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_003_lib_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_lib_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_003_lib_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_lib and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_lib and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_test and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_test and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: test_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: test_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: test_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_test and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_test and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_test_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_004_test_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_test_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_004_test_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_test and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_test and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_doc and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_doc and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 2 msi features for package: doc_AllUsers
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: doc_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_doc and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_doc and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 2 msi features for package: doc_JustForMe
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_doc_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_005_doc_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_doc_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_005_doc_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tools and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tools and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: tools_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tools and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tools and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_tools_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_006_tools_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_tools_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_006_tools_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 3 msi features for package: tcltk_AllUsers
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 1 msi features for package: tcltk_AllUsers_pdb
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers_pdb, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 1 msi features for package: tcltk_AllUsers_d
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DebugBinaries, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: tcltk_AllUsers_d, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tcltk and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 3 msi features for package: tcltk_JustForMe
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Shortcuts, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_tcltk_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_007_tcltk_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_tcltk_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_007_tcltk_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 1 msi features for package: tcltk_JustForMe_pdb
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_debug and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 1 msi features for package: tcltk_JustForMe_d
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DebugBinaries, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i052: Condition '(InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition '(InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 2 msi features for package: launcher_AllUsers
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: launcher_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_launcher_AllUsers' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_008_launcher_AllUsers.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not (InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not (InstallAllUsers or InstallLauncherAllUsers) and Include_launcher and not DetectedLauncher' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i204: Plan 2 msi features for package: launcher_JustForMe
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: DefaultFeature, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i203: Planned feature: AssociateFiles, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_pip and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and Include_pip and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: pip_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_pip and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and Include_pip and not LauncherOnly' evaluates to true.
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleRollbackLog_pip_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_009_pip_JustForMe_rollback.log'
[2B50:173C][2019-01-27T10:00:59]i000: Setting string variable 'WixBundleLog_pip_JustForMe' to value 'C:\Users\Admin\AppData\Local\Temp\Python 3.7.2 (32-bit)_20190127100056_009_pip_JustForMe.log'
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w322: Skipping cross-scope dependency registration on package: path_AllUsers, bundle scope: PerUser, package scope: PerMachine
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and PrependPath and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w321: Skipping dependency registration on package with no dependency providers: compileall_AllUsers
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w321: Skipping dependency registration on package with no dependency providers: compileallO_AllUsers
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w321: Skipping dependency registration on package with no dependency providers: compileallOO_AllUsers
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w321: Skipping dependency registration on package with no dependency providers: compileall_JustForMe
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w321: Skipping dependency registration on package with no dependency providers: compileallO_JustForMe
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]i052: Condition 'not InstallAllUsers and CompileAll and not LauncherOnly' evaluates to false.
[2B50:173C][2019-01-27T10:00:59]w321: Skipping dependency registration on package with no dependency providers: compileallOO_JustForMe
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: ucrt_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: ucrt_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: core_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: core_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: core_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: core_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: Yes, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: core_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: core_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: dev_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: dev_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: dev_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: dev_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: exe_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: exe_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: exe_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: exe_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: exe_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: exe_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: lib_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: lib_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: lib_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: lib_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: lib_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: lib_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: test_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: test_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: test_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: test_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: test_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: test_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: doc_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: doc_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tools_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tools_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tcltk_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tcltk_AllUsers_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tcltk_AllUsers_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tcltk_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tcltk_JustForMe_pdb, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: tcltk_JustForMe_d, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: launcher_AllUsers, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: launcher_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: pip_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: pip_JustForMe, state: Absent, default requested: Present, ba requested: Present, execute: Install, rollback: Uninstall, cache: No, uncache: No, dependency: Register
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: path_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: path_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: compileall_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: compileallO_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: compileallOO_AllUsers, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: compileall_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: compileallO_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i201: Planned package: compileallOO_JustForMe, state: Absent, default requested: Absent, ba requested: Absent, execute: None, rollback: None, cache: No, uncache: No, dependency: None
[2B50:173C][2019-01-27T10:00:59]i299: Plan complete, result: 0x0
[2B50:173C][2019-01-27T10:00:59]i300: Apply begin
[2B50:173C][2019-01-27T10:00:59]i010: Launching elevated engine process.
[2B50:173C][2019-01-27T10:00:59]i011: Launched elevated engine process.
[2B50:173C][2019-01-27T10:01:00]i012: Connected to elevated engine.
[1B88:112C][2019-01-27T10:01:00]i358: Pausing automatic updates.
[1B88:112C][2019-01-27T10:01:00]i359: Paused automatic updates.
[1B88:112C][2019-01-27T10:01:00]i360: Creating a system restore point.
[1B88:112C][2019-01-27T10:01:00]w363: Could not create system restore point, error: 0x80070422. Continuing...
[2B50:173C][2019-01-27T10:01:00]i370: Session begin, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}, options: 0x7, disable resume: No
[2B50:173C][2019-01-27T10:01:00]i000: Caching bundle from: 'C:\Users\Admin\AppData\Local\Temp\{D7C83811-B00B-414F-8B8B-8068607AB1EF}\.be\python-3.7.2.exe' to: 'C:\Users\Admin\AppData\Local\Package Cache\{0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}\python-3.7.2.exe'
[2B50:173C][2019-01-27T10:01:00]i320: Registering bundle dependency provider: CPython-3.7-32, version: 3.7.2150.0
[2B50:173C][2019-01-27T10:01:00]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}, resume: Active, restart initiated: No, disable resume: No
[2B50:0B44][2019-01-27T10:01:00]i305: Verified acquired payload: core_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\.unverified\core_JustForMe, moving to: C:\Users\Admin\AppData\Local\Package Cache\{3A09B849-4D48-41AA-9461-112E6CEC405D}v3.7.2150.0\core.msi.
[2B50:173C][2019-01-27T10:01:00]i323: Registering package dependency provider: {3A09B849-4D48-41AA-9461-112E6CEC405D}, version: 3.7.2150.0, package: core_JustForMe
[2B50:173C][2019-01-27T10:01:00]i301: Applying execute package: core_JustForMe, action: Install, path: C:\Users\Admin\AppData\Local\Package Cache\{3A09B849-4D48-41AA-9461-112E6CEC405D}v3.7.2150.0\core.msi, arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Users\Admin\AppData\Local\Programs\Python\Python37-32" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.7-32\InstalledFeatures"'
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: dev_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{A14E7090-5888-460B-9003-1C3DA5AD3D35}v3.7.2150.0\dev.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: exe_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{D6FF50CC-E41E-4FFB-B7B9-72D71BF00C55}v3.7.2150.0\exe.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: lib_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{667226B8-23CA-47C1-A070-D3B85E8C9292}v3.7.2150.0\lib.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: test_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{F0B6A6E9-C7E1-4730-A29D-71C02B800028}v3.7.2150.0\test.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: doc_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{D2FA452F-4742-4805-BEB1-AC81ED48F4A8}v3.7.2150.0\doc.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: tools_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{06CE3F8B-A658-462C-AD3D-FA7142297E97}v3.7.2150.0\tools.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: tcltk_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{34AD493A-01AA-4D6A-9229-BF0406F22D14}v3.7.2150.0\tcltk.msi.
[1B88:0F2C][2019-01-27T10:01:00]i304: Verified existing payload: launcher_AllUsers at path: C:\ProgramData\Package Cache\{FA2A3867-8965-4CF7-83E2-C8960652F5AD}v3.7.6565.0\launcher.msi.
[2B50:0B44][2019-01-27T10:01:00]i304: Verified existing payload: pip_JustForMe at path: C:\Users\Admin\AppData\Local\Package Cache\{0D2B3674-3B1E-4281-B5FD-37D700602129}v3.7.2150.0\pip.msi.
[2B50:173C][2019-01-27T10:01:02]e000: Error 0x80070643: Failed to install MSI package.
[2B50:173C][2019-01-27T10:01:02]e000: Error 0x80070643: Failed to configure per-user MSI package.
[2B50:173C][2019-01-27T10:01:02]i319: Applied execute package: core_JustForMe, result: 0x80070643, restart: None
[2B50:173C][2019-01-27T10:01:02]e000: Error 0x80070643: Failed to execute MSI package.
[2B50:173C][2019-01-27T10:01:02]i318: Skipped rollback of package: core_JustForMe, action: Uninstall, already: Absent
[2B50:173C][2019-01-27T10:01:02]i319: Applied rollback package: core_JustForMe, result: 0x0, restart: None
[2B50:173C][2019-01-27T10:01:02]i329: Removed package dependency provider: {3A09B849-4D48-41AA-9461-112E6CEC405D}, package: core_JustForMe
[2B50:173C][2019-01-27T10:01:02]i351: Removing cached package: core_JustForMe, from path: C:\Users\Admin\AppData\Local\Package Cache\{3A09B849-4D48-41AA-9461-112E6CEC405D}v3.7.2150.0\
[2B50:173C][2019-01-27T10:01:02]i329: Removed package dependency provider: {151F51CB-69A7-4634-AD01-E7312B781C80}, package: ucrt_JustForMe
[2B50:173C][2019-01-27T10:01:02]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}, resume: None, restart: None, disable resume: No
[2B50:173C][2019-01-27T10:01:02]i330: Removed bundle dependency provider: CPython-3.7-32
[2B50:173C][2019-01-27T10:01:02]i352: Removing cached bundle: {0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}, from path: C:\Users\Admin\AppData\Local\Package Cache\{0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}\
[2B50:173C][2019-01-27T10:01:02]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0f40e78b-67e1-4e0c-a2fd-e9325d9dfc82}, resume: None, restart initiated: No, disable resume: No
[2B50:173C][2019-01-27T10:01:02]i399: Apply complete, result: 0x80070643, restart: None, ba requested restart:  No

From report at bugs.python.org  Sun Jan 27 14:42:00 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 27 Jan 2019 19:42:00 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548618120.65.0.00993683521842.issue35835@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@jcrmatos, would you like to create a Github pull request with the change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 14:42:15 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 27 Jan 2019 19:42:15 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548618135.46.0.878035761455.issue35835@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 14:43:22 2019
From: report at bugs.python.org (jcrmatos)
Date: Sun, 27 Jan 2019 19:43:22 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548618202.23.0.363669961452.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

I'm sorry, I have no idea how to do it.

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 15:20:46 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 27 Jan 2019 20:20:46 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548600621.45.0.645312277596.issue35806@roundup.psfhosted.org>
Message-ID: <CAP7+vJL3L08ugjSSUJCZP0V77KZjQGosdf-LSNkTgmKpKns52g@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Option 2 sounds best. I am also not against adding __spec__ but I think we
should support the idiom regardless, and I don?t consider this a bug in the
typing module ? at best there?s a slight improvement.

On Sun, Jan 27, 2019 at 6:50 AM Nick Coghlan <report at bugs.python.org> wrote:

>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Closing this without any changes contradicts the answer we gave Ronald on
> #35791 that it's expected behaviour for importlib.find_spec() to throw an
> exception for already loaded modules without a __spec__ attribute.
>
> So if this stays closed, then we should reopen #35791, and treat it as a
> feature request to either:
>
> 1. add a "ignore_module_cache" option to bypass sys.modules; or
> 2. revert to searching for the original spec in cases where the
> sys.modules entry has no __spec__ attribute (which has the virtue of just
> working for cases of the "replace yourself in sys.modules" idiom)
>
> That said, the typing pseudo submodules *can* populate their __spec__ with
> useful information by copying most of their attributes from
> `typing.__spec__`, but setting their __spec__.loader attribute to one that
> throws an ImportError with a message saying to import `typing` instead of
> attempting to reload the submodule directly.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35806>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Sun Jan 27 16:49:49 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 27 Jan 2019 21:49:49 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548625789.1.0.360766457827.issue35806@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Note that I will have to special case namespaces like typing.re anyway in my code, being a namespace that does not correspond to a "real" module whose code I can analyse.

#35791 was mostly about 3th-party code like apipkg that are "real" modules, but for some reason effectively erase there __spec__ attribute. In those cases find_spec could return valid value.

As I mentioned in the other issue I have a simple workaround for this, and that's something I'll have to keep around for a while anyway. 

I'm not convinced at this point that anything needs to be changed, as long as the documentation is clear on the requirement that modules should have a __spec__ attribute (which makes it easier to convince 3th-party authors to update their code). 

Special cases like typing.re will always be special, and adding __spec__ to them won't change a lot there (the only vaguely useful attribute in the ModuleSpec for typing.re would be "name" and "parent") and IMHO would be needless code churn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Sun Jan 27 17:19:37 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 27 Jan 2019 22:19:37 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548627577.8.0.75312520061.issue35835@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@jcrmatos,

No problem.  :-)  If you are interested in learning how, we can guide you.  However, if you'd rather not, then that's OK too and we'll make the patch.  Just let us know which you'd prefer.

If you need help deciding, take a look at the devguide on how to get started.  
https://devguide.python.org/

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 17:27:03 2019
From: report at bugs.python.org (Phil Kang)
Date: Sun, 27 Jan 2019 22:27:03 +0000
Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict
Message-ID: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org>


New submission from Phil Kang <keepyourhonor at gmail.com>:

ConfigParser calls ConfigParser.optionxform twice per each key when assigning a dictionary to a section.

The following code:

    ini = configparser.ConfigParser()
    ini.optionxform = lambda x: '(' + x + ')'
    
    # Bugged
    ini['section A'] = {'key 1': 'value 1', 'key 2': 'value 2'}
    # Not bugged
    ini.add_section('section B')
    ini['section B']['key 3'] = 'value 3'
    ini['section B']['key 4'] = 'value 4'

   inifile = io.StringIO()
   ini.write(inifile)
   print(inifile.getvalue())

...results in an INI file that looks like:

    [section A]
    ((key 1)) = value 1
    ((key 2)) = value 2
    
    [section B]
    (key 3) = value 3
    (key 4) = value 4

Here, optionxform has been called twice on key 1 and key 2, resulting in the double parentheses.

This also breaks conventional mapping access on the ConfigParser:

    print(ini['section A']['key 1'])    # Raises KeyError('key 1')
    print(ini['section A']['(key 1)'])  # OK
    
    # Raises ValueError: too many values to unpack (expected 2)
    for key, value in ini['section A']:
        print(key + ', ' + value)

----------
components: Library (Lib)
messages: 334439
nosy: Phil Kang
priority: normal
severity: normal
status: open
title: ConfigParser calls optionxform twice when assigning dict
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35838>
_______________________________________

From report at bugs.python.org  Sun Jan 27 17:41:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 27 Jan 2019 22:41:11 +0000
Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict
In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org>
Message-ID: <1548628871.35.0.737210735061.issue35838@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35838>
_______________________________________

From report at bugs.python.org  Sun Jan 27 22:32:38 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 28 Jan 2019 03:32:38 +0000
Subject: [issue29541] Python3 error while building on Alt-F
In-Reply-To: <1486972341.9.0.0995375126995.issue29541@psf.upfronthosting.co.za>
Message-ID: <1548646358.24.0.626782435865.issue29541@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yen at chyen.cc>:


----------
nosy:  -yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29541>
_______________________________________

From report at bugs.python.org  Sun Jan 27 22:34:44 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 03:34:44 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548646484.19.0.84061378698.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

Yes, I'm interested in learning, thanks.
I use Windows not Linux. Is that a problem?
I will read the guide and let you know if I have any questions. Thanks again.

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 22:43:38 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 28 Jan 2019 03:43:38 +0000
Subject: [issue31710] setup.py: _ctypes won't get built when system ffi is
 only in $PREFIX
In-Reply-To: <1507266884.06.0.213398074469.issue31710@psf.upfronthosting.co.za>
Message-ID: <1548647018.06.0.552929831855.issue31710@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yen at chyen.cc>:


----------
nosy:  -yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31710>
_______________________________________

From report at bugs.python.org  Sun Jan 27 23:12:05 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 04:12:05 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548648725.8.0.336331301582.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

I'm using Github web interface.
I did these steps:
- Forked cpython and changed the pdb.rst file.
- Created a branch called "fix-issue-35835".
- Made the commit with description "Add reference to Python 3.7 new function breakpoint()".
- Made the pull request with title "bpo-35835: Add reference to Python 3.7 new function breakpoint()".
- Made the merge commit.

Now I have an option to delete the fix-issue-35835 branch.
Should I do it? I read some Git tutorials and I think I can, but can you confirm?

After that, how should I procede to create the patch?

Thanks,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 23:40:12 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 04:40:12 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548650412.47.0.593397222761.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

On the previous message I forgot to mention that the pull request was made in my fork, not the cpython repo.
Should I made a PR in the cpython repo at this point?

Thanks,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 23:44:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 28 Jan 2019 04:44:38 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548650678.77.0.290512215771.issue35835@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@jcrmatos yes, you should be making a PR to CPython repo's master branch since GitHub PRs are accepted. I hope also need to sign the CLA for your contribution to get merged though it's a documentation fix.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Sun Jan 27 23:47:43 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 04:47:43 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548650863.1.0.534210955691.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

Yes, I signed the CLA and now I have to wait at least 1 business day.
So I will wait for that confirmation before making the PR to the CPython repo.

Thanks,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 00:57:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Jan 2019 05:57:47 +0000
Subject: [issue35832] Installation error
In-Reply-To: <1548505296.29.0.442399484637.issue35832@roundup.psfhosted.org>
Message-ID: <1548655067.68.0.602440861747.issue35832@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks. You should have some more log files - I'm particularly interested in the one with "3.7.2" and "core_JustForMe" in the filename, as that is the one that failed.

Also, did you notice that you have 64-bit 3.7.0 and 32-bit 3.7.2? Is that deliberate? You can find the 64-bit version at https://www.python.org/downloads/release/python-372/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35832>
_______________________________________

From report at bugs.python.org  Mon Jan 28 01:54:16 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2019 06:54:16 +0000
Subject: [issue35839] Suggestion: Ignore sys.modules entries with no __spec__
 attribute in find_spec
Message-ID: <1548658454.23.0.545832854699.issue35839@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

(Alternate proposal inspired by the discussions in #35806 and #35791)

Currently, a sys.modules entry with no __spec__ attribute will prevent importlib.util.find_spec() from locating the module, requiring the following workaround:

   def find_spec_bypassing_module_cache(modname):
       _missing = object()
       module = sys.modules.pop(modname, _missing)
       try:
           spec = importlib.util.find_spec(modname)
       finally:
           if module is not _missing:
               sys.modules[modname] = module

The big downside of that approach is that it requires mutation of global state in order to work.

One of the easiest ways for this situation to be encountered is with code that replaces itself in sys.modules as a side effect of import, and doesn't bind __spec__ on the new object to the original module __spec__.

While we could take the hard line that all modules doing that need to transfer the attribute in order to be properly compatible with find_spec, I think there's a more pragmatic path we can take by differentiating between "__spec__ attribute doesn't exist" and "__spec__ attribute exists, but is None".

"__spec__ attribute doesn't exist" would be handled by find_spec as "Ignore the sys.modules entry entirely, and run the same search that would be run if the cache lookup had failed". This will then implicitly handle cases where a module replaces its own sys.modules entry.

By contrast, "__spec__ attribute is set to None" would be a true negative cache entry that indicated "this is a synthetic module that cannot be directly introspected or reloaded".

----------
components: Library (Lib)
messages: 334446
nosy: brett.cannon, eric.snow, ncoghlan, ronaldoussoren
priority: normal
severity: normal
status: open
title: Suggestion: Ignore sys.modules entries with no __spec__ attribute in find_spec
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35839>
_______________________________________

From report at bugs.python.org  Mon Jan 28 01:56:23 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2019 06:56:23 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548177402.52.0.471302677604.issue35806@roundup.psfhosted.org>
Message-ID: <1548658583.85.0.0219751404334.issue35806@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

OK, I've filed #35839 to propose falling back to a regular search when the __spec__ attribute is missing, while treating "obj.__spec__ is None" as a true negative cache entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Mon Jan 28 01:58:55 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2019 06:58:55 +0000
Subject: [issue35839] Suggestion: Ignore sys.modules entries with no __spec__
 attribute in find_spec
In-Reply-To: <1548658454.23.0.545832854699.issue35839@roundup.psfhosted.org>
Message-ID: <1548658735.93.0.221944199878.issue35839@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd also suggest that we emit ImportWarning when taking the fallback path, since we really would prefer that sys.modules entries either have a valid __spec__, or else explicitly set `__spec__ = None`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35839>
_______________________________________

From report at bugs.python.org  Mon Jan 28 02:00:42 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2019 07:00:42 +0000
Subject: [issue35791] Unexpected exception with importlib
In-Reply-To: <1548005903.93.0.648072616722.issue35791@roundup.psfhosted.org>
Message-ID: <1548658842.62.0.279380081126.issue35791@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

#35839 is follow-up enhancement request, proposing that we tweak the sys.modules handling in find_spec to ignore cache entries that don't have a __spec__ attribute set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35791>
_______________________________________

From report at bugs.python.org  Mon Jan 28 02:54:06 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Mon, 28 Jan 2019 07:54:06 +0000
Subject: [issue35840] Control flow inconsistency on closed asyncio stream
Message-ID: <1548662045.39.0.770532095049.issue35840@roundup.psfhosted.org>


New submission from Marc Schlaich <marc.schlaich at googlemail.com>:

After closing a StreamWriter the `StreamReaderProtocol.connection_lost` on the other end is not getting called. In this case the StreamReader is at EOF but calling write/drain does not raise any Exception (and sending data to Nirvana). 

I would expect that StreamWriter.is_closing returns True after the close and calling write/drain raises immediately and not just after the second call. Please see attached example. I see the same behavior with Proactor and Selector event loop on Windows.

Maybe this is expected behavior. But in this case it is completely undocumented. Should there be a check for `StreamReader.at_eof` (and maybe `StreamReader.exception`) before writing to the StreamWriter?

This might be related to bpo-34176.

----------
components: asyncio
files: tcp_test.py
messages: 334450
nosy: asvetlov, schlamar, yselivanov
priority: normal
severity: normal
status: open
title: Control flow inconsistency on closed asyncio stream
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48082/tcp_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35840>
_______________________________________

From report at bugs.python.org  Mon Jan 28 03:22:21 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 28 Jan 2019 08:22:21 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1548663741.22.0.968364374064.issue10915@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A more recent discussion of this on python-dev: https://mail.python.org/pipermail/python-dev/2019-January/156095.html

The situation there appears to be a case of "Hand off an OS level thread from the creating interpreter to a different subinterpreter. As far as I can tell, calling GILState_Ensure in such a thread will still acquire the GIL of the creating interpreter (or something equally nonsensical)."

It's a single-threaded application using subinterpreters, but all the callbacks from the NumPy code end up hitting the original interpreter that initialised the thread local state in the main thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Jan 28 03:56:57 2019
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 28 Jan 2019 08:56:57 +0000
Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict
In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org>
Message-ID: <1548665817.91.0.808527734469.issue35838@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

I think it's easy to solve this particular case.
But there may be some other cases.

optionxform must be idempotent?  If so, this is document issue.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35838>
_______________________________________

From report at bugs.python.org  Mon Jan 28 04:02:20 2019
From: report at bugs.python.org (Marc Schlaich)
Date: Mon, 28 Jan 2019 09:02:20 +0000
Subject: [issue35840] Control flow inconsistency on closed asyncio stream
In-Reply-To: <1548662045.39.0.770532095049.issue35840@roundup.psfhosted.org>
Message-ID: <1548666140.95.0.622862149497.issue35840@roundup.psfhosted.org>


Marc Schlaich <marc.schlaich at googlemail.com> added the comment:

After having a closer look I fear that there isn't a correct implementation for half closed sockets and returning True from eof_received results in a fundamentally broken state machine.

I'm not sure if a selector implementation can handle half closed sockets, at least I'm pretty sure that this is not supported on Windows (https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35840>
_______________________________________

From report at bugs.python.org  Mon Jan 28 04:11:08 2019
From: report at bugs.python.org (David Heiberg)
Date: Mon, 28 Jan 2019 09:11:08 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1548666668.27.0.637577645893.issue35701@roundup.psfhosted.org>


David Heiberg <dhdavvie at gmail.com> added the comment:

I have submitted a PR for the documentation. Hopefully this is enough to resolve the issue and close.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 28 04:31:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Jan 2019 09:31:29 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1548667889.04.0.370899797191.issue35701@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset ea446409cd5f1364beafd5e5255da6799993f285 by Victor Stinner (David H) in branch 'master':
bpo-35701: Update doc for UUID weak referencing (GH-11621)
https://github.com/python/cpython/commit/ea446409cd5f1364beafd5e5255da6799993f285


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 28 04:32:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Jan 2019 09:32:53 +0000
Subject: [issue35701] [uuid] 3.8 breaks weak references for UUIDs
In-Reply-To: <1547055424.22.0.868480715167.issue35701@roundup.psfhosted.org>
Message-ID: <1548667973.38.0.276941263478.issue35701@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I merged the doc change. I understand that the issue can now be closed, thanks to everyone who helped here!

----------
priority: release blocker -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35701>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:04:53 2019
From: report at bugs.python.org (kellerfuchs)
Date: Mon, 28 Jan 2019 11:04:53 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548673493.92.0.336102035504.issue35431@roundup.psfhosted.org>


kellerfuchs <kellerfuchs at hashbang.sh> added the comment:

Hi everyone,

Sorry for the lack of reply, I severely underestimated how exhausting the holiday season would be.
Catching up with the comments right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:07:29 2019
From: report at bugs.python.org (kellerfuchs)
Date: Mon, 28 Jan 2019 11:07:29 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548673649.78.0.389394937917.issue35431@roundup.psfhosted.org>


kellerfuchs <kellerfuchs at hashbang.sh> added the comment:

> Start with an initial patch that implements this simplest possible implementation, accompanied by clean documentation and thorough testing.
>
> Once everyone has agreed on the API (i.e. calling it "comb()", how to handle various input datatypes, and handling of corner cases), and the patch is applied, only then turn to a second pass for optimizations

+1 from me on that.

@Yash: Thanks a bunch for starting on the implementation.  I will have a look shortly  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:39:12 2019
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 28 Jan 2019 11:39:12 +0000
Subject: [issue35822] _queue _queuemodule.c is missing inside the Setup file
In-Reply-To: <1548374932.46.0.67529287669.issue35822@roundup.psfhosted.org>
Message-ID: <1548675552.19.0.694803580972.issue35822@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

_queue is normal extension module, not builtin module.
In my environment:

>>> import _queue
>>> _queue.__file__
'/usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so'

It seems your environment is somewhat broken.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35822>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:48:41 2019
From: report at bugs.python.org (kellerfuchs)
Date: Mon, 28 Jan 2019 11:48:41 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548676121.7.0.790455104605.issue35431@roundup.psfhosted.org>


kellerfuchs <kellerfuchs at hashbang.sh> added the comment:

So, I rebased Yash's and my branches, and merged them together.  The result is still in PR#11018.

This involved a few changes, which seem to reflect the consensus here:
- raise ValueError if k>n ;
- rename the function to math.combinations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:51:59 2019
From: report at bugs.python.org (BTaskaya)
Date: Mon, 28 Jan 2019 11:51:59 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1548676319.31.0.848261401822.issue35808@roundup.psfhosted.org>


Change by BTaskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35808>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:53:28 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 28 Jan 2019 11:53:28 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1548676408.88.0.33325488259.issue10915@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Jan 28 06:55:34 2019
From: report at bugs.python.org (kellerfuchs)
Date: Mon, 28 Jan 2019 11:55:34 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548676534.53.0.612493989957.issue35431@roundup.psfhosted.org>


kellerfuchs <kellerfuchs at hashbang.sh> added the comment:

@Raymond Hettinger
> Let's name this comb() instead of binomial() please (as requested by me, Mark, and Tim).

(Replying here to keep the discussion in a single place.)

As far as I can tell from the discussions here, Steven and you stated a preference for the shortened names, and that's it.
There was also no reply to my comment about `comb` being confusing (due to the collision with an English word).

Since there was, however, pretty clear agreement on calling it after combinations (shortened or not) rather than binomial(), I went with this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 07:32:10 2019
From: report at bugs.python.org (Tommy Rowland)
Date: Mon, 28 Jan 2019 12:32:10 +0000
Subject: [issue35841] Datetime strftime() does not return correct week numbers
 for 2019
Message-ID: <1548678729.34.0.0402959484409.issue35841@roundup.psfhosted.org>


New submission from Tommy Rowland <thomasrowland1 at googlemail.com>:

This relates to the calculation of the week number from a given datetime, when calling the strftime method. If you call isocalendar() on the datetime.datetime object for the date ?2018-12-31?, the week number returned is 1, which is correct. This is the same when checking the week attribute for the pandas timestamp equivalent. However, when you call strftime on this object (either datetime or timestamp), passing the ?%W? offset string, it returns 53, and then returns 00 for the remainder of the week. It seems that the rest of the weeks in 2019 are out by 1 when returned using this function. This issue seems to be present with the strptime function also.

----------
components: Extension Modules, Windows
files: Python Datetime Issue.JPG
messages: 334462
nosy: paul.moore, steve.dower, tim.golden, tr12, zach.ware
priority: normal
severity: normal
status: open
title: Datetime strftime() does not return correct week numbers for 2019
type: behavior
versions: Python 2.7, Python 3.6
Added file: https://bugs.python.org/file48083/Python Datetime Issue.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35841>
_______________________________________

From report at bugs.python.org  Mon Jan 28 07:56:18 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 28 Jan 2019 12:56:18 +0000
Subject: [issue35841] Datetime strftime() does not return correct week numbers
 for 2019
In-Reply-To: <1548678729.34.0.0402959484409.issue35841@roundup.psfhosted.org>
Message-ID: <1548680178.16.0.0817425987983.issue35841@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Possibly related to 35535.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35841>
_______________________________________

From report at bugs.python.org  Mon Jan 28 08:14:32 2019
From: report at bugs.python.org (Michael Jacob)
Date: Mon, 28 Jan 2019 13:14:32 +0000
Subject: [issue27749] multprocessing errors on Windows: WriteFile() argument 1
 must be int, not None; OSError: handle is closed
In-Reply-To: <1471028370.6.0.516756873542.issue27749@psf.upfronthosting.co.za>
Message-ID: <1548681272.5.0.0309820427716.issue27749@roundup.psfhosted.org>


Michael Jacob <jacob at j-e-b.net> added the comment:

Does this ticket track the issue in its title or the native crash? If it's the latter, is there a new ticket for the None _handle or shall I create one?

----------
nosy: +Michael Jacob2
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27749>
_______________________________________

From report at bugs.python.org  Mon Jan 28 08:36:10 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 28 Jan 2019 13:36:10 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548682570.67.0.963329567646.issue35835@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@jcrmatos - Sounds like you're on the right track.  :-)

Based on the steps you've outlined, I just had one question.  Were you able to rebuild the docs locally in order to see how your changes looked?  Here's the direct link to building the docs:
https://devguide.python.org/documenting/#building-doc

In section 7.5.1, it mentions Windows, so you should be able to follow that.  Although, I've had to use `./make html` in Powershell, so if `make html` doesn't work, then try that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 08:38:06 2019
From: report at bugs.python.org (rongxin)
Date: Mon, 28 Jan 2019 13:38:06 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
Message-ID: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>


New submission from rongxin <se.wu.rongxin at gmail.com>:

In the source file mmapmodule.c, the function mmap_subscript contains a potential bug about the use of uninitialised variable.


mmapmodule.c:

764 static PyObject *
765 mmap_subscript(mmap_object *self, PyObject *item)
766 {
...
    else if (PySlice_Check(item)) {
782        Py_ssize_t start, stop, step, slicelen;
783
784        if (PySlice_Unpack(item, &start, &stop, &step) < 0) {
785            return NULL;
786        }
787        slicelen = PySlice_AdjustIndices(self->size, &start, &stop, step);
     ...

In Line 782 of the file mmapmodule.c, the variable stop is not initialised and will be passed to the function PySlice_Unpack as the third parameter. Inside the function, it is likely that stop is not initialised. Please see the following code. 

sliceobject.c:
196 int
197 PySlice_Unpack(PyObject *_r,
198               Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step)
199 {
...
231    if (r->stop == Py_None) {
232        *stop = *step < 0 ? PY_SSIZE_T_MIN : PY_SSIZE_T_MAX;
233    }
234    else {
235        if (!_PyEval_SliceIndex(r->stop, stop)) return -1;
236    }


The third parameter **stop** may be changed at line 232 or 235. However, at Line 235, it is still likely that **stop** is not initialised at Line 235 where **stop** is passed as the second parameter. Note that, at Line 235, we only know r->stop!=Py_None. The following is the code snippet of the function _PyEval_SliceIndex.


ceval.c:
4718 int
4719 _PyEval_SliceIndex(PyObject *v, Py_ssize_t *pi)
4720 {
4721     if (v != Py_None) {
4722         Py_ssize_t x;
4723         if (PyIndex_Check(v)) {
4724             x = PyNumber_AsSsize_t(v, NULL);
4725             if (x == -1 && PyErr_Occurred())
4726                 return 0;
4727         }
4728         else {
4729             PyErr_SetString(PyExc_TypeError,
4730                             "slice indices must be integers or "
4731                             "None or have an __index__ method");
4732             return 0;
4733         }
4734         *pi = x;
4735     }
4736    return 1;
4737 }

As we can see, it is likely that when the third parameter v can be NULL, then the function _PyEval_SliceIndex will return 1. In the caller function PySlice_Unpack, at Line 235, the condition **if (!_PyEval_SliceIndex(r->stop, stop))** is not satisfied, and thus it will go to Line 238 which returns 0. In the caller function mmap_subscript in the file mmapmodule.c, at Line 784, since the return value is 0, and thus the path condition **PySlice_Unpack(item, &start, &stop, &step) < 0** is not satisfied. It will continue to execute the Line 787. The uninitialised variable **stop** again will be passed to the function PySlice_AdjustIndices as the third parameter. **stop** then will be dereferenced without initialisation. Please see the following.

sliceobject.c:
241 Py_ssize_t
242 PySlice_AdjustIndices(Py_ssize_t length,
243                      Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t step)
...
260 if (*stop < 0) {
261    *stop += length;
...

----------
messages: 334466
nosy: wurongxin1987
priority: normal
severity: normal
status: open
title: A potential bug about use of uninitialised variable
type: security
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 08:54:50 2019
From: report at bugs.python.org (BTaskaya)
Date: Mon, 28 Jan 2019 13:54:50 +0000
Subject: [issue35815] Able to instantiate a subclass with abstract methods
 from __init_subclass__ of the ABC
In-Reply-To: <1548316625.2.0.852101004839.issue35815@roundup.psfhosted.org>
Message-ID: <1548683690.6.0.607989164826.issue35815@roundup.psfhosted.org>


BTaskaya <batuhanosmantaskaya at gmail.com> added the comment:

I debugged object.__new__ and i saw the subclass you are trying to initalize doesn't have proper signature of abstract classes (it returns 0 from flags & Py_TPFLAGS_IS_ABSTRACT)

However it has __abstractmethods__ entry. Currently i'm trying to find why it is happening.

Type Name: Derived
Flags: 284161 
Abstract: 1048576 
Flags & Abstract: 0

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35815>
_______________________________________

From report at bugs.python.org  Mon Jan 28 09:00:39 2019
From: report at bugs.python.org (rongxin)
Date: Mon, 28 Jan 2019 14:00:39 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548684039.7.0.945414622812.issue35842@roundup.psfhosted.org>


rongxin <se.wu.rongxin at gmail.com> added the comment:

BTW, if this bug is true, there is a similar code snippet in the same file.
mmapmodule.c:
845 static int
846 mmap_ass_subscript(mmap_object *self, PyObject *item, PyObject *value)
847 {
...
888    else if (PySlice_Check(item)) {
889        Py_ssize_t start, stop, step, slicelen;
890        Py_buffer vbuf;
891
892        if (PySlice_Unpack(item, &start, &stop, &step) < 0) {
893            return -1;
894        }
895        slicelen = PySlice_AdjustIndices(self->size, &start, &stop, step);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 09:14:45 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 14:14:45 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548684885.45.0.485270944264.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Hello,

I didn't do anything locally. I did the change and preview it on GitHub's web interface.

Has I said, I did a PR to my own fork and now I think I have to do a PR to the cpython master. Is that correct?
The PR to my own fork was required, or the commit was enough?

Now I have an option to delete the fix-issue-35835 branch.
Should I do it? I read some Git tutorials and I think I can, but can you confirm?


Thanks in advance,

JM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 09:27:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 28 Jan 2019 14:27:28 +0000
Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict
In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org>
Message-ID: <1548685648.21.0.13907746587.issue35838@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be a bug with read_dict which is used internally when a dictionary is directly assigned. In read_dict optionxform is called with key [0] to check for duplicate and the transformed value is again passed to self.set which also calls optionxform [1] causing optionxform to be applied twice. A possible fix would be to assign the transformed key to a temporary variable to check for duplicate and then pass the original key to self.set ? My patch gives correct value and no tests fail on master. I can make a PR with test for this if my analysis is correct.

This fixes the below since the key is stored correctly now. 

print(ini['section A']['key 1'])    # OK
print(ini['section A']['(key 1)'])  # Raises KeyError

I think for iterating over the section items [2] need to be used and the reported code can be written as below

for key, value in ini.items('section A'):
    print(key + ', ' + value)

[0] https://github.com/python/cpython/blob/ea446409cd5f1364beafd5e5255da6799993f285/Lib/configparser.py#L748
[1] https://github.com/python/cpython/blob/ea446409cd5f1364beafd5e5255da6799993f285/Lib/configparser.py#L903
[2] https://docs.python.org/3.8/library/configparser.html#configparser.ConfigParser.items

# sample reproducer

import io
import configparser

ini = configparser.ConfigParser()
ini.optionxform = lambda x: '(' + x + ')'
ini.read_dict({'section A': {'key 1': 'value 1'}})

inifile = io.StringIO()
ini.write(inifile)
print(inifile.getvalue())

$ ./python.exe ../backups/bpo35838_1.py
[section A]
((key 1)) = value 1

# Possible patch

$ git diff -w | cat
diff --git a/Lib/configparser.py b/Lib/configparser.py
index 79a991084b..1389f4ac08 100644
--- a/Lib/configparser.py
+++ b/Lib/configparser.py
@@ -745,13 +745,13 @@ class RawConfigParser(MutableMapping):
                     raise
             elements_added.add(section)
             for key, value in keys.items():
-                key = self.optionxform(str(key))
+                option_key = self.optionxform(str(key))
                 if value is not None:
                     value = str(value)
-                if self._strict and (section, key) in elements_added:
-                    raise DuplicateOptionError(section, key, source)
-                elements_added.add((section, key))
-                self.set(section, key, value)
+                if self._strict and (section, option_key) in elements_added:
+                    raise DuplicateOptionError(section, option_key, source)
+                elements_added.add((section, option_key))
+                self.set(section, str(key), value)

     def readfp(self, fp, filename=None):
         """Deprecated, use read_file instead."""


$ ./python.exe ../backups/bpo35838_1.py
[section A]
(key 1) = value 1

----------
nosy: +xtreak
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35838>
_______________________________________

From report at bugs.python.org  Mon Jan 28 10:09:50 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 28 Jan 2019 15:09:50 +0000
Subject: [issue31456] SimpleCookie fails to parse any cookie if an entry has
 whitespace in the name
In-Reply-To: <1505328383.45.0.696771060303.issue31456@psf.upfronthosting.co.za>
Message-ID: <1548688190.1.0.157166687463.issue31456@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31456>
_______________________________________

From report at bugs.python.org  Mon Jan 28 10:10:50 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 28 Jan 2019 15:10:50 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548688250.82.0.202132543689.issue35842@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Your analysis would be (almost) correct if a slice object could have a stop value of NULL. It's wrong in that the error would be a NULL deference, not a silent use of an uninitialized value, but it would be a bug. In your scenario where v == NULL, it would pass the test for v != Py_None, then call PyIndex_Check(v), and since the macro doesn't check for the passed value being NULL, it would perform a NULL deference.

But even that's not possible; PySlice_New (which is ultimately responsible for all slice construction) explicitly replaces any argument of NULL with Py_None, so there is no such thing as a slice with *any* value being NULL.

So since r->stop is definitely non-NULL, either:

1. It's None, PySlice_Unpack line 232 executes, and stop is initialized

or

2. It's non-None, _PyEval_SliceIndex is called with a v that is definitely not None and non-NULL, so it always enters the `if (v != Py_None) {` block, and either it received a value index integer, in which case it initializes *pi (aka stop) and returns 1 (success), or returns 0 (failure), which means stop is never used.

The only way you could trigger your bug is to make a slice with an actual NULL for its stop value (and as noted, the bug would be a NULL dereference in PyIndex_Check, not a use of an uninitialized value, because v != Py_None would return true for v == NULL), which is only possible through intentionally misusing PySliceObject (reaching in and tweaking values of the struct directly). And if you can do that, you're already a C extension (or ctypes code) and can crash the interpreter any number of ways without resorting to this level of complexity.

----------
nosy: +josh.r
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 10:19:02 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 28 Jan 2019 15:19:02 +0000
Subject: [issue31456] SimpleCookie fails to parse any cookie if an entry has
 whitespace in the name
In-Reply-To: <1505328383.45.0.696771060303.issue31456@psf.upfronthosting.co.za>
Message-ID: <1548688742.3.0.160387068028.issue31456@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

It may be relevant: Ruby accept whitespaces in the name of the morsel:

?  ~ irb
irb(main):002:0> require "cgi"
=> true
irb(main):003:0> CGI::Cookie::parse "ASDF=stuff; ASDF space=more stuff"
=> {"ASDF"=>#<CGI::Cookie: "ASDF=stuff; path=">, "ASDF space"=>#<CGI::Cookie: "ASDF space=more+stuff; path=">}
irb(main):004:0>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31456>
_______________________________________

From report at bugs.python.org  Mon Jan 28 10:22:50 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 28 Jan 2019 15:22:50 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548688970.37.0.679693187445.issue35835@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

As Karthikeyan said, you do need to open a PR against the CPython master.  I'm not a Git expert, but this page (section 3.3) discusses the steps to open that PR:
https://devguide.python.org/pullrequest/

Those are the steps I follow and it's a good write-up so there's not much I can add to it.  I don't think the PR on your own fork was required.  It doesn't usually ask to delete the branch until the PR against CPython master has been merged (which is the last step in section 3.3), but since you merged against your own fork, that's probably why it's asking now.  Do you still get an option to create a PR against CPython master using your branch as per this part of section 3.3?

> Finally go on https://github.com/<your-username>/cpython: you will see a box with the branch you just pushed and a green button that allows you to create a pull request against the official CPython repository.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 10:26:01 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 28 Jan 2019 15:26:01 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548689161.51.0.77240919879.issue35431@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Steven: I'm assuming Brett rearranged the title to put emphasis on the new function and to place it earlier in the title. Especially important if you're reading e-mails with the old subject on an e-mail client with limited subject preview lengths, you end up seeing something like:

"The math module should provide a function for computing..."

rather than the more useful:

"Add a function for computing binomial coefficients to t..."

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 10:42:07 2019
From: report at bugs.python.org (rongxin)
Date: Mon, 28 Jan 2019 15:42:07 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548690127.97.0.710382333294.issue35842@roundup.psfhosted.org>


rongxin <se.wu.rongxin at gmail.com> added the comment:

Hi, Josh Rosenberg. As you mentioned PySlice_New (which is ultimately responsible for all slice construction) explicitly replaces any argument of NULL with Py_None, I am not sure whether this is always true r->stop cannot be NULL. I detected this bug using the code of Python 2.7.15. The implementation of _PyEval_SliceIndex is shown as followings. Please read the comments of this functions, and it is possible that v would be NULL. I wonder whether your assumption r->stop cannot be NULL will be broken in Python 2.7.15



/* Extract a slice index from a PyInt or PyLong or an object with the
   nb_index slot defined, and store in *pi.
   Silently reduce values larger than PY_SSIZE_T_MAX to PY_SSIZE_T_MAX,
   and silently boost values less than PY_SSIZE_T_MIN to PY_SSIZE_T_MIN.
   Return 0 on error, 1 on success.
*/
/* Note:  If v is NULL, return success without storing into *pi.  This
   is because_PyEval_SliceIndex() is called by apply_slice(), which can be
   called by the SLICE opcode with v and/or w equal to NULL.
*/
int
_PyEval_SliceIndex(PyObject *v, Py_ssize_t *pi)
{
    if (v != NULL && v != Py_None) {
        Py_ssize_t x;
        if (PyInt_Check(v)) {
            /* XXX(nnorwitz): I think PyInt_AS_LONG is correct,
               however, it looks like it should be AsSsize_t.
               There should be a comment here explaining why.
            */
            x = PyInt_AS_LONG(v);
        }
        else if (PyIndex_Check(v)) {
            x = PyNumber_AsSsize_t(v, NULL);
            if (x == -1 && PyErr_Occurred())
                return 0;
        }
        else {
            PyErr_SetString(PyExc_TypeError,
                            "slice indices must be integers or "
                            "None or have an __index__ method");
            return 0;
        }
        *pi = x;
    }
    return 1;
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 11:00:38 2019
From: report at bugs.python.org (rongxin)
Date: Mon, 28 Jan 2019 16:00:38 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548691238.99.0.168351890814.issue35842@roundup.psfhosted.org>


rongxin <se.wu.rongxin at gmail.com> added the comment:

I think this bug is valid at least in Python 2.7, as I mentioned the implementation of _PyEval_SliceIndex is different from the one in Python 3.8. The condition " if (v != NULL && v != Py_None) " will bypass the NULL pointer dereference. Would you please check this again? Thanks.

----------
status: closed -> open
versions: +Python 2.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 11:01:13 2019
From: report at bugs.python.org (rongxin)
Date: Mon, 28 Jan 2019 16:01:13 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548691273.98.0.753828764584.issue35842@roundup.psfhosted.org>


Change by rongxin <se.wu.rongxin at gmail.com>:


----------
resolution: not a bug -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 11:06:38 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Mon, 28 Jan 2019 16:06:38 +0000
Subject: [issue35535] time.strptime() unexpectedly gives the same result for
 %U and %W for 2018
In-Reply-To: <1545224060.23.0.788709270274.issue35535@psf.upfronthosting.co.za>
Message-ID: <1548691598.44.0.60754351002.issue35535@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

I try to reproduce and confirm the xtreak example, and how xtreak and p-ganssle explain, I think that the behavoir is correct according the documentation. 

I would like to know why there is difference between 2.3.4 (Paul Keating example) and cpython master

----------
nosy: +eamanu
Added file: https://bugs.python.org/file48084/test.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35535>
_______________________________________

From report at bugs.python.org  Mon Jan 28 11:17:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 28 Jan 2019 16:17:22 +0000
Subject: [issue32834] test_gdb fails with Posix locale in 3.7
In-Reply-To: <1518464593.71.0.467229070634.issue32834@psf.upfronthosting.co.za>
Message-ID: <1548692242.05.0.953566351223.issue32834@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This passes on my Ubuntu box and fails for the commit before issue34537 with the stack trace as per the original report.

karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ LC_ALL=C ./python -We -m test -vuall -m test_strings test_gdb
== CPython 3.8.0a0 (heads/master:ea446409cd, Jan 28 2019, 15:07:17) [GCC 5.4.0 20160609]
== Linux-4.4.0-127-generic-x86_64-with-glibc2.17 little-endian
== cwd: /home/karthi/cpython/build/test_python_19425
== CPU count: 1
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.89 [1/1] test_gdb
GDB version 8.2:
    GNU gdb (Ubuntu 8.2-0ubuntu1~16.04.1) 8.2
    Copyright (C) 2018 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.
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings ... ok

----------------------------------------------------------------------

Ran 1 test in 3.080s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 3 sec 571 ms
Tests result: SUCCESS
karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ git checkout 7279b5125e7c5d84a473d250b27d353cb7f6628e~1 
[...]
karthi at ubuntu-s-1vcpu-1gb-blr1-01:~/cpython$ LC_ALL=C ./python -We -m test -vuall -m test_strings test_gdb
== CPython 3.8.0a0 (heads/master:ea446409cd, Jan 28 2019, 15:07:17) [GCC 5.4.0 20160609]
== Linux-4.4.0-127-generic-x86_64-with-glibc2.17 little-endian
== cwd: /home/karthi/cpython/build/test_python_19484
== CPU count: 1
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.91 [1/1] test_gdb
GDB version 8.2:
    GNU gdb (Ubuntu 8.2-0ubuntu1~16.04.1) 8.2
    Copyright (C) 2018 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.
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings ... FAIL

======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/karthi/cpython/Lib/test/test_gdb.py", line 340, in test_strings
    check_repr('\u2620')
  File "/home/karthi/cpython/Lib/test/test_gdb.py", line 332, in check_repr
    self.assertGdbRepr(text)
  File "/home/karthi/cpython/Lib/test/test_gdb.py", line 278, in assertGdbRepr
    self.assertEqual(gdb_repr, exp_repr,
AssertionError: "'\\u2620'" != "'?'"
- '\u2620'
+ '?'
 : "'\\u2620'" did not equal expected "'?'"; full output was:
Breakpoint 1 at 0x5f9036: file Python/bltinmodule.c, line 1178.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, builtin_id (self=self at entry=, v='\u2620') at Python/bltinmodule.c:1178
1178
#0  builtin_id (self=, v='\u2620') at Python/bltinmodule.c:1178


----------------------------------------------------------------------

Ran 1 test in 1.979s

FAILED (failures=1)
test test_gdb failed
test_gdb failed

== Tests result: FAILURE ==

1 test failed:
    test_gdb

Total duration: 2 sec 576 ms
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32834>
_______________________________________

From report at bugs.python.org  Mon Jan 28 11:43:55 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 28 Jan 2019 16:43:55 +0000
Subject: [issue35841] Datetime strftime() does not return correct week numbers
 for 2019
In-Reply-To: <1548678729.34.0.0402959484409.issue35841@roundup.psfhosted.org>
Message-ID: <1548693835.35.0.211782016392.issue35841@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think this is not a bug. bpo-35535 is probably also intended behavior, but that is less certain.

The misunderstanding here is that %W does not give you the ISO week number, from the documentation:

    %W: Week number of the year (Monday as the first day of the week) as a decimal number.
        All days in a new year preceding the first Monday are considered to be in week 0.


If you want the ISO week number, I think you need %V, which *is* the ISO week:

    >>> datetime(2018, 12, 31).strftime("%V %W")                                                                                            
    '01 53'

I believe this ticket can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35841>
_______________________________________

From report at bugs.python.org  Mon Jan 28 11:53:11 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 28 Jan 2019 16:53:11 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548694391.77.0.29119544903.issue35707@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

You've got a reference leak in your __index__ based paths. PyNumber_Index is returning a new reference (either to the existing obj, or a new one, if the existing obj isn't already an int). You never release this reference. Simplest fix is to make intobj top level, initialized to NULL, and Py_XDECREF it along the convert_from_int code path (you can't DECREF it in the index specific path because it needs to survive past the goto, since it's replacing obj).

I'm also mildly concerned by how duplicative the code becomes post-patch. If it's not a major performance hit (don't think it is; not even sure the API is even used anymore), perhaps just implement _PyTime_ObjectToTime_t as a wrapper for _PyTime_ObjectToDenominator (with a denominator of 2, so rounding simplifies to just 0 == round down, 1 == round up)?

Example:

int
_PyTime_ObjectToTime_t(PyObject *obj, time_t *sec, _PyTime_round_t round)
{
    long numerator;
    if (_PyTime_ObjectToDenominator(obj, sec, &numerator, 2, round) == 0) {
       if (numerator) {
           if (*sec == _Py_IntegralTypeMax(time_t)) {
               error_time_t_overflow();
               return -1;
           }
           ++*sec;
       }
       return 0;
    }
    return -1;
}

Sorry for not commenting on GitHub, but my work computer has a broken Firefox that GitHub no longer supports properly.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 28 12:22:16 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 28 Jan 2019 17:22:16 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548696136.86.0.204661866865.issue35842@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Yes, the 2.7 version of _PyEval_SliceIndex would bypass the NULL pointer dereference, so *if* you could make a slice with a NULL stop value, you could trigger a read from uninitialized stack memory, rather than dying due to a NULL pointer dereference.

But just like Python 3, 2.7's PySlice_New explicitly replaces all NULLs with None ( https://github.com/python/cpython/blob/2.7/Objects/sliceobject.c#L60 ), so such a slice cannot exist.

Since you can't make a slice with a NULL value through any supported API, and any unsupported means of doing this means you already have the ability to execute arbitrary code (and do far worse things that just trigger a read from an uninitialized C stack value), the fact that _PyEval_SliceIndex returns success for v == NULL is irrelevant; v isn't NULL in any code path aside of the specific one documented (the SLICE opcode, gone in Py3, which can pass in NULL, but uses defaults of 0 and PY_SSIZE_T_MAX for low and high respectively, so the silent success just leaves the reasonable defaults set), because all other uses use slice objects as the source for v, and they cannot have NULL values.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 12:53:30 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Mon, 28 Jan 2019 17:53:30 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1548698010.43.0.309893643832.issue35808@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hello!

I can help if you consider it appropriate :-)

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35808>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:01:22 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 28 Jan 2019 18:01:22 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548698482.39.0.646046204431.issue35842@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

One additional note, just in case you're wondering. slice explicitly does not set Py_TPFLAGS_BASETYPE (in either Py2 or Py3), so you can't make a subclass of slice with NULLable fields by accident (you'll get a TypeError the moment you try to define it). There is one, and only one, slice type, and its fields are never NULL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:03:11 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 28 Jan 2019 18:03:11 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
Message-ID: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

For instance:


# `a` is an empty directory, a PEP 420 namespace package

>>> import importlib.util
>>> importlib.util.find_spec('a')
ModuleSpec(name='a', loader=None, origin='namespace', submodule_search_locations=_NamespacePath(['/tmp/x/a']))


https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.origin

> ...  Normally ?origin? should be set, but it may be None (the default) which indicates it is unspecified (e.g. for namespace packages).

above the `origin` is `'namespace'`

https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations

> List of strings for where to find submodules, if a package (None otherwise).

However the `_NamespacePath` object above is not indexable:

>>> x = importlib.util.find_spec('a').submodule_search_locations
>>> x[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '_NamespacePath' object does not support indexing


I can work around however with:

>>> next(iter(x))
'/tmp/x/a'


======================


so I guess a few things can/should come out of this:

- Document the `'namespace'` origin
- Document that `submodule_search_paths` is a Sized[str] instead
- Add `__getitem__` to `_NamespacePath` such that it implements the full `Sized` protocol

----------
assignee: docs at python
components: Documentation
messages: 334484
nosy: Anthony Sottile, docs at python
priority: normal
severity: normal
status: open
title: importlib.util docs for namespace packages innaccurate
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:07:26 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 28 Jan 2019 18:07:26 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1548698846.5.0.764327842913.issue35843@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

Hmmm, it appears this was changed in python3.7 to have `None` for the origin instead of `'namespace'` -- however the `submodule_search_locations` is still not indexable:



>>> importlib.util.find_spec('a')
ModuleSpec(name='a', loader=None, submodule_search_locations=_NamespacePath(['/tmp/x/a']))
>>> importlib.util.find_spec('a').origin
>>> spec = importlib.util.find_spec('a')
>>> spec.submodule_search_locations
_NamespacePath(['/tmp/x/a'])
>>> spec.submodule_search_locations[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '_NamespacePath' object does not support indexing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:14:58 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 28 Jan 2019 18:14:58 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548699298.48.0.641639584005.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I'm also mildly concerned by how duplicative the code becomes post-patch.

I know, that's why I added that comment on GitHub.

> perhaps just implement _PyTime_ObjectToTime_t as a wrapper for _PyTime_ObjectToDenominator

Sure, but will that increase the chances of PR 11636 being accepted? Unless a core developer who is willing to merge that PR asks me that, I'd rather not add extra complications to that PR. (to be clear: I mean no offense, it's just that getting a CPython PR accepted is hard)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:23:58 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 28 Jan 2019 18:23:58 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1548699838.52.0.219415743809.issue35843@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +11529
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:24:03 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 28 Jan 2019 18:24:03 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1548699843.8.0.239953894724.issue35843@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch
pull_requests: +11529, 11530
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:24:09 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 28 Jan 2019 18:24:09 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1548699849.64.0.223864877037.issue35843@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch, patch, patch
pull_requests: +11529, 11530, 11531
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:34:19 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 18:34:19 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548700459.05.0.699872420401.issue35835@roundup.psfhosted.org>


Change by jcrmatos <jcrmatos at gmail.com>:


----------
keywords: +patch
pull_requests: +11532
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:34:28 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 18:34:28 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548700468.38.0.215319084934.issue35835@roundup.psfhosted.org>


Change by jcrmatos <jcrmatos at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11532, 11533
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:34:37 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 18:34:37 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548700477.51.0.17866603686.issue35835@roundup.psfhosted.org>


Change by jcrmatos <jcrmatos at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11532, 11533, 11534
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:34:45 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 18:34:45 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548700485.8.0.632116818658.issue35835@roundup.psfhosted.org>


Change by jcrmatos <jcrmatos at gmail.com>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11532, 11533, 11534, 11535
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 13:51:52 2019
From: report at bugs.python.org (jcrmatos)
Date: Mon, 28 Jan 2019 18:51:52 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548701512.89.0.0257729706337.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

I deleted the fork and started again.
This time I didn't PR to my own fork but to cpython master.
It is now waiting for review, "skip news" labeling and CLA (I'm still waiting on my request).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Mon Jan 28 14:32:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 28 Jan 2019 19:32:39 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1548703959.05.0.733456460385.issue35843@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Mon Jan 28 14:57:59 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Jan 2019 19:57:59 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1548705479.74.0.290630540504.issue35808@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@eamanu, feel free to submit a PR. I won't be available to guide you through the steps; there are other forums e.g. Zulip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35808>
_______________________________________

From report at bugs.python.org  Mon Jan 28 15:00:47 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 28 Jan 2019 20:00:47 +0000
Subject: [issue35806] typing module adds objects to sys.modules that don't
 look like modules
In-Reply-To: <1548658583.85.0.0219751404334.issue35806@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+pusu=MasNGBdzonvzkSymYKjz_qEcTaLHFU0Ei7M3Lw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35806>
_______________________________________

From report at bugs.python.org  Mon Jan 28 15:28:54 2019
From: report at bugs.python.org (Samuel Grayson)
Date: Mon, 28 Jan 2019 20:28:54 +0000
Subject: [issue35844] Calling `Multiprocessing.Queue.close()` too quickly
 causes intermittent failure (BrokenPipeError)
Message-ID: <1548707332.73.0.0560406738777.issue35844@roundup.psfhosted.org>


New submission from Samuel Grayson <sam at samgrayson.me>:

If all processes try to close the Queue immediately after someone has written to it, this causes [an error][1] (see the link for more details). Uncommenting any of the `time.sleep`s makes it work consistently again.

    import multiprocessing
    import time
    import logging
    import multiprocessing.util
    multiprocessing.util.log_to_stderr(level=logging.DEBUG)
    
    queue = multiprocessing.Queue(maxsize=10)
    
    def worker(queue):
        queue.put('abcdefghijklmnop')
    
        # "Indicate that no more data will be put on this queue by the
        # current process." --Documentation
        # time.sleep(0.01)
        queue.close()
    
    proc = multiprocessing.Process(target=worker, args=(queue,))
    proc.start()
    
    # "Indicate that no more data will be put on this queue by the current
    # process." --Documentation
    # time.sleep(0.01)
    queue.close()
    
    proc.join()

Perhaps this is because I am not understanding the documentation correctly, but in that case I would contend this is a documentation bug.

    Traceback (most recent call last):
      File "/usr/lib/python3.7/multiprocessing/queues.py", line 242, in _feed
        send_bytes(obj)
      File "/usr/lib/python3.7/multiprocessing/connection.py", line 200, in send_bytes
        self._send_bytes(m[offset:offset + size])
      File "/usr/lib/python3.7/multiprocessing/connection.py", line 404, in _send_bytes
        self._send(header + buf)
      File "/usr/lib/python3.7/multiprocessing/connection.py", line 368, in _send
        n = write(self._handle, buf)
    BrokenPipeError: [Errno 32] Broken pipe

[1]: https://stackoverflow.com/q/51680479/1078199

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 334490
nosy: charmonium, docs at python
priority: normal
severity: normal
status: open
title: Calling `Multiprocessing.Queue.close()` too quickly causes intermittent failure (BrokenPipeError)
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35844>
_______________________________________

From report at bugs.python.org  Mon Jan 28 15:51:38 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jan 2019 20:51:38 +0000
Subject: [issue35845] Can't read a F-contiguous memoryview in physical order
Message-ID: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

This request is motivated in detail here:
https://github.com/python/peps/pull/883#issuecomment-458290745

In short: in C, when you have a Py_buffer, you can directly read the memory in whatever order you want (including physical order).  It is not possible in pure Python, though.  Somewhat unintuitively, memoryview.tobytes() as well as bytes(memoryview) read bytes in *logical* order, even though it flattens the dimensions and doesn't keep the original type.  Logical order is different from physical order for Fortran-contiguous arrays.

One possible way of alleviating this would be to offer a memoryview.transpose() method, similar to the Numpy transpose() method (see https://docs.scipy.org/doc/numpy/reference/generated/numpy.ndarray.transpose.html).

One could also imagine a memoryview.to_c_contiguous() method.

Or even: a memoryview.raw_memory() method, that would 1) flatten dimensions 2) cast to 'B' format 3) keep physical order.

----------
components: Interpreter Core
messages: 334491
nosy: pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Can't read a F-contiguous memoryview in physical order
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35845>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:09:07 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jan 2019 22:09:07 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548713347.56.0.0139011889636.issue25592@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:17:02 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jan 2019 22:17:02 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548713822.36.0.976666563634.issue25592@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Though it's difficult to say for certain (distutils' option selection logic is obscure and difficult to follow), it seems that Jeroen's analysis is right.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:35:23 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Jan 2019 22:35:23 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1546624569.37.0.765100758058.issue35431@roundup.psfhosted.org>
Message-ID: <20190128223515.GC1834@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Sorry for the late reply, I missed Tim's comment when it first came 
through.

> Please resist pointless feature creep. The original report was about 
> comb(n, k) for integer n and k with 0 <= k <= n and that's all.  
> Everyone who commented appeared to agree they'd find that useful.
> 
> But nobody has said [...] that they'd find perm(n, k) USEFUL.

I'm not going to argue for binomial coefficients with negative n, but I 
find it hard to imagine anyone needing combinations without also needing 
permutations, and I didn't think it was necessary to explicitly say so.

But since you insist, I'll say so: I would find it useful to have a 
function to compute the number of permutations of n taking k at a time.

My perspective may be biased from my experience with secondary school 
maths, where they are taught together, but providing one without the 
other strikes me as weird as providing tan without sin and cos.

There are other functions from combinatorics which I personally use, 
like derangements, but I know when I'm pushing my luck :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:41:36 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Jan 2019 22:41:36 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1548676121.7.0.790455104605.issue35431@roundup.psfhosted.org>
Message-ID: <20190128224130.GD1834@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> This involved a few changes, which seem to reflect the consensus here:
> - raise ValueError if k>n ;
> - rename the function to math.combinations.

I see at least four people (myself, Raymond, Mark and Tim) giving comb 
as first choice, and I didn't see anyone give combinations as their 
first choice.

I don't object to you taking it upon yourself to go with the longer name 
(which is my second choice), but I do object to you claiming concensus 
for the change without evidence of such.

> There was also no reply to my comment about `comb` being confusing 
> (due to the collision with an English word).

To be honest, I didn't think that comment needed a reply.

Collisions between words in different knowledge domains are not unusual. 
I don't think people think that math.tan has anything to do with 
changing the colour of their skin, or math.sin is about being wicked. 
Due to their length, permutation, combination and factorial are 
frequently abbreviated to perm, comb, fact and anyone looking for those 
functions should recognise the abbreviations.

But given the precedent set by itertools and math.factorial, perhaps you 
are right and we ought to stick to the longer name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:43:30 2019
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 28 Jan 2019 22:43:30 +0000
Subject: [issue35845] Can't read a F-contiguous memoryview in physical order
In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org>
Message-ID: <1548715410.64.0.576601049016.issue35845@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Yes, it's modeled after NumPy's tobytes():

>>> x = np.array(list(range(6)), dtype="int8").reshape(2,3)
>>> x.tobytes()
b'\x00\x01\x02\x03\x04\x05'
>>> x.T.tobytes()
b'\x00\x03\x01\x04\x02\x05'
>>> 
>>> 
>>> memoryview(x).tobytes()
b'\x00\x01\x02\x03\x04\x05'
>>> memoryview(x.T).tobytes()
b'\x00\x03\x01\x04\x02\x05'


I guess the reason is that without a type it's easier to serialize the logical array by default, so you can always assume C when you read back.



NumPy also has an 'F' parameter though that flips the order:

>>> x.tobytes('F')
b'\x00\x03\x01\x04\x02\x05'

It would be possible to add this to memoryview as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35845>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:46:52 2019
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 28 Jan 2019 22:46:52 +0000
Subject: [issue35845] Can't read a F-contiguous memoryview in physical order
In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org>
Message-ID: <1548715612.63.0.607599780753.issue35845@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

raw_bytes() is also possible of course. I assume it would do nothing and just dump the memory.

Or tobytes('F') AND tobytes('raw').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35845>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:52:32 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jan 2019 22:52:32 +0000
Subject: [issue35845] Can't read a F-contiguous memoryview in physical order
In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org>
Message-ID: <1548715952.77.0.960120317133.issue35845@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, raw_memory() would avoid a copy, which is useful.

As for tobytes(), if we want to follow NumPy, we can have 'F' mean if F-contiguous, 'C' otherwise:

>>> a = np.arange(12, dtype='int8').reshape((3,4))                                                                             
>>> a.tobytes('A')                                                                                                             
b'\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b'
>>> a.tobytes('A') == a.T.tobytes('A')                                                                                         
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35845>
_______________________________________

From report at bugs.python.org  Mon Jan 28 17:53:37 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Jan 2019 22:53:37 +0000
Subject: [issue35845] Can't read a F-contiguous memoryview in physical order
In-Reply-To: <1548708697.36.0.695790780311.issue35845@roundup.psfhosted.org>
Message-ID: <1548716017.02.0.844269989138.issue35845@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry, my fingers slipped.  Let me try again:

As for tobytes(), if we want to follow NumPy, we can have 'A' mean 'F' if F-contiguous, 'C' otherwise: [...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35845>
_______________________________________

From report at bugs.python.org  Mon Jan 28 20:46:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Jan 2019 01:46:42 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548726402.8.0.700553282561.issue35431@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> But given the precedent set by itertools and math.factorial,
> perhaps you are right and we ought to stick to the longer name

I disagree.  Let's stick with comb() which is what SciPy uses.  It is tedious to write out combinations in a formula what includes other steps. Also, I really want to differentiate it from the existing combinations() in the itertools module (it is reasonably forseeable that the two will used together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Mon Jan 28 22:10:17 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Jan 2019 03:10:17 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548731417.6.0.302806020323.issue35766@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Also the tests now all pass; for now I am happy with the solution I found for the indentation error (see https://github.com/python/cpython/pull/11645#issuecomment-456627216).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Tue Jan 29 00:44:25 2019
From: report at bugs.python.org (Yash Aggarwal)
Date: Tue, 29 Jan 2019 05:44:25 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548740665.68.0.00724358702036.issue35431@roundup.psfhosted.org>


Yash Aggarwal <aggarwal.yash2011 at gmail.com> added the comment:

Agreed, comb sounds much better than combination. And using the name binomial would make it sound like something that would puke out whole binomial series rather than a single coefficient(maybe leave it for that in case is it decided to be useful in the future).

PR 11414 implements simple algorithm that performs slower than using a factorial definition for k>n/3. 
@kellerfuchs I'd prefer if we could work on this since it's conflict free and already reflects the behavior everyone agreed upon. 

Would it be better to create a separate issue for math.perm to discuss its behavior?


If the behavior of comb is satisfactory, can we start with optimizations?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Tue Jan 29 01:40:41 2019
From: report at bugs.python.org (Tim Peters)
Date: Tue, 29 Jan 2019 06:40:41 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548744041.57.0.620988521399.issue35431@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

> As far as I can tell from the discussions here, Steven
> and you stated a preference for the shortened names, and
> that's it.

Plus Mark, plus me - all backed "comb()" specifically.

> I find it hard to imagine anyone needing combinations without
> also needing permutations, and I didn't think it was necessary
< to explicitly say so.

Of course it is.  Merely saying something is possible is no reason at all to do it.  The original report didn't say anything about counting partial permutations, and so it's "feature creep" on the face of it to tack that on.

I personally have scant use for `perm()`, but have written my own `comb()` many times.  Far more often than I've written a `factorial()` and a `product()` combined, but I've written each of the latter more than twice, and a `perm()` not even once.  Especially if `prod()` (the topic of a different report) is added, the case for adding a `perm()` gets weaker (rising and falling factorials are special cases of what `prod()` does, and `perm()` is just an instance of falling factorial).

Which doesn't mean `perm()` must not be added ;-)  You're now the first to say it _would_ be useful, which is a start.  Can we get a second?

In any case, I don't want to _see_ this report get bogged down by feature creep:  `comb()` is what it was about from the start, and everyone so far has agreed `comb()` would be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Tue Jan 29 02:41:14 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 29 Jan 2019 07:41:14 +0000
Subject: [issue35821] Clarify when logging events are propagated when
 propagate is true
In-Reply-To: <1548360439.22.0.955979079327.issue35821@roundup.psfhosted.org>
Message-ID: <1548747674.25.0.102339063449.issue35821@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I'm not sure which part of what I wrote you think is inaccurate.

It's just that language can be tricky. When you said "pass to the parent logger" this might be misconstrued as some kind of call to a method of the parent logger.

Your OP says that you think "logged to this logger" means (2), but actually it means (1). Expanding with examples:

If the propagate attribute of the logger named A.B.C evaluates to true, any event logged to A.B.C via a method call such as logging.getLogger('A.B.C').error(...) will [subject to passing that logger's level and filter settings] be passed in turn to any handlers attached to loggers named A.B, A and the root logger, after first being passed to any handlers attached to A.B.C. If any logger in the chain A.B.C, A.B, A has its propagate attribute set to false, then that is the last logger whose handlers are offered the event to handle, and propagation stops at that point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35821>
_______________________________________

From report at bugs.python.org  Tue Jan 29 03:06:09 2019
From: report at bugs.python.org (Pascal Bugnion)
Date: Tue, 29 Jan 2019 08:06:09 +0000
Subject: [issue35846] Incomplete documentation for re.sub
Message-ID: <1548749168.19.0.209945761228.issue35846@roundup.psfhosted.org>


New submission from Pascal Bugnion <pascal at bugnion.org>:

The documentation for `re.sub` states that "Unknown escapes such as ``\&`` are left alone.". This is only true for escapes which are not ascii characters, as far as I can tell (c.f. source on https://github.com/python/cpython/blob/master/Lib/sre_parse.py#L1047).

Would there be value in amending that documentation to either remove that sentence or to clarify it? If so, I'm happy to submit a PR on GitHub.

----------
components: Regular Expressions
messages: 334504
nosy: ezio.melotti, mrabarnett, pbugnion
priority: normal
severity: normal
status: open
title: Incomplete documentation for re.sub
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35846>
_______________________________________

From report at bugs.python.org  Tue Jan 29 03:35:41 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Tue, 29 Jan 2019 08:35:41 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
Message-ID: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>


New submission from Andreas Schwab <schwab at linux-m68k.org>:

======================================================================
FAIL: test_pass_by_value (ctypes.test.test_structures.StructureTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/Python-3.7.2/Lib/ctypes/test/test_structures.py", line 416, in test_pass_by_value
    self.assertEqual(s.first, 0xdeadbeef)
AssertionError: 195948557 != 3735928559

----------------------------------------------------------------------

----------
components: ctypes
messages: 334505
nosy: schwab
priority: normal
severity: normal
status: open
title: RISC-V needs CTYPES_PASS_BY_REF_HACK
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 04:10:02 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 29 Jan 2019 09:10:02 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1548753002.42.0.893907982151.issue35843@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

See also #35673.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Tue Jan 29 04:18:42 2019
From: report at bugs.python.org (Steve Palmer)
Date: Tue, 29 Jan 2019 09:18:42 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
Message-ID: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>


New submission from Steve Palmer <steve at srpalmer.me.uk>:

class io.IOBase states "Even though IOBase does not declare read(), readinto(), or write() because their signatures will vary, implementations and clients should consider those methods part of the interface. Also, implementations may raise a ValueError (or UnsupportedOperation) when operations they do not support are called."  However, even though class io.TextIOBase is described as inheriting from io.IOBase, a call to readinto method returns AttributeError exception indicating no readinto attribute, inconsistent with the documentation.

----------
components: IO
messages: 334507
nosy: steverpalmer
priority: normal
severity: normal
status: open
title: readinto is not a method on io.TextIOBase
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 05:10:15 2019
From: report at bugs.python.org (Henry S. Thompson)
Date: Tue, 29 Jan 2019 10:10:15 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
 violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1548756615.09.0.777541096001.issue12731@roundup.psfhosted.org>


Henry S. Thompson <ht at inf.ed.ac.uk> added the comment:

This issue is also implicated in a failure of isalpha and friends.
Easy way to see this is to compare
>>> isalpha('?')
True
>>> isalpha('?'.lower())
False

This results from the use of a combining character to encode lower-case Turkish dotted i:
>>> len('?'.lower())
2
>>> unicodedata.category('?'.lower()[1])
'Mn'

----------
nosy: +HThompson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Tue Jan 29 05:40:57 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Tue, 29 Jan 2019 10:40:57 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
In-Reply-To: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>
Message-ID: <1548758457.65.0.242214058021.issue35847@roundup.psfhosted.org>


Change by Andreas Schwab <schwab at linux-m68k.org>:


----------
keywords: +patch
pull_requests: +11536
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 05:41:01 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Tue, 29 Jan 2019 10:41:01 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
In-Reply-To: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>
Message-ID: <1548758461.59.0.00632635103373.issue35847@roundup.psfhosted.org>


Change by Andreas Schwab <schwab at linux-m68k.org>:


----------
keywords: +patch, patch
pull_requests: +11536, 11537
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 05:41:05 2019
From: report at bugs.python.org (Andreas Schwab)
Date: Tue, 29 Jan 2019 10:41:05 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
In-Reply-To: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>
Message-ID: <1548758465.35.0.692907677364.issue35847@roundup.psfhosted.org>


Change by Andreas Schwab <schwab at linux-m68k.org>:


----------
keywords: +patch, patch, patch
pull_requests: +11536, 11537, 11538
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 06:45:58 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 29 Jan 2019 11:45:58 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1548762358.35.0.426780164067.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> You've got a reference leak in your __index__ based paths.

Thanks for pointing that out. I fixed that now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:04:18 2019
From: report at bugs.python.org (Tommy Rowland)
Date: Tue, 29 Jan 2019 12:04:18 +0000
Subject: [issue35841] Datetime strftime() does not return correct week numbers
 for 2019
In-Reply-To: <1548693835.35.0.211782016392.issue35841@roundup.psfhosted.org>
Message-ID: <CAJOYu78PbvPnW-qoJ_8S861tAkMe5vvnv_57C0diHercak1uvg@mail.gmail.com>


Tommy Rowland <thomasrowland1 at googlemail.com> added the comment:

Hi Paul,

Thank you for the clarification. I can see that %V does indeed return the
correct week number. It seems that when calling strftime, it is possible to
use this in conjunction with %y, but when calling strptime, it is not. Is
this also intended behaviour?

Best regards,

Tommy

On Mon, Jan 28, 2019 at 4:44 PM Paul Ganssle <report at bugs.python.org> wrote:

>
> Paul Ganssle <p.ganssle at gmail.com> added the comment:
>
> I think this is not a bug. bpo-35535 is probably also intended behavior,
> but that is less certain.
>
> The misunderstanding here is that %W does not give you the ISO week
> number, from the documentation:
>
>     %W: Week number of the year (Monday as the first day of the week) as a
> decimal number.
>         All days in a new year preceding the first Monday are considered
> to be in week 0.
>
>
> If you want the ISO week number, I think you need %V, which *is* the ISO
> week:
>
>     >>> datetime(2018, 12, 31).strftime("%V %W")
>
>     '01 53'
>
> I believe this ticket can be closed.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35841>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35841>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:17:45 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Tue, 29 Jan 2019 12:17:45 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548764265.89.0.218377130974.issue25592@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> it seems that Jeroen's analysis is right.

So would you be willing to merge the PR then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:24:08 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 29 Jan 2019 12:24:08 +0000
Subject: [issue35841] Datetime strftime() does not return correct week numbers
 for 2019
In-Reply-To: <1548678729.34.0.0402959484409.issue35841@roundup.psfhosted.org>
Message-ID: <1548764648.0.0.354653587878.issue35841@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

> I believe this ticket can be closed.

Yes, I think so. How you say, on 35535 there is a detailed explanation about the behavior.

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35841>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:52:13 2019
From: report at bugs.python.org (Addons Zz)
Date: Tue, 29 Jan 2019 12:52:13 +0000
Subject: [issue35849] Added thousands separators to Lib/pstats.py final report
Message-ID: <1548766331.46.0.0833286868767.issue35849@roundup.psfhosted.org>


New submission from Addons Zz <addonszz at outlook.com>:

Instead of doing:
```
         10056.0 function calls in 0.006 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
     1.0    0.002    0.002    0.006    0.006 benchmark_tests.py:121(logging_mod_log_debuglog_off)
  5000.0    0.002    0.000    0.004    0.000 F:\Python\lib\logging\__init__.py:1362(debug)
  5000.0    0.001    0.000    0.001    0.000 F:\Python\lib\logging\__init__.py:1620(isEnabledFor)
```

Do:
```
         10,056.0 function calls in 0.006 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      1.0    0.002    0.002    0.006    0.006 benchmark_tests.py:121(logging_mod_log_debuglog_off)
  5,000.0    0.002    0.000    0.004    0.000 F:\Python\lib\logging\__init__.py:1362(debug)
  5,000.0    0.001    0.000    0.001    0.000 F:\Python\lib\logging\__init__.py:1620(isEnabledFor)
```

----------
components: Library (Lib)
messages: 334513
nosy: addons_zz
priority: normal
severity: normal
status: open
title: Added thousands separators to Lib/pstats.py final report
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35849>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:52:39 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Jan 2019 12:52:39 +0000
Subject: [issue35849] Added thousands separators to Lib/pstats.py final report
In-Reply-To: <1548766331.46.0.0833286868767.issue35849@roundup.psfhosted.org>
Message-ID: <1548766359.0.0.0756793085488.issue35849@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11539
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35849>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:52:42 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Jan 2019 12:52:42 +0000
Subject: [issue35849] Added thousands separators to Lib/pstats.py final report
In-Reply-To: <1548766331.46.0.0833286868767.issue35849@roundup.psfhosted.org>
Message-ID: <1548766362.05.0.830684372691.issue35849@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11539, 11540
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35849>
_______________________________________

From report at bugs.python.org  Tue Jan 29 07:52:44 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Jan 2019 12:52:44 +0000
Subject: [issue35849] Added thousands separators to Lib/pstats.py final report
In-Reply-To: <1548766331.46.0.0833286868767.issue35849@roundup.psfhosted.org>
Message-ID: <1548766364.46.0.686456842298.issue35849@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch, patch
pull_requests: +11539, 11540, 11541
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35849>
_______________________________________

From report at bugs.python.org  Tue Jan 29 08:26:26 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 29 Jan 2019 13:26:26 +0000
Subject: [issue29235] Allow profile/cProfile to be used as context managers
In-Reply-To: <1484097220.43.0.363931456874.issue29235@psf.upfronthosting.co.za>
Message-ID: <1548768386.55.0.866524461493.issue29235@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Closing as these changes have been merged for a few months.

msg285538 mentions that the pure-Python profiler doesn't have `enable` and `disable`, which is already opened in issue 32017.

----------
nosy: +cheryl.sabella
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29235>
_______________________________________

From report at bugs.python.org  Tue Jan 29 08:27:40 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Jan 2019 13:27:40 +0000
Subject: [issue32834] test_gdb fails with Posix locale in 3.7
In-Reply-To: <1518464593.71.0.467229070634.issue32834@psf.upfronthosting.co.za>
Message-ID: <1548768460.43.0.803154397911.issue32834@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Added Dave Malcolm to the nosy list, as the more recent tracebacks are actually throwing an exception in the gdb hooks, rather than just failing the expected output comparison in the test suite.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32834>
_______________________________________

From report at bugs.python.org  Tue Jan 29 08:48:01 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 29 Jan 2019 13:48:01 +0000
Subject: [issue35500] Align expected and actual calls on
 mock.assert_called_with error message
In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za>
Message-ID: <1548769681.66.0.243098373333.issue35500@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@xtreak, were you going to submit a pull request for this or do you think this would be a 'good first issue' for a new contributor?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35500>
_______________________________________

From report at bugs.python.org  Tue Jan 29 08:50:49 2019
From: report at bugs.python.org (Previn Kutty)
Date: Tue, 29 Jan 2019 13:50:49 +0000
Subject: [issue35850] CKAN installation went on script error
Message-ID: <1548769847.83.0.810844890416.issue35850@roundup.psfhosted.org>


New submission from Previn Kutty <previnnk at gmail.com>:

Command : paster make-config ckan development.ini

was showing the following error

(ckan) C:\applns\ckan-master>paster make-config ckan test.ini
Distribution already installed:
  ckan 2.8.2 from c:\users\x179706\envs\ckan\lib\site-packages\ckan-2.8.2-py3.7.egg
Traceback (most recent call last):
  File "C:\applns\Python37-32\Lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\applns\Python37-32\Lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\x179706\Envs\ckan\Scripts\paster.exe\__main__.py", line 9, in <module>
  File "c:\users\x179706\envs\ckan\lib\site-packages\paste\script\command.py", line 102, in run
    invoke(command, command_name, options, args[1:])
  File "c:\users\x179706\envs\ckan\lib\site-packages\paste\script\command.py", line 141, in invoke
    exit_code = runner.run(args)
  File "c:\users\x179706\envs\ckan\lib\site-packages\paste\script\appinstall.py", line 66, in run
    return super(AbstractInstallCommand, self).run(new_args)
  File "c:\users\x179706\envs\ckan\lib\site-packages\paste\script\command.py", line 236, in run
    result = self.command()
  File "c:\users\x179706\envs\ckan\lib\site-packages\paste\script\appinstall.py", line 293, in command
    self.distro, self.options.ep_group, self.options.ep_name)
  File "c:\users\x179706\envs\ckan\lib\site-packages\paste\script\appinstall.py", line 232, in get_installer
    'paste.app_install', ep_name)
  File "c:\users\x179706\envs\ckan\lib\site-packages\pkg_resources\__init__.py", line 2728, in load_entry_poin
t

===============================================
Python version : 3.7.2
CKAN version : 2.8.2 -> https://github.com/ckan/ckan

----------
components: Library (Lib), Windows
messages: 334517
nosy: Previn Kutty, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: CKAN installation went on script error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35850>
_______________________________________

From report at bugs.python.org  Tue Jan 29 08:56:04 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 29 Jan 2019 13:56:04 +0000
Subject: [issue35850] CKAN installation went on script error
In-Reply-To: <1548769847.83.0.810844890416.issue35850@roundup.psfhosted.org>
Message-ID: <1548770164.53.0.827650949548.issue35850@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

ckan is a 3rd party package and not maintain by Python core developers. Please report the issue with the authors of that package.

----------
nosy: +christian.heimes
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35850>
_______________________________________

From report at bugs.python.org  Tue Jan 29 08:57:32 2019
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 29 Jan 2019 13:57:32 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1548770252.78.0.73726200198.issue34778@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

CC Antoine and Nick.

I think we can do it, but we'd need cast(shape=[2,3], order='F')
to allow casting back.

The only practical objections are feature creep. To preserve
symmetry with tobytes(), we'd need to add tobytes('F') (and
tobytes('A')).

----------
nosy: +ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:04:09 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 29 Jan 2019 14:04:09 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1548770649.02.0.0716599345546.issue34778@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think feature creep is ok if it stems from user needs.

Slighty related, but simpler, is https://bugs.python.org/issue35845

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:14:24 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 29 Jan 2019 14:14:24 +0000
Subject: [issue35500] Align expected and actual calls on
 mock.assert_called_with error message
In-Reply-To: <1544813146.35.0.788709270274.issue35500@psf.upfronthosting.co.za>
Message-ID: <1548771264.24.0.29638626598.issue35500@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Cheryl, this is a good first issue for new contributor. I was waiting for suggestion and I am not sure if there is a consensus over the format. I would like to go with the below format as per suggestion from Mario and Terry.

AssertionError: expected call not found.
Expected: mock(2, 3)
Actual: mock(1, 2)

test_assert_called_with_failure_message has to be fixed as a result of this change. Feel free to mark it as an easy issue.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35500>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:32:10 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 29 Jan 2019 14:32:10 +0000
Subject: [issue35849] Added thousands separators to Lib/pstats.py final report
In-Reply-To: <1548766331.46.0.0833286868767.issue35849@roundup.psfhosted.org>
Message-ID: <1548772330.57.0.60292768789.issue35849@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Hi, your change breaks some test, most of the breakage is related to the change in whitespace separators. This breakages should be fixed before your PR can be considered for inclusion. You can see the status of the tests within discussion on github.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35849>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:35:45 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 29 Jan 2019 14:35:45 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548772545.9.0.416921195631.issue35848@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
assignee:  -> docs at python
components: +Documentation -IO
nosy: +docs at python
stage:  -> needs patch
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:36:38 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 29 Jan 2019 14:36:38 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1548772598.44.0.523348860922.issue35810@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I would very much like to see this fixed.

Yes, it can make some extension types immortal, but I believe those types were relying on buggy behavior, and need to be fixed to prevent memory leaks.

I think this is a big enough change to be mentioned in What?s New.


> Any ideas for reducing the chance of breakage or increasing the chance of detecting it in user code would help.

I'd recommend that all C extensions have leak detection as part of their test suite. I don't think we can do much better :(

> leaking types is unlikely to have a big enough memory impact in most application to be easily detected.

Indeed, it's not a big enough problem in most applications.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:37:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 29 Jan 2019 14:37:51 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548772671.43.0.0230599316103.issue35848@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://docs.python.org/3/library/io.html#io.TextIOBase

> Base class for text streams. This class provides a character and line based interface to stream I/O. There is no readinto() method because Python?s character strings are immutable. It inherits IOBase. There is no public constructor.

io.TextIOBase docs say there is no readinto method in the documentation.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:38:07 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 29 Jan 2019 14:38:07 +0000
Subject: [issue34148] Fatal read error on socket transport
In-Reply-To: <1531923784.93.0.56676864532.issue34148@psf.upfronthosting.co.za>
Message-ID: <1548772687.17.0.235084749865.issue34148@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +asvetlov, yselivanov
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34148>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:40:09 2019
From: report at bugs.python.org (Roel Schroeven)
Date: Tue, 29 Jan 2019 14:40:09 +0000
Subject: [issue35851] Make search result in online docs keep their position
 when search finishes
Message-ID: <1548772807.63.0.497905321537.issue35851@roundup.psfhosted.org>


New submission from Roel Schroeven <roel at roelschroeven.net>:

Search in the online documentation shows results while the search continues in the background, which is very nice.

Only problem is: when the search finishes, a line with the text "Search finished, found x page(s) matching the search query." appears which pushes all the search results down a bit. When the result you were looking for was already displayed, you suddenly have to aim the mouse cursor at a new position, or it can happen that you accidentally open the wrong link because of the results not staying in their place.

Is it possible to allocate space for the "Search finished, ..." line from the beginning, so that search results stay in the same place the whole time?

----------
assignee: docs at python
components: Documentation
messages: 334525
nosy: docs at python, roelschroeven
priority: normal
severity: normal
status: open
title: Make search result in online docs keep their position when search finishes
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/issue35851>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:43:42 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 29 Jan 2019 14:43:42 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548773022.57.0.448833917918.issue35848@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I checked and io.TextIOBase is the only io.IOBase subclass to lack one of read, readinto or write:


>>> import io, inspect
>>> for name, obj in inspect.getmembers(io, predicate=inspect.isclass):
... 	missing = {'read', 'readinto', 'write'} - {name for name, _ in inspect.getmembers(obj)}
...	if issubclass(obj, io.IOBase) and missing:
...	     print(obj, missing, issubclass(obj, io.TextIOBase))

<class 'io.IOBase'> {'write', 'read', 'readinto'} False
<class '_io.StringIO'> {'readinto'} True
<class 'io.TextIOBase'> {'readinto'} True
<class '_io.TextIOWrapper'> {'readinto'} True

I can open a PR to fix the conflicts between the two parts of the documentation. I think it's appropriate to change TextIOBase to raise UnsupportedOperation when calling readinto and to change the documentation accordingly.

----------
components: +IO -Documentation
nosy: +remi.lapeyre -docs at python, xtreak
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 09:43:57 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 29 Jan 2019 14:43:57 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548773037.08.0.532462623943.issue35848@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 10:11:50 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 29 Jan 2019 15:11:50 +0000
Subject: [issue35851] Make search result in online docs keep their position
 when search finishes
In-Reply-To: <1548772807.63.0.497905321537.issue35851@roundup.psfhosted.org>
Message-ID: <1548774710.85.0.990336608753.issue35851@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have minimum experience with CSS but this seems to be a Sphinx level enhancement that needs to be made. The text is set after search completion at [0]. The element [1] to which the text is added has no fixed height and is empty at the beginning so adding a fixed height might ensure the text doesn't push it down. But the relevant file is part of sphinx repo and doesn't have an id associated with it so I am not sure how feasible it is to customize this as part of Python doc distribution.

[0] https://github.com/sphinx-doc/sphinx/blob/97d99f830258a4612a6c77f5be084819634dcbad/sphinx/themes/basic/static/searchtools.js#L299
[1] https://github.com/sphinx-doc/sphinx/blob/97d99f830258a4612a6c77f5be084819634dcbad/sphinx/themes/basic/static/searchtools.js#L133

----------
nosy: +mdk, xtreak
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35851>
_______________________________________

From report at bugs.python.org  Tue Jan 29 10:52:23 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 29 Jan 2019 15:52:23 +0000
Subject: [issue35769] IDLE: change new file name from ''Untitled" to "untitled"
In-Reply-To: <1547792346.64.0.506304768871.issue35769@roundup.psfhosted.org>
Message-ID: <1548777143.28.0.790825894601.issue35769@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35769>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:16:15 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Jan 2019 16:16:15 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
In-Reply-To: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>
Message-ID: <1548778575.69.0.573513683395.issue35847@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 742d768656512a469ce9571b1cbd777def7bc5ea by Miss Islington (bot) (Andreas Schwab) in branch 'master':
bpo-35847: RISC-V needs CTYPES_PASS_BY_REF_HACK (GH-11694)
https://github.com/python/cpython/commit/742d768656512a469ce9571b1cbd777def7bc5ea


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:16:38 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Jan 2019 16:16:38 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
In-Reply-To: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>
Message-ID: <1548778598.82.0.851011904683.issue35847@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:27:03 2019
From: report at bugs.python.org (Addons Zz)
Date: Tue, 29 Jan 2019 16:27:03 +0000
Subject: [issue35852] Fixed tests regenerating using CRLF when running it on
 Windows
Message-ID: <1548779221.97.0.25499601133.issue35852@roundup.psfhosted.org>


New submission from Addons Zz <addonszz at outlook.com>:

When generating the file on Windows by running
```
python test/test_profile.py -r
```

The file has its line ending converted from LF to CRLF, creating noise on the git diff.

----------
components: Library (Lib), Tests
messages: 334529
nosy: addons_zz
priority: normal
severity: normal
status: open
title: Fixed tests regenerating using CRLF when running it on Windows
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35852>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:27:36 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Jan 2019 16:27:36 +0000
Subject: [issue35852] Fixed tests regenerating using CRLF when running it on
 Windows
In-Reply-To: <1548779221.97.0.25499601133.issue35852@roundup.psfhosted.org>
Message-ID: <1548779256.3.0.77651716934.issue35852@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +11544
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35852>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:27:39 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Jan 2019 16:27:39 +0000
Subject: [issue35852] Fixed tests regenerating using CRLF when running it on
 Windows
In-Reply-To: <1548779221.97.0.25499601133.issue35852@roundup.psfhosted.org>
Message-ID: <1548779259.57.0.00873833939268.issue35852@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch, patch
pull_requests: +11544, 11545
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35852>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:50:34 2019
From: report at bugs.python.org (Steve Palmer)
Date: Tue, 29 Jan 2019 16:50:34 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548780634.53.0.112866724192.issue35848@roundup.psfhosted.org>


Steve Palmer <steve at srpalmer.me.uk> added the comment:

I agree with Karthikeyan that the method does not apply in the io.TextIOBase class context.  I'm sorry that I didn't spot the note in the description of io.TextIOBase - though I think that it is easy to miss.

I'd suggest that there are two ways to clear this up:

1. change only the documentation to read "Even though IOBase does not declare read() or write() because their signatures will vary, implementations and clients should consider those methods part of the interface."  (deleting reference to readinto())

2. change the standard library for io.TextIOBase to add a method readinto which will raise an UnsupportedOperation.

With option 1, the descriptions for io.RawIOBase and io.BufferedIOBase both include description of the readinto method, so nothing is lost by removing mention of it at the io.IOBase level of the hierarchy.  In any case, readinto() is not defined on the io.IOBase class.

>>> 'readinto' not in dir(io.IOBase)
True

With option 2, it feels like this is closer to the design intent of a common interface over similar but distinguished classes.  It also avoids removing things from the documentation in case someone already has some expectations of the behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:58:28 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jan 2019 16:58:28 +0000
Subject: [issue35837] smtpd PureProxy breaks on mail_options keyword argument
In-Reply-To: <1548593797.17.0.823741388378.issue35837@roundup.psfhosted.org>
Message-ID: <1548781108.64.0.61142358162.issue35837@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm closing this in favor of #35799 because someone has to first make a remove-or-fix decision, which is mentioned there.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> fix or remove smtpd.PureProxy
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35837>
_______________________________________

From report at bugs.python.org  Tue Jan 29 11:59:55 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Jan 2019 16:59:55 +0000
Subject: [issue35799] fix or remove smtpd.PureProxy
In-Reply-To: <1548091515.27.0.738178577175.issue35799@roundup.psfhosted.org>
Message-ID: <1548781195.03.0.124281589943.issue35799@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm neutral on fixing versus removing philosophically. Since fixing is actually the least effort in this case, I think practically I favor fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35799>
_______________________________________

From report at bugs.python.org  Tue Jan 29 12:16:50 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 29 Jan 2019 17:16:50 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548782210.81.0.162570080103.issue35848@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Steve for the details. I am adding io module maintainers to the issue who will have better context on whether to clarify the docs or to change the implementation to raise UnsupportedOperation.

----------
nosy: +benjamin.peterson, stutzbach, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Tue Jan 29 13:06:31 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 29 Jan 2019 18:06:31 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548785191.99.0.125322928039.issue35823@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thank you for the review and your thoughts, Gregory.

> With this in place we may want to make the _use_posix_spawn() logic in subprocess.py stricter?  That could be its own followup PR.

Yes, I think we can always use vfork() on Linux unless we find some issues. (Victor Stinner doesn't seem to be against: https://github.com/python/cpython/pull/11668#issuecomment-457637207). Though C libraries are in a better position to provide safe vfork/exec, by using our implementation we will:
* avoid breaking QEMU user-mode (and preserve existing subprocess behavior)
* automatically support fast process creation on musl (which has a good posix_spawn, but doesn't have easy means (macros) on detect that we're on musl and thus avoid unacceptable posix_spawn).
* avoid having different code paths (and thus potential surprises) depending on arguments of subprocess.Popen()

> This is a scary issue.  But I think a reasonable approach could be to never use vfork when running as whatever we choose to define a "privileged user" to be.

> getuid() or geteuid() return 0?  don't use vfork.

I thought about something like this, but initially dismissed it because I (mistakenly) decided that an application may concurrently switch between arbitrary uids back and forth, so that checking getuid() becomes useless (if we're already talking about an exotic app that calls setuid() concurrently with spawning children, why stop there?). But now I realize that an app may use *arbitrary* uids only if one of its real, effective or saved uids is zero (that is, if we don't take capabilities into account), so at least we could call getresuid() to get all 3 uids in a race-free way and check whether the app is *definitely* privileged...

> the concept of "privileged user" can obviously mean a lot more than that and likely goes beyond what we should attempt to ascertain ourselves.

...but you're making a good point here. So I'm not sure that we want such checks, but if we do, we'd probably need to allow users to disable them -- what if some heavy privileged daemon wants a faster subprocess?

> How about also providing a disable-only global setting so that someone writing code they consider to have elevated privileges can prevent its use entirely.  subprocess.disable_use_of_vfork() and subprocess.is_vfork_enabled() calls perhaps (just setting/reading a static int vfork_disallowed = 0 flag within _posixsubprocess.c).

I think it's reasonable. I'll look into it when I'm done with current issues.

> True setuid vs vfork attack security would suggest code needs to opt-in to vfork() or posix_spawn() rather than opt-out.  Which would destroy the benefit for most users (who won't bother) for the sake of an issue that just is not what most code ever does (setuid/setgid/etc. calls are very uncommon for most software).

Agree, especially since we're not talking about "just" using setuid() but rather about using setuid() *in a multithreaded process in a racy manner while spawning children*. Honestly, I'm not sure such apps can blame Python if they get a security hole :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Tue Jan 29 16:11:40 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Jan 2019 21:11:40 +0000
Subject: [issue35847] RISC-V needs CTYPES_PASS_BY_REF_HACK
In-Reply-To: <1548750939.45.0.386681668204.issue35847@roundup.psfhosted.org>
Message-ID: <1548796300.73.0.640661288304.issue35847@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 10354cbb5067b4719ba1c2d51d22314a644ed3e5 by Miss Islington (bot) in branch '3.7':
bpo-35847: RISC-V needs CTYPES_PASS_BY_REF_HACK (GH-11694)
https://github.com/python/cpython/commit/10354cbb5067b4719ba1c2d51d22314a644ed3e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35847>
_______________________________________

From report at bugs.python.org  Tue Jan 29 17:08:39 2019
From: report at bugs.python.org (Tobias Pleyer)
Date: Tue, 29 Jan 2019 22:08:39 +0000
Subject: [issue35853] Extend the functools module with more higher order
 function combinators
Message-ID: <1548799718.5.0.603490291.issue35853@roundup.psfhosted.org>


New submission from Tobias Pleyer <tobi.pleyer at gmail.com>:

The partial function is a typical example of a higher order function: It takes a function as argument and returns a function. As the name of the functools module suggests its purpose is to provide tools for working with  functions. This should, in my opinion, include a much bigger set of higher order function combinators as they are known from functional programming.
As a start I suggest to add the following functions:

identity: The identity function which returns its input
compose: Create a function pipeline (threaded computation)
sequence: Use compose without binding it to a variable

----------
components: Library (Lib)
messages: 334536
nosy: tpleyer
priority: normal
severity: normal
status: open
title: Extend the functools module with more higher order function combinators
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35853>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:13:15 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Jan 2019 23:13:15 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
Message-ID: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The change to pull the redirector executables as part of scripts was... perhaps too clever. There exists code out there that uses EnvBuilder to create environments _without_ copying scripts, which now results in an environment that does not include python.exe.

It also undid symlink support, as scripts are never symlinked.

I'll restore both.

----------
assignee: steve.dower
components: Windows
keywords: 3.7regression
messages: 334537
nosy: eryksun, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
priority: normal
severity: normal
status: open
title: EnvBuilder and venv symlinks do not work on Windows on 3.7.2
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:27:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Jan 2019 23:27:51 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548804471.41.0.903741207466.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Actually, it seems like venv symlinks are so far from working that they haven't worked (on Windows) since 3.5 or possibly earlier.

I'm just going to make that option ignored and mark it as such in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:40:33 2019
From: report at bugs.python.org (Tobias Pleyer)
Date: Tue, 29 Jan 2019 23:40:33 +0000
Subject: [issue35853] Extend the functools module with more higher order
 function combinators
In-Reply-To: <1548799718.5.0.603490291.issue35853@roundup.psfhosted.org>
Message-ID: <1548805233.22.0.900255088648.issue35853@roundup.psfhosted.org>


Change by Tobias Pleyer <tobi.pleyer at gmail.com>:


----------
keywords: +patch
pull_requests: +11546
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35853>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:47:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Jan 2019 23:47:36 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548805656.82.0.0985019319538.issue35854@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +11548
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:47:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Jan 2019 23:47:47 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548805667.89.0.330731600471.issue35854@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch
pull_requests: +11548, 11549
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:48:01 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Jan 2019 23:48:01 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548805681.44.0.359576527799.issue35854@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch, patch, patch
pull_requests: +11548, 11549, 11550
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Jan 29 18:49:08 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Jan 2019 23:49:08 +0000
Subject: [issue35853] Extend the functools module with more higher order
 function combinators
In-Reply-To: <1548799718.5.0.603490291.issue35853@roundup.psfhosted.org>
Message-ID: <1548805748.54.0.345938487142.issue35853@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I believe each of these has been discussed and individually rejected before.  They don't apply as neatly to Python as one would hope.  Identity is usually inefficient in Python and we use a func=None as a substitute.  Identity also had issues with returning scalars versus an args tuple and issues with keyword arguments.   Compose wasn't found to be generally useful in typical Python programming and its application order was deemed to be confusing relative to a simple nested function call or a simple lambda.  Compose also had challenges with chaining multi-argument functions together in an intuitive way.  For both, there were also error message issues and other challenges to making code that is easily debuggable when there is a failure.  We did accept partial() because it was a good fit with the language, it was easy to reason about, and it had a number of known use cases in real code.   FWIW, it is not the aspiration of the functools module to emulate a straight functional programming environment.  It is more a generic set of tools that that have function-like behavior rather than class-like behavior.   Please also take a look a various posts from Guido van Rossum on why didn't push the language more in the direction of functional programming.

Thank for the suggestion, but this isn't the first time it has crossed our minds.  If there had been a good case for these constructs, it would have happened long ago :-)

----------
nosy: +rhettinger
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35853>
_______________________________________

From report at bugs.python.org  Tue Jan 29 22:14:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Jan 2019 03:14:32 +0000
Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze
 default
Message-ID: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

This issue continues #35196, which fixed some bugs (inconsistencies) in auto-squeezing and sped the scan of output strings for possible auto-squeezing.  This issue has two parts:
1. Make unsqueezing faster and easier for the user.  Details discussed below.
2. Reconsider the parameters and protocol for auto-squeezing.
2a. Increase the default setting for the minimum number of number of lines to squeeze.  The best setting depends on the result of part 1.
2b. Other changes?

(Some of the work might be done on separate PRs on issues that are dependencies of this one.)

If users ask for a big blob of text, they presumably want to read at least some of it, usually from the beginning, and possibly scan up and down.  The most common example is output from help(object), defined in the pydoc and _sitebuiltins modules.

Help first computes a single output string, whether 2 lines (list.append), 600 (itertools) or over 20000 (tkinter).  For modules, one most likely want to see the module docstring.  Those for itertools are about 40 and 80 lines respectively and both list the functions/classes in the module.

With standard interactive python on a text terminal/console, help output is run through a pager.  If more than a full screen, output is paused with a prompt.  I consider both 'more' on Windows and 'less' on Mac to be overall unsatisfactory, especially for naive beginners, and hope we can do overall better on IDLE.

On Windows, the prompt is "-- More --", with no hint of what to do.  One can experiment and discover that Enter means 'display one more line' and Space means 'display one more screenful'.  Or one can guess to enter "more /h" at a console command prompt.  Either way, paging a thousand times to get the entire output for tkinter is not practical.

As far as I can tell from the 'more /h' output, there is no 'dump remaining text' command other than 'p <more than remaining # of lines>'.  What is worse, a Windows console only holds the last N lines displayed, where N defaults to 300 and can be increased to at most 9999. So scrolling back is limited.  This is terrible, especially at the default setting.

On Mac Terminal, the pager is 'less', the prompt is ':', Space and Enter do the same, scrolling is only partially possible and weird, P goes to the top, a number N after space goes down N lines, to an 'END' prompt. As near as I could discover, less refuses to exit until one hits 'q', at which point the help text disappears.  This is true even for the 2-line help for list.append.  Terrible.

On IDLE, without squeezer, the entire text is displayed followed by a fresh 'enter code' prompt ('>>>').  However, for multi-screen text, the user immediately sees only the last lines, not the first.  This is bad, But at least there is a possibility of scrolling up and trying to find the beginning of the text, although this may take several seconds.

When squeezer unsqueezes, it makes the first line, not the last line, visible.  For a long enough output string, the easier way to get to the first line to start reading, other than scrolling, is to squeeze and unsqueeze.  (This applies to open_file.read() also.)  Absent anything better, I now consider this the primary justification for auto-squeezing.

The following should make triggering expansion of a squeeze label easier and faster, in terms of user actions, regardless of how the  label came about.

E1. Add 'Expand' at the top of the context menu.  (I sometimes right click instead of double-clicking the squeeze label.)  (And add 'Help' at the bottom, to display an explanation of Squeezer.)

E2. Add a hot key to expand when the text cursor is on the line with the squeeze label.  After typing 'help(xyz)' and getting a squeeze label, I would prefer to hit <up arrow> <something> and perhaps use navigation keys instead of immediately having to grab the mouse.

E3. Stop the false (or at least out-dated) and confusing warning about many normal text lines causing problems.  The 20000 lines of tkinter help is not an issue on either my years-old Windows desktop and slower years-old MacbookAir.  I once printed over half a million lines , about 40 chars as I remember, on Windows IDLE without issue.

Long lines are a different issue.  'a'*10000 is okay on Windows, but not on Mac.  On the latter, after unsqueezing, and scrolling down to the new prompt, trying to scroll back up results in the OS twirly pause icon for a few seconds.  The natureal response of adding more keys presses and mouse clicks trying to get a response probably made the experience worse.  This reminds me of my previous Windows machine a decade ago.  

A line length warning needs data both on the machine and the max lines of the text.  The latter might be gathered fast enough by checking line lengths in an after loop.


Once the text is expanded, it could be more immediately useful.

U1. If the squeeze label is near the bottom of the window, only the top few lines are made visible.  Instead, put the top of the output at the top of the window to make as many lines as possible visible.  This should be easy.

U2. *Perhaps* we should put the text cursor at the beginning of the output, instead of leaving it at the next prompt, so nagivation keys work.  But this has tradeoffs and I think it should be left until some other stuff is done.


Once we improve unsqueezing, we can consider auto-squeeze changes. 

A1. Increase the default max lines before auto-squeeze.  Changing defaults is problematical because users customizations apply to all versions a user runs.  A new default on a new version will erase a matching custom value set on an older version.  So new values should be unlikely as custom values.

Another issue is using the lines number to check line length.
10000 = 125 X 80.  On my Windows machine, I think 123 (not 125!) might be okay.  But definitely not on Mac.

One could say we should not protect people from the consequence of foolish inputs, but letting IDLE freeze is part of what has lead to 'IDLE is junk' comments (on Stackoverflow and pydev that I know of).

A2. Decouple lines from length.  Regardless of what I thought when reviewing squeezer, I think now that this is crucial.  But try to determine an appropriate length by internal checks instead of adding another configuration value.  Or make the coupling non-linear (maxlen = C*log(maxlines)?)  Or see what adding horizontal scroll does.

A3. (Suggestion from others) Print a screenful of an output block and then squeeze.  The downside to me is two-fold: one will likely need to unsqueeze anyway; this prevents or complicates moving text to the clipboard or a text viewer.  (The label item could keep track of how much was displayed, but then resizing is an issue.)

Some other ideas.

I1. Write a pager.  No.

I2. Add other ways to get back to the start of a text block.  Add 'Previous Prompt' or 'Prompt Up' or ??? (and Prompt next/down) to the unsqueezed menu.  Or add Control/Command PageUp/Down for Prev/Next Prompt to the fixed navigation keys.  (or both.) These sequences are unused for my current keysets.  config-keys.def should be checked.  Some people would likely prefer these to autosqueeze for getting to the beginning of a blob.  

I3. Add 'Copy' and 'View' (and 'Help') to the unsqueezed context menu so one can skip the visible label step.

----------
assignee: terry.reedy
components: IDLE
messages: 334541
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE squeezer: improve unsqueezing and autosqueeze default
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35855>
_______________________________________

From report at bugs.python.org  Tue Jan 29 23:23:53 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 30 Jan 2019 04:23:53 +0000
Subject: [issue35856] bundled pip syntaxwarning
Message-ID: <1548822232.71.0.928620315145.issue35856@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

It seems that `pip` vendored/bundled with Python3.8 doesn't conform to 3.8 syntax:

? ~> /usr/local/bin/python3.8 -m ensurepip
/.../tmp.../pip-18.1-py2.py3-none-any.whl/pip/_vendor/requests/status_codes.py:3: SyntaxWarning: invalid escape sequence \o
/.../tmp.../pip-18.1-py2.py3-none-any.whl/pip/_vendor/requests/status_codes.py:3: SyntaxWarning: invalid escape sequence \o
Looking in links: /.../tmp...
Requirement already satisfied: setuptools in /usr/local/lib/python3.8/site-packages (40.6.2)
Requirement already satisfied: pip in /usr/local/lib/python3.8/site-packages (18.1)

Python 3.8.0a0 (bafa8487f77fa076de3a06755399daf81cb75598) built from source

----------
components: Library (Lib)
messages: 334542
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: bundled pip syntaxwarning
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35856>
_______________________________________

From report at bugs.python.org  Tue Jan 29 23:38:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 30 Jan 2019 04:38:56 +0000
Subject: [issue35856] bundled pip syntaxwarning
In-Reply-To: <1548822232.71.0.928620315145.issue35856@roundup.psfhosted.org>
Message-ID: <1548823136.18.0.072619919093.issue35856@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This needs to be updated in vendor files for pip repo and then updating the files in CPython. The upstream issue on requests is fixed.

----------
nosy: +dstufft, ncoghlan, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35856>
_______________________________________

From report at bugs.python.org  Wed Jan 30 00:03:28 2019
From: report at bugs.python.org (Steve Pryde)
Date: Wed, 30 Jan 2019 05:03:28 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
Message-ID: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>


New submission from Steve Pryde <spryde81 at gmail.com>:

When python prints or returns a stacktrace, it displays the appropriate line from the *current file on disk*, which may have changed since the program was run. It should instead show the lines from the file as it was when the code was executed.

Steps to reproduce:
1. Save the following code to a file and run it in a terminal.

    import time 

    time.sleep(600)

2. While it is running, insert a line before "time.sleep(600)", type some random characters, and save the file. The "time.sleep" should now be on line 4, and some random characters on line 3.

3. Now go back to the terminal and press Ctrl+C (to generate a stacktrace).


Expected output:

^CTraceback (most recent call last):
  File "py1.py", line 3, in <module>
    time.sleep(600)
KeyboardInterrupt


Actual output:

^CTraceback (most recent call last):
  File "py1.py", line 3, in <module>
    some random characters
KeyboardInterrupt

----------
components: Interpreter Core
messages: 334544
nosy: Steve Pryde
priority: normal
severity: normal
status: open
title: Stacktrace shows lines from updated file on disk, not code actually running
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 00:48:36 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 30 Jan 2019 05:48:36 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548827316.92.0.987260210672.issue35854@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Actually, it seems like venv symlinks are so far from working 
> that they haven't worked (on Windows) since 3.5 or possibly 
> earlier.

I use venv with --symlinks prior to 3.7.2. It works fine as far as I can tell. Perhaps you could elaborate. I assumed you removed it because it's not compatible with the Microsoft Store release for some reason. 

The loader doesn't resolve links, so it should work as long as the python.exe, python3x.dll, python3.dll, and vcruntime140.dll files are linked together in the Scripts directory. 

    >>> hPython3 = ctypes.WinDLL('python3')._handle
    >>> hVcruntime140 = ctypes.WinDLL('vcruntime140')._handle
    >>> for h in (0, sys.dllhandle, hPython3, hVcruntime140):
    ...     print(_winapi.GetModuleFileName(h), '->')
    ...     print('\t', os.readlink(_winapi.GetModuleFileName(h)))
    ...
    C:\Temp\env36\scripts\python.exe ->
             C:\Program Files\Python36\python.exe
    C:\Temp\env36\scripts\python36.dll ->
             C:\Program Files\Python36\python36.dll
    C:\Temp\env36\scripts\python3.dll ->
             C:\Program Files\Python36\python3.dll
    C:\Temp\env36\scripts\VCRUNTIME140.dll ->
             C:\Program Files\Python36\vcruntime140.dll

    >>> print(sys.executable)
    C:\Temp\env36\scripts\python.exe

    >>> print(*sys.path, sep='\n')

    C:\Temp\env36\scripts\python36.zip
    C:\Program Files\Python36\DLLs
    C:\Program Files\Python36\lib
    C:\Program Files\Python36
    C:\Temp\env36
    C:\Temp\env36\lib\site-packages

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 01:45:17 2019
From: report at bugs.python.org (rongxin)
Date: Wed, 30 Jan 2019 06:45:17 +0000
Subject: [issue35842] A potential bug about use of uninitialised variable
In-Reply-To: <1548682684.86.0.506675719122.issue35842@roundup.psfhosted.org>
Message-ID: <1548830717.53.0.991486478491.issue35842@roundup.psfhosted.org>


rongxin <se.wu.rongxin at gmail.com> added the comment:

Josh Rosenberg, thanks for your useful comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35842>
_______________________________________

From report at bugs.python.org  Wed Jan 30 01:56:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Jan 2019 06:56:26 +0000
Subject: [issue35196] IDLE text squeezer is too aggressive and is slow
In-Reply-To: <1541757652.98.0.788709270274.issue35196@psf.upfronthosting.co.za>
Message-ID: <1548831386.35.0.949625662504.issue35196@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think any further work on IDLE print speed should look at the entire path from print('x') to 'x' appearing in IDLE's Shell.  Where does the time go, what might be sped up?

I no longer think auto-squeezing should consider more than a single output string.

To continue this issue, I opened squeezer index issue #35855.  It describes what I think are the 2 main uses of auto-squeezing and several possible squeezer or related improvements, labeled for easy reference.

Some existing and new issues related to some of the off-topic messages:
#21261: Dict key tab completion.
#22121: Start in $HOME.
#24776: Configdialog font tab user interface -- add comment.
#25522: Save-as warning -- include unimportable names.
#28775: Set start-up directory
#32761: Modern Mac Keyset.
#33397: Change font size with cntl +- (text view first).

#35763: Calltips: make positional note smaller.
#35768: Detecting monospaced fonts with font sample -- automeasure.
#35769: ''Untitled" to "untitled" (fixed).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35196>
_______________________________________

From report at bugs.python.org  Wed Jan 30 03:21:28 2019
From: report at bugs.python.org (Martin Panter)
Date: Wed, 30 Jan 2019 08:21:28 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548836488.36.0.433941792925.issue35848@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I think it would be more practical to fix the documentation (option 1). Do you have a use case for ?TextIOBase.readinto? raising ValueError (something more concrete than someone having expectations)?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Wed Jan 30 03:37:30 2019
From: report at bugs.python.org (Steve Palmer)
Date: Wed, 30 Jan 2019 08:37:30 +0000
Subject: [issue35848] readinto is not a method on io.TextIOBase
In-Reply-To: <1548753520.89.0.970608711782.issue35848@roundup.psfhosted.org>
Message-ID: <1548837450.65.0.229860863696.issue35848@roundup.psfhosted.org>


Steve Palmer <steve at srpalmer.me.uk> added the comment:

I don't have a "real" use case.  I discovered the issue when I was developing a unittest suite for what it means to be "file-like".  I've been codifying the description in the standard library and exercising my tests against the built-in file-likes, such as the io.StringIO class, when it raised the Attribute Exception.

The more I think about it, the more like a documentation problem it feels.  For example, the statement "... because their signatures will vary ..." does not apply to readinto in the cases where it is defined.

For completeness, the note in io.TextIOBase stating "There is no readinto() method because Python?s character strings are immutable." would also need to be removed as part of a documentation fix.

(It's also nice when solutions result in less "stuff". :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35848>
_______________________________________

From report at bugs.python.org  Wed Jan 30 04:34:19 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 30 Jan 2019 09:34:19 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548840859.26.0.91037982748.issue35857@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> It should instead show the lines from the file as it was when the code was executed.

How is Python supposed to do that without making a copy of every module and script it runs just in case it gets modified?

(That's not a rhetorical question -- if you can think of a cheap way to implement this, I'm listening :-)

99.99% of the time this would be a total waste of time, so this would be a very expensive exercise for very little gain. Python's startup time is already too slow without having to also make potentially hundreds of file copies every time you run a script.

For the record, I too once ran into this issue. It left me utterly confused for an hour or so until I worked out what was happening, and then I never made the mistake of editing a running script again.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 05:46:47 2019
From: report at bugs.python.org (Steve Pryde)
Date: Wed, 30 Jan 2019 10:46:47 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548845207.18.0.569714605353.issue35857@roundup.psfhosted.org>


Steve Pryde <spryde81 at gmail.com> added the comment:

> How is Python supposed to do that without making a copy of every module and script it runs just in case it gets modified?

Aha, I suspected this might be the reason. Feel free to close this issue if there's nothing else to be said here.

Python certainly only executes the code as it was at the time of initial execution, or rather it executes the generated bytecode. I gather therefore that python has enough info to display the files and line numbers but not their contents (which must be loaded fresh from disk).

As mentioned, if this is the case, I'm happy for this to be closed. Cheers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 06:01:04 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 30 Jan 2019 11:01:04 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548845207.18.0.569714605353.issue35857@roundup.psfhosted.org>
Message-ID: <20190130110059.GK1834@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

There may be something we can do to improve the error reporting and make 
it less perplexing:

https://mail.python.org/pipermail/python-ideas/2019-January/055041.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 06:36:16 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 30 Jan 2019 11:36:16 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548848176.6.0.974767980802.issue35857@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

The problem, as I understand it, is a mismatch between the code object being executed and the file on disk referred to by the code object. When a module is reloaded it is first recompiled, if the .py file is newer than the .pyc file. (I've tested this at a console.)

Suppose wibble.py contains a function fn. Now do
   import wibble
   fn = wibble.fn
   # Modify and save wibble.py
   reload(wibble)
   fn()

It seems to me that
1) We have a mismatch between fn (in module __main__) and the file on disk.
2) Comparison will show that wibble.pyc is later than wibble.py.
3) There's no reliable way to discover that fn is not the current fn  ...
4) ... other than comparing its bytecode with that of the current value of wibble.fn.

Regarding (4) there might be another method. But I can't think of one that's reliable.

----------
nosy: +jfine2358

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 06:37:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 30 Jan 2019 11:37:18 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548848238.29.0.482725287967.issue35857@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also issue8087 that has a similar case with interactive shell where the imported module was changed on disk. It has some discussion along similar lines with some more possible cases msg145291.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 06:42:45 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 30 Jan 2019 11:42:45 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548848565.73.0.460261167458.issue35857@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Looking more into the issue8087 there is issue31300 and issue23594 that are linked as duplicates with issue31300 very similar to this report. Maybe close this to continue discussion on issue8087?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 08:51:58 2019
From: report at bugs.python.org (jcrmatos)
Date: Wed, 30 Jan 2019 13:51:58 +0000
Subject: [issue35858] Consider adding the option of running shell/console
 commands inside the REPL
Message-ID: <1548856317.43.0.990558066571.issue35858@roundup.psfhosted.org>


New submission from jcrmatos <jcrmatos at gmail.com>:

Consider adding the option of running shell/console commands inside the REPL.
Something like
>>>!ls

----------
messages: 334556
nosy: jcrmatos
priority: normal
severity: normal
status: open
title: Consider adding the option of running shell/console commands inside the REPL
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35858>
_______________________________________

From report at bugs.python.org  Wed Jan 30 08:54:21 2019
From: report at bugs.python.org (pmpp)
Date: Wed, 30 Jan 2019 13:54:21 +0000
Subject: [issue35858] Consider adding the option of running shell/console
 commands inside the REPL
In-Reply-To: <1548856317.43.0.990558066571.issue35858@roundup.psfhosted.org>
Message-ID: <1548856461.48.0.975780067394.issue35858@roundup.psfhosted.org>


pmpp <pmpp.pub at gmail.com> added the comment:

Hi, maybe have a look to third parties for that 
because repl internals are tied to each supported platforms.

https://xon.sh/index.html

https://github.com/pmp-p/aioprompt

https://github.com/prompt-toolkit

----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35858>
_______________________________________

From report at bugs.python.org  Wed Jan 30 09:11:01 2019
From: report at bugs.python.org (jcrmatos)
Date: Wed, 30 Jan 2019 14:11:01 +0000
Subject: [issue35858] Consider adding the option of running shell/console
 commands inside the REPL
In-Reply-To: <1548856317.43.0.990558066571.issue35858@roundup.psfhosted.org>
Message-ID: <1548857461.13.0.425919076618.issue35858@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Yes, I understand that, but I don't see why that should prevent this feature from going forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35858>
_______________________________________

From report at bugs.python.org  Wed Jan 30 09:12:47 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 30 Jan 2019 14:12:47 +0000
Subject: [issue35823] Use vfork() in subprocess on Linux
In-Reply-To: <1548381806.02.0.709569222975.issue35823@roundup.psfhosted.org>
Message-ID: <1548857567.2.0.280649687207.issue35823@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

I've been struggling with fixing spurious -Wclobbered GCC warnings. Originally, I've got the following:

/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c: In function ?subprocess_fork_exec?:
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:612:15: warning: variable ?gc_module? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     PyObject *gc_module = NULL;
               ^~~~~~~~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:616:15: warning: variable ?preexec_fn_args_tuple? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     PyObject *preexec_fn_args_tuple = NULL;
               ^~~~~~~~~~~~~~~~~~~~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:621:17: warning: variable ?cwd? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     const char *cwd;
                 ^~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:623:9: warning: variable ?need_to_reenable_gc? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     int need_to_reenable_gc = 0;
         ^~~~~~~~~~~~~~~~~~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:624:38: warning: variable ?argv? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     char *const *exec_array, *const *argv = NULL, *const *envp = NULL;
                                      ^~~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:624:59: warning: variable ?envp? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     char *const *exec_array, *const *argv = NULL, *const *envp = NULL;
                                                           ^~~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:626:9: warning: variable ?need_after_fork? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     int need_after_fork = 0;
         ^~~~~~~~~~~~~~~
/scratch2/izbyshev/cpython/Modules/_posixsubprocess.c:627:9: warning: variable ?saved_errno? might be clobbered by ?longjmp? or ?vfork? [-Wclobbered]
     int saved_errno = 0;
         ^~~~~~~~~~~

I've checked that all warnings are spurious: all flagged variables are either not modified in the child or modified and used only by the child. A simple way to suppress the warnings would be "volatile", but I don't want to spray "volatile" over the huge declaration block of subprocess_fork_exec().

Another way is to move vfork() to a separate function and ensure that this function does as little as possible with its local variables. I've implemented two versions of this approach, both are ugly in some sense. I've pushed the first into the PR branch and the second into a separate branch https://github.com/izbyshev/cpython/tree/single-do-fork-exec.

Yet another way would be to simply disable this diagnostic for _posixsubprocess (e.g. via #pragma GCC diagnostic), but I'm not sure we want to do that -- may be it'll be fixed in the future or a real defect will be introduced into our code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35823>
_______________________________________

From report at bugs.python.org  Wed Jan 30 09:16:15 2019
From: report at bugs.python.org (James Davis)
Date: Wed, 30 Jan 2019 14:16:15 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
Message-ID: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>


New submission from James Davis <davisjam at vt.edu>:

I have two regexes: /(a|ab)*?b/ and /(ab|a)*?b/.
If I re.search the string "ab" for these regexes, I get inconsistent behavior.
Specifically, /(a|ab)*?b/ matches with capture "a", while /(ab|a)*?b/ matches with an empty capture group.

I am not actually sure which behavior is correct.


Interpretation 1: The (ab|a) clause matches the a, satisfying the (ab|a)*? once, and the engine proceeds to the b and completes. The capture group ends up containing "a".

Interpretation 2: The (ab|a) clause matches the a. Since the clause is marked with *, the engine repeats the attempt and finds nothing the second time. It proceeds to the b and completes. Because the second match attempt on (ab|a) found nothing, the capture group ends up empty.

The behavior depends on both the order of (ab|a) vs. (a|ab), and the use of the non-greedy quantifier.

I cannot see why changing the order of the alternation should have this effect.

The change in behavior occurs in the built-in "re" module but not in the competing "regex" module.
The behavior is consistent in both Python 2.7 and Python 3.5. I have not tested other versions.

I have included the confusing-regex-behavior.py file for troubleshooting.

Below is the behavior for matches on these and many variants.
I find the following lines the most striking:

Regex pattern                    matched?       matched string     captured content
-------------------- -------------------- -------------------- --------------------
(ab|a)*?b                            True                   ab                ('',)
(ab|a)+?b                            True                   ab                ('',)
(ab|a){0,}?b                         True                   ab                ('',)
(ab|a){0,2}?b                        True                   ab                ('',)
(ab|a){0,1}?b                        True                   ab               ('a',)
(ab|a)*b                             True                   ab               ('a',)
(ab|a)+b                             True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)+?b                            True                   ab               ('a',)


(08:58:48) jamie at woody ~ $ python3 /tmp/confusing-regex-behavior.py 


Behavior from re


Regex pattern                    matched?       matched string     captured content
-------------------- -------------------- -------------------- --------------------
(ab|a)*?b                            True                   ab                ('',)
(ab|a)+?b                            True                   ab                ('',)
(ab|a){0,}?b                         True                   ab                ('',)
(ab|a){0,2}?b                        True                   ab                ('',)
(ab|a)?b                             True                   ab               ('a',)
(ab|a)??b                            True                   ab               ('a',)
(ab|a)b                              True                   ab               ('a',)
(ab|a){0,1}?b                        True                   ab               ('a',)
(ab|a)*b                             True                   ab               ('a',)
(ab|a)+b                             True                   ab               ('a',)
(a|ab)*b                             True                   ab               ('a',)
(a|ab)+b                             True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)+?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(bb|a)*?b                            True                   ab               ('a',)
((?:ab|a)*?)b                        True                   ab               ('a',)
((?:a|ab)*?)b                        True                   ab               ('a',)


Behavior from regex


Regex pattern                    matched?       matched string     captured content
-------------------- -------------------- -------------------- --------------------
(ab|a)*?b                            True                   ab               ('a',)
(ab|a)+?b                            True                   ab               ('a',)
(ab|a){0,}?b                         True                   ab               ('a',)
(ab|a){0,2}?b                        True                   ab               ('a',)
(ab|a)?b                             True                   ab               ('a',)
(ab|a)??b                            True                   ab               ('a',)
(ab|a)b                              True                   ab               ('a',)
(ab|a){0,1}?b                        True                   ab               ('a',)
(ab|a)*b                             True                   ab               ('a',)
(ab|a)+b                             True                   ab               ('a',)
(a|ab)*b                             True                   ab               ('a',)
(a|ab)+b                             True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)+?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(a|ab)*?b                            True                   ab               ('a',)
(bb|a)*?b                            True                   ab               ('a',)
((?:ab|a)*?)b                        True                   ab               ('a',)
((?:a|ab)*?)b                        True                   ab               ('a',)

----------
components: Regular Expressions
files: confusing-regex-behavior.py
messages: 334560
nosy: davisjam, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Capture behavior depends on the order of an alternation
type: behavior
versions: Python 2.7, Python 3.5
Added file: https://bugs.python.org/file48085/confusing-regex-behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 09:27:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Jan 2019 14:27:47 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548858467.05.0.553457854736.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

No, removing it was accidental. But when I tried it myself with a few regular installs of 3.5 and later, none of them updated sys.path correctly, and all of them resolved the links in the loader (or perhaps the shell?).

I hadn't activated the environments, as I generally don't, but if that's required for symlinks to work here then I consider them broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 09:43:45 2019
From: report at bugs.python.org (Manjusaka)
Date: Wed, 30 Jan 2019 14:43:45 +0000
Subject: [issue35517] selector.EpollSelector: add new parameter to support
 EPOLLEXCLUSIVE
In-Reply-To: <1545042698.49.0.788709270274.issue35517@psf.upfronthosting.co.za>
Message-ID: <1548859425.14.0.658483206525.issue35517@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

ping....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35517>
_______________________________________

From report at bugs.python.org  Wed Jan 30 09:54:29 2019
From: report at bugs.python.org (Utkarsh Gupta)
Date: Wed, 30 Jan 2019 14:54:29 +0000
Subject: [issue30951] Documentation error in inspect module
In-Reply-To: <1500312575.69.0.52467451771.issue30951@psf.upfronthosting.co.za>
Message-ID: <1548860069.37.0.187942699937.issue30951@roundup.psfhosted.org>


Utkarsh Gupta <guptautkarsh2102 at gmail.com> added the comment:

Serhiy: What change d'you possibly suggest then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30951>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:00:15 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 30 Jan 2019 15:00:15 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548860415.99.0.495701094314.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:47:56 2019
From: report at bugs.python.org (Ivan Krivosheev)
Date: Wed, 30 Jan 2019 15:47:56 +0000
Subject: [issue34222] Email message serialization enters an infinite loop when
 folding non-ASCII headers with long words
In-Reply-To: <1532523404.04.0.56676864532.issue34222@psf.upfronthosting.co.za>
Message-ID: <1548863276.08.0.532325814357.issue34222@roundup.psfhosted.org>


Ivan Krivosheev <py.krivosheev at gmail.com> added the comment:

Hello Grigory. I using our patch in my project. I have some problems with your fixes.


Source text:
Subject: test ????????? ?????????? ???????????? ????????? ??????????? ? ??????? ?????????? ?? ???????? ??????????, ? ????? ????????? ? ??????? ? ?????. ?? ???? ?????? ??????????? ?????????? ??????????? ????????????? ????????? ??? ??????????? ???????????? ?????????? (???) ??????? ????? ???????? ?? ??????????? ? ????????????? ?????? ?????????????? ? ????????????? ????????????, ????????

Encoded text using thunderbird:
Subject: =?UTF-8?B?dGVzdCDQktC10L3QtdGB0YPRjdC70LAg0YHQvtCx0LjRgNCw0LXRgtGB?=
 =?UTF-8?B?0Y8g0L/QtdGA0LXRgdC80L7RgtGA0LXRgtGMINGB0YLQvtC40LzQvtGB0YLRjCA=?=
 =?UTF-8?B?0LfQsNC60LvRjtGH0LXQvdC90YvRhSDRgSDQoNC+0YHRgdC40LXQuSDQutC+0L0=?=
 =?UTF-8?B?0YLRgNCw0LrRgtC+0LIg0L3QsCDQv9C+0YHRgtCw0LLQutGDINCy0L7QvtGA0YM=?=
 =?UTF-8?B?0LbQtdC90LjQuSwg0LAg0YLQsNC60LbQtSDQvtGC0L3QvtGI0LXQvdC40Y8g0YEg?=
 =?UTF-8?B?0JzQvtGB0LrQstC+0Lkg0LIg0YbQtdC70L7QvC4g0J7QsSDRjdGC0L7QvCDQt9Cw?=
 =?UTF-8?B?0Y/QstC40Lsg0L3QsNC30L3QsNGH0LXQvdC90YvQuSDQvtC/0L/QvtC30LjRhtC4?=
 =?UTF-8?B?0LXQuSDRgdC/0LXRhtC40LDQu9GM0L3Ri9C5INC/0YDQtdC00YHRgtCw0LLQuNGC?=
 =?UTF-8?B?0LXQu9GMINCS0LXQvdC10YHRg9GN0LvRiyDQv9GA0Lgg0J7RgNCz0LDQvdC40Lc=?=
 =?UTF-8?B?0LDRhtC40Lgg0LDQvNC10YDQuNC60LDQvdGB0LrQuNGFINCz0L7RgdGD0LTQsNGA?=
 =?UTF-8?B?0YHRgtCyICjQntCQ0JMpINCT0YPRgdGC0LDQstC+INCi0LDRgNGA0LUg0JHRgNC4?=
 =?UTF-8?B?0YHQtdC90YzQviDQvdCwINCy0YvRgdGC0YPQv9C70LXQvdC40Lgg0LIg0LLQsNGI?=
 =?UTF-8?B?0LjQvdCz0YLQvtC90YHQutC+0Lwg0KbQtdC90YLRgNC1INGB0YLRgNCw0YLQtdCz?=
 =?UTF-8?B?0LjRh9C10YHQutC40YUg0Lgg0LzQtdC20LTRg9C90LDRgNC+0LTQvdGL0YUg0Lg=?=
 =?UTF-8?B?0YHRgdC70LXQtNC+0LLQsNC90LjQuSwg0L/QtdGA0LXQtNCw0LXRgg==?=

Text after decode and encode in python with our patch:
Subject: test =?utf-8?b?0JLQtdC90LXRgdGD0Y3Qu9CwINGB0L7QsdC40YDQsNC10YLRgdGP?=
 =?utf-8?b?0L/=?utf-8?q?QtdGA0LXRgdC80L7RgtGA0LXRgtGM=3F=3D_=D1=81=D1=82?=
 =?utf-8?b?0L7QuNC80L7RgdGC0Ywg0LfQsNC60LvRjtGH0LXQvdC90YvRhSDRgSDQoNC+0YE=?=
 =?utf-8?b?0YHQuNC10Lkg0LrQvtC90YLRgNCw0LrRgtC+0LIg0L3QsCDQv9C+0YHRgtCw0LI=?=
 =?utf-8?b?0LrRgyDQstC+0L7RgNGD0LbQtdC90LjQuSwg0LAg0YLQsNC60LbQtSDQvtGC0L0=?=
 =?utf-8?b?0L7RiNC10L3QuNGPINGBINCc0L7RgdC60LLQvtC5INCyINGG0LXQu9C+0LwuINCe?=
 =?utf-8?b?0LEg0Y3RgtC+0Lwg0LfQsNGP0LLQuNC7INC90LDQt9C90LDRh9C10L3QvdGL0Lkg?=
 =?utf-8?b?0L7Qv9C/0L7Qt9C40YbQuNC10Lkg0YHQv9C10YbQuNCw0LvRjNC90YvQuSDQv9GA?=
 =?utf-8?b?0LXQtNGB0YLQsNCy0LjRgtC10LvRjCDQktC10L3QtdGB0YPRjdC70Ysg0L/RgNC4?=
  =?utf-8?b?0J7RgNCz0LDQvdC40LfQsNGG0LjQuCDQsNC80LXRgNC40LrQsNC90YHQutC40YU=?=
 =?utf-8?b?0LPQvtGB0YPQtNCw0YDRgdGC0LIgKNCe0JDQkykg0JPRg9GB0YLQsNCy0L4g0KI=?=
 =?utf-8?b?0LDRgNGA0LUg0JHRgNC40YHQtdC90YzQviDQvdCwINCy0YvRgdGC0YPQv9C70LU=?=
 =?utf-8?b?0L3QuNC4INCyINCy0LDRiNC40L3Qs9GC0L7QvdGB0LrQvtC8INCm0LXQvdGC0YA=?=
 =?utf-8?b?0LUg0YHRgtGA0LDRgtC10LPQuNGH0LXRgdC60LjRhSDQuCDQvNC10LbQtNGD0L0=?=
 =?utf-8?b?0LDRgNC+0LTQvdGL0YUg0LjRgdGB0LvQtdC00L7QstCw0L3QuNC5LCDQv9C10YA=?=
 =?utf-8?b?0LXQtNCw0LXRgg==?=

Result text:
Subject: test ????????? ??????????
 =?utf-8?b?0L/QtdGA0LXRgdC80L7RgtGA0LXRgtGM?= ????????? ??????????? ? ??????? ?????????? ?? ???????? ??????????, ? ????? ????????? ? ??????? ? ?????. ?? ???? ?????? ??????????? ?????????? ??????????? ????????????? ????????? ?????????????? ?????????????????????? (???) ??????? ????? ???????? ?? ??????????? ? ????????????? ?????? ?????????????? ? ????????????? ????????????, ????????

If need, i can write simple code for reproduce bug.

----------
nosy: +ikrivosheev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34222>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:49:44 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jan 2019 15:49:44 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863384.52.0.319719291843.issue25592@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 598e15d4feaee3849a91d92c9ca51f17baafe19c by Antoine Pitrou (jdemeyer) in branch 'master':
bpo-25592: Improve documentation of distutils data_files (GH-9767)
https://github.com/python/cpython/commit/598e15d4feaee3849a91d92c9ca51f17baafe19c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:50:02 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 15:50:02 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863402.54.0.538579510936.issue25592@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:50:13 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 15:50:13 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863413.26.0.019595534732.issue25592@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11551, 11552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:50:26 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 15:50:26 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863426.65.0.346680857292.issue25592@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11551, 11552, 11553

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:54:05 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Jan 2019 15:54:05 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863645.42.0.164444636416.issue25592@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the analysis and PR!  Sorry that the slow process here was frustrating.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:56:53 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jan 2019 15:56:53 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863813.73.0.990904537567.issue25592@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset ebae1ce9c40e62ce52dc968f86ed11578d2fcdfd by Antoine Pitrou (Miss Islington (bot)) in branch '3.7':
bpo-25592: Improve documentation of distutils data_files (GH-9767) (GH-11701)
https://github.com/python/cpython/commit/ebae1ce9c40e62ce52dc968f86ed11578d2fcdfd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 10:57:30 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Jan 2019 15:57:30 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548863850.51.0.377154654092.issue25592@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixing this on 2.7 would require additional investigation (distutils might have diverged), so I'm closing now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Wed Jan 30 11:00:33 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 30 Jan 2019 16:00:33 +0000
Subject: [issue29999] repr() of ImportError misses keyword arguments name and
 path
In-Reply-To: <1491431351.79.0.0513888316468.issue29999@psf.upfronthosting.co.za>
Message-ID: <1548864033.59.0.496245885494.issue29999@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I think the issue steems from the more general #27015 for which a PR is ready that fixes the repr not only for ImportError but all other BaseException subclasses that override __init__.

----------
keywords: +patch
nosy: +remi.lapeyre
pull_requests: +11554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29999>
_______________________________________

From report at bugs.python.org  Wed Jan 30 11:06:58 2019
From: report at bugs.python.org (Bence Nagy)
Date: Wed, 30 Jan 2019 16:06:58 +0000
Subject: [issue35860] ProcessPoolExecutor subprocesses crash & break pool when
 raising an exception with keyword-only args and an arg passed to
 Exception
Message-ID: <1548864416.11.0.414806369535.issue35860@roundup.psfhosted.org>


New submission from Bence Nagy <bence at underyx.me>:

ProcessPoolExecutor's subprocesses normally transparently proxy exceptions
raised within a child to the parent process.

One special case I bumped into however causes a crash
within the stdlib code responsible for communication.
The special case is triggered when both of these are true:

1) The exception being raised uses `*` to mark arguments as keyword-only
2) The exception being raised sets a positional argument for Exception: `super().__init__("test")`

I have attached a file which demonstrates what happens
when only 1), only 2), and both 1) and 2) are true.

Running the file with Python 3.7.2 will result in this output:

```
<function works1 at 0x1010070d0> raised Works1('test')

<function works2 at 0x1016ae2f0> raised Works2()

<function breaks at 0x1016ae378> raised BrokenProcessPool('A process in the process pool was terminated abruptly while the future was running or pending.')
```

The expected result for the third call would be keeping the executor usable and printing this:

```
<function breaks at 0x1016ae378> raised Breaks('test')
```

----------
components: Library (Lib)
files: ppe_crash.py
messages: 334570
nosy: underyx
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor subprocesses crash & break pool when raising an exception with keyword-only args and an arg passed to Exception
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48086/ppe_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35860>
_______________________________________

From report at bugs.python.org  Wed Jan 30 11:33:00 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 30 Jan 2019 16:33:00 +0000
Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem -
 segmentation error
In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>
Message-ID: <1548865980.36.0.0354674377411.issue35828@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

OK. being more specific about the test situation.

When I run ./python -m test test_multiprocessing_fork all is fine. However, when I run it as: ./python -m test -j2 test_multiprocessing_main_handling test_multiprocessing_fork

test_multiprocessing_main_handling PASSes and test_multiprocessing_fork crashes (and has a segmentation core dump in the process).

----------
title: test_multiprocessing_* - crash in PyDict_GetItem - segmentation error -> test_multiprocessing_fork - crashes in PyDict_GetItem - segmentation error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35828>
_______________________________________

From report at bugs.python.org  Wed Jan 30 11:43:15 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 30 Jan 2019 16:43:15 +0000
Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem -
 segmentation error
In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>
Message-ID: <1548866595.67.0.95296761368.issue35828@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

After enabling PYTHONTHREADDEBUG=1 I got the dprintf output.

I added line info (as fixed text) asin:
Python/thread_pthread.h:
  +511  PyLockStatus
  +512  PyThread_acquire_lock_timed(PyThread_type_lock lock, PY_TIMEOUT_T microseconds,
  +513                              int intr_flag)
  +514  {
  +515      PyLockStatus success = PY_LOCK_FAILURE;
  +516      pthread_lock *thelock = (pthread_lock *)lock;
  +517      int status, error = 0;
  +518
  +519      dprintf(("519: PyThread_acquire_lock_timed(%p, %lld, %d) called\n",
  +520               lock, microseconds, intr_flag));
  +521
  +522      if (microseconds == 0) {
  +523          status = pthread_mutex_trylock( &thelock->mut );
  +524          if (status != EBUSY)
  +525              CHECK_STATUS_PTHREAD("pthread_mutex_trylock[1]");
  +526      }
  +527      else {
  +528          status = pthread_mutex_lock( &thelock->mut );
  +529          CHECK_STATUS_PTHREAD("pthread_mutex_lock[1]");
  +530      }

and can establish that USE_SEMAPHORES is not being used.

There are many reasons why - I expect - something re: Python3.5 (issue23428) talks about this routine and also something about CLOCk_MONOTONIC versus CLOCK_REALTIME (hope I spelled those right).

Further, back in Python 2.3 days - issue525532 added POSIX support for semaphores.

I would love to proceed - but particularly, issue23428 makes me think I should not think that the logic that keeps USE_SEMAPHORE is incorrect.

Help appreciated!

p.s. - deeper details

with PYTHONTHREADDEBUG=1 I no longer get a segmentation fault. Instead I get:

Total duration: 1 min 53 sec
Tests result: NO TEST RUN
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/libregrtest/runtest_mp.py", line 145, in run
    stop = self._runtest()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/libregrtest/runtest_mp.py", line 135, in _runtest
    result = json.loads(result)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/json/__init__.py", line 348, in loads
    return _default_decoder.decode(s)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Exception in thread Thread-2:
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/libregrtest/runtest_mp.py", line 145, in run
    stop = self._runtest()
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/libregrtest/runtest_mp.py", line 135, in _runtest
    result = json.loads(result)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/json/__init__.py", line 348, in loads
    return _default_decoder.decode(s)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
?

This is prefixed by:
PyThread_allocate_lock called
PyThread_allocate_lock() -> 200a9b40
519: PyThread_acquire_lock_timed(200a9b40, 0, 0) called
577: PyThread_acquire_lock_timed(200a9b40, 0, 0) -> 1
PyThread_release_lock(200a5fe0) called
519: PyThread_acquire_lock_timed(200a9b40, 0, 0) called
577: PyThread_acquire_lock_timed(200a9b40, 0, 0) -> 0
519: PyThread_acquire_lock_timed(200a9b40, 29999996, 1) called
519: PyThread_acquire_lock_timed(200fe220, 0, 0) called
577: PyThread_acquire_lock_timed(200fe220, 0, 0) -> 1
PyThread_release_lock(200fe220) called
519: PyThread_acquire_lock_timed(200fe220, 0, 0) called
577: PyThread_acquire_lock_timed(200fe220, 0, 0) -> 1
PyThread_release_lock(200fe220) called
519: PyThread_acquire_lock_timed(20156c00, 0, 0) called
577: PyThread_acquire_lock_timed(20156c00, 0, 0) -> 1
PyThread_release_lock(20156c00) called
519: PyThread_acquire_lock_timed(20156c00, 0, 0) called
577: PyThread_acquire_lock_timed(20156c00, 0, 0) -> 1
PyThread_release_lock(20156c00) called
519: PyThread_acquire_lock_timed(200fe1a0, 0, 0) called
577: PyThread_acquire_lock_timed(200fe1a0, 0, 0) -> 1
PyThread_release_lock(200fe1a0) called
PyThread_free_lock(200fe1a0) called
PyThread_free_lock(200fe220) called
PyThread_free_lock(20156c00) called
519: PyThread_acquire_lock_timed(200a5fe0, 0, 0) called
577: PyThread_acquire_lock_timed(200a5fe0, 0, 0) -> 1
519: PyThread_acquire_lock_timed(200a5fe0, 0, 0) called
577: PyThread_acquire_lock_timed(200a5fe0, 0, 0) -> 0
PyThread_release_lock(200a9b40) called
PyThread_release_lock(200a5fe0) called
577: PyThread_acquire_lock_timed(200a9b40, 29999996, 1) -> 1
519: PyThread_acquire_lock_timed(200a5fe0, 0, 0) called
577: PyThread_acquire_lock_timed(200a5fe0, 0, 0) -> 1
PyThread_release_lock(200a9b40) called
PyThread_free_lock(200a9b40) called
519: PyThread_acquire_lock_timed(200a5fe0, 0, 0) called
577: PyThread_acquire_lock_timed(200a5fe0, 0, 0) -> 0
PyThread_release_lock(200a5fe0) called
PyThread_free_lock(200c44c0) called
PyThread_free_lock(200a81c0) called
519: PyThread_acquire_lock_timed(200b7e30, 0, 0) called
577: PyThread_acquire_lock_timed(200b7e30, 0, 0) -> 1
PyThread_release_lock(200b7e30) called
PyThread_release_lock(200fd1f0) called
PyThread_free_lock(200fd1f0) called
PyThread_free_lock(200a9ac0) called
PyThread_free_lock(200a6d30) called
PyThread_free_lock(200a5fe0) called
519: PyThread_acquire_lock_timed(200a3ac0, -1, 0) called
577: PyThread_acquire_lock_timed(200a3ac0, -1, 0) -> 1
PyThread_release_lock(200a3ac0) called
PyThread_exit_thread called

== Tests result: NO TEST RUN ==


Hope this helps!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35828>
_______________________________________

From report at bugs.python.org  Wed Jan 30 11:59:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jan 2019 16:59:24 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548867564.27.0.765343075837.issue35859@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I cannot see why changing the order of the alternation should have this effect.

The first regex, r'(a|ab)*?b', looks for the first alternative group by matching left-to-right [1] stopping at the first matching alternation "a".  Roughly, the regex simplifies to r'(a)*?b' giving 'a' in the captured group.

The second regex, r'(ab|a)*?b', looks for the first  alternative group by matching left-to-right [1] stopping at the first matching alternation "ab".  Roughly, the regex simplifies to r'(ab)*?b' giving '' in the captured group.

>From there, I'm not clear on how a non-greedy kleene-star works with capturing groups and with the overall span().  A starting point would be to look at the re.DEBUG output for each pattern [2][3].

[1] From the re docs for the alternation operator:
As the target string is scanned, REs separated by '|' are tried from left to right. When one pattern completely matches, that branch is accepted. This means that once A matches, B will not be tested further, even if it would produce a longer overall match. In other words, the '|' operator is never greedy.

[2] re.DEBUG output for r'(a|ab)*?b'
 0. INFO 4 0b0 1 MAXREPEAT (to 5)
 5: REPEAT 19 0 MAXREPEAT (to 25)
 9.   MARK 0
11.   LITERAL 0x61 ('a')
13.   BRANCH 3 (to 17)
15.     JUMP 7 (to 23)
17:   branch 5 (to 22)
18.     LITERAL 0x62 ('b')
20.     JUMP 2 (to 23)
22:   FAILURE
23:   MARK 1
25: MIN_UNTIL
26. LITERAL 0x62 ('b')
28. SUCCESS

[3] re.DEBUG output for r'(ab|a)*?b'
MIN_REPEAT 0 MAXREPEAT
  SUBPATTERN 1 0 0
    LITERAL 97
    BRANCH
      LITERAL 98
    OR
LITERAL 98

 0. INFO 4 0b0 1 MAXREPEAT (to 5)
 5: REPEAT 19 0 MAXREPEAT (to 25)
 9.   MARK 0
11.   LITERAL 0x61 ('a')
13.   BRANCH 5 (to 19)
15.     LITERAL 0x62 ('b')
17.     JUMP 5 (to 23)
19:   branch 3 (to 22)
20.     JUMP 2 (to 23)
22:   FAILURE
23:   MARK 1
25: MIN_UNTIL
26. LITERAL 0x62 ('b')
28. SUCCESS

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:00:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jan 2019 17:00:30 +0000
Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem -
 segmentation error
In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>
Message-ID: <1548867630.44.0.324294744311.issue35828@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35828>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:19:54 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Jan 2019 17:19:54 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548868794.3.0.782291320784.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Okay, testing more thoroughly on 3.5, symlinks are fine from the console but not via Explorer.

Personally, I dislike that double-clicking python.exe is different from running it from the command line, but so be it. I'll add a note to the docs that this doesn't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:23:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Jan 2019 17:23:17 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1548868997.2.0.322719880697.issue35760@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug can be triggered on Linux using this patch:

diff --git a/Lib/test/test_asyncgen.py b/Lib/test/test_asyncgen.py
index 71b0968c79..5e0084dc32 100644
--- a/Lib/test/test_asyncgen.py
+++ b/Lib/test/test_asyncgen.py
@@ -668,8 +668,8 @@ class AsyncGenAsyncioTest(unittest.TestCase):
                 while True:
                     yield 1
             finally:
-                await asyncio.sleep(0.01)
-                await asyncio.sleep(0.01)
+                await asyncio.sleep(0.001)
+                await asyncio.sleep(0.001)
                 DONE = 1
 
         async def run():
@@ -678,7 +678,7 @@ class AsyncGenAsyncioTest(unittest.TestCase):
             await g.__anext__()
             del g
 
-            await asyncio.sleep(0.1)
+            await asyncio.sleep(0.005)
 
         self.loop.run_until_complete(run())
         self.assertEqual(DONE, 1)


And command:

$ ./python -m test -j8 -F test_asyncgen -m test_async_gen_asyncio_gc_aclose_09
0:00:00 load avg: 7.30 [  1] test_asyncgen passed
0:00:00 load avg: 7.30 [  2] test_asyncgen passed
0:00:00 load avg: 7.30 [  3] test_asyncgen passed
(...)
0:00:02 load avg: 7.30 [ 38] test_asyncgen passed
0:00:02 load avg: 7.30 [ 39/1] test_asyncgen failed
Task was destroyed but it is pending!
task: <Task pending name='Task-2' coro=<<async_generator_athrow without __name__>()> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7fb9ad249aa0>()]>>
test test_asyncgen failed -- Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncgen.py", line 684, in test_async_gen_asyncio_gc_aclose_09
    self.assertEqual(DONE, 1)
AssertionError: 0 != 1
0:00:02 load avg: 7.30 [ 40/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 41/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 42/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 43/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 44/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 45/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 46/1] test_asyncgen passed
0:00:03 load avg: 7.30 [ 47/1] test_asyncgen passed

== Tests result: FAILURE ==

46 tests OK.

1 test failed:
    test_asyncgen

Total duration: 3 sec 323 ms
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:23:43 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 17:23:43 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548869023.47.0.220951358075.issue35835@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cf991e653ac550a9f011631447c61ce583404a57 by Miss Islington (bot) (Jo?o Matos) in branch 'master':
bpo-35835: Add reference to Python 3.7 new breakpoint() function in pdb documentation. (GH-11691)
https://github.com/python/cpython/commit/cf991e653ac550a9f011631447c61ce583404a57


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:23:56 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 17:23:56 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548869036.68.0.0371618426737.issue35835@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11555

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:24:04 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 17:24:04 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548869044.41.0.56607460274.issue35835@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11555, 11556

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:24:11 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 17:24:11 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548869051.73.0.799153895405.issue35835@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11555, 11556, 11557

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:25:49 2019
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 30 Jan 2019 17:25:49 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548869149.62.0.249370285325.issue35835@roundup.psfhosted.org>


Mariatta Wijaya <mariatta at python.org> added the comment:

Thanks!

----------
nosy: +Mariatta
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:28:12 2019
From: report at bugs.python.org (jcrmatos)
Date: Wed, 30 Jan 2019 17:28:12 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548869292.8.0.0844060275686.issue35835@roundup.psfhosted.org>


jcrmatos <jcrmatos at gmail.com> added the comment:

Thank you all for the help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:35:49 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 30 Jan 2019 17:35:49 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548869749.21.0.87865415978.issue35857@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think the REPL could, when it formats a stack trace for printing, check every referenced source file if it's newer than its compiled .pyc (bytecode) file, and insert a warning into the stack trace if that is the case.

I don't see any use in doing this for all stack traces, so only ones that get printed out for the user could receive special treatment.

I also don't think we need to go further than that, e.g. check startup or module import time. Basically, whenever the source file is not in sync with the .pyc file, it's not unlikely that the code that is running corresponds to the .pyc file and no longer to the .py file.

Changing to target version to 3.8, since this is essentially a new feature and not acceptable as a bug fix for older versions.

----------
nosy: +scoder
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:36:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Jan 2019 17:36:54 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548869814.14.0.695282643845.issue35717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1c79891026c57046f5ac596080ea60c515e0560a by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-35717: Fix KeyError exception raised when using enums and compile (GH-11523) (GH-11669)
https://github.com/python/cpython/commit/1c79891026c57046f5ac596080ea60c515e0560a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:38:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Jan 2019 17:38:01 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548869881.98.0.366630026666.issue35717@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I was confused with PR, so here you have:

* master: https://github.com/python/cpython/pull/11523
* 3.7: https://github.com/python/cpython/pull/11669

Both are merged, so I close the issue. Thanks R?mi Lapeyre for the fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:38:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Jan 2019 17:38:33 +0000
Subject: [issue35717] enum.Enum error on sys._getframe(2)
In-Reply-To: <1547219293.78.0.972109062344.issue35717@roundup.psfhosted.org>
Message-ID: <1548869913.38.0.418036093332.issue35717@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35717>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:41:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Jan 2019 17:41:11 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1548870071.52.0.886104459623.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892 has been fixed in the development branch ("trunk"):
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=268083

I requested a fix for GCC 8.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:41:55 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 17:41:55 +0000
Subject: [issue35835] There is no mention of breakpoint() in the pdb
 documentation
In-Reply-To: <1548544149.44.0.0958996770934.issue35835@roundup.psfhosted.org>
Message-ID: <1548870115.53.0.709114250943.issue35835@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7516f265a8517e4fdc7d6e63d72ae1b57fda26ee by Miss Islington (bot) in branch '3.7':
bpo-35835: Add reference to Python 3.7 new breakpoint() function in pdb documentation. (GH-11691)
https://github.com/python/cpython/commit/7516f265a8517e4fdc7d6e63d72ae1b57fda26ee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35835>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:42:52 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 30 Jan 2019 17:42:52 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1548870172.48.0.0975131092794.issue35760@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems this used to happen rarely on Appveyor builds too in the past randomly. Past report of the same issue issue32646

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Wed Jan 30 12:45:21 2019
From: report at bugs.python.org (Eddie Elizondo)
Date: Wed, 30 Jan 2019 17:45:21 +0000
Subject: [issue35810] Object Initialization Bug with Heap-allocated Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1548870321.97.0.025710805069.issue35810@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Hi Petr,

Please take a look at the Github PR. What do you think that's missing to move this forward? I'd be more than happy to add more documentation/testing to it. Let me know what you think

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Wed Jan 30 13:18:35 2019
From: report at bugs.python.org (James Davis)
Date: Wed, 30 Jan 2019 18:18:35 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548872315.96.0.745498600802.issue35859@roundup.psfhosted.org>


James Davis <davisjam at vt.edu> added the comment:

Thanks for your thoughts, Raymond. I understand that the alternation has "short-circuit" behavior, but I still find it confusing in this case.

Consider these two:


Regex pattern                    matched?       matched string     captured content
-------------------- -------------------- -------------------- --------------------
(ab|a)*?b                            True                   ab                ('',)
(ab|a)+?b                            True                   ab                ('',)

In order to satisfy the first "(ab|a)+?" clause the regex engine has to find at least one match for (ab|a), and still match the final "b" clause of the pattern.

In this case, although "(ab|a)" will match "ab", doing so would cause the overall pattern to mismatch. So it seems like in order to obtain the match (which it does, see the second column), the regex engine must proceed past the first "ab" into the "a" part of the OR. But then I would expect the capture group to contain "a" and it does not.

For what it's worth, I also tried the match /(ab|a)*?b/ in PHP, Perl, Java, Ruby, Go, Rust and Node.js. The other 7 regex engines all matched "ab" and captured "a". Only Python's re module matches with an empty capture -- and even here it disagrees with the Python "regex" module as I noted in my initial post.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:05:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 30 Jan 2019 19:05:33 +0000
Subject: [issue35861] test_named_expressions raises SyntaxWarning
Message-ID: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

SyntaxWarning was recently added for comparison using "is" over literals with issue34850. This is raised on master for a PEP 572 related test. The warning is emitted twice which is covered with bpo-35798 and I verified the patch. The fix for this issue would be to use == as noted in the warning. 

Emily, if you can confirm my report then I would like to triage this as an easy one since the fix is simple.

# SyntaxWarning on master

?  cpython git:(master) ./python.exe Lib/test/test_named_expressions.py
Lib/test/test_named_expressions.py:168: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if (match := 10) is 10:
Lib/test/test_named_expressions.py:168: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if (match := 10) is 10:
........................................................
----------------------------------------------------------------------
Ran 56 tests in 0.010s

OK


Thanks

----------
components: Tests
messages: 334587
nosy: emilyemorehouse, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: test_named_expressions raises SyntaxWarning
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35861>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:08:25 2019
From: report at bugs.python.org (Valentin Beyer)
Date: Wed, 30 Jan 2019 19:08:25 +0000
Subject: [issue30670] pprint for dict in sorted order or insert order?
In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za>
Message-ID: <1548875305.83.0.549276418516.issue30670@roundup.psfhosted.org>


Valentin Beyer <valentinbeyer at gmail.com> added the comment:

Please reopen this.
With version 3.7 and guaranteed dict order pprint should not sort by key.

----------
nosy: +Valentin Beyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30670>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:14:25 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 30 Jan 2019 19:14:25 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548824606.25.0.597748947115.issue35857@roundup.psfhosted.org>
Message-ID: <1548875665.5.0.390692041475.issue35857@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

For information - all taken from docs and Lib/*.py

https://docs.python.org/3.7/library/traceback.html
traceback -- Print or retrieve a stack traceback
Source code: Lib/traceback.py
===
This module provides a standard interface to extract, format and print stack traces of Python programs. It exactly mimics the behavior of the Python interpreter when it prints a stack trace. This is useful when you want to print stack traces under program control, such as in a ?wrapper? around the interpreter.
===

https://github.com/python/cpython/blob/3.7/Lib/traceback.py#L344-L359
===
        for f, lineno in frame_gen:
            co = f.f_code
            filename = co.co_filename
            name = co.co_name

            fnames.add(filename)
            linecache.lazycache(filename, f.f_globals)
            # Must defer line lookups until we have called checkcache.
            if capture_locals:
                f_locals = f.f_locals
            else:
                f_locals = None
            result.append(FrameSummary(
                filename, lineno, name, lookup_line=False, locals=f_locals))
        for filename in fnames:
            linecache.checkcache(filename)
===
By the way, here fnames is a set.

https://docs.python.org/3.7/library/linecache.html#module-linecache
linecache -- Random access to text lines
===
The linecache module allows one to get any line from a Python source file, while attempting to optimize internally, using a cache, the common case where many lines are read from a single file. This is used by the traceback module to retrieve source lines for inclusion in the formatted traceback.
===

===
linecache.checkcache(filename=None)
Check the cache for validity. Use this function if files in the cache may have changed on disk, and you require the updated version. If filename is omitted, it will check all the entries in the cache.

linecache.lazycache(filename, module_globals)
Capture enough detail about a non-file-based module to permit getting its lines later via getline() even if module_globals is None in the later call. This avoids doing I/O until a line is actually needed, without having to carry the module globals around indefinitely.
===

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:45:18 2019
From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=)
Date: Wed, 30 Jan 2019 19:45:18 +0000
Subject: [issue35862] Change the environment for a new process
Message-ID: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>


New submission from Tobias D?ullary <t-dae at live.de>:

There should be a possibility to change the environment of a process created with multiprocessing.

For subprocess this is possible thanks to the "env" attribute.

Elaboration:
While it is trivial to change os.environ manually, in some cases this is not possible. 

For instance: creating a COM process on Windows; this process will always inherit the environment of the host process.
A workaround is to spawn a python process with a different environment which then will provide this to the child COM process.

----------
components: Library (Lib)
messages: 334591
nosy: r-or
priority: normal
severity: normal
status: open
title: Change the environment for a new process
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:49:33 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 30 Jan 2019 19:49:33 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548877773.95.0.947693450468.issue35859@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It looks like a bug in re to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:59:48 2019
From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=)
Date: Wed, 30 Jan 2019 19:59:48 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548878388.29.0.489412340357.issue35862@roundup.psfhosted.org>


Change by Tobias D?ullary <t-dae at live.de>:


----------
keywords: +patch
pull_requests: +11558
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:59:52 2019
From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=)
Date: Wed, 30 Jan 2019 19:59:52 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548878392.32.0.159010943934.issue35862@roundup.psfhosted.org>


Change by Tobias D?ullary <t-dae at live.de>:


----------
keywords: +patch, patch
pull_requests: +11558, 11559
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:59:55 2019
From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=)
Date: Wed, 30 Jan 2019 19:59:55 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548878395.62.0.999571913827.issue35862@roundup.psfhosted.org>


Change by Tobias D?ullary <t-dae at live.de>:


----------
keywords: +patch, patch, patch
pull_requests: +11558, 11559, 11560
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 14:59:58 2019
From: report at bugs.python.org (=?utf-8?q?Tobias_D=C3=A4ullary?=)
Date: Wed, 30 Jan 2019 19:59:58 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548878398.99.0.464607128082.issue35862@roundup.psfhosted.org>


Change by Tobias D?ullary <t-dae at live.de>:


----------
keywords: +patch, patch, patch, patch
pull_requests: +11558, 11559, 11560, 11561
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 15:19:24 2019
From: report at bugs.python.org (Rohit travels and tours)
Date: Wed, 30 Jan 2019 20:19:24 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548879564.87.0.80407382895.issue35862@roundup.psfhosted.org>


Change by Rohit travels and tours <roufique at rtat.net>:


Added file: https://bugs.python.org/file48087/core-nix.snapshot.json

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 15:20:13 2019
From: report at bugs.python.org (Rohit travels and tours)
Date: Wed, 30 Jan 2019 20:20:13 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548879613.07.0.183688442044.issue35862@roundup.psfhosted.org>


Rohit travels and tours <roufique at rtat.net> added the comment:

rtat.net

----------
nosy: +roufique7
Added file: https://bugs.python.org/file48088/bq-nix.snapshot.json

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 15:21:32 2019
From: report at bugs.python.org (Rohit travels and tours)
Date: Wed, 30 Jan 2019 20:21:32 +0000
Subject: [issue35862] Change the environment for a new process
In-Reply-To: <1548877516.06.0.747468813802.issue35862@roundup.psfhosted.org>
Message-ID: <1548879692.85.0.347738474664.issue35862@roundup.psfhosted.org>


Change by Rohit travels and tours <roufique at rtat.net>:


----------
hgrepos: +379
Added file: https://bugs.python.org/file48089/bq-nix.manifest

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35862>
_______________________________________

From report at bugs.python.org  Wed Jan 30 15:48:14 2019
From: report at bugs.python.org (Matthew Ryan)
Date: Wed, 30 Jan 2019 20:48:14 +0000
Subject: [issue28494] is_zipfile false positives
In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
Message-ID: <1548881294.15.0.438626696077.issue28494@roundup.psfhosted.org>


Change by Matthew Ryan <mjr at centauri.org>:


----------
nosy: +mryan1539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28494>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:09:30 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 30 Jan 2019 21:09:30 +0000
Subject: [issue28494] is_zipfile false positives
In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
Message-ID: <1548882570.17.0.544586043179.issue28494@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28494>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:23:57 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 30 Jan 2019 21:23:57 +0000
Subject: [issue28494] is_zipfile false positives
In-Reply-To: <1476997729.0.0.643464084789.issue28494@psf.upfronthosting.co.za>
Message-ID: <1548883437.44.0.773968415479.issue28494@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

it's a bugfix, it seems reasonable for 3.7 to me.  I agree that the previous is_zipfile check is too lenient.  I'll follow up on jjolly's PR for any specific concerns I have with the implementation.

----------
assignee: serhiy.storchaka -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28494>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:23:59 2019
From: report at bugs.python.org (Jon Ribbens)
Date: Wed, 30 Jan 2019 21:23:59 +0000
Subject: [issue35863] email.headers wraps headers badly
Message-ID: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org>


New submission from Jon Ribbens <jribbens at gmail.com>:

email.headers can wrap headers by putting a FWS as the very first thing in the output:

>>> from email.header import Header
>>> Header("a" * 67, header_name="Content-ID").encode() 
'\n aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'

i.e. it produces headers that look like this:

    Content-ID:
        blah

It is unclear to me whether this is compliant with the spec, but there seems to be little reason to do this, and good reason not to in that at the very least Outlook does not understand such headers. (e.g. if you have an HTML email with an inline image referenced by Content-ID then Outlook will not find it if the Content-ID header is wrapped as above.)

----------
components: Library (Lib)
messages: 334594
nosy: jribbens
priority: normal
severity: normal
status: open
title: email.headers wraps headers badly
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35863>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:38:25 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 30 Jan 2019 21:38:25 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548884305.48.0.298282689689.issue35854@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Okay, testing more thoroughly on 3.5, symlinks are fine from the 
> console but not via Explorer.

I gave up on using EXE symlinks with Explorer and ShellExecute[Ex]. The shell handles symlinks like shortcuts instead of leaving it up to the file system. In Windows 7, I recall it was thoroughly broken. Symlinks wouldn't even execute. In Windows 10 it's broken in many cases because of the shortcut-like behavior.

I think I know why they're doing this, but I think the fix belongs at a lower level in the system runtime library and loader. It's to accommodate the importance of the application directory. People expect a symlink to an executable to work like a shortcut. In Unix this often just works because most libraries are installed to the system, and an application's private shared libraries can use "$ORIGIN" in the binary's RPATH (or RUNPATH), which refers to the resolved (final) executable directory. In contrast, Windows doesn't use the resolved executable path for the application directory. IMO, they could use a pair of application directories at the start of the search path -- the link's directory and then the resolved executable's directory (or the DLL directory when loading a DLL). Some resources do get resolved like this already. For example, when searching for a "<local name>\<exename>.mui" language resource, in Process Monitor we see that it will first try the unresolved application directory (e.g. "C:\Temp\en-US\notepad.exe.mui") and then the resolved path (e.g. "C:\Windows\en-US\notepad.exe.mui").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:49:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Jan 2019 21:49:16 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548884956.68.0.726394449326.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a1f9a3332bd4767e47013ea787022f06b6dbcbbd by Steve Dower in branch 'master':
bpo-35854: Fix EnvBuilder and --symlinks in venv on Windows (GH-11700)
https://github.com/python/cpython/commit/a1f9a3332bd4767e47013ea787022f06b6dbcbbd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:49:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Jan 2019 21:49:27 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548884956.68.0.726394449326.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a1f9a3332bd4767e47013ea787022f06b6dbcbbd by Steve Dower in branch 'master':
bpo-35854: Fix EnvBuilder and --symlinks in venv on Windows (GH-11700)
https://github.com/python/cpython/commit/a1f9a3332bd4767e47013ea787022f06b6dbcbbd


----------
pull_requests: +11562

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 16:49:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Jan 2019 21:49:29 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548884956.68.0.726394449326.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a1f9a3332bd4767e47013ea787022f06b6dbcbbd by Steve Dower in branch 'master':
bpo-35854: Fix EnvBuilder and --symlinks in venv on Windows (GH-11700)
https://github.com/python/cpython/commit/a1f9a3332bd4767e47013ea787022f06b6dbcbbd


----------
pull_requests: +11562, 11563

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 17:14:42 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Jan 2019 22:14:42 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1548886482.72.0.479065764259.issue35854@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 03082a836b707528f885080bda9732d89849d4e3 by Miss Islington (bot) in branch '3.7':
bpo-35854: Fix EnvBuilder and --symlinks in venv on Windows (GH-11700)
https://github.com/python/cpython/commit/03082a836b707528f885080bda9732d89849d4e3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Wed Jan 30 17:40:08 2019
From: report at bugs.python.org (Emily Morehouse)
Date: Wed, 30 Jan 2019 22:40:08 +0000
Subject: [issue35861] test_named_expressions raises SyntaxWarning
In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org>
Message-ID: <1548888008.89.0.803254903937.issue35861@roundup.psfhosted.org>


Emily Morehouse <emilyemorehouse at gmail.com> added the comment:

Yes, you're exactly correct! Feel free to submit a PR and add me as a reviewer when you're ready.

----------
assignee:  -> xtreak
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35861>
_______________________________________

From report at bugs.python.org  Wed Jan 30 17:44:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jan 2019 22:44:24 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548888264.09.0.30229846208.issue35859@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm not at all clear on how these features should interact (alternation, non-greedy matching, and group capture).  Was just pointing that the first-match behavior of alternation is the documented behavior and that re.DEBUG can be used to explore what the regex is actually doing.   Whether this is correct, intended, desirable or consistent with other tools is a completely different question.  Even if not, there is a question about whether the behavior should be changed or just documented rather than risk breaking an untold number of regexes in already tested and deployed code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 17:45:37 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jan 2019 22:45:37 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548888337.11.0.844609101664.issue35859@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +effbot, serhiy.storchaka, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 18:11:43 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 30 Jan 2019 23:11:43 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548889903.99.0.66031702265.issue35859@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It matches, and the span is (0, 2).

The only way that it can match like that is for the capture group to match the 'a', and the final 'b' to match the 'b'.

Therefore, re.search(r'(ab|a)*b', 'ab').groups() should be ('a', ), as it is for the pattern with a greedy repeat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 21:20:13 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 02:20:13 +0000
Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's
 _asdict() method.
Message-ID: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Now that regular dicts are ordered and compact, it makes more sense for the _asdict() method to create a regular dict (as it did in its early days) rather than an OrderedDict.  The regular dict is much smaller, much faster, and has a much cleaner looking repr. 

Historically we would go through a deprecation period for a possibly breaking change; however, it was considered more benefit to users and less disruptive to make the update directly.  See the thread starting at: https://mail.python.org/pipermail/python-dev/2019-January/156150.html

----------
assignee: rhettinger
components: Library (Lib)
messages: 334602
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Replace OrderedDict with regular dict in namedtuple's _asdict() method.
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35864>
_______________________________________

From report at bugs.python.org  Wed Jan 30 22:28:20 2019
From: report at bugs.python.org (Ma Lin)
Date: Thu, 31 Jan 2019 03:28:20 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1548905300.62.0.776732690778.issue35859@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

You can `#define VERBOSE` in file `_sre.c`, it will print the engine's actual actions:

|02FAC684|02FC7402|MARK 0
...
|02FAC6BC|02FC7401|MARK 1

In my computer, 02FC7400 points to "ab", 02FC7401 points 'b' in "ab", 02FC7402 points to the end of "ab".

This capture group, begin at 02FC7402, end at 02FC7401. `begin > end` makes it return an empty string.

This seems a bug, the begin should at 02FC7400.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Wed Jan 30 23:25:27 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 04:25:27 +0000
Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's
 _asdict() method.
In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org>
Message-ID: <1548908727.69.0.753247569744.issue35864@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +11564
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35864>
_______________________________________

From report at bugs.python.org  Wed Jan 30 23:25:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 04:25:30 +0000
Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's
 _asdict() method.
In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org>
Message-ID: <1548908730.98.0.665368425785.issue35864@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11564, 11565
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35864>
_______________________________________

From report at bugs.python.org  Wed Jan 30 23:25:33 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 04:25:33 +0000
Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's
 _asdict() method.
In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org>
Message-ID: <1548908733.39.0.727457556209.issue35864@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11564, 11565, 11566
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35864>
_______________________________________

From report at bugs.python.org  Thu Jan 31 00:33:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 31 Jan 2019 05:33:56 +0000
Subject: [issue35861] test_named_expressions raises SyntaxWarning
In-Reply-To: <1548875131.95.0.280347289465.issue35861@roundup.psfhosted.org>
Message-ID: <1548912836.93.0.786187511836.issue35861@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Emily, I am marking this as easy since it's related to tests and doesn't affect alpha release. If no one gets to this I will raise a fix for this by Sunday.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35861>
_______________________________________

From report at bugs.python.org  Thu Jan 31 00:57:00 2019
From: report at bugs.python.org (Joseph Shen)
Date: Thu, 31 Jan 2019 05:57:00 +0000
Subject: [issue30670] pprint for dict in sorted order or insert order?
In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za>
Message-ID: <1548914220.39.0.488979367471.issue30670@roundup.psfhosted.org>


Joseph Shen <joseph.smeng at gmail.com> added the comment:

I reopened this issue, and change affected versions to 3.6, 3.7 and 3.8.

----------
status: closed -> open
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30670>
_______________________________________

From report at bugs.python.org  Thu Jan 31 00:57:26 2019
From: report at bugs.python.org (Pascal van der Donck)
Date: Thu, 31 Jan 2019 05:57:26 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1548914246.6.0.129770827597.issue20767@roundup.psfhosted.org>


Change by Pascal van der Donck <pvddonck at gmail.com>:


----------
assignee:  -> docs at python
components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, XML, asyncio, ctypes, email
nosy: +Alex.Willmer, asvetlov, barry, docs at python, larry, mrabarnett, r.david.murray, terry.reedy, yselivanov
type: compile error -> resource usage
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Thu Jan 31 01:00:11 2019
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 31 Jan 2019 06:00:11 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1548914411.29.0.548773746913.issue20767@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

It's too late to fix this for Python 3.4 and 3.5, as those are now in security-fixes-only mode.  Also, please don't select every possible component that could be remotely connected.

----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, XML, asyncio, ctypes, email
versions:  -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Thu Jan 31 01:01:45 2019
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 31 Jan 2019 06:01:45 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1548914505.56.0.796942877586.issue20767@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
priority: high -> normal
type: resource usage -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Thu Jan 31 01:14:15 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 31 Jan 2019 06:14:15 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548915255.55.0.535864356755.issue25592@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Fixing this on 2.7 would require additional investigation (distutils might have diverged)

Let's be honest, we are talking about distutils here. So it's way more likely that it didn't diverge and that the behavior is exactly the same on 2.7 and 3.8. So I would suggest to backport it to 2.7 also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Thu Jan 31 01:16:57 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 31 Jan 2019 06:16:57 +0000
Subject: [issue35857] Stacktrace shows lines from updated file on disk,
 not code actually running
In-Reply-To: <1548875665.5.0.390692041475.issue35857@roundup.psfhosted.org>
Message-ID: <20190131061651.GO1834@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> For information - all taken from docs and Lib/*.py

I'm sorry Jonathon, I don't see how they are relevant or interesting to 
the topic in hand other than "they're used to print stack traces". Okay, 
they're used to print stack traces. And...? Can you explain further why 
they are of interest?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35857>
_______________________________________

From report at bugs.python.org  Thu Jan 31 01:25:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 31 Jan 2019 06:25:20 +0000
Subject: [issue35863] email.headers wraps headers badly
In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org>
Message-ID: <1548915920.81.0.713185006453.issue35863@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +email
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35863>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:10:12 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:10:12 +0000
Subject: [issue35865] configparser document refers about random dict order
Message-ID: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>


New submission from INADA Naoki <songofacandy at gmail.com>:

GH-6819 (bpo-33504) changed OrderedDict to dict, and removed note about randomness of dict order in dict.

But it is only for 3.8.  Python 3.7 document should remove the note too.

----------
assignee: docs at python
components: Documentation
messages: 334609
nosy: docs at python, inada.naoki
priority: normal
severity: normal
status: open
title: configparser document refers about random dict order
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:13:28 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:13:28 +0000
Subject: [issue35865] configparser document refers about random dict order
In-Reply-To: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>
Message-ID: <1548922408.03.0.555755801525.issue35865@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +11567
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:13:33 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:13:33 +0000
Subject: [issue35865] configparser document refers about random dict order
In-Reply-To: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>
Message-ID: <1548922413.19.0.777917275853.issue35865@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +11567, 11568
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:13:37 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:13:37 +0000
Subject: [issue35865] configparser document refers about random dict order
In-Reply-To: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>
Message-ID: <1548922417.96.0.405253930173.issue35865@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch, patch, patch
pull_requests: +11567, 11568, 11569
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:16:48 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:16:48 +0000
Subject: [issue33504] configparser should use dict instead of OrderedDict in
 3.7+
In-Reply-To: <1526321898.65.0.682650639539.issue33504@psf.upfronthosting.co.za>
Message-ID: <1548922608.74.0.223226630612.issue33504@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +11570

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33504>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:16:57 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:16:57 +0000
Subject: [issue33504] configparser should use dict instead of OrderedDict in
 3.7+
In-Reply-To: <1526321898.65.0.682650639539.issue33504@psf.upfronthosting.co.za>
Message-ID: <1548922617.76.0.615333440297.issue33504@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +11570, 11571

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33504>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:17:09 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:17:09 +0000
Subject: [issue33504] configparser should use dict instead of OrderedDict in
 3.7+
In-Reply-To: <1526321898.65.0.682650639539.issue33504@psf.upfronthosting.co.za>
Message-ID: <1548922629.31.0.139574488818.issue33504@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
pull_requests: +11570, 11571, 11572

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33504>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:30:23 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:30:23 +0000
Subject: [issue33800] Fix default argument for parameter dict_type of
 ConfigParser/RawConfigParser
In-Reply-To: <1528401689.57.0.592728768989.issue33800@psf.upfronthosting.co.za>
Message-ID: <1548923423.4.0.434440453667.issue33800@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

This should be reverted in 3.7.
bpo-33504 changed dict_type from 3.8+, not 3.7.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33800>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:34:26 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:34:26 +0000
Subject: [issue33800] Fix default argument for parameter dict_type of
 ConfigParser/RawConfigParser
In-Reply-To: <1528401689.57.0.592728768989.issue33800@psf.upfronthosting.co.za>
Message-ID: <1548923666.95.0.216119101057.issue33800@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

I revert this change in GH-35865.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33800>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:35:33 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:35:33 +0000
Subject: [issue35865] configparser document refers about random dict order
In-Reply-To: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>
Message-ID: <1548923733.31.0.514002738754.issue35865@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

Also revert GH-7542 (bpo-33800) too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:47:55 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 08:47:55 +0000
Subject: [issue34003] csv.DictReader can return basic dict instead of
 OrderedDict
In-Reply-To: <1530301659.14.0.56676864532.issue34003@psf.upfronthosting.co.za>
Message-ID: <1548924475.57.0.465995723478.issue34003@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 9f3f0931cfc58498086d287226650599a97412bb by Raymond Hettinger (Michael Selik) in branch 'master':
bpo-34003: Use dict instead of OrderedDict in csv.DictReader (GH-8014)
https://github.com/python/cpython/commit/9f3f0931cfc58498086d287226650599a97412bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34003>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:53:05 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:53:05 +0000
Subject: [issue33800] Fix default argument for parameter dict_type of
 ConfigParser/RawConfigParser
In-Reply-To: <1528401689.57.0.592728768989.issue33800@psf.upfronthosting.co.za>
Message-ID: <1548924785.1.0.860554667832.issue33800@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

I'm sorry. bpo-35865 (GH-11711)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33800>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:53:52 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:53:52 +0000
Subject: [issue33504] configparser should use dict instead of OrderedDict in
 3.7+
In-Reply-To: <1526321898.65.0.682650639539.issue33504@psf.upfronthosting.co.za>
Message-ID: <1548924832.07.0.555701557128.issue33504@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 0897e0c597c065f043e4286d01f16f473ab664ee by Inada Naoki in branch 'master':
bpo-33504: fix wrong "versionchanged" (GH-11712)
https://github.com/python/cpython/commit/0897e0c597c065f043e4286d01f16f473ab664ee


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33504>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:54:57 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:54:57 +0000
Subject: [issue35865] configparser document refers about random dict order
In-Reply-To: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>
Message-ID: <1548924897.53.0.422153645313.issue35865@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:


New changeset 59014449721966a7890f6323616431ad869ec7cc by Inada Naoki in branch '3.7':
bpo-35865: doc: Remove wrong note and directives (GH-11711)
https://github.com/python/cpython/commit/59014449721966a7890f6323616431ad869ec7cc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:56:37 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 08:56:37 +0000
Subject: [issue35865] configparser document refers about random dict order
In-Reply-To: <1548922210.28.0.356473813231.issue35865@roundup.psfhosted.org>
Message-ID: <1548924997.64.0.809223964128.issue35865@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35865>
_______________________________________

From report at bugs.python.org  Thu Jan 31 03:59:54 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 08:59:54 +0000
Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's
 _asdict() method.
In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org>
Message-ID: <1548925194.76.0.844613775069.issue35864@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 0bb4bdf0d93b301407774c4ffd6df54cff947df8 by Raymond Hettinger in branch 'master':
bpo-35864: Replace OrderedDict with regular dict in namedtuple() (#11708)
https://github.com/python/cpython/commit/0bb4bdf0d93b301407774c4ffd6df54cff947df8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35864>
_______________________________________

From report at bugs.python.org  Thu Jan 31 04:46:00 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 09:46:00 +0000
Subject: [issue35825] Py_UNICODE_SIZE=4 fails to link on Windows
In-Reply-To: <1548412277.74.0.133748802246.issue35825@roundup.psfhosted.org>
Message-ID: <1548927960.59.0.344125238742.issue35825@roundup.psfhosted.org>


Change by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35825>
_______________________________________

From report at bugs.python.org  Thu Jan 31 05:02:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 31 Jan 2019 10:02:57 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1548928977.12.0.894979821303.issue20767@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Thu Jan 31 05:04:27 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jan 2019 10:04:27 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548929067.58.0.155615108942.issue25592@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Thu Jan 31 05:05:12 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 31 Jan 2019 10:05:12 +0000
Subject: [issue35866] concurrent.futures deadlock
Message-ID: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>


New submission from Jakub Wilk <jwilk at jwilk.net>:

The attached test program hangs eventually (it may need a few thousand of iterations).

Tested with Python v3.7.2 on Linux, amd64.

----------
components: Library (Lib)
files: cf-deadlock.py
messages: 334618
nosy: jwilk
priority: normal
severity: normal
status: open
title: concurrent.futures deadlock
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48090/cf-deadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Thu Jan 31 05:08:13 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 31 Jan 2019 10:08:13 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1548929293.39.0.0193272801299.issue25592@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Jeroen you're right.  Could you still give it a quick check?  Then I'll mark the PR for a 2.7 backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Thu Jan 31 05:26:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Jan 2019 10:26:46 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1548930406.87.0.278441928811.issue20767@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> If the intent is to use this issue to track the resolution of the original issue (clang compilation broken) and cover the new PR (which just moves the code from os detection to compiler detection), then it can remain open. Otherwise it can be closed, as the original issue 'has' been fixed.

Ok, I close the issue.

On https://github.com/python/cpython/pull/5233 bapt asked "code changes", but I don't understand what exactly and I'm not interested to continue to work on these changes. If someone is interested, please open a new issue (pointing to this one).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Thu Jan 31 05:45:59 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 31 Jan 2019 10:45:59 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1548931559.37.0.957208063557.issue35866@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Thu Jan 31 06:19:08 2019
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 31 Jan 2019 11:19:08 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1548933548.43.0.276477864195.issue12822@roundup.psfhosted.org>


INADA Naoki <songofacandy at gmail.com> added the comment:

ref: https://bugs.chromium.org/p/webrtc/issues/detail?id=9269
macOS and iOS don't support pthread_condattr_setclock yet.

----------
components: +Interpreter Core -None
versions: +Python 3.8 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Thu Jan 31 06:27:39 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 Jan 2019 11:27:39 +0000
Subject: [issue34778] Memoryview for column-major (f_contiguous) arrays from
 bytes impossible to achieve
In-Reply-To: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>
Message-ID: <1548934059.03.0.900218216678.issue34778@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

+1 for Antoine's comment - while our approach with memoryview has generally been "If you're doing serious work with n-dimensional data, you still need NumPy (or an equivalent)", we've also been open to borrowing more NumPy behaviours for memoryview as particular pain points arise, and I think that applies here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34778>
_______________________________________

From report at bugs.python.org  Thu Jan 31 06:30:08 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 Jan 2019 11:30:08 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1548934208.68.0.937772917506.issue27015@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests:  -11260

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Thu Jan 31 06:30:22 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 Jan 2019 11:30:22 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1548934222.46.0.122698891172.issue27015@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests:  -11261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Thu Jan 31 06:33:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Jan 2019 11:33:56 +0000
Subject: [issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
In-Reply-To: <1314085416.99.0.752578807259.issue12822@psf.upfronthosting.co.za>
Message-ID: <1548934436.75.0.403932720965.issue12822@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-23428: "Use the monotonic clock for thread conditions on POSIX platforms".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12822>
_______________________________________

From report at bugs.python.org  Thu Jan 31 06:40:34 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 31 Jan 2019 11:40:34 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548934834.56.0.164001389839.issue35766@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset dcfcd146f8e6fc5c2fc16a4c192a0c5f5ca8c53c by ?ukasz Langa (Guido van Rossum) in branch 'master':
bpo-35766: Merge typed_ast back into CPython (GH-11645)
https://github.com/python/cpython/commit/dcfcd146f8e6fc5c2fc16a4c192a0c5f5ca8c53c


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Thu Jan 31 08:16:38 2019
From: report at bugs.python.org (Sampsa Riikonen)
Date: Thu, 31 Jan 2019 13:16:38 +0000
Subject: [issue35867] NameError is not caught at Task execution
Message-ID: <1548940597.02.0.134680701167.issue35867@roundup.psfhosted.org>


New submission from Sampsa Riikonen <sampsa.riikonen at gmail.com>:

- Create a cofunction that raises an Exception or an Error
- Schedule that cofunction as a task
- Exceptions are raised when the task is executed OK
- However, Errors (i.e. NameError, AssertionError, etc.) are raised only at task garbage collection..!

Please try this snippet:

```
import asyncio

class HevonPaskaa:
    
    def __init__(self):
        pass
        
    async def goodfunc(self):
        await asyncio.sleep(3)
        print("Good function was called allright")
        print("While it was sleeping, hevonpaska must have been executed")

    async def hevonpaska(self):
        """When this cofunction is scheduled as a task:
        - The NameError is not raised immediately .. !
        - BaseException is raised immeadiately OK
        """
        raise NameError # WARNING: This is catched only when the program terminates
        # raise BaseException # WARNING: comment the previous line and uncomment this: this is catched immediately

    async def cofunc2(self):
        # # we'd like this to raise the NameError immediately:
        self.task = asyncio.get_event_loop().create_task(self.hevonpaska())
        self.good_task = asyncio.get_event_loop().create_task(self.goodfunc())
        # # this raises NameError immediately because the task is garbage collected:
        # self.task = None
        
    async def cofunc1(self):
        await self.cofunc2()
        print("\nwaitin' : where-t-f is the NameError hiding!?")
        await asyncio.sleep(6)
        print("Wait is over, let's exit\n")

hv = HevonPaskaa()

asyncio.get_event_loop().run_until_complete(hv.cofunc1())
```

----------
components: asyncio
messages: 334625
nosy: Sampsa Riikonen, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: NameError is not caught at Task execution
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35867>
_______________________________________

From report at bugs.python.org  Thu Jan 31 08:33:08 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 31 Jan 2019 13:33:08 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1548941588.53.0.767842472886.issue27015@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reviewing R?mi's page made me realise that a big part of the root cause here is pickle support in exceptions predating the introduction of `__getnewargs__` and `__getnewargs_ex__`.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Thu Jan 31 08:35:36 2019
From: report at bugs.python.org (Oleh Khoma)
Date: Thu, 31 Jan 2019 13:35:36 +0000
Subject: [issue35868] Support ALL_PROXY environment variable in urllib
Message-ID: <1548941734.95.0.137679013052.issue35868@roundup.psfhosted.org>


New submission from Oleh Khoma <okhoma at gmail.com>:

Please, add support for ALL_PROXY environment variable to urllib. When this environment variable is found, add same proxy for HTTP, HTTPS and FTP.

----------
components: Extension Modules
messages: 334627
nosy: Oleh Khoma
priority: normal
severity: normal
status: open
title: Support ALL_PROXY environment variable in urllib
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35868>
_______________________________________

From report at bugs.python.org  Thu Jan 31 08:35:57 2019
From: report at bugs.python.org (Oleh Khoma)
Date: Thu, 31 Jan 2019 13:35:57 +0000
Subject: [issue35868] Support ALL_PROXY environment variable in urllib
In-Reply-To: <1548941734.95.0.137679013052.issue35868@roundup.psfhosted.org>
Message-ID: <1548941757.23.0.928046531078.issue35868@roundup.psfhosted.org>


Change by Oleh Khoma <okhoma at gmail.com>:


----------
components: +Library (Lib) -Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35868>
_______________________________________

From report at bugs.python.org  Thu Jan 31 08:36:04 2019
From: report at bugs.python.org (Michael Jacob)
Date: Thu, 31 Jan 2019 13:36:04 +0000
Subject: [issue27749] multprocessing errors on Windows: WriteFile() argument 1
 must be int, not None; OSError: handle is closed
In-Reply-To: <1471028370.6.0.516756873542.issue27749@psf.upfronthosting.co.za>
Message-ID: <1548941764.06.0.245582215148.issue27749@roundup.psfhosted.org>


Michael Jacob <jacob at j-e-b.net> added the comment:

So, I'm experiencing the issue in the title, too. The pipe handle stays valid for between 5 and 60 minutes, then it goes None when written to.

I'm far from understanding that code, but this crude re-connect code seems to solve the issue for me:

In BaseProxy._callmethod, I changed:

        conn.send((self._id, methodname, args, kwds))

to:

        try:
            conn.send((self._id, methodname, args, kwds))
        except TypeError:
            self._connect()
            conn = self._tls.connection
            conn.send((self._id, methodname, args, kwds))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27749>
_______________________________________

From report at bugs.python.org  Thu Jan 31 09:30:52 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 31 Jan 2019 14:30:52 +0000
Subject: [issue35868] Support ALL_PROXY environment variable in urllib
In-Reply-To: <1548941734.95.0.137679013052.issue35868@roundup.psfhosted.org>
Message-ID: <1548945052.86.0.888238066896.issue35868@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +orsenthil
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35868>
_______________________________________

From report at bugs.python.org  Thu Jan 31 09:58:48 2019
From: report at bugs.python.org (Salvo Tomaselli)
Date: Thu, 31 Jan 2019 14:58:48 +0000
Subject: [issue29995] re.escape() escapes too much
In-Reply-To: <1491401871.1.0.717928370576.issue29995@psf.upfronthosting.co.za>
Message-ID: <1548946728.9.0.15132371096.issue29995@roundup.psfhosted.org>


Salvo Tomaselli <tiposchi at tiscali.it> added the comment:

Aaaand this broke my unit tests when moving from 3.6 to 3.7!

----------
nosy: +LtWorf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29995>
_______________________________________

From report at bugs.python.org  Thu Jan 31 10:21:52 2019
From: report at bugs.python.org (Steve Palmer)
Date: Thu, 31 Jan 2019 15:21:52 +0000
Subject: [issue35869] io.BufferReader.read() returns None
Message-ID: <1548948110.23.0.999331035986.issue35869@roundup.psfhosted.org>


New submission from Steve Palmer <steve at srpalmer.me.uk>:

class io.BufferedIOBase states "In addition, those methods [read(), readinto() and write()] can raise BlockingIOError if the underlying raw stream is in non-blocking mode and cannot take or give enough data; unlike their RawIOBase counterparts, they will never return None."

However, class.io.BufferedReader (inheriting from io.BufferedIOBase) *does* return None in this case.  Admittedly, io.BufferedReader does says it is overriding the inherited method, but I'm surprised that change in behaviour declared for buffered objects, is reverted to the RarIOBase behaviour on a more specific class.

The attached file (a little long - sorry), simulates a slow non-blocking raw file, which it wraps in a BufferReader to test the behaviour defined in BufferedIOBase.

----------
files: read2.py
messages: 334630
nosy: steverpalmer
priority: normal
severity: normal
status: open
title: io.BufferReader.read() returns None
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48091/read2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35869>
_______________________________________

From report at bugs.python.org  Thu Jan 31 10:40:05 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 31 Jan 2019 15:40:05 +0000
Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze
 default
In-Reply-To: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org>
Message-ID: <1548949205.17.0.46124549346.issue35855@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:

In my opinion, everything here is relatively minor compared to some other current issues with IDLE, e.g. some of those mentioned by Raymond Hettinger in his comments on #35196.

That being said, a few comments:

> E1. Add 'Expand' at the top of the context menu.  (I sometimes right click instead of double-clicking the squeeze label.)  (And add 'Help' at the bottom, to display an explanation of Squeezer.)

I agree. If you create an issue, I'll make a PR.

> E2. Add a hot key to expand when the text cursor is on the line with the squeeze label.

This existed in previous versions of Squeezer, but I removed it to keep things simple. It can easily be added.

> U1. If the squeeze label is near the bottom of the window, only the top few lines are made visible.

Scrolling the screen for the user should usually be avoided. With scrolling being easy these days (scroll wheels, native scrolling in touchpads, touch screens) I vote to leave this up to the user.

> U2. *Perhaps* we should put the text cursor at the beginning of the output, instead of leaving it at the next prompt, so nagivation keys work.

This would be the case when done via keyboard as suggested in E2. I'm strongly against moving the cursor upon un-squeezing text in general.


Regarding A1-A3 and the rest, I fail to see the point, but have nothing constructive to say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35855>
_______________________________________

From report at bugs.python.org  Thu Jan 31 10:56:29 2019
From: report at bugs.python.org (Steve Palmer)
Date: Thu, 31 Jan 2019 15:56:29 +0000
Subject: [issue35869] io.BufferReader.read() returns None
In-Reply-To: <1548948110.23.0.999331035986.issue35869@roundup.psfhosted.org>
Message-ID: <1548950189.55.0.263734070649.issue35869@roundup.psfhosted.org>


Steve Palmer <steve at srpalmer.me.uk> added the comment:

The description of read in io.BufferedReader.read function states "Read and return size bytes, or if size is not given or negative, until EOF or if the read call would block in non-blocking mode."  This does mention the non-block mode scenario, but I can't parse this sentence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35869>
_______________________________________

From report at bugs.python.org  Thu Jan 31 12:05:35 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jan 2019 17:05:35 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548954335.9.0.255540211973.issue35766@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +11573

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Thu Jan 31 12:05:49 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jan 2019 17:05:49 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548954349.27.0.197167606154.issue35766@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +11573, 11574

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Thu Jan 31 12:06:03 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jan 2019 17:06:03 +0000
Subject: [issue35766] Merge typed_ast back into CPython
In-Reply-To: <1547771581.08.0.389360423635.issue35766@roundup.psfhosted.org>
Message-ID: <1548954363.05.0.682714363707.issue35766@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
pull_requests: +11573, 11574, 11575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35766>
_______________________________________

From report at bugs.python.org  Thu Jan 31 12:43:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 17:43:18 +0000
Subject: [issue35864] Replace OrderedDict with regular dict in namedtuple's
 _asdict() method.
In-Reply-To: <1548901211.98.0.0872539907535.issue35864@roundup.psfhosted.org>
Message-ID: <1548956598.5.0.746845581775.issue35864@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35864>
_______________________________________

From report at bugs.python.org  Thu Jan 31 12:57:17 2019
From: report at bugs.python.org (Michael Felt)
Date: Thu, 31 Jan 2019 17:57:17 +0000
Subject: [issue35773] test_bdb fails on AIX bot (regression)
In-Reply-To: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org>
Message-ID: <1548957437.16.0.46980647432.issue35773@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Update:
buildbot at x064:[/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue]./python -m test -v test_bdb
== CPython 3.8.0a0 (heads/master-dirty:0785889468, Jan 30 2019, 16:16:31) [C]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/build/test_python_11862246
== CPU count: 8
== encodings: locale=ISO8859-15, FS=iso8859-15
Run tests sequentially
0:00:00 [1/1] test_bdb
test_down (test.test_bdb.StateTestCase) ... ok
...
test_step_at_return_with_no_trace_in_caller (test.test_bdb.IssuesTestCase) ... ok

======================================================================
FAIL: test_skip (test.test_bdb.StateTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/test_bdb.py", line 731, in test_skip
    tracer.runcall(tfunc_import)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/test_bdb.py", line 448, in __exit__
    self.test_case.fail(err_msg)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/issue/Lib/test/test_bdb.py", line 582, in fail
    raise self.failureException(msg) from None
AssertionError: encoding with 'iso8859-15' codec failed (BdbNotExpectedError: Wrong event type at expect_set item 2, got 'call'
  Expected: ('line', 3, 'tfunc_import')
  Got:      ('call', 11, 'encode'),         ('quit',),)

----------------------------------------------------------------------

Ran 31 tests in 0.392s

Is this somehow related to "encoding" as in AIX is not using utf-8 as default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35773>
_______________________________________

From report at bugs.python.org  Thu Jan 31 13:13:52 2019
From: report at bugs.python.org (Victor Porton)
Date: Thu, 31 Jan 2019 18:13:52 +0000
Subject: [issue35870] readline() specification is unclear
Message-ID: <1548958431.25.0.44536557418.issue35870@roundup.psfhosted.org>


New submission from Victor Porton <porton at narod.ru>:

In https://docs.python.org/3/library/io.html it is forgotten to say whether '\n' is appened to the return value of readline().

It is also unclear what happens if the last line not terminated by '\n' is read.

It is also unclear what is returned if a text file (say with '\r\n' terminators) is read. Is it appended to the return value '\n', '\r\n' or nothing?

----------
assignee: docs at python
components: Documentation
messages: 334634
nosy: docs at python, porton
priority: normal
severity: normal
status: open
title: readline() specification is unclear
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35870>
_______________________________________

From report at bugs.python.org  Thu Jan 31 15:38:42 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 31 Jan 2019 20:38:42 +0000
Subject: [issue35431] Add a function for computing binomial coefficients to
 the math module
In-Reply-To: <1544131082.09.0.788709270274.issue35431@psf.upfronthosting.co.za>
Message-ID: <1548967122.93.0.919119671419.issue35431@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35431>
_______________________________________

From report at bugs.python.org  Thu Jan 31 17:01:09 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 22:01:09 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548972069.31.0.903309813603.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +11576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Thu Jan 31 17:01:14 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 22:01:14 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548972074.63.0.58512067131.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +11576, 11577

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Thu Jan 31 17:01:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Jan 2019 22:01:19 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548972079.86.0.498627612463.issue35780@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +11576, 11577, 11578

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Thu Jan 31 17:45:10 2019
From: report at bugs.python.org (R. David Murray)
Date: Thu, 31 Jan 2019 22:45:10 +0000
Subject: [issue20767] Some python extensions can't be compiled with clang 3.4
In-Reply-To: <1393335198.15.0.97052317234.issue20767@psf.upfronthosting.co.za>
Message-ID: <1548974710.63.0.183697326819.issue20767@roundup.psfhosted.org>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20767>
_______________________________________

From report at bugs.python.org  Thu Jan 31 17:50:09 2019
From: report at bugs.python.org (R. David Murray)
Date: Thu, 31 Jan 2019 22:50:09 +0000
Subject: [issue35863] email.headers wraps headers badly
In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org>
Message-ID: <1548975009.64.0.66060636558.issue35863@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

That is correct folding.  The word is too long to fit within the 78 character default if put on the same line as the label, but does fit on a line by itself.

If Outlook can't understand such a header it is even more broken than I thought it was :(  You can work around the outlook but by specifying a longer-than-standard (but still RFC compliant) line length when serializing the message.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35863>
_______________________________________

From report at bugs.python.org  Thu Jan 31 17:51:15 2019
From: report at bugs.python.org (R. David Murray)
Date: Thu, 31 Jan 2019 22:51:15 +0000
Subject: [issue35863] email.headers wraps headers badly
In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org>
Message-ID: <1548975075.06.0.59696407267.issue35863@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Also note that you might want to switch to the new API, the folder it uses is smarter, although in this case I think it will produce the same result because it is the "best" rendering of the header under the circumstances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35863>
_______________________________________

From report at bugs.python.org  Thu Jan 31 18:07:04 2019
From: report at bugs.python.org (Jon Ribbens)
Date: Thu, 31 Jan 2019 23:07:04 +0000
Subject: [issue35863] email.headers wraps headers badly
In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org>
Message-ID: <1548976024.6.0.34876298094.issue35863@roundup.psfhosted.org>


Jon Ribbens <jribbens at gmail.com> added the comment:

It is not correct folding. It might not be explicitly forbidden, but it is clearly unwise, and is breaking 'conservative in what you send'. Outlook will not be the only program that fails to parse Python's output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35863>
_______________________________________

From report at bugs.python.org  Thu Jan 31 18:08:26 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 31 Jan 2019 23:08:26 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548976106.89.0.734667208115.issue35780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11579

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Thu Jan 31 18:08:30 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 31 Jan 2019 23:08:30 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548976110.59.0.92187838467.issue35780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11579, 11580

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Thu Jan 31 18:08:33 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 31 Jan 2019 23:08:33 +0000
Subject: [issue35780] Recheck logic in the C version of the lru_cache()
In-Reply-To: <1547871578.67.0.302934084247.issue35780@roundup.psfhosted.org>
Message-ID: <1548976113.77.0.463926184005.issue35780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +11579, 11580, 11581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35780>
_______________________________________

From report at bugs.python.org  Thu Jan 31 18:28:45 2019
From: report at bugs.python.org (Martin Panter)
Date: Thu, 31 Jan 2019 23:28:45 +0000
Subject: [issue35870] readline() specification is unclear
In-Reply-To: <1548958431.25.0.44536557418.issue35870@roundup.psfhosted.org>
Message-ID: <1548977325.06.0.248213750705.issue35870@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I agree that the documentation should be clearer about the first two points. Considering that the "input" function and by default the "str.splitlines" method both behave differently, I often had to re-learn this when I had less Python experience.

The expected behaviour as I understand is the line terminator is included if it was read. It is not included if the size limit or EOF was reached first. The Python 2 documentation <https://docs.python.org/2/library/stdtypes.html#file.readline> is clear about both the newline being included and EOF behaviour.

Regarding text files, if you mean the "TextIOWrapper.readline" method, I think it is reasonable to assume you get the translated line endings as specified by the constructor's "newline" argument: <https://docs.python.org/3/library/io.html#io.TextIOWrapper>. Newline='' and newline='\r\n' would keep the '\r\n' terminators, and newline=None would translate them to '\n'.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35870>
_______________________________________

From report at bugs.python.org  Thu Jan 31 19:25:51 2019
From: report at bugs.python.org (Jayanth Raman)
Date: Fri, 01 Feb 2019 00:25:51 +0000
Subject: [issue35871] Pdb NameError in generator param and list comprehension
Message-ID: <1548980749.75.0.843445055452.issue35871@roundup.psfhosted.org>


New submission from Jayanth Raman <raman.jayanth at gmail.com>:

I get a NameError for a variable in the generator param of a function or in a list comprehension.  See example below.  The variable is available to the program, but not to the interactive Pdb shell.

# Test file:

def main(nn=10):
    xx = list(range(nn))
    breakpoint()
    for ii in range(nn):
        num = sum(xx[jj] for jj in range(nn))
    print(f'xx={xx}')

if __name__ == '__main__':
    main()


$ python3
Python 3.7.2 (default, Jan 13 2019, 12:50:15)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

$ python3 /tmp/test.py
> /tmp/test.py(5)main()
-> for ii in range(nn):
(Pdb) n
> /tmp/test.py(6)main()
-> num = sum(xx[jj] for jj in range(nn))
(Pdb) sum(xx[jj] for jj in range(nn))
*** NameError: name 'xx' is not defined
(Pdb) [xx[jj] for jj in range(nn)]
*** NameError: name 'xx' is not defined
(Pdb) c
xx=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]


FWIW python3 is a homebrew installation.  I had the same issue with 3.7.0 as well (also homebrew):
Python 3.7.0 (default, Sep 18 2018, 18:47:22)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin

----------
components: Interpreter Core
messages: 334639
nosy: jayanth
priority: normal
severity: normal
status: open
title: Pdb NameError in generator param and list comprehension
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35871>
_______________________________________

From report at bugs.python.org  Thu Jan 31 19:31:03 2019
From: report at bugs.python.org (Chris Langton)
Date: Fri, 01 Feb 2019 00:31:03 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1548981063.8.0.961679720975.issue33081@roundup.psfhosted.org>


Chris Langton <chrislangton84 at gmail.com> added the comment:

@pitrou I am interested in a fix for Python 2.7 because in Python 3.x the manner in which arithmetic is output is not arbitrary precise.

So I will continue using Python 2.7 until another language I am familiar with that has superior arbitrary precise arithmetic compared to python 3.x reaches a point where the lib ecosystem is as mature as python 2.7

I heavily use multiprocessing and have many use cases where i work around this issue, because i encounter it almost every time i find i need multiprocessing, basically i decide i need multiprocessing when i have too many external resources being processed by 1 CPU, meaning that multiprocessing will be managing thousands of external resources on immediate use!

I work around this issue with this solution instead of the Queue with always failed!

========================================================================================

#!/usr/bin/env python      

import multiprocessing, time

ARBITRARY_DELAY = 10

processes = []
for data in parse_file(zonefile_path, regex):
    t = multiprocessing.Process(target=write_to_json, args=(data, ))
    processes.append(t)

i = 0
for one_process in processes:
    i += 1
    if i % 1000 == 0:
        time.sleep(ARBITRARY_DELAY)
    one_process.start()

for one_process in processes:
    one_process.join()

========================================================================================

At the time (years ago) i don't think i knew enough about fd to be good enough to solve the root cause (or be elegant) and i've reused this code every time Queue failed me (every time i use Queue basically)

To be frank, i ask anyone and they say Queue is flawed.

Now, I am older, and I had some free time, I decided to fix my zonefile parsing scripts and use more elegant solutions, i finally looked at the old code i reused in many projects and identified it was actually a fd issue (yay for knowledge) and was VERY disappointed to see here that you didn't care to solve the problem for python 2.7.. very unprofessional..

Now i am disappointed to by unpythonic and add to my script gc... you're unprofessionalism now makes me be unprofessional

----------
nosy: +Chris Langton

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Jan 31 20:29:59 2019
From: report at bugs.python.org (Chris Langton)
Date: Fri, 01 Feb 2019 01:29:59 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1548984599.6.0.785921805558.issue33081@roundup.psfhosted.org>


Chris Langton <chrislangton84 at gmail.com> added the comment:

interestingly, while it is expected Process or Queue would actually close resource file descriptors and doesn't because a dev decided they prefer to defer to the user how to manage gc themselves, the interesting thing is if you 'upgrade' your code to use a pool, the process fd will be closed as the pool will destroy the object (so it is gc more often);

Say you're limited to a little over 1000 fd in your o/s you can do this

#######################################################################

import multiprocessing
import json


def process(data):
    with open('/tmp/fd/%d.json' % data['name'], 'w') as f:
        f.write(json.dumps(data))
    return 'processed %d' % data['name']

if __name__ == '__main__':
    pool = multiprocessing.Pool(1000)
    try:
        for _ in range(10000000):
            x = {'name': _}
            pool.apply(process, args=(x,))
    finally:
        pool.close()
        del pool

#######################################################################

only the pool fd hangs around longer then it should, which is a huge improvement, and you might not find a scenario where you need many pool objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Thu Jan 31 20:46:34 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 01 Feb 2019 01:46:34 +0000
Subject: [issue35846] Incomplete documentation for re.sub
In-Reply-To: <1548749168.19.0.209945761228.issue35846@roundup.psfhosted.org>
Message-ID: <1548985594.02.0.357124878488.issue35846@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I wonder if possible that c not in ASCIILETTERS when we get KeyError?

    if c in ASCIILETTERS:
        raise s.error('bad escape %s' % this, len(this))

----------
nosy: +Windson Yang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35846>
_______________________________________

From report at bugs.python.org  Thu Jan 31 20:51:06 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 01 Feb 2019 01:51:06 +0000
Subject: [issue35868] Support ALL_PROXY environment variable in urllib
In-Reply-To: <1548941734.95.0.137679013052.issue35868@roundup.psfhosted.org>
Message-ID: <1548985866.17.0.306499640251.issue35868@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

This is not a bug, it would be better to submit your ideas to python-ideas mail-list

----------
nosy: +Windson Yang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35868>
_______________________________________

From report at bugs.python.org  Thu Jan 31 20:57:21 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 01 Feb 2019 01:57:21 +0000
Subject: [issue35858] Consider adding the option of running shell/console
 commands inside the REPL
In-Reply-To: <1548856317.43.0.990558066571.issue35858@roundup.psfhosted.org>
Message-ID: <1548986241.56.0.544179824205.issue35858@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Hello, jcrmatos. Maybe you can submit your idea to python-ideas mail-list.

----------
nosy: +Windson Yang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35858>
_______________________________________

From report at bugs.python.org  Thu Jan 31 21:30:34 2019
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Feb 2019 02:30:34 +0000
Subject: [issue35863] email.headers wraps headers badly
In-Reply-To: <1548883437.25.0.0584466696793.issue35863@roundup.psfhosted.org>
Message-ID: <1548988234.16.0.740084665135.issue35863@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The rules are: lines should be less than 78 characters; and that lines may be broken only at FWS (folding whitespace), not in the middle of words.  Putting these rules together, you get the result that the email library produces.  "Conservative in what you send" means *following the RFC rules*, which is what the code does.  The failure here is on the Outlook side, which is supposed to be being "liberal in what you accept".  Which it is clearly not doing.

In case you want to read the RFCs, which I just reviewed, Content-ID is defined to have the same syntax as Message-ID, and Message-Id is defined as "Message-ID:" msg-id CRLF, while 'msg-id' is defined as:

    msg-id          =       [CFWS] "<" id-left "@" id-right ">" [CFWS]

Which means that a fold is permitted before the id itself.

We could consider an "enhancement" request to cater to Outlook's deficiency, since email clients that are actually limited to 78 character lines are vanishingly rare these days.  The change would only be made in the new API folder, and I myself wouldn't have the time (or desire :) to work on it, but if you want to submit an issue as see what the other email team members think and produce a PR if the vote is positive, that's fine by me.

Do you know if it is all headers that Outlook has this problem with, or only some?  I will admit that it has been long enough since I implemented this that I can't confirm that I made sure it was legal to fold *every* header after the colon, but I'm pretty sure I did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35863>
_______________________________________

From report at bugs.python.org  Thu Jan 31 22:02:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2019 03:02:05 +0000
Subject: [issue34003] csv.DictReader can return basic dict instead of
 OrderedDict
In-Reply-To: <1530301659.14.0.56676864532.issue34003@psf.upfronthosting.co.za>
Message-ID: <1548990125.04.0.471036744115.issue34003@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34003>
_______________________________________

From report at bugs.python.org  Thu Jan 31 22:02:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2019 03:02:18 +0000
Subject: [issue34003] csv.DictReader can return basic dict instead of
 OrderedDict
In-Reply-To: <1530301659.14.0.56676864532.issue34003@psf.upfronthosting.co.za>
Message-ID: <1548990138.95.0.408601595438.issue34003@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution: not a bug -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34003>
_______________________________________

From report at bugs.python.org  Thu Jan 31 23:02:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Feb 2019 04:02:57 +0000
Subject: [issue35871] Pdb NameError in generator param and list comprehension
In-Reply-To: <1548980749.75.0.843445055452.issue35871@roundup.psfhosted.org>
Message-ID: <1548993777.46.0.234201284062.issue35871@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. This seems related to issue21161 and issue26072 that contain explanation about scope where exec is called with the code and patches that fix this issue. As a possible workaround in the issues you can use "interact" command to get to a REPL where you can evaluate and exit back to pdb.

----------
nosy: +xdegaye, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35871>
_______________________________________