From report at bugs.python.org  Sun Dec  1 04:13:41 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 09:13:41 +0000
Subject: [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1575191621.69.0.114417321639.issue28805@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

PR 14079 has been merged, is there anything left as unresolved about this issue?

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 05:40:54 2019
From: report at bugs.python.org (Ankur)
Date: Sun, 01 Dec 2019 10:40:54 +0000
Subject: [issue38948] os.module.ismount() returns true in python 3.7.4 and
 false in 2.7.14
Message-ID: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>


New submission from Ankur <jainankur11788 at gmail.com>:

Tested with following lines of code on windows 10:

import os.path
print(os.path.ismount("F:"))

The above statement returns true in python 3.7.4 and false in 2.7.14

Note that F: drive does not have any mount points.
Somehow, python 3.7.4 returns true for all drive letters except C:

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 357674
nosy: jainankur
priority: normal
severity: normal
status: open
title: os.module.ismount() returns true in python 3.7.4 and false in 2.7.14
versions: Python 3.7

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

From report at bugs.python.org  Sun Dec  1 05:42:23 2019
From: report at bugs.python.org (Ankur)
Date: Sun, 01 Dec 2019 10:42:23 +0000
Subject: [issue38948] os.path.ismount() returns true in python 3.7.4 and false
 in 2.7.14
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575196943.78.0.736932338551.issue38948@roundup.psfhosted.org>


Change by Ankur <jainankur11788 at gmail.com>:


----------
title: os.module.ismount() returns true in python 3.7.4 and false in 2.7.14 -> os.path.ismount() returns true in python 3.7.4 and false in 2.7.14

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

From report at bugs.python.org  Sun Dec  1 05:50:39 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Sun, 01 Dec 2019 10:50:39 +0000
Subject: [issue38948] os.path.ismount() returns true in python 3.7.4 and false
 in 2.7.14
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575197439.39.0.391506944836.issue38948@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

related: issue28859

----------
nosy: +lazka

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

From report at bugs.python.org  Sun Dec  1 06:59:07 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 11:59:07 +0000
Subject: [issue37496] Support annotations in signature strings.
In-Reply-To: <1562197526.36.0.0415942737779.issue37496@roundup.psfhosted.org>
Message-ID: <1575201547.99.0.451372253821.issue37496@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

We have exposed Tools/unparse.py under ast module, so that option also can help. @potomak are you still interested in working on this issue?

----------
nosy: +BTaskaya, pablogsal

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

From report at bugs.python.org  Sun Dec  1 07:13:25 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 12:13:25 +0000
Subject: [issue16649] Add a PyCF_DISPLAY_EXPRESSION_RESULTS flag
In-Reply-To: <1355034868.91.0.795623819186.issue16649@psf.upfronthosting.co.za>
Message-ID: <1575202405.61.0.283002085114.issue16649@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 07:16:25 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 12:16:25 +0000
Subject: [issue4724] setting f_exc_traceback aborts in debug builds
In-Reply-To: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za>
Message-ID: <1575202585.48.0.699468619265.issue4724@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

This issue looks like specific to 2.7, which is almost dead. Is there any interest about adding this to 2.7 branch?

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 07:45:43 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 01 Dec 2019 12:45:43 +0000
Subject: [issue38947] dataclass defaults behave inconsistently for
 init=True/init=False when default is a descriptor
In-Reply-To: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>
Message-ID: <1575204343.96.0.156417996012.issue38947@roundup.psfhosted.org>


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


----------
assignee:  -> eric.smith

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

From report at bugs.python.org  Sun Dec  1 07:54:23 2019
From: report at bugs.python.org (Itay azolay)
Date: Sun, 01 Dec 2019 12:54:23 +0000
Subject: [issue31821] pause_reading() doesn't work from connection_made()
In-Reply-To: <1508438943.14.0.213398074469.issue31821@psf.upfronthosting.co.za>
Message-ID: <1575204863.03.0.522255225228.issue31821@roundup.psfhosted.org>


Change by Itay azolay <itayazolay at gmail.com>:


----------
pull_requests: +16904
pull_request: https://github.com/python/cpython/pull/17425

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

From report at bugs.python.org  Sun Dec  1 09:01:26 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 01 Dec 2019 14:01:26 +0000
Subject: [issue38949] incorrect prefix,
 exec_prefix in distutils.command.install
Message-ID: <1575208886.3.0.139345727722.issue38949@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

In function finalize_options() of Lib/distutils/command/install.py at

https://github.com/python/cpython/blob/575d0b46d122292ca6e0576a91265d7abf7cbc3d/Lib/distutils/command/install.py#L284

(prefix, exec_prefix) is set using get_config_vars(). This may be incorrect when Python has been manually copied in another location from the location where it has been installed with 'make install'. We should use sys.prefix and sy.exec_prefix instead, those values are calculated by getpath.c instead of being retrieved from the sysconfigdata module.

----------
components: Distutils
messages: 357678
nosy: dstufft, eric.araujo, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: incorrect prefix, exec_prefix in distutils.command.install
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Dec  1 09:01:56 2019
From: report at bugs.python.org (Giovanni Cappellotto)
Date: Sun, 01 Dec 2019 14:01:56 +0000
Subject: [issue37496] Support annotations in signature strings.
In-Reply-To: <1575201547.99.0.451372253821.issue37496@roundup.psfhosted.org>
Message-ID: <CANCHDOoVBQz8rNErRANd_aNi8e7a2ZB87hpAg9MZn89d7NBa+w@mail.gmail.com>


Giovanni Cappellotto <potomak84 at gmail.com> added the comment:

Thanks for the info.

Yes, I?m still interested in working on the issue, but lately I didn?t have
much time to do it.

If this is a high priority feel free to re-assign to someone else,
otherwise I?ll start working on it next week.

On Sun, Dec 1, 2019 at 6:59 AM Batuhan <report at bugs.python.org> wrote:

>
> Batuhan <batuhanosmantaskaya at gmail.com> added the comment:
>
> We have exposed Tools/unparse.py under ast module, so that option also can
> help. @potomak are you still interested in working on this issue?
>
> ----------
> nosy: +BTaskaya, pablogsal
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue37496>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Dec  1 09:15:33 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 01 Dec 2019 14:15:33 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575209733.4.0.265806936755.issue38941@roundup.psfhosted.org>


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

Not so quick. :) You're probably aware of the details, but still, let me state clearly what this is about, to make sure that we're all on the same page here.
(I'm also asking in Serhiy, because he did quite some work on ET in the past and has experience with it.)

The Element class in ElementTree represents an XML tag, but it also mimics a sequence container of child elements. Its behaviour is quite list-like, in that it supports indexing and slicing of its children "list", and also has an "append()" method to add one at the end. All of this is a nice and simple API, so what's the catch?

The gotcha is the behaviour of "__bool__". Following the sequence protocol, the truth value of an Element depends on its children. No children ? false. Has children, true. While this makes sense from the sequence protocol side, I don't think it is what users expect. In Python, it is very common to say "if something: ?" in order to test if "something" is "a thing". When doing this with Elements, users usually don't think of the element's children but the Element itself, often because they got it back from from kind of tree search, as in the OP's example using ".find()".

I would argue that this is brittle, because it works when testing with Elements that happen to have children, but it fails when the Element that was found has no children. The intention of the "FutureWarning" was to allow changing the behaviour at some point to always return true as the truth value, i.e. to remove the "__bool__" implementation all together.

This
1) fixes the behaviour for broken code that intended to test if it "is a thing"
2) does not change the behaviour when testing Elements (for whatever reason) that have children
3) returns true instead of false when truth-testing Elements that have no children, whether the code originally expected this or not.

The main question now is: what is more common? Code that only accidentally works because it didn't get in touch with child-free (leaf-)elements yet? Or code that would start failing with this change because it really wants to find out if an Element has children by truth-testing it.

I'm sure that both exist, because I have seen both, and my very limited *feeling* from what I've seen is that there's more brittle code out there than intentional code that truth-tests Elements, and that future users are also more likely to get it wrong until they get bitten by it and learn the actual meaning of the truth-test.

But, we don't know, and this isn't something to easily find out via a code search. I'm personally more leaning towards changing the behaviour to help new users, but lacking enough evidence, not changing something long-standing is always the safer choice. I'm aware that I will have to take the "final" decision in the end, but would be happy to hear some more intuitions, ideas or even data points first.

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

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

From report at bugs.python.org  Sun Dec  1 09:30:00 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 01 Dec 2019 14:30:00 +0000
Subject: [issue38950] argparse uses "optional arguments" for "keyword
 arguments"
Message-ID: <1575210600.45.0.569419059905.issue38950@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

The argparse module incorrectly uses the terms "optional arguments" for keyword arguments.

For instance this argument parser takes a required keyword argument and an optional positional argument, but classifies the former as an "optional argument" and the latter as a "positional argument":

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', required=True)
_StoreAction(option_strings=['--foo'], dest='foo', nargs=None, const=None, default=None, type=None, choices=None, help=None, metavar=None)
>>> parser.add_argument('bar', nargs='?')
_StoreAction(option_strings=[], dest='bar', nargs='?', const=None, default=None, type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args(['-h'])
usage: [-h] --foo FOO [bar]

positional arguments:
  bar

optional arguments:
  -h, --help  show this help message and exit
  --foo FOO

Since the actual classification seems to distinguish positional from keyword arguments instead of required from optional arguments, I think that the "optional arguments:" section should be renamed to "keyword arguments:".

----------
components: Library (Lib)
messages: 357681
nosy: bethard, maggyero, rhettinger
priority: normal
severity: normal
status: open
title: argparse uses "optional arguments" for "keyword arguments"
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec  1 11:55:20 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 01 Dec 2019 16:55:20 +0000
Subject: [issue38948] os.path.ismount() returns true in python 3.7.4 and false
 in 2.7.14
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575219320.03.0.98437852563.issue38948@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +Windows -2to3 (2.x to 3.x conversion tool)
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Sun Dec  1 12:32:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2019 17:32:09 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575221529.66.0.721902509233.issue38941@roundup.psfhosted.org>


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

Stefan's arguments looked reasonable to me. I supported deprecating Element.__bool__. This was an old plan, although we failed with deprecation in the C implementation (this is not the first oversight in deprecations in ElementTree).

But there is a problem: removing __bool__ will not change the value of bool(element). It will still return False for an Element without children, because bool() falls back to __len__ if __bool__ is not defined, and Element.__len__ is defined. So we will need either to define Element.__bool__ always returning True, and this will be the first case when __bool__ and __len__ return inconsistent values, or to deprecate __len__ (and perhaps __getitem__) that goes too far from the initial plan.

So now I am not sure. Making Element.__bool__ always returning True or raising an exception could help to fix some bugs in user code. But this differs from common behavior of sequence-like types in Python. On other hand, we have a precedence: bool(NotImplemented) raises an exception now (this also can save from common errors).

When I started to write this message I was -0 for changing Element.__bool__. Now I am +0, after considering all arguments that came in my mind, but still have doubts. Can we ask some of the language ideologues?

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Sun Dec  1 13:35:44 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 18:35:44 +0000
Subject: [issue32894] AST unparsing of infinity numbers
In-Reply-To: <1519215659.19.0.467229070634.issue32894@psf.upfronthosting.co.za>
Message-ID: <1575225344.48.0.85301274366.issue32894@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
versions: +Python 3.9

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

From report at bugs.python.org  Sun Dec  1 13:35:53 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 18:35:53 +0000
Subject: [issue32894] AST unparsing of infinity numbers
In-Reply-To: <1519215659.19.0.467229070634.issue32894@psf.upfronthosting.co.za>
Message-ID: <1575225353.12.0.470763109229.issue32894@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 13:38:27 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 18:38:27 +0000
Subject: [issue32894] AST unparsing of infinity numbers
In-Reply-To: <1519215659.19.0.467229070634.issue32894@psf.upfronthosting.co.za>
Message-ID: <1575225507.06.0.658341659184.issue32894@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +16905
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17426

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

From report at bugs.python.org  Sun Dec  1 13:38:45 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 01 Dec 2019 18:38:45 +0000
Subject: [issue38951] Use threading.main_thread() check in asyncio
Message-ID: <1575225525.0.0.724928399081.issue38951@roundup.psfhosted.org>


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

Now we use private `isinstance(thread, threading._MainThread)` check.

main_thread() function was added in Python 3.4 by me to avoid it.
Sorry, I forgot to update asyncio code.

The fix is trivial, I very appreciate if somebody will take care.

----------
components: asyncio
keywords: easy
messages: 357683
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Use threading.main_thread() check in asyncio
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Dec  1 13:39:05 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 01 Dec 2019 18:39:05 +0000
Subject: [issue38951] Use threading.main_thread() check in asyncio
In-Reply-To: <1575225525.0.0.724928399081.issue38951@roundup.psfhosted.org>
Message-ID: <1575225545.15.0.578831963506.issue38951@roundup.psfhosted.org>


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


----------
versions:  -Python 3.8

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

From report at bugs.python.org  Sun Dec  1 13:50:20 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 18:50:20 +0000
Subject: [issue35632] support unparse for Suite ast
In-Reply-To: <1546365770.39.0.971588675244.issue35632@roundup.psfhosted.org>
Message-ID: <1575226220.65.0.51980803457.issue35632@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Tools/parser/unparse.py has been moved under ast module and exposed via ast.unparse() interface. If you want to support custom AST statements, the current version is incapable of doing such changes because of the real unparser class is private. As a workaround you can import it and subclass it /assign a method and then use ast.unparse() but that is a hacky way and there is no one who can guarantee if that unparser class will change its API or not. Currently it uses NodeVisitor API. Also you can use Berker's astor project to do this job, which gives you ability of changing source generator class.

----------
components: +Library (Lib) -Demos and Tools
nosy: +BTaskaya, pablogsal
versions: +Python 3.9 -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  Sun Dec  1 13:54:10 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 18:54:10 +0000
Subject: [issue19541] ast.dump(indent=True) prettyprinting
In-Reply-To: <1384060618.33.0.960245227555.issue19541@psf.upfronthosting.co.za>
Message-ID: <1575226450.1.0.543579748303.issue19541@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

issue 37995 has added pretty printing to the ast.dump, IMHO this issue can be closed.

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 13:58:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2019 18:58:56 +0000
Subject: [issue19541] ast.dump(indent=True) prettyprinting
In-Reply-To: <1384060618.33.0.960245227555.issue19541@psf.upfronthosting.co.za>
Message-ID: <1575226736.34.0.220530208227.issue19541@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> Multiline ast.dump()

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

From report at bugs.python.org  Sun Dec  1 14:09:22 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 19:09:22 +0000
Subject: [issue38702] Adding new types to parser/unparse.py
In-Reply-To: <1572977826.42.0.982480683243.issue38702@roundup.psfhosted.org>
Message-ID: <1575227362.56.0.471127940077.issue38702@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> be changed to span across more number of lines?
Yes, that changed in ast._Unparser, and i agree with Serhiy. There is no need for supporting that old constant nodes. IMHO this issue can be closed

----------
nosy: +BTaskaya, pablogsal

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

From report at bugs.python.org  Sun Dec  1 14:18:20 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 19:18:20 +0000
Subject: [issue21992] New AST node Else() should be introduced
In-Reply-To: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>
Message-ID: <1575227900.75.0.699476643541.issue21992@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

IMHO there are no need to keep this issue open according to opinions of core developers, so can this be closed or it needs more discussion (which i prefer to do on mailing lists)?

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 14:20:28 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 01 Dec 2019 19:20:28 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575228028.96.0.990212152079.issue38941@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I'm +1 on adding the deprecation and changing it to an error in the future.

I think it's an anti-pattern that objects with complex behavior that includes some sequence behavior allow the fallback behavior for checking the empty sequence. I recall being bitten by this nearly 20 years ago (at Zope) when some database class used this pattern -- somehow the app ended up thinking there was no database at all when in fact there was one but it was empty, and it reinitialized the database with bad results.

The fallback from truth testing to __len__() is built into the language and cannot be changed, but we *can* override __bool__() to raise an exception, and I think that's what we should do. (Clearly that's also what we were planning to do, hence the warning in the Python version.)

----------

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

From report at bugs.python.org  Sun Dec  1 14:20:32 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 19:20:32 +0000
Subject: [issue36000] __debug__ is a keyword but not a keyword
In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org>
Message-ID: <1575228032.24.0.504136870791.issue36000@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 14:25:30 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 19:25:30 +0000
Subject: [issue27119] `compile` doesn't compile into an AST object as specified
In-Reply-To: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>
Message-ID: <1575228330.79.0.806250349636.issue27119@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec  1 14:25:42 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 19:25:42 +0000
Subject: [issue34000] Document when compile returns a code object v. AST
In-Reply-To: <1530287332.99.0.56676864532.issue34000@psf.upfronthosting.co.za>
Message-ID: <1575228342.63.0.856830772064.issue34000@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I think this is a duplicate of issue 27119

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 14:32:13 2019
From: report at bugs.python.org (Ido Michael)
Date: Sun, 01 Dec 2019 19:32:13 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1575228733.45.0.810829545937.issue37883@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +16906
pull_request: https://github.com/python/cpython/pull/17427

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

From report at bugs.python.org  Sun Dec  1 14:35:30 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 01 Dec 2019 19:35:30 +0000
Subject: [issue33754] f-strings should be part of the Grammar
In-Reply-To: <1528030778.27.0.592728768989.issue33754@psf.upfronthosting.co.za>
Message-ID: <1575228930.05.0.373956206346.issue33754@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  1 14:38:52 2019
From: report at bugs.python.org (Ido Michael)
Date: Sun, 01 Dec 2019 19:38:52 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1575229132.98.0.207045419316.issue37883@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Hey Tal, created a new PR: GH-17427
Also fixed the signed CLA issue

----------

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

From report at bugs.python.org  Sun Dec  1 14:59:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2019 19:59:06 +0000
Subject: [issue38702] Adding new types to parser/unparse.py
In-Reply-To: <1572977826.42.0.982480683243.issue38702@roundup.psfhosted.org>
Message-ID: <1575230346.59.0.62956090367.issue38702@roundup.psfhosted.org>


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

We usually do not accept cosmetic changes. If these lines be changed for other reasons (fixing a bug, adding new feature), their style can be changed.

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

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

From report at bugs.python.org  Sun Dec  1 15:00:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2019 20:00:11 +0000
Subject: [issue21992] New AST node Else() should be introduced
In-Reply-To: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>
Message-ID: <1575230411.19.0.941585136804.issue21992@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/issue21992>
_______________________________________

From report at bugs.python.org  Sun Dec  1 15:07:51 2019
From: report at bugs.python.org (Ido Michael)
Date: Sun, 01 Dec 2019 20:07:51 +0000
Subject: [issue34344] Fix the docstring for
 AbstractEventLoopPolicy.get_event_loop
In-Reply-To: <1533549887.39.0.56676864532.issue34344@psf.upfronthosting.co.za>
Message-ID: <1575230871.48.0.340467328957.issue34344@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

@yselivanov

Can we close this?

----------

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

From report at bugs.python.org  Sun Dec  1 15:09:59 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 20:09:59 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1575230999.85.0.540233580921.issue37883@roundup.psfhosted.org>


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


----------
pull_requests: +16907
pull_request: https://github.com/python/cpython/pull/17428

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

From report at bugs.python.org  Sun Dec  1 15:10:11 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 20:10:11 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1575231011.5.0.372806231948.issue37883@roundup.psfhosted.org>


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


----------
pull_requests: +16908
pull_request: https://github.com/python/cpython/pull/17429

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

From report at bugs.python.org  Sun Dec  1 15:10:18 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 20:10:18 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1575231018.15.0.697222582437.issue37883@roundup.psfhosted.org>


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


----------
pull_requests: +16909
pull_request: https://github.com/python/cpython/pull/17430

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

From report at bugs.python.org  Sun Dec  1 15:32:39 2019
From: report at bugs.python.org (Tal Einat)
Date: Sun, 01 Dec 2019 20:32:39 +0000
Subject: [issue37883] threading.Lock.locked is not documented
In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org>
Message-ID: <1575232359.03.0.294953729713.issue37883@roundup.psfhosted.org>


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

Thanks for the report R?mi and for the PR Ido!

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

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

From report at bugs.python.org  Sun Dec  1 18:06:42 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 23:06:42 +0000
Subject: [issue38449] regression - mimetypes guess_type is confused by ;
 in the filename
In-Reply-To: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>
Message-ID: <1575241602.11.0.184405818689.issue38449@roundup.psfhosted.org>


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


----------
pull_requests: +16910
pull_request: https://github.com/python/cpython/pull/17431

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

From report at bugs.python.org  Sun Dec  1 18:06:39 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 01 Dec 2019 23:06:39 +0000
Subject: [issue38449] regression - mimetypes guess_type is confused by ;
 in the filename
In-Reply-To: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>
Message-ID: <1575241599.78.0.713862262848.issue38449@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:


New changeset 2fe4c48917c2d1b40cf063c6ed22ae2e71f4cb62 by Abhilash Raj (Dong-hee Na) in branch 'master':
bpo-38449: Add URL delimiters test cases (#16729)
https://github.com/python/cpython/commit/2fe4c48917c2d1b40cf063c6ed22ae2e71f4cb62


----------

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

From report at bugs.python.org  Sun Dec  1 18:07:11 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 23:07:11 +0000
Subject: [issue38449] regression - mimetypes guess_type is confused by ;
 in the filename
In-Reply-To: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>
Message-ID: <1575241631.29.0.571617200346.issue38449@roundup.psfhosted.org>


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


----------
pull_requests: +16911
pull_request: https://github.com/python/cpython/pull/17432

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

From report at bugs.python.org  Sun Dec  1 18:23:36 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 23:23:36 +0000
Subject: [issue38449] regression - mimetypes guess_type is confused by ;
 in the filename
In-Reply-To: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>
Message-ID: <1575242616.22.0.996287397825.issue38449@roundup.psfhosted.org>


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


New changeset 926eabb6b46106e677d5e1ea25b7bab918da4110 by Miss Islington (bot) in branch '3.7':
bpo-38449: Add URL delimiters test cases (GH-16729)
https://github.com/python/cpython/commit/926eabb6b46106e677d5e1ea25b7bab918da4110


----------

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

From report at bugs.python.org  Sun Dec  1 18:24:21 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 01 Dec 2019 23:24:21 +0000
Subject: [issue38449] regression - mimetypes guess_type is confused by ;
 in the filename
In-Reply-To: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>
Message-ID: <1575242661.07.0.346395334313.issue38449@roundup.psfhosted.org>


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


New changeset 4f1eaf028058cc357030dfaa5e611c90662539f0 by Miss Islington (bot) in branch '3.8':
bpo-38449: Add URL delimiters test cases (GH-16729)
https://github.com/python/cpython/commit/4f1eaf028058cc357030dfaa5e611c90662539f0


----------

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

From report at bugs.python.org  Sun Dec  1 19:24:02 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2019 00:24:02 +0000
Subject: [issue38951] Use threading.main_thread() check in asyncio
In-Reply-To: <1575225525.0.0.724928399081.issue38951@roundup.psfhosted.org>
Message-ID: <1575246242.61.0.37812850103.issue38951@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16912
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17433

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

From report at bugs.python.org  Sun Dec  1 20:07:46 2019
From: report at bugs.python.org (Max Coplan)
Date: Mon, 02 Dec 2019 01:07:46 +0000
Subject: [issue38952] asyncio cannot handle Python3 IPv4Address or IPv6 Address
Message-ID: <1575248866.63.0.518271436447.issue38952@roundup.psfhosted.org>


New submission from Max Coplan <mchcopl at gmail.com>:

Trying to use new Python 3 `IPv4Address`s fails with the following error
```
File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py", line 1270, in _ensure_resolved
    info = _ipaddr_info(host, port, family, type, proto, *address[2:])
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py", line 134, in _ipaddr_info
    if '%' in host:
TypeError: argument of type 'IPv4Address' is not iterable
```

----------
components: asyncio
messages: 357697
nosy: Max Coplan, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio cannot handle Python3 IPv4Address or IPv6 Address
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Dec  1 20:09:17 2019
From: report at bugs.python.org (Max Coplan)
Date: Mon, 02 Dec 2019 01:09:17 +0000
Subject: [issue38952] asyncio cannot handle Python3 IPv4Address or IPv6 Address
In-Reply-To: <1575248866.63.0.518271436447.issue38952@roundup.psfhosted.org>
Message-ID: <1575248957.62.0.940672152289.issue38952@roundup.psfhosted.org>


Change by Max Coplan <mchcopl at gmail.com>:


----------
keywords: +patch
pull_requests: +16913
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17434

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

From report at bugs.python.org  Sun Dec  1 20:17:42 2019
From: report at bugs.python.org (Max Coplan)
Date: Mon, 02 Dec 2019 01:17:42 +0000
Subject: [issue38952] asyncio cannot handle Python3 IPv4Address
In-Reply-To: <1575248866.63.0.518271436447.issue38952@roundup.psfhosted.org>
Message-ID: <1575249462.98.0.449091564136.issue38952@roundup.psfhosted.org>


Change by Max Coplan <mchcopl at gmail.com>:


----------
title: asyncio cannot handle Python3 IPv4Address or IPv6 Address -> asyncio cannot handle Python3 IPv4Address

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

From report at bugs.python.org  Sun Dec  1 20:21:50 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Mon, 02 Dec 2019 01:21:50 +0000
Subject: [issue38720] Logging failure with timestamp messages
In-Reply-To: <1573053027.67.0.846988059067.issue38720@roundup.psfhosted.org>
Message-ID: <1575249710.23.0.281970044933.issue38720@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

I think this needs a script to reproduce the problem.

Tested first with Anaconda Python 3.7.1 on Win10 Pro. Not able to reproduce the issue. Smae with the latest version.

Using Python master and Win10Pro and timezone set to NZ (not that really matter, but just in case).

    Python 3.9.0a1+ (heads/master:2fe4c48917, Dec  2 2019, 14:12:32) [MSC v.1916 64 bit (AMD64)] on win32

with the example from https://docs.python.org/3/library/logging.html:

    import logging
    FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s'
    logging.basicConfig(format=FORMAT)
    d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
    logger = logging.getLogger('tcpserver')
    
    logger.warning('Protocol problem: %s', 'connection reset', extra=d)

Gives:

    2019-12-02 14:14:46,615 192.168.0.1 fbloggs  Protocol problem: connection reset

If I modify the example to use just %(asctime)s


    import logging
    FORMAT = '%(asctime)s'
    logging.basicConfig(format=FORMAT)
    d = {'clientip': '192.168.0.1', 'user': 'fbloggs'}
    logger = logging.getLogger('tcpserver')
    
    logger.warning('Protocol problem: %s', 'connection reset', extra=d)

Now gives:

    2019-12-02 14:18:29,047

Everything looks OK, at least on my environment.

----------
nosy: +kinow

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

From report at bugs.python.org  Sun Dec  1 20:53:11 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Mon, 02 Dec 2019 01:53:11 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
In-Reply-To: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>
Message-ID: <1575251591.29.0.421613269077.issue38868@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

I think eryksun is correct. Reproduced it locally. Setting to read-only initially did not raise the issue, but then as administrator I removed the inherited permissions and set it to read-only for my user, then it raised the exact same WinError 5 Permission Error.

With the extra code to remove the readonly attribute, the directory was successfully deleted.

>It does so as an accident of history, not because it's justified

I think it would be easier for users if this attribute was not copied, especially as it looks like other attributes are not being copied (on Win). That would remove the need of this extra code when using Windows.

----------
nosy: +kinow

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

From report at bugs.python.org  Sun Dec  1 22:16:30 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Mon, 02 Dec 2019 03:16:30 +0000
Subject: [issue35981] shutil make_archive create wrong file when base name
 contains dots at end
In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org>
Message-ID: <1575256590.32.0.321220193327.issue35981@roundup.psfhosted.org>


Change by Bruno P. Kinoshita <brunodepaulak at yahoo.com.br>:


----------
keywords: +patch, patch
pull_requests: +16914, 16915
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17435

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

From report at bugs.python.org  Sun Dec  1 22:16:30 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Mon, 02 Dec 2019 03:16:30 +0000
Subject: [issue35981] shutil make_archive create wrong file when base name
 contains dots at end
In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org>
Message-ID: <1575256590.14.0.0130803829581.issue35981@roundup.psfhosted.org>


Change by Bruno P. Kinoshita <brunodepaulak at yahoo.com.br>:


----------
keywords: +patch
pull_requests: +16914
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17435

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

From report at bugs.python.org  Sun Dec  1 22:18:32 2019
From: report at bugs.python.org (Bruno P. Kinoshita)
Date: Mon, 02 Dec 2019 03:18:32 +0000
Subject: [issue35981] shutil make_archive create wrong file when base name
 contains dots at end
In-Reply-To: <1550042124.47.0.589800343777.issue35981@roundup.psfhosted.org>
Message-ID: <1575256712.73.0.943938263642.issue35981@roundup.psfhosted.org>


Bruno P. Kinoshita <brunodepaulak at yahoo.com.br> added the comment:

Tested locally on Win10 pro, and both suggestions of steve.dower worked. I've put a PR (https://github.com/python/cpython/pull/17435) based on his second suggestion.

The rationale being that that way, the format function (zip/bztar/etc) will get the absolute file name. I thought this was less risk then trusting that the format function would work with the relative paths in win/linux/etc.

----------
nosy: +kinow

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

From report at bugs.python.org  Sun Dec  1 22:27:17 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 02 Dec 2019 03:27:17 +0000
Subject: [issue34344] Fix the docstring for
 AbstractEventLoopPolicy.get_event_loop
In-Reply-To: <1533549887.39.0.56676864532.issue34344@psf.upfronthosting.co.za>
Message-ID: <1575257237.76.0.648677963277.issue34344@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing this as fixed. Thanks.

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

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

From report at bugs.python.org  Mon Dec  2 00:39:48 2019
From: report at bugs.python.org (LiJiayuan)
Date: Mon, 02 Dec 2019 05:39:48 +0000
Subject: [issue31842] pathlib: "Incorrect function" during resolve()
In-Reply-To: <1508707873.05.0.213398074469.issue31842@psf.upfronthosting.co.za>
Message-ID: <1575265188.38.0.627124852028.issue31842@roundup.psfhosted.org>


LiJiayuan <zombie110year at outlook.com> added the comment:

Same Error.

It happend by resolving a path which is not under C: driver,
in Windows System.

>>> Path().resolve()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\zom\scoop\apps\miniconda3\current\envs\web\lib\pathlib.py", line 1159, in resolve
    s = self._flavour.resolve(self, strict=strict)
  File "C:\Users\zom\scoop\apps\miniconda3\current\envs\web\lib\pathlib.py", line 202, in resolve
    s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1] Incorrect function: '.'
>>> Path().absolute()
WindowsPath('R:/fileshare/fileshare-s')
>>> Path().absolute().resolve()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\zom\scoop\apps\miniconda3\current\envs\web\lib\pathlib.py", line 1159, in resolve
    s = self._flavour.resolve(self, strict=strict)
  File "C:\Users\zom\scoop\apps\miniconda3\current\envs\web\lib\pathlib.py", line 202, in resolve
    s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1] Incorrect function: 'R:\\fileshare\\fileshare-s'

----------
nosy: +zombie110year
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Mon Dec  2 01:44:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 02 Dec 2019 06:44:07 +0000
Subject: [issue38952] asyncio cannot handle Python3 IPv4Address
In-Reply-To: <1575248866.63.0.518271436447.issue38952@roundup.psfhosted.org>
Message-ID: <1575269047.8.0.0336733598666.issue38952@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This looks like a duplicate of issue35019.

----------
nosy: +xtreak
type:  -> enhancement
versions: +Python 3.9 -Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Dec  2 01:47:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 02 Dec 2019 06:47:04 +0000
Subject: [issue31842] pathlib: "Incorrect function" during resolve()
In-Reply-To: <1508707873.05.0.213398074469.issue31842@psf.upfronthosting.co.za>
Message-ID: <1575269224.13.0.661369872299.issue31842@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/issue31842>
_______________________________________

From report at bugs.python.org  Mon Dec  2 03:29:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 02 Dec 2019 08:29:10 +0000
Subject: [issue31807] unitest.mock: Using autospec=True conflicts with 'wraps'
In-Reply-To: <1508287695.22.0.213398074469.issue31807@psf.upfronthosting.co.za>
Message-ID: <1575275350.15.0.135254418263.issue31807@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/issue31807>
_______________________________________

From report at bugs.python.org  Mon Dec  2 06:06:14 2019
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 02 Dec 2019 11:06:14 +0000
Subject: [issue38953] Untokenize and retokenize does not round-trip
Message-ID: <1575284774.35.0.371169137429.issue38953@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

I've been working on a tool called Hypothesmith - https://github.com/Zac-HD/hypothesmith - to generate arbitrary Python source code, inspired by CSmith's success in finding C compiler bugs.  It's based on the grammar but ultimately only generates strings which `compile` accepts; this is the only way I know to answer the question "is the string valid Python"!

I should be clear that I don't think the minimal examples are representative of real problems that users may encounter!  However, fuzzing is very effective at finding important bugs if we can get these apparently-trivial ones out of the way by changing either the code or the test :-)

```python
@example("#")
@example("\n\\\n")
@example("#\n\x0cpass#\n")
@given(source_code=hypothesmith.from_grammar().map(fixup).filter(str.strip))
def test_tokenize_round_trip_string(source_code):
    tokens = list(tokenize.generate_tokens(io.StringIO(source_code).readline))
    outstring = tokenize.untokenize(tokens)  # may have changed whitespace from source
    output = tokenize.generate_tokens(io.StringIO(outstring).readline)
    assert [(t.type, t.string) for t in tokens] == [(t.type, t.string) for t in output]
```

Each of the `@example` cases are accepted by `compile` but fail the test; the `@given` case describes how to generate more such strings.  You can read more details in the Hypothesmith repo if interested.

I think these are real and probably unimportant bugs, but I'd love to start a conversation about what properties should *always* hold for functions dealing with Python source code - and how best to report research results if I can demonstrate that they don't!

(for example, lib2to3 has many similar failures but I don't want to open a long list of low-value issues)

----------
components: Library (Lib)
messages: 357704
nosy: Zac Hatfield-Dodds, meador.inge
priority: normal
severity: normal
status: open
title: Untokenize and retokenize does not round-trip
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Dec  2 08:07:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2019 13:07:32 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575292052.5.0.00784552111963.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Similar issue in Fedora: https://src.fedoraproject.org/rpms/python3/pull-request/155

----------

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

From report at bugs.python.org  Mon Dec  2 08:10:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2019 13:10:55 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575292255.71.0.485132375616.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Debian and Fedora are already using OPENSSL_CONF=/non-existing-file workaround.

IMHO test_ssl should be fixed instead. test_ssl should not make assumptions on min/max TLS version.

----------

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

From report at bugs.python.org  Mon Dec  2 08:28:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2019 13:28:42 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on AMD64 FreeBSD
 Shared 3.x
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575293322.89.0.282518794228.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Previous attempt:
https://github.com/python/cpython/pull/11508#issuecomment-453186969

Old Fedora issue, worked around in the Fedora buildbot configuration: bpo-35045.

----------

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

From report at bugs.python.org  Mon Dec  2 08:38:37 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 02 Dec 2019 13:38:37 +0000
Subject: [issue38954] test_ssl  fails in all Fedora buildbots
Message-ID: <1575293917.48.0.60189521632.issue38954@roundup.psfhosted.org>


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

This issue is probably duplicate of some other, but I decided to make one new one due to the fact that this affect all Fedora build bots.


test test_ssl failed
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok
======================================================================
FAIL: test_min_max_version (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_ssl.py", line 1207, in test_min_max_version
    self.assertEqual(
AssertionError: <TLSVersion.TLSv1_3: 772> != <TLSVersion.MAXIMUM_SUPPORTED: -1>
----------------------------------------------------------------------
Ran 161 tests in 2.681s
FAILED (failures=1, skipped=11)
1 test failed again:
    test_ssl

Example failure:

https://buildbot.python.org/all/#/builders/222

----------
components: Tests
messages: 357708
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_ssl  fails in all Fedora buildbots
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 08:41:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2019 13:41:41 +0000
Subject: [issue38954] test_ssl  fails in all Fedora buildbots
In-Reply-To: <1575293917.48.0.60189521632.issue38954@roundup.psfhosted.org>
Message-ID: <1575294101.84.0.499867113418.issue38954@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I suggest to reuse bpo-38815.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_ssl: test_min_max_version() fails on AMD64 FreeBSD Shared 3.x

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

From report at bugs.python.org  Mon Dec  2 08:42:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2019 13:42:23 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575294143.96.0.604795307047.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-38954 as duplicate of this issue. Copy of its message:
---
 This issue is probably duplicate of some other, but I decided to make one new one due to the fact that this affect all Fedora build bots.


test test_ssl failed
test_timeout_connect_ex (test.test_ssl.NetworkedTests) ... ok
======================================================================
FAIL: test_min_max_version (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.8.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_ssl.py", line 1207, in test_min_max_version
    self.assertEqual(
AssertionError: <TLSVersion.TLSv1_3: 772> != <TLSVersion.MAXIMUM_SUPPORTED: -1>
----------------------------------------------------------------------
Ran 161 tests in 2.681s
FAILED (failures=1, skipped=11)
1 test failed again:
    test_ssl

Example failure:

https://buildbot.python.org/all/#/builders/222
---

----------
title: test_ssl: test_min_max_version() fails on AMD64 FreeBSD Shared 3.x -> test_ssl: test_min_max_version() fails on FreeBSD and Fedora

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

From report at bugs.python.org  Mon Dec  2 08:55:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 02 Dec 2019 13:55:03 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575294903.4.0.995615030013.issue38815@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Raising the priority to 'critical' as this is masking all other problems on a significant number of buildbots.

Christian, could you take a look?

----------
nosy: +pablogsal
priority: normal -> critical

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

From report at bugs.python.org  Mon Dec  2 10:03:09 2019
From: report at bugs.python.org (AnLong)
Date: Mon, 02 Dec 2019 15:03:09 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1575298989.9.0.830345596089.issue27873@roundup.psfhosted.org>


Change by AnLong <aisk1988 at gmail.com>:


----------
pull_requests: +16916
pull_request: https://github.com/python/cpython/pull/17436

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

From report at bugs.python.org  Mon Dec  2 10:32:21 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2019 15:32:21 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575300741.19.0.366486585601.issue38815@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Tomas Orsava is going to provide a PR within the next hour.

----------

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

From report at bugs.python.org  Mon Dec  2 10:54:09 2019
From: report at bugs.python.org (Tomas Orsava)
Date: Mon, 02 Dec 2019 15:54:09 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575302049.88.0.44754976364.issue38815@roundup.psfhosted.org>


Change by Tomas Orsava <tomas.n at orsava.cz>:


----------
keywords: +patch
pull_requests: +16917
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17437

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

From report at bugs.python.org  Mon Dec  2 11:14:36 2019
From: report at bugs.python.org (Max Coplan)
Date: Mon, 02 Dec 2019 16:14:36 +0000
Subject: [issue38952] asyncio cannot handle Python3 IPv4Address
In-Reply-To: <1575248866.63.0.518271436447.issue38952@roundup.psfhosted.org>
Message-ID: <1575303276.3.0.633903820637.issue38952@roundup.psfhosted.org>


Max Coplan <mchcopl at gmail.com> added the comment:

Well I?ve submitted a fix for it.  It isn?t perfect.  Well, while it doesn?t look perfect, it actually worked with everything I?ve thrown at it, and seems to be a very robust and sufficient fix.

----------

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

From report at bugs.python.org  Mon Dec  2 11:15:46 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 16:15:46 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575303346.56.0.263577470707.issue38815@roundup.psfhosted.org>


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


New changeset 34864d1cffdbfc620f8517dab9a68ae9a37b8c53 by Miss Islington (bot) (torsava) in branch 'master':
bpo-38815: Accept TLSv3 default in min max test (GH-NNNN) (GH-17437)
https://github.com/python/cpython/commit/34864d1cffdbfc620f8517dab9a68ae9a37b8c53


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

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

From report at bugs.python.org  Mon Dec  2 11:16:10 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 16:16:10 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575303370.01.0.842059233116.issue38815@roundup.psfhosted.org>


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


----------
pull_requests: +16919
pull_request: https://github.com/python/cpython/pull/17438

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

From report at bugs.python.org  Mon Dec  2 11:16:17 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 16:16:17 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575303377.43.0.480781705982.issue38815@roundup.psfhosted.org>


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


----------
pull_requests: +16920
pull_request: https://github.com/python/cpython/pull/17439

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

From report at bugs.python.org  Mon Dec  2 11:18:09 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 02 Dec 2019 16:18:09 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575303489.65.0.217287168274.issue38815@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Testing for the latest PR happening here:

https://buildbot.python.org/all/#/builders?tags=%2Bstable&tags=%2Bcustom

----------

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

From report at bugs.python.org  Mon Dec  2 11:34:49 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 16:34:49 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575304489.17.0.279074449428.issue38815@roundup.psfhosted.org>


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


New changeset 9e728806d03fff8fa9e75159e567b2b4e040971b by Miss Islington (bot) in branch '3.8':
bpo-38815: Accept TLSv3 default in min max test (GH-NNNN) (GH-17437)
https://github.com/python/cpython/commit/9e728806d03fff8fa9e75159e567b2b4e040971b


----------

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

From report at bugs.python.org  Mon Dec  2 11:35:54 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 16:35:54 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575304554.31.0.397972762793.issue38815@roundup.psfhosted.org>


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


New changeset 1f4f28cbf3ca4c7f85b41b1f7b9455a375415cc0 by Miss Islington (bot) in branch '3.7':
bpo-38815: Accept TLSv3 default in min max test (GH-NNNN) (GH-17437)
https://github.com/python/cpython/commit/1f4f28cbf3ca4c7f85b41b1f7b9455a375415cc0


----------

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

From report at bugs.python.org  Mon Dec  2 12:21:34 2019
From: report at bugs.python.org (Gregory Shevchenko)
Date: Mon, 02 Dec 2019 17:21:34 +0000
Subject: [issue22640] Add silent mode for py_compile
In-Reply-To: <1413361400.01.0.34334853586.issue22640@psf.upfronthosting.co.za>
Message-ID: <1575307294.22.0.71324625228.issue22640@roundup.psfhosted.org>


Change by Gregory Shevchenko <gvsheva at gmail.com>:


----------
pull_requests: +16921
pull_request: https://github.com/python/cpython/pull/17134

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

From report at bugs.python.org  Mon Dec  2 12:35:05 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 02 Dec 2019 17:35:05 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575308105.75.0.911846034438.issue38815@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

All Fedora tests are successful, so I will de-escalate the priority of the issue. Thank you very much Christian and Tomas Orsava!

----------
priority: critical -> normal

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

From report at bugs.python.org  Mon Dec  2 12:41:43 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Dec 2019 17:41:43 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1575308503.11.0.158430237429.issue35003@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> If venv is run in a child process of the shell, how does it set those variables in the parent shell?

You can't. Tools like `pipenv shell` and `conda shell` end up with a new shell running instead of changing the current shell in-place.

----------

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

From report at bugs.python.org  Mon Dec  2 12:47:39 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Dec 2019 17:47:39 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575308859.87.0.359155017273.issue38924@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I'm going with Serhiy's recommendation and closing this. Sorry, Ionu?.

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

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

From report at bugs.python.org  Mon Dec  2 12:51:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Dec 2019 17:51:36 +0000
Subject: [issue38948] os.path.ismount() returns False for current working drive
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575309096.17.0.0943571748097.issue38948@roundup.psfhosted.org>


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

ntpath.ismount() is using a name-only check here, it never tries to resolve the path if splitdrive() returns (anything, one_of("", "/", "\\"))

Now it's not clear whether handling "" is intended there, but that's certainly the difference (Python 2 required exactly one character in that part). And it appears to be consistent back to 3.4, so I'm not sure we can or should fix anything. The only thing 'F:' can ever be is a mount point.

However, we should probably fix the fact that C: returns False. This is because we call abspath(path), and "x:" is a relative path. When the drive does not match the current working drive, you get "x:\\". But when it _does_ match, you get the current working directory, which (unless it's the root directory) is no longer a mount point.

Perhaps the best fix for that is to just say that "x:" is a relative path and hence never a mount point? Which would be the same as switching back to the Python 2 behaviour, but would be a much better reason.

----------
nosy: +eryksun
title: os.path.ismount() returns true in python 3.7.4 and false in 2.7.14 -> os.path.ismount() returns False for current working drive
type:  -> behavior
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 12:52:35 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Dec 2019 17:52:35 +0000
Subject: [issue28859] os.path.ismount sometimes raises FileNotFoundError on
 Windows
In-Reply-To: <1480689560.28.0.129916928722.issue28859@psf.upfronthosting.co.za>
Message-ID: <1575309155.81.0.417329964178.issue28859@roundup.psfhosted.org>


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

Traditionally we handle exceptions in os.path.is* functions and return False.

----------
keywords: +easy, newcomer friendly
stage:  -> test needed
type:  -> behavior
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 13:03:22 2019
From: report at bugs.python.org (=?utf-8?b?SW9udcibIENpb2PDrnJsYW4=?=)
Date: Mon, 02 Dec 2019 18:03:22 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575309802.19.0.609554521213.issue38924@roundup.psfhosted.org>


Ionu? Cioc?rlan <ionut.ciocirlan at gmail.com> added the comment:

Brett and Serhiy, you do realise there are no symlinks to resolve on PurePaths, right?


> os.path.normpath() is broken by design.

Why don't you deprecate it then? Sounds like the reasonable thing to do, no? So many innocent souls endangered by this evil function...

It's broken by design if you use it to shoot yourself in the foot. If you want however to normalize an abstract path, an absolutely reasonable thing to do, it does the right and very useful thing. Because, well, the filesystem isn't the only thing that has paths and other things don't have symlinks. Also, this lib is called pathlib, not fspathlib, *and* someone had the foresight of separating filesystem paths from abstract paths. Quite a strange series of coincidences, no?

Let me quote the initial comment for this issue, which apparently noone read:

> On `PurePath` its usefulness is obvious, but it's debatable for `Path`, as it would yield different results from `.resolve()` in case of symlinks (which resolves them before normalizing).

----------

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

From report at bugs.python.org  Mon Dec  2 13:23:12 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 02 Dec 2019 18:23:12 +0000
Subject: [issue31842] pathlib: "Incorrect function" during resolve()
In-Reply-To: <1508707873.05.0.213398074469.issue31842@psf.upfronthosting.co.za>
Message-ID: <1575310992.85.0.00867642430038.issue31842@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> When strict is "false", pathlib should not fail if the network 
> share is inaccessible.

A redirected filesystem (i.e. a share, whether local or remote) that's physically inaccessible should fail with a FileNotFoundError -- due to underlying errors such as ERROR_BAD_NETPATH (53) or ERROR_BAD_NET_NAME (67). This case is already handled by resolve() in non-strict mode. But error handling for other cases does need to be expanded.

A PermissionError should be ignored, from OS errors such as ERROR_ACCESS_DENIED (5), ERROR_SHARING_VIOLATION (32), and ERROR_NOT_READY (21). 

It should ignore errors due to bad reparse points (e.g. filesystem symlinks and mount points), such as ERROR_INVALID_REPARSE_DATA (4392) and ERROR_REPARSE_TAG_INVALID (4393). 

The resolve() method is supposed to raise a RuntimeError for a symlink loop (i.e. reparse loop). In Windows, the system detects this case as ERROR_CANT_RESOLVE_FILENAME (1921). It's not necessarily due to a reparse loop, but in practice it usually is. (It's actually due to the upper limit for the number of reparse attempts, which as of Windows 10 is no more than 63 attempts.) Maybe this error should be re-raised as a RuntimeError for the sake of compatibility with the POSIX implementation.

The above-mentioned cases are all due to WINAPI CreateFileW failing. 
Additionally, the GetFinalPathNameByHandleW call in nt._getfinalpathname relies on several low-level system calls, any one of which can fail with ERROR_INVALID_FUNCTION (1) or ERROR_INVALID_PARAMETER (87) -- and possibly ERROR_NOT_SUPPORTED (50). These errors should be ignored in non-strict mode. 

At a lower level, the reliability of nt._getfinalpathname could be improved for non-strict operation. It could fall back on other forms of the final name that may be supported. It could try FILE_NAME_OPENED instead of FILE_NAME_NORMALIZED to handle a filesystem that does not support normalizing 8.3 short names as long names. Try VOLUME_NAME_GUID instead of VOLUME_NAME_DOS to handle a volume that only has a GUID name (i.e. a volume device that's registered with the mount-point manager but lacks a DOS drive name or even a mountpoint on a volume that has a DOS drive name). Try VOLUME_NAME_NT to handle legacy volume/filesystem devices ('legacy' because they do not support the mount-point manager interface that was introduced almost 20 years ago in NT 5). For the sake of simplicity and performance, the latter case could be limited to well-known DOS device names such as r"\\?\PIPE" -> r"\Device\NamedPipe". The NT device path for the comparison should be queried instead of hard coded, e.g. via QueryDosDeviceW(L"PIPE", ...).

----------

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

From report at bugs.python.org  Mon Dec  2 13:24:31 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 02 Dec 2019 18:24:31 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1575311071.61.0.263906923307.issue15273@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@pablogsal should we add Lib/test/test_grammar by default to every test? Also if this is still needed @Daniel.Cioata do you still want to prepare another patch for current version?

----------
nosy: +BTaskaya, pablogsal

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

From report at bugs.python.org  Mon Dec  2 13:39:47 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 02 Dec 2019 18:39:47 +0000
Subject: [issue38955] Non indemnpotent behavior of asyncio.get_event_loop and
 asyncio.run sequence.
Message-ID: <1575311987.47.0.389219942485.issue38955@roundup.psfhosted.org>


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

Hi, Not sure if this a bug, or an intended feature. 
I got surprise by the following behavior. 


    from asyncio import run, sleep, get_event_loop

    print(get_event_loop()) # return the current eventloop
    run(sleep(0))
    print(get_event_loop()) # raise a RuntimeError


I would expect `get_event_loop` to get back to it's initial default value. 

This comes from the fact that `run()` call `set_event_loop()` to `None`. with
both sets `_set_called` to `True`, but `get_event_loop` seem to assume if
_set_called is True, then loop cannot be none. 

I'm tempted to think that if `set_loop()` is called with `None`, it should reset the `_set_called` to False. Or Am I supposed to call `set_event_loop(new_event_loop())` myself ? 

I'm likely missing  something so any insight would be appreciated; if you
believe this is an actual issue I'm happy to send a PR.

----------
components: asyncio
messages: 357727
nosy: asvetlov, mbussonn, yselivanov
priority: normal
severity: normal
status: open
title: Non indemnpotent behavior of asyncio.get_event_loop and asyncio.run sequence.
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 14:10:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Dec 2019 19:10:42 +0000
Subject: [issue38920] Audit events for unhandled exceptions
In-Reply-To: <1574788528.67.0.338103182779.issue38920@roundup.psfhosted.org>
Message-ID: <1575313842.3.0.51708308338.issue38920@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Mon Dec  2 15:17:37 2019
From: report at bugs.python.org (PCManticore)
Date: Mon, 02 Dec 2019 20:17:37 +0000
Subject: [issue36470] dataclasses.replace raises an exception if InitVar with
 default argument is not provided.
In-Reply-To: <1553860338.68.0.823118501948.issue36470@roundup.psfhosted.org>
Message-ID: <1575317857.79.0.0709870881547.issue36470@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


----------
keywords: +patch
pull_requests: +16922
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17441

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

From report at bugs.python.org  Mon Dec  2 15:24:15 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 02 Dec 2019 20:24:15 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1575318255.18.0.541383747208.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> You can't. Tools like `pipenv shell` and `conda shell` end up with a new shell running instead of changing the current shell in-place.

Indeed. I raised it because of what you said earlier:

> and so maybe proposing a simple `venv --activate <path>` that does nothing more than set those key environment variables and prints out a message about what is happening is enough to do the trick

So not that simple, then, if it has to handle multiple shells cross-platform. Especially as if tools like pew, pipenv, conda already do this. Are you proposing to bring that functionality, which these third-party tools perform currently, into the stdlib?

----------

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

From report at bugs.python.org  Mon Dec  2 16:45:15 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 02 Dec 2019 21:45:15 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1575323115.07.0.133796854868.issue15273@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> @pablogsal should we add Lib/test/test_grammar by default to every test? Also if this is still needed @Daniel.Cioata do you still want to prepare another patch for current version?

I think is a good idea, let me check how complete is the current version first.

----------

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

From report at bugs.python.org  Mon Dec  2 17:25:28 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2019 22:25:28 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575325528.12.0.00742382333344.issue38945@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset a62ad4730c9b575f140f24074656c0257c86a09a by Guido van Rossum (Matthew Rollings) in branch 'master':
bpo-38945: UU Encoding: Don't let newline in filename corrupt the output format (#17418)
https://github.com/python/cpython/commit/a62ad4730c9b575f140f24074656c0257c86a09a


----------
nosy: +gvanrossum

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

From report at bugs.python.org  Mon Dec  2 17:25:36 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 22:25:36 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575325536.16.0.551114651727.issue38945@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16923
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17442

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

From report at bugs.python.org  Mon Dec  2 17:25:42 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 22:25:42 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575325542.43.0.812918047628.issue38945@roundup.psfhosted.org>


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


----------
pull_requests: +16924
pull_request: https://github.com/python/cpython/pull/17443

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

From report at bugs.python.org  Mon Dec  2 17:25:48 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 22:25:48 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575325548.84.0.449967867349.issue38945@roundup.psfhosted.org>


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


----------
pull_requests: +16925
pull_request: https://github.com/python/cpython/pull/17444

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

From report at bugs.python.org  Mon Dec  2 17:41:47 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 02 Dec 2019 22:41:47 +0000
Subject: [issue1875] "if 0: return" not raising SyntaxError
In-Reply-To: <1200768950.55.0.245752373825.issue1875@psf.upfronthosting.co.za>
Message-ID: <1575326507.95.0.491880035549.issue1875@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/issue1875>
_______________________________________

From report at bugs.python.org  Mon Dec  2 17:43:19 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 22:43:19 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575326599.28.0.892439287934.issue38945@roundup.psfhosted.org>


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


New changeset 87f2d261ee1c63ed39517355833d087c5a78b4bf by Miss Islington (bot) in branch '3.7':
bpo-38945: UU Encoding: Don't let newline in filename corrupt the output format (GH-17418)
https://github.com/python/cpython/commit/87f2d261ee1c63ed39517355833d087c5a78b4bf


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

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

From report at bugs.python.org  Mon Dec  2 17:44:47 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 02 Dec 2019 22:44:47 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575326687.92.0.0703119844818.issue38945@roundup.psfhosted.org>


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


New changeset 8859fc629474ab1ca7eb2e67aec538097c327e58 by Miss Islington (bot) in branch '3.8':
bpo-38945: UU Encoding: Don't let newline in filename corrupt the output format (GH-17418)
https://github.com/python/cpython/commit/8859fc629474ab1ca7eb2e67aec538097c327e58


----------

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

From report at bugs.python.org  Mon Dec  2 18:03:24 2019
From: report at bugs.python.org (Antony Lee)
Date: Mon, 02 Dec 2019 23:03:24 +0000
Subject: [issue38956] argparse.BooleanOptionalAction should not add the
 default value to the help string by default
Message-ID: <1575327804.72.0.272027136625.issue38956@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

https://bugs.python.org/issue8538 recently added to Py3.9 a much welcome addition to argparse, namely the capability to generate --foo/--no-foo flag pairs.  A small issue with the implementation is that it *always* appends the default value to the help string (if any):

    if help is not None and default is not None:
        help += f" (default: {default})"

This is inconsistent with other action classes, and results in the defaults being printed twice if using ArgumentsDefaultHelpFormatter (which is the documented way to include the defaults in the help text):

    from argparse import *
    parser = ArgumentParser(formatter_class=ArgumentDefaultsHelpFormatter)
    parser.add_argument("--foo", action=BooleanOptionalAction, help="Whether to foo it", default=True)
    parser.add_argument("--quux", help="Set the quux", default=42)
    print(parser.parse_args())

yields

    usage: foo.py [-h] [--foo | --no-foo] [--quux QUUX]

    optional arguments:
      -h, --help       show this help message and exit
      --foo, --no-foo  Whether to foo it (default: True) (default: True)  # <--- HERE
      --quux QUUX      Set the quux (default: 42)

I think the fix is just a matter of not adding the default value to the help string.

----------
components: Library (Lib)
messages: 357733
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: argparse.BooleanOptionalAction should not add the default value to the help string by default
versions: Python 3.9

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

From report at bugs.python.org  Mon Dec  2 18:34:37 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Dec 2019 23:34:37 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575329677.53.0.389313160422.issue38945@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 30afc91f5e70cf4748ffac77a419ba69ebca6f6a by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-38945: UU Encoding: Don't let newline in filename corrupt the output format (GH-17418) (GH-17444)
https://github.com/python/cpython/commit/30afc91f5e70cf4748ffac77a419ba69ebca6f6a


----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Dec  2 18:37:00 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2019 23:37:00 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575329820.16.0.970309989574.issue38945@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

(Now waiting for 2.7 backport by stealthcopter.)

----------

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

From report at bugs.python.org  Mon Dec  2 18:38:33 2019
From: report at bugs.python.org (Ashley Whetter)
Date: Mon, 02 Dec 2019 23:38:33 +0000
Subject: [issue38957] Cannot compile with libffi from source on Windows
Message-ID: <1575329913.13.0.856957660536.issue38957@roundup.psfhosted.org>


New submission from Ashley Whetter <ashley at awhetter.co.uk>:

get_externals.bat downloads and extracts libffi to a versioned directory (much like the other external libraries). See https://github.com/python/cpython/blob/v3.8.0/PCbuild/get_externals.bat#L55
However the binary release is downloaded to an unversioned directory. See https://github.com/python/cpython/blob/v3.8.0/PCbuild/get_externals.bat#L79
The visual studio project looks for the unversioned directory (https://github.com/python/cpython/blob/v3.8.0/PCbuild/python.props#L62), and so the binaries are always used.

So it is possible to build from source, but you have to move libffi yourself after running `get_externals_bat --libffi-src`. I think the fix here is to make get_externals.bat and visual studio always use a versioned directory.

----------
components: Build, Windows
messages: 357736
nosy: AWhetter, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot compile with libffi from source on Windows
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 18:39:38 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Dec 2019 23:39:38 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575329978.9.0.355449815044.issue38945@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
versions: +Python 2.7, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 19:05:20 2019
From: report at bugs.python.org (Philip Rowlands)
Date: Tue, 03 Dec 2019 00:05:20 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575331520.62.0.661803438101.issue38941@roundup.psfhosted.org>


Philip Rowlands <pythonbugs at dimebar.com> added the comment:

I went digging through the archives, made more interesting as elementtree was imported into the standard library.

AFAICT, the FutureWarning for __bool__ (or __nonzero__ in py2) appeared circa 2007-06 in version 1.3a2:
http://svn.effbot.org/public/tags/elementtree-1.3a3-20070912/CHANGES

- Added future warnings for "if e" (use explicit len(e) or is None
  test) and "e.getchildren()" (use list(e) or iteration).

The docs are still there, warning about the pitfalls and suggesting "This behaviour is likely to change somewhat in ElementTree 1.3."
https://effbot.org/zone/element.htm#truth-testing

12 years on, it has not, but what was the intended change (+effbot for possible context)??

I assumed on first reading that the plan was to switch bool(Element) to return True, but others have pointed out the inconsistency with len(), or having __bool__() raise an exception.

My 2c would be to steer devs away from using bool(Element) as a final step, i.e. keep the existing True/False definition, warts and all, but raise a SyntaxWarning (RuntimeWarning?) with a similar message to the current FutureWarning.

----------
nosy: +effbot

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

From report at bugs.python.org  Mon Dec  2 19:10:02 2019
From: report at bugs.python.org (Io Mintz)
Date: Tue, 03 Dec 2019 00:10:02 +0000
Subject: [issue38958] asyncio REPL swallows KeyboardInterrupt while editing
Message-ID: <1575331802.11.0.760790431063.issue38958@roundup.psfhosted.org>


New submission from Io Mintz <io at mintz.cc>:

"python3 -m asyncio" swallows KeyboardInterrupt while editing a line.

Problem steps:
==============

- run python -m asyncio
- press ^C

Expected behavior (normal CPython REPL, as well as python -m code):
==================================================================

The current input line is abandoned and "\nKeyboardInterrupt" is printed.

Sample for "spam^C" with the normal REPL:
-----------------------------------------

Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> spam
KeyboardInterrupt

Python 3.9.0a1+ (heads/master:a62ad4730c, Dec  2 2019, 17:38:37) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> spam
KeyboardInterrupt


Sample for "spam^C" in the InteractiveConsole REPL, as invoked by `python -m code`:
-----------------------------------------------------------------------------------

Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> spam
KeyboardInterrupt

Python 3.9.0a1+ (heads/master:a62ad4730c, Dec  2 2019, 17:38:37) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> spam
KeyboardInterrupt


Actual behavior:
================

The KeyboardInterrupt is ignored, the current input line remains on screen, and a new line is not started:

asyncio REPL 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> spam

asyncio REPL 3.9.0a1+ (heads/master:a62ad4730c, Dec  2 2019, 17:38:37) 
[GCC 9.2.0] on linux
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> spam


Workaround
==========

If editing a continued block (ie a line prefixed by sys.ps2 / "..."), enter any invalid syntax (such as unindented code) to cancel the current block. If editing a single line, press ^U to clear the line.

OS Details
==========

Arch Linux, python extra/python 3.8.0-1.

----------
components: asyncio
messages: 357738
nosy: asvetlov, iomintz, yselivanov
priority: normal
severity: normal
status: open
title: asyncio REPL swallows KeyboardInterrupt while editing
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  2 19:16:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 03 Dec 2019 00:16:42 +0000
Subject: [issue38957] Cannot compile with libffi from source on Windows
In-Reply-To: <1575329913.13.0.856957660536.issue38957@roundup.psfhosted.org>
Message-ID: <1575332202.3.0.0152701992098.issue38957@roundup.psfhosted.org>


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

The intent is that you'd build from source and then copy the binaries into the libffi directory (the *real* intent is that very few people should have to build libffi from source).

Can you tell us a bit more about what you were trying to achieve when you ran into this?

----------

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

From report at bugs.python.org  Mon Dec  2 19:21:11 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2019 00:21:11 +0000
Subject: [issue38941] xml.etree.ElementTree.Element inconsistent warning for
 bool
In-Reply-To: <1575033665.72.0.950765215131.issue38941@roundup.psfhosted.org>
Message-ID: <1575332471.92.0.0175652356389.issue38941@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I doubt effbot will respond. :-)

I think the first order of business is to add the same FutureWarning to the C version of the code, and to reset the clock on the deprecation. 

In terms of the final stages, why wouldn't we want it to just always raise? Just because there's so much code that might break?

It shouldn't be a SyntaxWarning, since this is most definitely not a syntax issue. I'd be okay with RuntimeError (or RuntimeWarning if we decide to keep the old outcome with a warning forever).

(Huh, does FutureWarning count as a deprecation?)

----------

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

From report at bugs.python.org  Mon Dec  2 19:42:21 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 03 Dec 2019 00:42:21 +0000
Subject: [issue38270] Tests: Avoid MD5 or check for MD5 availablity
In-Reply-To: <1569406198.76.0.145895264341.issue38270@roundup.psfhosted.org>
Message-ID: <1575333741.34.0.923435230628.issue38270@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +cstratak

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

From report at bugs.python.org  Mon Dec  2 19:50:14 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Dec 2019 00:50:14 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575334214.21.0.899532884098.issue38945@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +16926
pull_request: https://github.com/python/cpython/pull/17445

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

From report at bugs.python.org  Mon Dec  2 19:50:48 2019
From: report at bugs.python.org (Ashley Whetter)
Date: Tue, 03 Dec 2019 00:50:48 +0000
Subject: [issue38957] Cannot compile with libffi from source on Windows
In-Reply-To: <1575329913.13.0.856957660536.issue38957@roundup.psfhosted.org>
Message-ID: <1575334248.83.0.284386324047.issue38957@roundup.psfhosted.org>


Ashley Whetter <ashley at awhetter.co.uk> added the comment:

Ah you're right. I was trying to install in the same way as previous versions. I didn't realise that calling prepare_*.bat was a separate step now.
Sorry about that.

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

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

From report at bugs.python.org  Mon Dec  2 19:50:57 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 03 Dec 2019 00:50:57 +0000
Subject: [issue38270] Tests: Avoid MD5 or check for MD5 availablity
In-Reply-To: <1569406198.76.0.145895264341.issue38270@roundup.psfhosted.org>
Message-ID: <1575334257.71.0.835571654762.issue38270@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
pull_requests: +16927
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17446

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

From report at bugs.python.org  Mon Dec  2 19:52:20 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Dec 2019 00:52:20 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575334340.92.0.310643861967.issue38945@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
versions: +Python 3.5

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

From report at bugs.python.org  Mon Dec  2 22:01:53 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 03 Dec 2019 03:01:53 +0000
Subject: [issue38956] argparse.BooleanOptionalAction should not add the
 default value to the help string by default
In-Reply-To: <1575327804.72.0.272027136625.issue38956@roundup.psfhosted.org>
Message-ID: <1575342113.67.0.579349517944.issue38956@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

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

From report at bugs.python.org  Tue Dec  3 00:15:48 2019
From: report at bugs.python.org (paul j3)
Date: Tue, 03 Dec 2019 05:15:48 +0000
Subject: [issue38950] argparse uses "optional arguments" for "keyword
 arguments"
In-Reply-To: <1575210600.45.0.569419059905.issue38950@roundup.psfhosted.org>
Message-ID: <1575350148.68.0.599666280745.issue38950@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

This related to an old issue

https://bugs.python.org/issue9694
argparse required arguments displayed under "optional arguments"

argparse defines two initial argument groups, titled 'positional arguments' and 'optional arguments'.   Alternatives have been suggested, such as 'flagged arguments' and/or 'required arguments'.  But nothing was settled.

Users can define their own argument groups. 

I'd suggest closing this a duplicate, though we can certainly revisit the earlier discussion.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Tue Dec  3 01:06:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Dec 2019 06:06:24 +0000
Subject: [issue38950] argparse uses "optional arguments" for "keyword
 arguments"
In-Reply-To: <1575210600.45.0.569419059905.issue38950@roundup.psfhosted.org>
Message-ID: <1575353184.73.0.690215121694.issue38950@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Dec  3 01:14:57 2019
From: report at bugs.python.org (Micky Yun Chan)
Date: Tue, 03 Dec 2019 06:14:57 +0000
Subject: [issue38956] argparse.BooleanOptionalAction should not add the
 default value to the help string by default
In-Reply-To: <1575327804.72.0.272027136625.issue38956@roundup.psfhosted.org>
Message-ID: <1575353697.19.0.896939706725.issue38956@roundup.psfhosted.org>


Micky Yun Chan <michan at redhat.com> added the comment:

Hi, if it's possible can I take this issue?

----------
nosy: +Micky Yun Chan

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

From report at bugs.python.org  Tue Dec  3 01:36:00 2019
From: report at bugs.python.org (Jiebin)
Date: Tue, 03 Dec 2019 06:36:00 +0000
Subject: [issue38959] Parboil -- OpenMP CUTCP performance regression when
 upgrade from python 2.7.15 to 2.7.17
Message-ID: <1575354960.22.0.085059134503.issue38959@roundup.psfhosted.org>


New submission from Jiebin <jiebin.sun at intel.com>:

When we replace the rpm package from 2.7.15 to 2.7.17. The benchmark Parboil -- OpenMP CUTCP shows regression.
Steps to reproduce the regression. You can reproduce the issue by phoronix test suite or run it from the source code.




Benchmarks	indicators	unit	HIB/LIB	Legacy version			New version			Regression status	OS	HW platform	comments
				component version	value	RSD	component version	value	RSD				
?parboil	?OpenMP CUTCP	Seconds	?LIB	?2.7.15	?1.20	?0.5%	?2.7.17	?1.37	?0.5%	?12%	?Clear Linux	?CLX server

----------
components: Library (Lib)
files: image-2019-12-03-13-55-06-020.png
messages: 357744
nosy: jiebinsu
priority: normal
severity: normal
status: open
title: Parboil -- OpenMP CUTCP performance regression when upgrade from python 2.7.15 to 2.7.17
type: performance
versions: Python 2.7
Added file: https://bugs.python.org/file48749/image-2019-12-03-13-55-06-020.png

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

From report at bugs.python.org  Tue Dec  3 01:40:05 2019
From: report at bugs.python.org (Jiebin)
Date: Tue, 03 Dec 2019 06:40:05 +0000
Subject: [issue38959] Parboil -- OpenMP CUTCP performance regression when
 upgrade from python 2.7.15 to 2.7.17
In-Reply-To: <1575354960.22.0.085059134503.issue38959@roundup.psfhosted.org>
Message-ID: <1575355205.58.0.0151772325036.issue38959@roundup.psfhosted.org>


Jiebin <jiebin.sun at intel.com> added the comment:

In Clear Linux, You can produce by the following steps.

1, sudo swupd bundle-add os-testsuite-phoronix
2, phoronix-test-suite run parboil-1.2.1
3, select the option OpenMP CUTCP

Or download it from the source code. Refer the file attached.

----------
Added file: https://bugs.python.org/file48750/install.sh

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

From report at bugs.python.org  Tue Dec  3 01:40:21 2019
From: report at bugs.python.org (Jiebin)
Date: Tue, 03 Dec 2019 06:40:21 +0000
Subject: [issue38959] Parboil -- OpenMP CUTCP performance regression when
 upgrade from python 2.7.15 to 2.7.17
In-Reply-To: <1575354960.22.0.085059134503.issue38959@roundup.psfhosted.org>
Message-ID: <1575355221.56.0.781961862766.issue38959@roundup.psfhosted.org>


Change by Jiebin <jiebin.sun at intel.com>:


Added file: https://bugs.python.org/file48751/downloads.xml

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

From report at bugs.python.org  Tue Dec  3 01:40:35 2019
From: report at bugs.python.org (Jiebin)
Date: Tue, 03 Dec 2019 06:40:35 +0000
Subject: [issue38959] Parboil -- OpenMP CUTCP performance regression when
 upgrade from python 2.7.15 to 2.7.17
In-Reply-To: <1575354960.22.0.085059134503.issue38959@roundup.psfhosted.org>
Message-ID: <1575355235.72.0.186257345645.issue38959@roundup.psfhosted.org>


Change by Jiebin <jiebin.sun at intel.com>:


Added file: https://bugs.python.org/file48752/test-definition.xml

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

From report at bugs.python.org  Tue Dec  3 02:05:11 2019
From: report at bugs.python.org (Micky Yun Chan)
Date: Tue, 03 Dec 2019 07:05:11 +0000
Subject: [issue38956] argparse.BooleanOptionalAction should not add the
 default value to the help string by default
In-Reply-To: <1575327804.72.0.272027136625.issue38956@roundup.psfhosted.org>
Message-ID: <1575356711.57.0.439089786406.issue38956@roundup.psfhosted.org>


Change by Micky Yun Chan <michan at redhat.com>:


----------
keywords: +patch
pull_requests: +16928
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17447

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

From report at bugs.python.org  Tue Dec  3 02:11:45 2019
From: report at bugs.python.org (Micky Yun Chan)
Date: Tue, 03 Dec 2019 07:11:45 +0000
Subject: [issue38956] argparse.BooleanOptionalAction should not add the
 default value to the help string by default
In-Reply-To: <1575327804.72.0.272027136625.issue38956@roundup.psfhosted.org>
Message-ID: <1575357104.99.0.0505292423536.issue38956@roundup.psfhosted.org>


Micky Yun Chan <michan at redhat.com> added the comment:

Hi I created a new pull request on Github

----------

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

From report at bugs.python.org  Tue Dec  3 04:37:44 2019
From: report at bugs.python.org (PCManticore)
Date: Tue, 03 Dec 2019 09:37:44 +0000
Subject: [issue38572] Misleading AttributeError accessing fileno attribute in
 tarfile
In-Reply-To: <1571900132.35.0.991486656774.issue38572@roundup.psfhosted.org>
Message-ID: <1575365864.03.0.176395664517.issue38572@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

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

From report at bugs.python.org  Tue Dec  3 05:42:52 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 03 Dec 2019 10:42:52 +0000
Subject: [issue38955] Non indemnpotent behavior of asyncio.get_event_loop and
 asyncio.run sequence.
In-Reply-To: <1575311987.47.0.389219942485.issue38955@roundup.psfhosted.org>
Message-ID: <1575369772.95.0.580084717819.issue38955@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I think now it is too late for changing the behavior.
In the ideal world, get_event_loop() should never exist, maybe we can deprecate/remove it eventually.
run() should be used for executing async code; get_running_loop() for getting a reference to the currently executed loop.
It may help to avoid many silly problems.
Maybe some scenarios are not covered but at least high-level code can be organized this way.

P.S.
set_event_loop(None) is not for resetting to default but for disabling of the default loop creation for the current thread. Non-main threads work like set_event_loop(None) was called implicitly.

----------

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

From report at bugs.python.org  Tue Dec  3 06:04:48 2019
From: report at bugs.python.org (PCManticore)
Date: Tue, 03 Dec 2019 11:04:48 +0000
Subject: [issue38572] Misleading AttributeError accessing fileno attribute in
 tarfile
In-Reply-To: <1571900132.35.0.991486656774.issue38572@roundup.psfhosted.org>
Message-ID: <1575371088.63.0.18403199003.issue38572@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


----------
keywords: +patch
pull_requests: +16930
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17449

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

From report at bugs.python.org  Tue Dec  3 06:05:44 2019
From: report at bugs.python.org (PCManticore)
Date: Tue, 03 Dec 2019 11:05:44 +0000
Subject: [issue38572] Misleading AttributeError accessing fileno attribute in
 tarfile
In-Reply-To: <1571900132.35.0.991486656774.issue38572@roundup.psfhosted.org>
Message-ID: <1575371144.67.0.432224639906.issue38572@roundup.psfhosted.org>


PCManticore <pcmanticore at gmail.com> added the comment:

Just submitted a PR for this issue, hope I got it right. Curious to see if there are any backwards compatibility concerns with this approach.

----------

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

From report at bugs.python.org  Tue Dec  3 06:15:25 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 03 Dec 2019 11:15:25 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1575371725.8.0.66663106348.issue9694@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

I have just run into the same issue here: https://bugs.python.org/issue38950

- I prefer Terry J. Reedy's "keyword arguments" as it is clear and consistent with "positional arguments".
- But Steven Bethard 's "flag arguments" looks fine since it is well known to shell users.
- Martin Panter's "options" looks okay since it is the standard name in GNU Coreutils (https://www.gnu.org/software/coreutils/manual/coreutils.html#Common-options). However I don't like it very much as it is still ambiguous: "options", like "optional arguments", still suggests something that is non required. And "options" is less consistent with "positional arguments" (nobody seems to have suggested "option arguments").
- Oliver Smith's "switches" does not look okay because it is not general enough since it is commonly restricted to Boolean arguments.

Anyway, the first 3 solutions are better than the current "optional arguments". What is blocking the approval of Martin Panter's PR?

----------
nosy: +maggyero

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

From report at bugs.python.org  Tue Dec  3 06:18:05 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 03 Dec 2019 11:18:05 +0000
Subject: [issue38950] argparse uses "optional arguments" for "keyword
 arguments"
In-Reply-To: <1575210600.45.0.569419059905.issue38950@roundup.psfhosted.org>
Message-ID: <1575371885.17.0.557085340649.issue38950@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

Thanks paul j3 for the link. I am continuing the discussion there.

----------

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

From report at bugs.python.org  Tue Dec  3 08:08:59 2019
From: report at bugs.python.org (Parth Sharma)
Date: Tue, 03 Dec 2019 13:08:59 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1575378538.96.0.746920478665.issue38918@roundup.psfhosted.org>


Parth Sharma <parth261297 at gmail.com> added the comment:

Hey Eric,

I made a PR [1] which adds an entry for __module__ in the "function" and "method" sections of the table [2]. Can you review it and let me know if any changes are required?

[1] https://github.com/python/cpython/pull/17408
[2] https://docs.python.org/3/library/inspect.html#types-and-members

----------
nosy: +parthsharma2

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

From report at bugs.python.org  Tue Dec  3 08:28:38 2019
From: report at bugs.python.org (JohnnyNajera)
Date: Tue, 03 Dec 2019 13:28:38 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575379718.54.0.693793304895.issue38943@roundup.psfhosted.org>


JohnnyNajera <JohnnyNajera at protonmail.com> added the comment:

At least this scenario:
Ubuntu 19.10
Open the interpreter
Literally nothing makes the autocomplete window show up.

As mentioned in the PR, it's not about the 1-ms but about being called outside of the event itself.
This can also be fixed by immediately calling `update_idletasks`, but more about this in the PR.

Thanks, have a nice day.

----------

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

From report at bugs.python.org  Tue Dec  3 08:54:08 2019
From: report at bugs.python.org (uliludmann)
Date: Tue, 03 Dec 2019 13:54:08 +0000
Subject: [issue29427] Option to skip padding for base64 urlsafe
 encoding/decoding
In-Reply-To: <1486085117.43.0.563120448637.issue29427@psf.upfronthosting.co.za>
Message-ID: <1575381248.41.0.103092403214.issue29427@roundup.psfhosted.org>


Change by uliludmann <ulrichludmann at gmail.com>:


----------
nosy: +uliludmann

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

From report at bugs.python.org  Tue Dec  3 10:36:03 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 15:36:03 +0000
Subject: [issue38270] Tests: Avoid MD5 or check for MD5 availablity
In-Reply-To: <1569406198.76.0.145895264341.issue38270@roundup.psfhosted.org>
Message-ID: <1575387363.15.0.191433989596.issue38270@roundup.psfhosted.org>


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


New changeset 894331838b256412c95d54051ec46a1cb96f52e7 by Miss Islington (bot) (stratakis) in branch 'master':
bpo-38270: Fix indentation of test_hmac assertions (GH-17446)
https://github.com/python/cpython/commit/894331838b256412c95d54051ec46a1cb96f52e7


----------

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

From report at bugs.python.org  Tue Dec  3 10:36:20 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 15:36:20 +0000
Subject: [issue38270] Tests: Avoid MD5 or check for MD5 availablity
In-Reply-To: <1569406198.76.0.145895264341.issue38270@roundup.psfhosted.org>
Message-ID: <1575387380.23.0.175793832621.issue38270@roundup.psfhosted.org>


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


----------
pull_requests: +16931
pull_request: https://github.com/python/cpython/pull/17450

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

From report at bugs.python.org  Tue Dec  3 11:38:06 2019
From: report at bugs.python.org (David Carlier)
Date: Tue, 03 Dec 2019 16:38:06 +0000
Subject: [issue38960] DTrace FreeBSD build fix
Message-ID: <1575391086.22.0.899014183284.issue38960@roundup.psfhosted.org>


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


----------
components: FreeBSD
nosy: David Carlier, koobs
priority: normal
severity: normal
status: open
title: DTrace FreeBSD build fix
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  3 11:38:32 2019
From: report at bugs.python.org (David Carlier)
Date: Tue, 03 Dec 2019 16:38:32 +0000
Subject: [issue38960] DTrace FreeBSD build fix
Message-ID: <1575391112.41.0.0738305621435.issue38960@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16932
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17451

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

From report at bugs.python.org  Tue Dec  3 11:40:39 2019
From: report at bugs.python.org (John-Mark)
Date: Tue, 03 Dec 2019 16:40:39 +0000
Subject: [issue38961] Flaky detection of compiler vendor
Message-ID: <1575391239.52.0.258963452733.issue38961@roundup.psfhosted.org>


New submission from John-Mark <johnmarka at gmail.com>:

The `configure` script for building what appears to be any version of python (I've manually checked 2.7, 3.6.6, and master) uses simple substring-in-path checks to determine the compiler vendor. This is problematic because it is very easy for it to produce very confusing false-positives.

This appeared for me when compiling with a custom version of `clang` located at 
`/home/riccardo/some/path`, which caused this line

https://github.com/python/cpython/blob/894331838b256412c95d54051ec46a1cb96f52e7/configure#L7546

to mistakenly assume an ICC configuration (because `icc` is a substring of `riccardo`). A quick check through the script reveals that compiler vendor detection in the script doesn't appear to be unified and are mostly similarly flaky.

Other projects compile a small program that checks for defines, or parses the output of `$CC --version` or similar.

----------
components: Build
messages: 357755
nosy: jmaargh
priority: normal
severity: normal
status: open
title: Flaky detection of compiler vendor
type: compile error
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Dec  3 12:23:21 2019
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Dec 2019 17:23:21 +0000
Subject: [issue24764] cgi.FieldStorage can't parse multipart part headers with
 Content-Length and no filename in Content-Disposition
In-Reply-To: <1438358841.56.0.603079767616.issue24764@psf.upfronthosting.co.za>
Message-ID: <1575393801.27.0.750513994139.issue24764@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
nosy: +Rhodri James, ethan.furman

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

From report at bugs.python.org  Tue Dec  3 12:23:29 2019
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Dec 2019 17:23:29 +0000
Subject: [issue27777] cgi.FieldStorage can't parse simple body with
 Content-Length and no Content-Disposition
In-Reply-To: <1471355745.98.0.805545529346.issue27777@psf.upfronthosting.co.za>
Message-ID: <1575393809.68.0.892389743013.issue27777@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
nosy: +Rhodri James, ethan.furman
versions:  -Python 3.5

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

From report at bugs.python.org  Tue Dec  3 12:29:48 2019
From: report at bugs.python.org (Amged Rustom)
Date: Tue, 03 Dec 2019 17:29:48 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1575394188.4.0.416968744778.issue38295@roundup.psfhosted.org>


Change by Amged Rustom <amgadhs at codehill.com>:


----------
nosy: +amgedr

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

From report at bugs.python.org  Tue Dec  3 12:32:43 2019
From: report at bugs.python.org (stealthcopter)
Date: Tue, 03 Dec 2019 17:32:43 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575394363.02.0.0482058552875.issue38945@roundup.psfhosted.org>


Change by stealthcopter <admin at stealthcopter.com>:


----------
pull_requests: +16933
pull_request: https://github.com/python/cpython/pull/17452

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

From report at bugs.python.org  Tue Dec  3 13:18:59 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2019 18:18:59 +0000
Subject: [issue38945] Remove newline characters from uu encoding methods
In-Reply-To: <1575133561.73.0.538278905149.issue38945@roundup.psfhosted.org>
Message-ID: <1575397139.14.0.209146297649.issue38945@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset a016d4e32cc9faa48105d00db275439c3dc93559 by Guido van Rossum (Matthew Rollings) in branch '2.7':
[2.7] bpo-38945: UU Encoding: Don't let newline in filename corrupt the output format (GH-17418). (#17452)
https://github.com/python/cpython/commit/a016d4e32cc9faa48105d00db275439c3dc93559


----------

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

From report at bugs.python.org  Tue Dec  3 13:36:53 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 03 Dec 2019 18:36:53 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1575398213.36.0.448696804184.issue35003@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> Are you proposing to bring that functionality, which these third-party tools perform currently, into the stdlib?

I was hoping to, but it turns out you can't make this work under Windows without inspecting the parent process (PowerShell and Command Prompt provide no way to know the path to the shell being run).

So since there's no interest in providing a way to unify the paths I'm going to close this issue.

----------
resolution:  -> rejected
stage: test needed -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  3 13:37:12 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 03 Dec 2019 18:37:12 +0000
Subject: [issue38924] pathlib paths .normalize()
In-Reply-To: <1574807025.92.0.455161841329.issue38924@roundup.psfhosted.org>
Message-ID: <1575398232.81.0.360825928658.issue38924@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

While I understand you're disappointed, do realize that the tone of your response isn't necessary. I'm going to assume you didn't mean for it to come off as confrontational and still provide a reply.

> you do realise there are no symlinks to resolve on PurePaths, right?

Yes.

> Why don't you deprecate it then?

Because the amount of code that would break for those that are willing to deal with its drawbacks is way too vast. But just because we keep that function around even with its drawbacks doesn't meant we want to propagate that in newer code.

> Let me quote the initial comment for this issue, which apparently noone read

We read it, but as I said in response, "Path inherits from PurePath, so providing a normalize() method on the latter means it will end up on the former". Now I know you suggested putting in code to somehow hide it from Path, but we try to avoid being so magical in the stdlib, especially when it would require some careful explanation in the docs that for some reason a method on an inherited class wasn't available.

Please note you can also use your own subclass or function to get the functionality you are after. There is nothing special to what you are asking for that requires inclusion in the stdlib.

----------

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

From report at bugs.python.org  Tue Dec  3 14:17:51 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 03 Dec 2019 19:17:51 +0000
Subject: [issue38960] DTrace FreeBSD build fix
Message-ID: <1575400671.76.0.248812397873.issue38960@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


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

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

From report at bugs.python.org  Tue Dec  3 14:55:50 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 19:55:50 +0000
Subject: [issue38962] Reference leaks in subinterpreters
Message-ID: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>


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

All the refleak build bots for master are reporting reference leaks in subinterpreter related tests:

https://buildbot.python.org/all/#/builders/126/builds/6/steps/5/logs/stdio
https://buildbot.python.org/all/#/builders/144/builds/6/steps/5/logs/stdio
https://buildbot.python.org/all/#/builders/206/builds/6
https://buildbot.python.org/all/#/builders/157/builds/6/steps/4/logs/stdio

......
test_atexit leaked [882, 882, 882] references, sum=2646
test_atexit leaked [12, 12, 12] memory blocks, sum=36
5 tests failed again:
    test__xxsubinterpreters test_atexit test_capi test_httpservers
    test_threading
== Tests result: FAILURE then FAILURE ==
401 tests OK.
10 slowest tests:
- test_asyncio: 33 min 34 sec
- test_concurrent_futures: 17 min 22 sec
- test_multiprocessing_spawn: 17 min 6 sec
- test_zipfile: 9 min 25 sec
- test_multiprocessing_forkserver: 9 min 2 sec
- test_multiprocessing_fork: 8 min 43 sec
- test_largefile: 7 min 32 sec
- test_lib2to3: 7 min 3 sec
- test_mailbox: 6 min 27 sec
- test_argparse: 5 min 5 sec
5 tests failed:
    test__xxsubinterpreters test_atexit test_capi test_httpservers
    test_threading
14 tests skipped:
    test_devpoll test_gdb test_ioctl test_kqueue test_msilib
    test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly
    test_winconsoleio test_winreg test_winsound test_zipfile64
7 re-run tests:
    test__xxsubinterpreters test_atexit test_capi test_httpservers
    test_nntplib test_pty test_threading


Bisecting shows the following commit as the culprit:

ef5aa9af7c7e493402ac62009e4400aed7c3d54e is the first bad commit
commit ef5aa9af7c7e493402ac62009e4400aed7c3d54e
Author: Victor Stinner <vstinner at python.org>
Date:   Wed Nov 20 00:38:03 2019 +0100

    bpo-38858: Reorganize pycore_init_types() (GH-17265)
    
    * Call _PyLong_Init() and _PyExc_Init() earlier
    * new_interpreter() reuses pycore_init_types()

 Python/pylifecycle.c | 31 +++++++++++--------------------
 1 file changed, 11 insertions(+), 20 deletions(-)
bisect run success


Running * test.test_atexit.SubinterpreterTest.test_callbacks_leak is enough for reproducing the problem.

----------
assignee: vstinner
components: Tests
messages: 357759
nosy: pablogsal, vstinner
priority: high
severity: normal
stage: needs patch
status: open
title: Reference leaks in subinterpreters
type: resource usage
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  3 15:47:39 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 20:47:39 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575406059.68.0.812019888117.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Actually, that commit has an independent refleak that was fixed (!) regarding the small integer cache. Seems that the actual commit that made the new leak is:

commit 2582d46fbcf7bdf86b9cf4016850b8d155267ac6
Author: Victor Stinner <vstinner at python.org>
Date:   Fri Nov 22 19:24:49 2019 +0100

    bpo-38858: new_interpreter() reuses pycore_init_builtins() (GH-17351)
    
    new_interpreter() now calls _PyBuiltin_Init() to create the builtins
    module and calls _PyImport_FixupBuiltin(), rather than using
    _PyImport_FindBuiltin(tstate, "builtins").
    
    pycore_init_builtins() is now responsible to initialize
    intepr->builtins_copy: inline _PyImport_Init() and remove this
    function.



Reverting this commit fixes the refleaks in atexit at least

----------

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

From report at bugs.python.org  Tue Dec  3 15:58:02 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 20:58:02 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575406682.44.0.999975031036.issue38962@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +16934
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17453

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

From report at bugs.python.org  Tue Dec  3 15:59:09 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 20:59:09 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575406749.38.0.212701215733.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, the problem seems to be that _PyBuiltin_Init() returns a new reference that is not cleared once PyModule_GetDict() and _PyBuiltins_AddExceptions() is called.

----------
stage: patch review -> needs patch

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

From report at bugs.python.org  Tue Dec  3 16:02:51 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:02:51 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575406971.91.0.312917996422.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Indeed, that fixes the problem in at least 2 modules:

 ./python -m test test_atexit -R :
0:00:00 load avg: 0.84 Run tests sequentially
0:00:00 load avg: 0.84 [1/1] test_atexit
beginning 9 repetitions
123456789
.........

== Tests result: SUCCESS ==

1 test OK.

Total duration: 1.5 sec
Tests result: SUCCESS


 ./python -m test test_capi -R :  
0:00:00 load avg: 1.19 Run tests sequentially
0:00:00 load avg: 1.19 [1/1] test_capi
beginning 9 repetitions
123456789
..........
test_capi passed in 2 min 8 sec

== Tests result: SUCCESS ==

1 test OK.

Total duration: 2 min 8 sec
Tests result: SUCCESS



Although the rest of the tests still leak, so there is something else :(

----------

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

From report at bugs.python.org  Tue Dec  3 16:22:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:22:17 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575408137.25.0.29766278973.issue38962@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +16935
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17454

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

From report at bugs.python.org  Tue Dec  3 16:22:56 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:22:56 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575408176.02.0.967903373139.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Opened https://github.com/python/cpython/pull/17454 for the fixing the leak in http_servers

----------

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

From report at bugs.python.org  Tue Dec  3 16:32:23 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:32:23 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575408743.67.0.669755516785.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

For the subinterpreter other leaks it seems that the commit that introduced the leak is:

7247407c35330f3f6292f1d40606b7ba6afd5700 is the first bad commit
commit 7247407c35330f3f6292f1d40606b7ba6afd5700
Author: Victor Stinner <vstinner at python.org>
Date:   Wed Nov 20 12:25:50 2019 +0100

    bpo-36854: Move _PyRuntimeState.gc to PyInterpreterState (GH-17287)
    
    * Rename _PyGC_InitializeRuntime() to _PyGC_InitState()
    * finalize_interp_clear() now also calls _PyGC_Fini() in
      subinterpreters (clear the GC state).

 Include/internal/pycore_object.h                   |  2 +-
 Include/internal/pycore_pymem.h                    |  2 +-
 Include/internal/pycore_pystate.h                  |  7 +--
 .../2019-11-20-12-01-37.bpo-36854.Zga_md.rst       |  3 +
 Modules/gcmodule.c                                 | 72 ++++++++++++----------
 Objects/object.c                                   | 20 +++---
 Python/pylifecycle.c                               |  3 +-
 Python/pystate.c                                   |  2 +-
 8 files changed, 62 insertions(+), 49 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2019-11-20-12-01-37.bpo-36854.Zga_md.rst
bisect run success

----------

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

From report at bugs.python.org  Tue Dec  3 16:34:19 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:34:19 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575408859.25.0.292195535635.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Indeed, reverting commit 7247407c35330f3f6292f1d40606b7ba6afd5700 fixes the issues in test_threading

----------

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

From report at bugs.python.org  Tue Dec  3 16:45:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:45:20 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1575409520.19.0.321403642347.issue36854@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +16936
pull_request: https://github.com/python/cpython/pull/17455

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

From report at bugs.python.org  Tue Dec  3 16:46:40 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:46:40 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575409600.78.0.629423320807.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I created https://github.com/python/cpython/pull/17455 to revert commit 7247407c35330f3f6292f1d40606b7ba6afd5700 as it seems that the leak is more complex than the others. 

If a solution is not found in a couple of days we need to merge it to fix the refleak buildbots.

----------

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

From report at bugs.python.org  Tue Dec  3 16:59:58 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 21:59:58 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575410398.06.0.924253818243.issue38962@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +16937
pull_request: https://github.com/python/cpython/pull/17456

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

From report at bugs.python.org  Tue Dec  3 17:02:04 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 22:02:04 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575410524.5.0.227977856959.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This patch (which is wrong) fixes the reference issues:

diff --git a/Python/pylifecycle.c b/Python/pylifecycle.c
index cce4783bc1..c354af18db 100644
--- a/Python/pylifecycle.c
+++ b/Python/pylifecycle.c
@@ -1276,6 +1276,7 @@ finalize_interp_clear(PyThreadState *tstate)
         _PyExc_Fini();
     }
 
+    PyGC_Collect();
     _PyGC_Fini(tstate);
 }


This suggests that the per-interpreter gc does not play well with the refleak checker.

----------

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

From report at bugs.python.org  Tue Dec  3 17:12:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 22:12:57 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575411177.61.0.901739785214.issue38962@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +16938
pull_request: https://github.com/python/cpython/pull/17457

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

From report at bugs.python.org  Tue Dec  3 17:15:35 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 03 Dec 2019 22:15:35 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575411335.21.0.665320821131.issue38962@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Opened PR 17457 for the refleaks of test__xxsubinterpreters although I am not very convinced that we can call the GC at that point.

----------

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

From report at bugs.python.org  Tue Dec  3 18:31:08 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 23:31:08 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1575415868.89.0.851954914695.issue27873@roundup.psfhosted.org>


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


----------
pull_requests: +16939
pull_request: https://github.com/python/cpython/pull/17458

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

From report at bugs.python.org  Tue Dec  3 18:31:07 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 23:31:07 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1575415867.91.0.113277374583.issue27873@roundup.psfhosted.org>


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


New changeset eb48a451e3844185b9a8751c9badffbddc89689d by Miss Islington (bot) (An Long) in branch 'master':
bpo-27873: Update docstring for multiprocessing.Pool.map (GH-17436)
https://github.com/python/cpython/commit/eb48a451e3844185b9a8751c9badffbddc89689d


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

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

From report at bugs.python.org  Tue Dec  3 18:31:15 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 23:31:15 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1575415875.92.0.641303814607.issue27873@roundup.psfhosted.org>


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


----------
pull_requests: +16940
pull_request: https://github.com/python/cpython/pull/17459

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

From report at bugs.python.org  Tue Dec  3 18:36:51 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 23:36:51 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1575416211.76.0.0321565056469.issue27873@roundup.psfhosted.org>


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


New changeset 55a7046471e19843a68d4a1a15252fd197bb6913 by Miss Islington (bot) in branch '3.7':
bpo-27873: Update docstring for multiprocessing.Pool.map (GH-17436)
https://github.com/python/cpython/commit/55a7046471e19843a68d4a1a15252fd197bb6913


----------

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

From report at bugs.python.org  Tue Dec  3 18:37:44 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 03 Dec 2019 23:37:44 +0000
Subject: [issue27873] multiprocessing.pool.Pool.map should take more than one
 iterable
In-Reply-To: <1472253350.37.0.404019702525.issue27873@psf.upfronthosting.co.za>
Message-ID: <1575416264.84.0.419168132623.issue27873@roundup.psfhosted.org>


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


New changeset baf07395eaa77e515ddfa1d3f42785d50b4d2889 by Miss Islington (bot) in branch '3.8':
bpo-27873: Update docstring for multiprocessing.Pool.map (GH-17436)
https://github.com/python/cpython/commit/baf07395eaa77e515ddfa1d3f42785d50b4d2889


----------

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

From report at bugs.python.org  Tue Dec  3 19:48:48 2019
From: report at bugs.python.org (Andrew Frost)
Date: Wed, 04 Dec 2019 00:48:48 +0000
Subject: [issue7982] extend captured_output to simulate different
 stdout.encoding
In-Reply-To: <1266844157.92.0.671833558035.issue7982@psf.upfronthosting.co.za>
Message-ID: <1575420528.75.0.378851991442.issue7982@roundup.psfhosted.org>


Andrew Frost <adfrost at ucdavis.edu> added the comment:

in test_xmlrpc.py, it can replace this entire function
- https://github.com/python/cpython/blob/8f4ef3b019ce380022018587571b0f970e668de3/Lib/test/test_xmlrpc.py#L1344
in test_source_encoding.py, it can remove this line
- https://github.com/python/cpython/blob/8f4ef3b019ce380022018587571b0f970e668de3/Lib/test/test_source_encoding.py#L209

It could also be useful if a test file switches between encoding schemes frequently.

----------

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

From report at bugs.python.org  Tue Dec  3 21:57:02 2019
From: report at bugs.python.org (Jason Killen)
Date: Wed, 04 Dec 2019 02:57:02 +0000
Subject: [issue38741] Definition of multiple ']' in header configparser
In-Reply-To: <1573193272.74.0.118296138456.issue38741@roundup.psfhosted.org>
Message-ID: <1575428222.14.0.618767287578.issue38741@roundup.psfhosted.org>


Change by Jason Killen <jsnklln at gmail.com>:


----------
nosy: +Jason.Killen

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

From report at bugs.python.org  Wed Dec  4 00:34:03 2019
From: report at bugs.python.org (Roman Joost)
Date: Wed, 04 Dec 2019 05:34:03 +0000
Subject: [issue38963] multiprocessing processes seem to "bleed" user
 information (GID/UID/groups)
Message-ID: <1575437643.58.0.600766236009.issue38963@roundup.psfhosted.org>


New submission from Roman Joost <roman at bromeco.de>:

When running a process which changes UID/GID, some of the following processes will run as the user I change to per process.

In order to reproduce (see the attached reproducer):
1. Change the 'USERNAME' to an unprivileged user on your system.
2. Run the reproducer as a user with elevated privileges (e.g. root or some secondary user you have on your system). Mind you, I don't think the user you run as needs elevated privileges, but that's the user I ran as when I observed this behaviour.
3. The reproducer iterates over a list (It stems from a test function which was checking permissions on log files). Observe the print out, which prints the process' GID, UID and secondary groups before we're changing to the users GID, UID and secondary groups.
4. You should observe that at some point the process prints the user information of the user we want to change to not the one which initially started the script.

Example output when running locally as root:

('B', (0, 0, [0]))
('A', (0, 0, [0]))
('C', (0, 0, [0]))
('E', (0, 0, [0]))
('D', (0, 0, [0]))
('F', (1002, 1002, [10, 135, 1000, 1002]))
('H', (1002, 1002, [10, 135, 1000, 1002]))
('I', (1002, 1002, [10, 135, 1000, 1002]))
('J', (1002, 1002, [10, 135, 1000, 1002]))
('G', (1002, 1002, [10, 135, 1000, 1002]))
('K', (1002, 1002, [10, 135, 1000, 1002]))
('L', (1002, 1002, [10, 135, 1000, 1002]))
('M', (1002, 1002, [10, 135, 1000, 1002]))
('N', (1002, 1002, [10, 135, 1000, 1002]))

I would have expected `0` all the way through.

However, if I initialise the Pool with `maxtasksperchild=1` the isolation seems as expected.

I don't know whether this is a bug or I'm foolish to invoke multiprocessing like this. I've run out of time to investigate this further. It's certainly strange behaviour to me and I thought I better report it, since reproducing seems fairly deterministic.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: reproducer.py
messages: 357773
nosy: docs at python, romanofski
priority: normal
severity: normal
status: open
title: multiprocessing processes seem to "bleed" user information (GID/UID/groups)
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48753/reproducer.py

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

From report at bugs.python.org  Wed Dec  4 01:09:48 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Wed, 04 Dec 2019 06:09:48 +0000
Subject: [issue38960] DTrace FreeBSD build fix
Message-ID: <1575439788.6.0.75374191254.issue38960@roundup.psfhosted.org>


New submission from Kubilay Kocak <koobs.freebsd at gmail.com>:

Thank you for the heads-up David.

If you need OS support and don't have access to a FreeBSD install, I can provide you with an SSH account to the servers that run the Python buildbots if that would be helpful either now or in the future

----------

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

From report at bugs.python.org  Wed Dec  4 01:15:27 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 06:15:27 +0000
Subject: [issue29636] Specifying indent in the json.tool command
In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za>
Message-ID: <1575440127.2.0.125258414043.issue29636@roundup.psfhosted.org>


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


New changeset 03257949bc02a4afdf2ea1eb07a73f8128129579 by Inada Naoki (Daniel Himmelstein) in branch 'master':
bpo-29636: Add --(no-)indent arguments to json.tool (GH-345)
https://github.com/python/cpython/commit/03257949bc02a4afdf2ea1eb07a73f8128129579


----------

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

From report at bugs.python.org  Wed Dec  4 01:17:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 06:17:13 +0000
Subject: [issue29636] Specifying indent in the json.tool command
In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za>
Message-ID: <1575440233.0.0.394008402923.issue29636@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

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

From report at bugs.python.org  Wed Dec  4 01:36:29 2019
From: report at bugs.python.org (Bar Harel)
Date: Wed, 04 Dec 2019 06:36:29 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1575441389.74.0.284817631078.issue38878@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

Ready for merge

----------

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

From report at bugs.python.org  Wed Dec  4 01:39:59 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 06:39:59 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575441599.19.0.0078349585485.issue33684@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +16941
pull_request: https://github.com/python/cpython/pull/17460

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

From report at bugs.python.org  Wed Dec  4 03:27:53 2019
From: report at bugs.python.org (Erik Cederstrand)
Date: Wed, 04 Dec 2019 08:27:53 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
Message-ID: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>


New submission from Erik Cederstrand <erik at cederstrand.dk>:

When I have a normal syntax error in a file, Python reports the filename in the exception output:

$ cat syntax_error.py 
0x=5

$ python3.8 syntax_error.py 
  File "syntax_error.py", line 1
    0x=5
     ^
SyntaxError: invalid hexadecimal literal


But if the syntax error is inside an f-string, Python reports 'File "<fstring>"' instead of the actual filename in the exception output.

$ cat syntax_error_in_fstring.py 
f'This is a syntax error: {0x=5}'

$ python3.8 syntax_error_in_fstring.py 
  File "<fstring>", line 1
SyntaxError: invalid hexadecimal literal

----------
messages: 357777
nosy: Erik Cederstrand
priority: normal
severity: normal
status: open
title: Output of syntax error in f-string contains wrong filename
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  4 03:33:21 2019
From: report at bugs.python.org (=?utf-8?q?Martin_Li=C5=A1ka?=)
Date: Wed, 04 Dec 2019 08:33:21 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
Message-ID: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>


New submission from Martin Li?ka <marxin.liska at gmail.com>:

The test-case is stuck after update to GCC 10.
I've got a patch for that.

----------
messages: 357778
nosy: Martin Li?ka
priority: normal
severity: normal
status: open
title: test_stack_overflow (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10

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

From report at bugs.python.org  Wed Dec  4 03:35:26 2019
From: report at bugs.python.org (=?utf-8?q?Martin_Li=C5=A1ka?=)
Date: Wed, 04 Dec 2019 08:35:26 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575448526.15.0.422895827036.issue38965@roundup.psfhosted.org>


Change by Martin Li?ka <marxin.liska at gmail.com>:


----------
keywords: +patch
pull_requests: +16942
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17462

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

From report at bugs.python.org  Wed Dec  4 03:39:40 2019
From: report at bugs.python.org (Pranav Pandya)
Date: Wed, 04 Dec 2019 08:39:40 +0000
Subject: [issue38966] List similarity relationship
Message-ID: <1575448780.55.0.278075875702.issue38966@roundup.psfhosted.org>


New submission from Pranav Pandya <thepranavpandya at gmail.com>:

When list is initialized and equated to give the same value as list1=list2=[],

then post initialization list1 & list2 are taken as same values and any changes in list2 are changed in list 1 and so on. 

Thus during initialization if lists are equated, they are taken as same values even if one is changed

----------
assignee: terry.reedy
components: IDLE
messages: 357779
nosy: PranavSP, terry.reedy
priority: normal
severity: normal
status: open
title: List similarity relationship
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  4 03:39:59 2019
From: report at bugs.python.org (Erik Cederstrand)
Date: Wed, 04 Dec 2019 08:39:59 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575448799.23.0.337025853656.issue38964@roundup.psfhosted.org>


Erik Cederstrand <erik at cederstrand.dk> added the comment:

Additionally, the output in the 2nd example does not contain the helpful text printing the context and location of the code containing the syntax error.

----------

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

From report at bugs.python.org  Wed Dec  4 03:46:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 08:46:12 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575449172.95.0.584046533365.issue38964@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Wed Dec  4 03:54:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 08:54:03 +0000
Subject: [issue38966] List similarity relationship
In-Reply-To: <1575448780.55.0.278075875702.issue38966@roundup.psfhosted.org>
Message-ID: <1575449643.12.0.736707792606.issue38966@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is same as doing the below with list1 getting a reference of list2. Assignments in Python don't copy the value but make a reference. This is not an issue specific to IDLE as tagged and has the same behaviour under a normal REPL.

https://docs.python.org/3/reference/expressions.html#evaluation-order

>>> list2 = []
>>> list1 = list2
>>> id(list2)
4487803136
>>> id(list1)
4487803136

----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Dec  4 04:06:39 2019
From: report at bugs.python.org (=?utf-8?b?UnViw6luIEplc8O6cyBHYXJjw61hIEhlcm7DoW5kZXo=?=)
Date: Wed, 04 Dec 2019 09:06:39 +0000
Subject: [issue38967] Improve error message in enum.py for python 3.5
Message-ID: <1575450398.98.0.140033297408.issue38967@roundup.psfhosted.org>


New submission from Rub?n Jes?s Garc?a Hern?ndez <rubengarciahernandez at gmail.com>:

I changed the '_names_ are reserved for future Enum use' line to be more user-friendly thus:
'Names surrounded by underscore (such as "%s") are reserved for future Enum use' % key

The current message can be interpreted as the literal string _names_; and showing the offending key can help users debug.

----------
assignee: docs at python
components: Documentation
files: enum.diff.txt
messages: 357782
nosy: Rub?n Jes?s Garc?a Hern?ndez, docs at python
priority: normal
severity: normal
status: open
title: Improve error message in enum.py for python 3.5
versions: Python 3.5
Added file: https://bugs.python.org/file48754/enum.diff.txt

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

From report at bugs.python.org  Wed Dec  4 04:07:05 2019
From: report at bugs.python.org (=?utf-8?b?UnViw6luIEplc8O6cyBHYXJjw61hIEhlcm7DoW5kZXo=?=)
Date: Wed, 04 Dec 2019 09:07:05 +0000
Subject: [issue38967] Improve error message in enum.py for python 3.5
In-Reply-To: <1575450398.98.0.140033297408.issue38967@roundup.psfhosted.org>
Message-ID: <1575450425.31.0.755147250297.issue38967@roundup.psfhosted.org>


Change by Rub?n Jes?s Garc?a Hern?ndez <rubengarciahernandez at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Wed Dec  4 04:17:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 09:17:16 +0000
Subject: [issue38967] Improve error message in enum for member name surrounded
 by underscore.
In-Reply-To: <1575450398.98.0.140033297408.issue38967@roundup.psfhosted.org>
Message-ID: <1575451036.66.0.866703528055.issue38967@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Error message changes in code are normally not backported to older versions so I have changed the subject accordingly and tagged 3.9. Thanks.

----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
nosy: +xtreak
title: Improve error message in enum.py for python 3.5 -> Improve error message in enum for member name surrounded by underscore.
versions: +Python 3.9 -Python 3.5

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

From report at bugs.python.org  Wed Dec  4 04:18:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 09:18:26 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575451106.82.0.7633271016.issue38965@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Tests
nosy: +vstinner
type:  -> behavior

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

From report at bugs.python.org  Wed Dec  4 04:29:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 09:29:17 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575451757.34.0.445660613647.issue38962@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 24f5cac7254177a4c9956d680c0a9b6dadd85c6f by Victor Stinner (Pablo Galindo) in branch 'master':
bpo-38962: Fix reference leak in test_httpservers (GH-17454)
https://github.com/python/cpython/commit/24f5cac7254177a4c9956d680c0a9b6dadd85c6f


----------

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

From report at bugs.python.org  Wed Dec  4 04:31:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 09:31:41 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1575451901.37.0.657377392429.issue38863@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The change introduced a reference leak, see bpo-38962. Pablo fixed it:

commit 24f5cac7254177a4c9956d680c0a9b6dadd85c6f (HEAD -> master, upstream/master)
Author: Pablo Galindo <Pablogsal at gmail.com>
Date:   Wed Dec 4 09:29:10 2019 +0000

    bpo-38962: Fix reference leak in test_httpservers (GH-17454)

----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Dec  4 04:39:37 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 09:39:37 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575452377.05.0.704791503439.issue33684@roundup.psfhosted.org>


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


New changeset 808769f3a4cbdc47cf1a5708dd61b1787bb192d4 by Inada Naoki in branch 'master':
bpo-33684: json.tool: Use utf-8 for infile and outfile. (GH-17460)
https://github.com/python/cpython/commit/808769f3a4cbdc47cf1a5708dd61b1787bb192d4


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

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

From report at bugs.python.org  Wed Dec  4 04:39:52 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 09:39:52 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575452392.09.0.366599559931.issue33684@roundup.psfhosted.org>


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


----------
pull_requests: +16943
pull_request: https://github.com/python/cpython/pull/17464

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

From report at bugs.python.org  Wed Dec  4 04:47:51 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 04 Dec 2019 09:47:51 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1575452871.33.0.0378507359873.issue38863@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks, Pablo!

----------

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

From report at bugs.python.org  Wed Dec  4 04:56:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 09:56:02 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575453362.16.0.769537515337.issue38962@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

"""
5 tests failed again:
    test__xxsubinterpreters test_atexit test_capi test_httpservers
    test_threading
"""

I merged Pablo's fix for test_httpservers.

With PR 17457 + PR 17453 (and the test_httpservers fix), the 5 tests don't leak anymore.

I am fine with PR 17457 and PR 17453, I added some comments.

I would prefer to avoid a revert (PR 17455) if possible ;-)

--

Except of PR 17453 which was my fault in my refactoring work, the problem is the work on subinterpreters doesn't introduce regressions but only reveal existing issues.

Example with Python compiled in the debug mode (master branch):

$ ./python -X showrefcount -c pass
[18564 refs, 6496 blocks]

Python "leaks" 18564 references at exit.

My work is to better isolate subinterpreters from the main interpreter, and so the missing clean up code is revealed by reference leak buildbot checks.

----------

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

From report at bugs.python.org  Wed Dec  4 04:57:59 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 09:57:59 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575453479.11.0.780326345408.issue33684@roundup.psfhosted.org>


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


New changeset a75cad440ab50d823af5f06e51dfed3a319f1e8c by Miss Islington (bot) in branch '3.8':
bpo-33684: json.tool: Use utf-8 for infile and outfile. (GH-17460)
https://github.com/python/cpython/commit/a75cad440ab50d823af5f06e51dfed3a319f1e8c


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

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

From report at bugs.python.org  Wed Dec  4 04:58:41 2019
From: report at bugs.python.org (Siwon Kang)
Date: Wed, 04 Dec 2019 09:58:41 +0000
Subject: [issue38863] Improve is_cgi() in http.server
In-Reply-To: <1574258479.69.0.180515084691.issue38863@roundup.psfhosted.org>
Message-ID: <1575453521.22.0.835538651278.issue38863@roundup.psfhosted.org>


Siwon Kang <kkangshawn at gmail.com> added the comment:

Obviously, I should have taken back what I added to cgi_directories. Thank you Pablo and Victor!

----------

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

From report at bugs.python.org  Wed Dec  4 05:05:53 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 10:05:53 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575453953.08.0.466302207406.issue33684@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +16944
pull_request: https://github.com/python/cpython/pull/17465

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

From report at bugs.python.org  Wed Dec  4 05:26:29 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 10:26:29 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575455189.47.0.390730613999.issue33684@roundup.psfhosted.org>


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


New changeset e0f148e6635480521036415bd782c3424fe6c619 by Inada Naoki in branch '3.7':
bpo-33684: json.tool: Use utf-8 for infile and outfile. (GH-17460)
https://github.com/python/cpython/commit/e0f148e6635480521036415bd782c3424fe6c619


----------

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

From report at bugs.python.org  Wed Dec  4 05:27:07 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 10:27:07 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575455227.58.0.760361492158.issue33684@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.9

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

From report at bugs.python.org  Wed Dec  4 05:27:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 04 Dec 2019 10:27:17 +0000
Subject: [issue33684] parse failed for mutibytes characters,
 encode will show in \xxx
In-Reply-To: <1527604179.28.0.682650639539.issue33684@psf.upfronthosting.co.za>
Message-ID: <1575455237.76.0.359028110132.issue33684@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
components: +Library (Lib) -Unicode

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

From report at bugs.python.org  Wed Dec  4 05:43:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 Dec 2019 10:43:13 +0000
Subject: [issue38966] List similarity relationship
In-Reply-To: <1575448780.55.0.278075875702.issue38966@roundup.psfhosted.org>
Message-ID: <1575456193.06.0.985493165538.issue38966@roundup.psfhosted.org>


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


----------
assignee: terry.reedy -> 
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 05:57:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 10:57:29 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575457049.62.0.805601049245.issue38815@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_ssl still fails on FreeBSD:

======================================================================
FAIL: test_min_max_version (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 1244, in test_min_max_version
    self.assertIn(
AssertionError: <TLSVersion.TLSv1_2: 771> not found in {<TLSVersion.SSLv3: 768>, <TLSVersion.TLSv1: 769>}

======================================================================
FAIL: test_min_max_version_mismatch (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 220, in wrapper
    return func(*args, **kw)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_ssl.py", line 3846, in test_min_max_version_mismatch
    self.assertIn("alert", str(e.exception))
AssertionError: 'alert' not found in '[SSL: NO_PROTOCOLS_AVAILABLE] no protocols available (_ssl.c:1108)'

----------

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

From report at bugs.python.org  Wed Dec  4 06:20:08 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 11:20:08 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575458408.36.0.563428357795.issue38962@roundup.psfhosted.org>


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


New changeset b96c6b0723b889d3a0c1740bce7f579f33d246f2 by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-38962: Fix reference leak in new_interpreter() (GH-17453)
https://github.com/python/cpython/commit/b96c6b0723b889d3a0c1740bce7f579f33d246f2


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

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

From report at bugs.python.org  Wed Dec  4 06:29:11 2019
From: report at bugs.python.org (Riccardo La Marca)
Date: Wed, 04 Dec 2019 11:29:11 +0000
Subject: [issue38968] int method works improperly
Message-ID: <1575458951.34.0.163465014932.issue38968@roundup.psfhosted.org>


Change by Riccardo La Marca <riccardolamarca1 at gmail.com>:


----------
files: Schermata 2019-12-04 alle 12.09.36.png
nosy: Riccardo La Marca
priority: normal
severity: normal
status: open
title: int method works improperly
versions: Python 3.8
Added file: https://bugs.python.org/file48755/Schermata 2019-12-04 alle 12.09.36.png

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

From report at bugs.python.org  Wed Dec  4 06:34:40 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Wed, 04 Dec 2019 11:34:40 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575459280.8.0.192643104988.issue38815@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

In case it's relevant, I note the following:

The ssl module is built with -I/usr/local/include in the compile line.

Leaving aside:

 - the warts of the build system, and 
 - the lack of specific --with-foo=<path> semantics to allow providing well(narrowly)-scoped include/library paths
 - how and whether the default python build using -I/usr/local/include is 'good' or not ...

it means that the build is finding openssl111 on FreeBSD provided by ports, not base (base also includes openssl 1.1.1 @ /usr/include|lib)

More specifically, our openssl111 port happens to have many options that allow enabling/disabling various software features, including encryption algorithms and protocol versions

The current (installed) build of openssl111 on the buildbot worker that is failing, has the following options set/unset:

OPTIONS_FILE_UNSET+=CT
OPTIONS_FILE_UNSET+=MAN3
OPTIONS_FILE_UNSET+=RFC3779
OPTIONS_FILE_SET+=SHARED
OPTIONS_FILE_UNSET+=ZLIB
OPTIONS_FILE_UNSET+=ARIA
OPTIONS_FILE_UNSET+=DES
OPTIONS_FILE_UNSET+=GOST
OPTIONS_FILE_UNSET+=IDEA
OPTIONS_FILE_UNSET+=SM2
OPTIONS_FILE_UNSET+=SM3
OPTIONS_FILE_UNSET+=SM4
OPTIONS_FILE_UNSET+=RC2
OPTIONS_FILE_UNSET+=RC4
OPTIONS_FILE_UNSET+=RC5
OPTIONS_FILE_UNSET+=MD2
OPTIONS_FILE_UNSET+=MD4
OPTIONS_FILE_UNSET+=MDC2
OPTIONS_FILE_UNSET+=RMD160
OPTIONS_FILE_SET+=ASM
OPTIONS_FILE_SET+=SSE2
OPTIONS_FILE_SET+=THREADS
OPTIONS_FILE_SET+=EC
OPTIONS_FILE_SET+=NEXTPROTONEG
OPTIONS_FILE_UNSET+=SCTP
OPTIONS_FILE_UNSET+=SSL3
OPTIONS_FILE_UNSET+=TLS1
OPTIONS_FILE_UNSET+=TLS1_1
OPTIONS_FILE_SET+=TLS1_2

In summary, this build only has TLS 1.2 and TLS 1.3 enabled (but with other various things disabled, not the defaults of the upstream openssl build), and may be indicated in this test failure, possibly only one example of many other similar issues of the same class, something like "tests assume certain features"

Relatedly, this method of disabling various default options in openssl, is how a number [1] of issues in the Python cryptography package were found:

https://github.com/pyca/cryptography/issues/5065

* Another issue is a build failure with NPN disabled, yet to be reported

----------
nosy: +koobs

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

From report at bugs.python.org  Wed Dec  4 06:36:30 2019
From: report at bugs.python.org (Riccardo La Marca)
Date: Wed, 04 Dec 2019 11:36:30 +0000
Subject: [issue38968] int method works improperly
Message-ID: <1575459390.3.0.635497452263.issue38968@roundup.psfhosted.org>


Change by Riccardo La Marca <riccardolamarca1 at gmail.com>:


Removed file: https://bugs.python.org/file48755/Schermata 2019-12-04 alle 12.09.36.png

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

From report at bugs.python.org  Wed Dec  4 06:36:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 11:36:37 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1575459397.78.0.580978460107.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Victor> I'm not fully happy with this solution

Eric> Should we have an issue open for finding a better solution?  Are there risks with what you did that we don't want long-term?

Pablo made a small changes in my workaround, by calling _PyGC_CollectNoFail() after PyInterpreterState_Clear().
https://github.com/python/cpython/pull/17457/files

I tried to avoid that, since I consider that no arbitrary Python code should be called after PyInterpreterState_Clear(), whereas the GC can trigger arbitrary __del__() methods implemented in pure Python. See discussion at https://github.com/python/cpython/pull/17457

Each time I tried to fix a bug in the Python finalization, I introduced worse bugs :-D

We cannot fix all bugs at once, we have to work incrementally. I like the idea of introducing workarounds specific to subinterpreters: leave the code path for the main interpreter unchanged. It helps to iterate on the code to slowly fix the code.

I prefer to not open an issue, since the Python finalization is broken is so many ways :-D Anyway, I'm hitting issues on the finalization each time I'm working on subinterpeter changes, so it's hard to forget about it :-)

I started to take notes at:
https://github.com/python/cpython/pull/17457/files

----------

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

From report at bugs.python.org  Wed Dec  4 06:39:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 11:39:08 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1575459548.43.0.664957466261.issue36854@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Eric:
"""
Thanks so much for getting this done, Victor!
Did I mention that you're my hero? :)
"""

You're welcome. I'm a believer that subinterpreters is one of the most realistic solution to make Python faster. I said it in my EuroPython keynote on CPython performance ;-)

https://github.com/vstinner/talks/blob/master/2019-EuroPython/python_performance.pdf

"Conclusion: PyHandle, tracing GC and subinterpreters are very promising!"

----------

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

From report at bugs.python.org  Wed Dec  4 06:41:44 2019
From: report at bugs.python.org (Riccardo La Marca)
Date: Wed, 04 Dec 2019 11:41:44 +0000
Subject: [issue38968] int method works improperly
Message-ID: <1575459704.49.0.181517637531.issue38968@roundup.psfhosted.org>


Change by Riccardo La Marca <riccardolamarca1 at gmail.com>:


Added file: https://bugs.python.org/file48756/Code.png

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

From report at bugs.python.org  Wed Dec  4 06:44:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2019 11:44:41 +0000
Subject: [issue38968] int method works improperly
Message-ID: <1575459881.87.0.715105566225.issue38968@roundup.psfhosted.org>


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

Please provide any details. What methods and why do you think they do not work properly.

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

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

From report at bugs.python.org  Wed Dec  4 06:48:27 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 Dec 2019 11:48:27 +0000
Subject: [issue38968] int method works improperly
In-Reply-To: <1575459881.87.0.715105566225.issue38968@roundup.psfhosted.org>
Message-ID: <1575460107.7.0.817771772079.issue38968@roundup.psfhosted.org>


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

Hi Riccardo,

In the future, would you mind not posting screenshots of code or errors? Rather, copy and paste the text. That makes it easier for others to replicate the error, and also allows visually impaired and blind people using screen leaders.

Otherwise you force us to retype your code, which can introduce errors.

This is not a bug, it is normal and expected behaviour. You type the number "123456789012345678901234567890.76" but floats only have 64 bits of precision, so that becomes the float 1.2345678901234568e+29 which is *exactly* the whole number 123456789012345677877719597056 just as `int` reports.

So nothing to do with `int`, it is normal behaviour for floats.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 06:50:58 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 Dec 2019 11:50:58 +0000
Subject: [issue38968] int method works improperly
In-Reply-To: <1575459881.87.0.715105566225.issue38968@roundup.psfhosted.org>
Message-ID: <1575460258.86.0.696351911811.issue38968@roundup.psfhosted.org>


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

You can read more here:

https://docs.python.org/3/tutorial/floatingpoint.html

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

----------

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

From report at bugs.python.org  Wed Dec  4 06:51:08 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 11:51:08 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575460268.6.0.0953206220885.issue38962@roundup.psfhosted.org>


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


New changeset ac0e1c2694bc199dbd073312145e3c09bee52cc4 by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-38962: Fix reference leak in the per-subinterpreter gc (GH-17457)
https://github.com/python/cpython/commit/ac0e1c2694bc199dbd073312145e3c09bee52cc4


----------

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

From report at bugs.python.org  Wed Dec  4 07:08:14 2019
From: report at bugs.python.org (Batuhan)
Date: Wed, 04 Dec 2019 12:08:14 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575461294.15.0.405430691471.issue38964@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

This is actually specified behavior in PEP 498
 
https://www.python.org/dev/peps/pep-0498/#expression-evaluation

> Expressions are parsed with the equivalent of ast.parse('(' + expression + ')', '<fstring>', 'eval')

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Wed Dec  4 07:11:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 12:11:41 +0000
Subject: [issue31821] pause_reading() doesn't work from connection_made()
In-Reply-To: <1508438943.14.0.213398074469.issue31821@psf.upfronthosting.co.za>
Message-ID: <1575461501.21.0.269585129978.issue31821@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

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

From report at bugs.python.org  Wed Dec  4 07:12:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 12:12:28 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1575461548.47.0.754491125131.issue38962@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The 5 tests don't leak anymore, I close thee issue. Thanks Pablo!

$ ./python -m test -R 3:3 -j0 test__xxsubinterpreters test_atexit test_capi test_httpservers test_threading
(...)
Total duration: 1 min 2 sec
Tests result: SUCCESS

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

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

From report at bugs.python.org  Wed Dec  4 08:00:31 2019
From: report at bugs.python.org (Riccardo La Marca)
Date: Wed, 04 Dec 2019 13:00:31 +0000
Subject: [issue38969] The "int" method doesn't work correctly for long numbers
 with some decimal places.
Message-ID: <1575464431.36.0.640599521559.issue38969@roundup.psfhosted.org>


New submission from Riccardo La Marca <riccardolamarca1 at gmail.com>:

PyDev console: starting.

Python 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27) 
[Clang 6.0 (clang-600.0.57)] on darwin
>>> int(123456789012345678901234567890)
123456789012345678901234567890
>>> int(123456789012345678901234567890.76)
123456789012345677877719597056

----------
messages: 357803
nosy: Riccardo La Marca
priority: normal
severity: normal
status: open
title: The "int" method doesn't work correctly for long numbers with some decimal places.
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  4 08:10:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2019 13:10:03 +0000
Subject: [issue38969] The "int" method doesn't work correctly for long numbers
 with some decimal places.
In-Reply-To: <1575464431.36.0.640599521559.issue38969@roundup.psfhosted.org>
Message-ID: <1575465003.79.0.359932446424.issue38969@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> int method works improperly

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

From report at bugs.python.org  Wed Dec  4 08:18:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 04 Dec 2019 13:18:18 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575465498.78.0.961596496628.issue38964@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Although Batuhan is correct maybe we can consider trying to improve the debugging experience off-strings due to the fact that these errors in a big project may be difficult to find. Although you have always the back-trace on the other side.

----------
nosy: +pablogsal
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 08:18:30 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 04 Dec 2019 13:18:30 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575465510.93.0.918682579386.issue38964@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Wed Dec  4 08:23:16 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 Dec 2019 13:23:16 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575465796.0.0.0071941609816.issue38964@roundup.psfhosted.org>


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

I agree that although the PEP says that's how it behaves, that shouldn't be prescriptive of the error message. Clearly we can be more helpful here.

I have a large, elaborate re-write of the error generating code that I've been working on, on and off for over a year, which would address this problem. I'm not sure when or if I'll finish it. It touches a lot of things, and my branch won't merge cleanly any more.

Additionally, the idea of moving f-strings into the Python grammar would also fix this problem. That might be a better way forward, although it has a number of downsides, too.

----------

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

From report at bugs.python.org  Wed Dec  4 08:23:34 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 Dec 2019 13:23:34 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575465814.84.0.062922576496.issue38964@roundup.psfhosted.org>


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


----------
assignee:  -> eric.smith
stage: resolved -> 

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

From report at bugs.python.org  Wed Dec  4 10:06:45 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 04 Dec 2019 15:06:45 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575472005.0.0.130963830185.issue38964@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Additionally, the idea of moving f-strings into the Python grammar would also fix this problem. That might be a better way forward, although it has a number of downsides, too.

For considerin this path we would need to wait to see first the future of the new experiment with the PEG parser to avoid potentially throwing away all the work in the parser and the tokenizer. Also, this approach will likely entail much more changes than reworking the error reporting code.

----------

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

From report at bugs.python.org  Wed Dec  4 10:17:04 2019
From: report at bugs.python.org (castix)
Date: Wed, 04 Dec 2019 15:17:04 +0000
Subject: [issue38970] [PDB] NameError in list comprehension in PDB
Message-ID: <1575472624.05.0.465658492617.issue38970@roundup.psfhosted.org>


New submission from castix <vincenzo.castiglia at axant.it>:

Related to https://bugs.python.org/issue27316

This code works from the repl:
Python 3.7.4 (default, Oct  4 2019, 06:57:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb; pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) z = True
(Pdb) [x for x in [1,2] if z]
[1, 2]
(Pdb) 

However in my (turbogears2) wsgi application it raises:
(Pdb) z = True
(Pdb) [x for x in [1,2] if z]
*** NameError: name 'z' is not defined
(Pdb) z
True
(Pdb) 

I don't know how to report the issue in a reproducible way.
Thanks

----------
components: Library (Lib)
messages: 357807
nosy: castix
priority: normal
severity: normal
status: open
title: [PDB] NameError in list comprehension in PDB
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Dec  4 11:03:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 16:03:04 +0000
Subject: [issue38634] Symbol resolution conflict when embeding python in an
 application using libedit
In-Reply-To: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>
Message-ID: <1575475384.69.0.752689625496.issue38634@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7105319ada2e663659020cbe9fdf7ff38f421ab2 by Victor Stinner (serge-sans-paille) in branch 'master':
 bpo-38634: Allow non-apple build to cope with libedit (GH-16986)
https://github.com/python/cpython/commit/7105319ada2e663659020cbe9fdf7ff38f421ab2


----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Dec  4 11:03:22 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 16:03:22 +0000
Subject: [issue38634] Symbol resolution conflict when embeding python in an
 application using libedit
In-Reply-To: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>
Message-ID: <1575475402.12.0.770151002214.issue38634@roundup.psfhosted.org>


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


----------
pull_requests: +16945
pull_request: https://github.com/python/cpython/pull/17466

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

From report at bugs.python.org  Wed Dec  4 11:03:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 16:03:58 +0000
Subject: [issue38634] Symbol resolution conflict when embeding python in an
 application using libedit
In-Reply-To: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>
Message-ID: <1575475438.31.0.805906912033.issue38634@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +Library (Lib)
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  4 11:05:15 2019
From: report at bugs.python.org (Eric Wieser)
Date: Wed, 04 Dec 2019 16:05:15 +0000
Subject: [issue37604] warnings should use a ContextVar to manage
 filters/registry
In-Reply-To: <1563283497.67.0.626244687635.issue37604@roundup.psfhosted.org>
Message-ID: <1575475515.48.0.996345244887.issue37604@roundup.psfhosted.org>


Eric Wieser <wieser.eric at gmail.com> added the comment:

A relevant old issue is https://bugs.python.org/issue6647

----------
components: +Library (Lib)
nosy: +Eric Wieser
type:  -> behavior

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

From report at bugs.python.org  Wed Dec  4 11:21:21 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 16:21:21 +0000
Subject: [issue38634] Symbol resolution conflict when embeding python in an
 application using libedit
In-Reply-To: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>
Message-ID: <1575476481.33.0.651357889455.issue38634@roundup.psfhosted.org>


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


New changeset 68669ef7883ea6338ca441e50f4f9d975f54d017 by Miss Islington (bot) in branch '3.8':
bpo-38634: Allow non-apple build to cope with libedit (GH-16986)
https://github.com/python/cpython/commit/68669ef7883ea6338ca441e50f4f9d975f54d017


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

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

From report at bugs.python.org  Wed Dec  4 11:51:47 2019
From: report at bugs.python.org (Brock Mendel)
Date: Wed, 04 Dec 2019 16:51:47 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
Message-ID: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>


New submission from Brock Mendel <jbrockmendel at gmail.com>:

xref https://github.com/pandas-dev/pandas/pull/30034

codecs.open does `file = open(...)` before validating the encoding kwarg, leaving the open file behind if that validation raises.

----------
messages: 357811
nosy: Brock Mendel
priority: normal
severity: normal
status: open
title: codecs.open leaks file descriptor when invalid encoding is passed

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

From report at bugs.python.org  Wed Dec  4 11:54:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 16:54:51 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575478491.5.0.676224724965.issue38971@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/issue38971>
_______________________________________

From report at bugs.python.org  Wed Dec  4 12:01:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 17:01:30 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575478890.17.0.0194495902242.issue38971@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Does using with block similar to https://bugs.python.org/issue22831 solve this problem?

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

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

From report at bugs.python.org  Wed Dec  4 12:08:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 17:08:27 +0000
Subject: [issue38634] Symbol resolution conflict when embeding python in an
 application using libedit
In-Reply-To: <1572362225.21.0.644355885677.issue38634@roundup.psfhosted.org>
Message-ID: <1575479307.26.0.863238315456.issue38634@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks serge-sans-paille for the bug report and the fix!

I backported it to 3.8 since it could be automated, but I don't think that it's worth it to backport it to 3.7:
https://github.com/python/cpython/pull/16986#issuecomment-561711232

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

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

From report at bugs.python.org  Wed Dec  4 12:19:31 2019
From: report at bugs.python.org (Brock Mendel)
Date: Wed, 04 Dec 2019 17:19:31 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575479971.45.0.584118307238.issue38971@roundup.psfhosted.org>


Brock Mendel <jbrockmendel at gmail.com> added the comment:

> Does using with block similar to https://bugs.python.org/issue22831 solve this problem?

The motivating use case uses `with codecs.open(buf, "w", encoding=encoding) as f:`

https://github.com/pandas-dev/pandas/blob/master/pandas/io/formats/format.py#L498

----------

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

From report at bugs.python.org  Wed Dec  4 13:01:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 04 Dec 2019 18:01:56 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575482516.25.0.258077466769.issue38971@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ah okay, thanks for the detail. Forgot there should be an open file handle to be returned by codecs.open

----------

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

From report at bugs.python.org  Wed Dec  4 13:24:06 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Dec 2019 18:24:06 +0000
Subject: [issue38972] Link to instructions to change PowerShell execution
 policy for venv activation
Message-ID: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

It would probably be good to add a note in the venv docs about execution policies, why it needs to change for environment activation, and how to do it -- especially now that we sign Activate.ps1 -- so there's less of a chance of people being caught off-guard.

----------
assignee: brett.cannon
components: Documentation
messages: 357816
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Link to instructions to change PowerShell execution policy for venv activation
type: enhancement

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

From report at bugs.python.org  Wed Dec  4 13:29:50 2019
From: report at bugs.python.org (Derek Frombach)
Date: Wed, 04 Dec 2019 18:29:50 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
Message-ID: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>


New submission from Derek Frombach <neoredstone at gmail.com>:

When accessing Shared Memory Lists, occasionally the shared memory list will have a length of zero for only one line of code.

Even know the length of the list is constant and greater than zero, when accessing this list, like say sml[0], python returns a ValueError complaining that sml is an empty list.

As well, if you print out sml on the very next line in the exception handler, then you get a full length list, with no access issues whatsoever.

This isn't a locking issue, since locks were acquired before writing to the lists, and released after writing.  This is a shared memory list runtime access consistency issue.

An Example of this Issue can be Seen Here:
https://github.com/uofrobotics/RPLidarVidStream

The issue is in the process_data function, only when smd, sma, smq, or sml are read from.

----------
components: Extension Modules, IO, Interpreter Core, asyncio, ctypes
files: 20191203_194951.jpg
messages: 357817
nosy: Derek Frombach, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Shared Memory List Returns 0 Length
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48757/20191203_194951.jpg

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

From report at bugs.python.org  Wed Dec  4 14:34:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2019 19:34:41 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575488081.46.0.881097300111.issue38971@roundup.psfhosted.org>


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

Add

    try:
        ...
    except:
        file.close()
        raise

----------
components: +IO, Library (Lib)
keywords: +easy
stage:  -> needs patch
type:  -> resource usage
versions: +Python 2.7, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  4 14:44:42 2019
From: report at bugs.python.org (Daniel Preston)
Date: Wed, 04 Dec 2019 19:44:42 +0000
Subject: [issue38974] using filedialog.askopenfilename() freezes python 3.8
Message-ID: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>


New submission from Daniel Preston <danpreston24 at gmail.com>:

I am using Tkinter in my program, and at a point I use a button to open a file by running a function with the following code:
def UploadAction(event=None):
     global filename
     filename = filedialog.askopenfilename()
     filename = [filename]
return filename
However, when I run this function, it causes Python to freeze. Apparently there have been bugs like this before in previous versions, and this wasn't a problem on 3.7, which makes me suspect that this is a bug rather than a fault on my end. Would you be able to release an update to fix this bug? Thanks.

----------
components: Windows
messages: 357819
nosy: Daniel Preston, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: using filedialog.askopenfilename() freezes python 3.8
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  4 14:53:39 2019
From: report at bugs.python.org (Paul Moore)
Date: Wed, 04 Dec 2019 19:53:39 +0000
Subject: [issue38974] using filedialog.askopenfilename() freezes python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575489219.08.0.592517480646.issue38974@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Can you provide a minimal, self-contained, example of a program that demonstrates this behaviour in 3.8, but works in 3.7. It's not really possible to determine what the issue might be without a means of reproducing the problem.

----------
components: +Tkinter -Windows

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

From report at bugs.python.org  Wed Dec  4 14:55:23 2019
From: report at bugs.python.org (Paul Moore)
Date: Wed, 04 Dec 2019 19:55:23 +0000
Subject: [issue38974] using filedialog.askopenfilename() freezes python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575489323.89.0.80454872136.issue38974@roundup.psfhosted.org>


Change by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +gpolo, serhiy.storchaka

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

From report at bugs.python.org  Wed Dec  4 15:05:26 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 Dec 2019 20:05:26 +0000
Subject: [issue38964] Output of syntax error in f-string contains wrong
 filename
In-Reply-To: <1575448073.72.0.500810200955.issue38964@roundup.psfhosted.org>
Message-ID: <1575489926.02.0.265194876806.issue38964@roundup.psfhosted.org>


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

Yes, moving f-strings to the grammar would be a huge change, and not just for CPython.

I discussed it at the last PyCon with the authors of various editors (for syntax highlighting) and other tools that parse python code. No one was hugely opposed to it, and I think even one person was very excited about it. But it's not a step to be taken lightly. I don't think I've discussed it with any other Python implementors outside of CPython.

My biggest concern is that it makes naive string recognition fail. For example, this would become a valid f-string:
f'{fn('some string')}'
while
'{fn('some string')}'
is not a valid string.

I now I think I've completely derailed this bug report. I think the action item here is for me to finish up my better error reporting.

----------

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

From report at bugs.python.org  Wed Dec  4 15:05:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 20:05:28 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575489928.76.0.532860817586.issue38965@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16946
pull_request: https://github.com/python/cpython/pull/17467

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

From report at bugs.python.org  Wed Dec  4 15:07:24 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 04 Dec 2019 20:07:24 +0000
Subject: [issue38974] using filedialog.askopenfilename() freezes python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575490044.99.0.437691887498.issue38974@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've just tried it on Windows 10 with Python 3.8 64-bit and Python 3.8 32-bit without issue.

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Wed Dec  4 15:09:56 2019
From: report at bugs.python.org (Daniel Preston)
Date: Wed, 04 Dec 2019 20:09:56 +0000
Subject: [issue38974] using filedialog.askopenfilename() freezes python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575490196.59.0.448798937237.issue38974@roundup.psfhosted.org>


Daniel Preston <danpreston24 at gmail.com> added the comment:

Just tried to do that and found out that IDLE also crashes when opening a new python file, not just when using that code. Maybe it's a problem just with my computer? I am running python on Windows with an AMD Ryzen 5 processor with 8GB RAM if it helps.

----------
nosy:  -mrabarnett

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

From report at bugs.python.org  Wed Dec  4 15:10:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 20:10:27 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575490227.31.0.670246712032.issue38965@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8b787964e0a647caa0558b7c29ae501470d727d9 by Victor Stinner in branch 'master':
bpo-38965: Fix faulthandler._stack_overflow() on GCC 10 (GH-17467)
https://github.com/python/cpython/commit/8b787964e0a647caa0558b7c29ae501470d727d9


----------
message_count: 1.0 -> 2.0
pull_requests: +16947
pull_request: https://github.com/python/cpython/pull/17468

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

From report at bugs.python.org  Wed Dec  4 15:10:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 20:10:27 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575490227.31.0.670246712032.issue38965@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8b787964e0a647caa0558b7c29ae501470d727d9 by Victor Stinner in branch 'master':
bpo-38965: Fix faulthandler._stack_overflow() on GCC 10 (GH-17467)
https://github.com/python/cpython/commit/8b787964e0a647caa0558b7c29ae501470d727d9


----------

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

From report at bugs.python.org  Wed Dec  4 15:11:08 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Dec 2019 20:11:08 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575490268.85.0.659241718373.issue38974@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: using filedialog.askopenfilename() freezes python 3.8 -> using tkinter.filedialog.askopenfilename() freezes python 3.8

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

From report at bugs.python.org  Wed Dec  4 15:11:42 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Dec 2019 20:11:42 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1575490302.3.0.0524885811662.issue38878@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Wed Dec  4 15:11:54 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 20:11:54 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575490314.15.0.812211038679.issue38965@roundup.psfhosted.org>


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


----------
pull_requests: +16948
pull_request: https://github.com/python/cpython/pull/17469

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

From report at bugs.python.org  Wed Dec  4 15:14:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 20:14:09 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575490449.53.0.279793935424.issue38965@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Martin Li?ka for the bug report and your PR 17462!

I chose to use volatile instead, since it's already the second time that we have to fix this function for a specific compiler. You abandonned your PR and confrmed that my PR fix your issue with GCC 10, so I merged my PR. Thanks for testing ;-)

I backported the fix to 3.7 and 3.8 branches.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  4 15:14:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2019 20:14:43 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575490483.88.0.892266796532.issue38965@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The cool thing is that GCC now also implements tail call optimization!

----------

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

From report at bugs.python.org  Wed Dec  4 15:29:30 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 20:29:30 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575491370.29.0.426057801264.issue38965@roundup.psfhosted.org>


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


New changeset 5044c889dfced2f43e2cccb673d889a4882f6b3b by Miss Islington (bot) in branch '3.7':
bpo-38965: Fix faulthandler._stack_overflow() on GCC 10 (GH-17467)
https://github.com/python/cpython/commit/5044c889dfced2f43e2cccb673d889a4882f6b3b


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

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

From report at bugs.python.org  Wed Dec  4 15:30:36 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 04 Dec 2019 20:30:36 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575491435.99.0.59785797508.issue38965@roundup.psfhosted.org>


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


New changeset f4a21d3b239bf4f4e4e2a8a5936b9b040645b246 by Miss Islington (bot) in branch '3.8':
bpo-38965: Fix faulthandler._stack_overflow() on GCC 10 (GH-17467)
https://github.com/python/cpython/commit/f4a21d3b239bf4f4e4e2a8a5936b9b040645b246


----------

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

From report at bugs.python.org  Wed Dec  4 16:05:58 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2019 21:05:58 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575493558.02.0.855878100395.issue38974@roundup.psfhosted.org>


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

What is your OS? Is it macOS specific issue?

----------

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

From report at bugs.python.org  Wed Dec  4 16:10:39 2019
From: report at bugs.python.org (Daniel Preston)
Date: Wed, 04 Dec 2019 21:10:39 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575493839.8.0.0943179163376.issue38974@roundup.psfhosted.org>


Daniel Preston <danpreston24 at gmail.com> added the comment:

No, it is an issue with Windows. I think it might only be a problem with my computer though, maybe the fact that I have an AMD processor might have something to do with the problem?

----------

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

From report at bugs.python.org  Wed Dec  4 16:12:31 2019
From: report at bugs.python.org (Baptiste Mispelon)
Date: Wed, 04 Dec 2019 21:12:31 +0000
Subject: [issue38975] Add direct anchors to regex syntax documentation
Message-ID: <1575493951.25.0.258282311971.issue38975@roundup.psfhosted.org>


New submission from Baptiste Mispelon <bmispelon at gmail.com>:

While writing documentation about regexps for a project I help maintain, I wanted to link to some specific aspects of Python's implementation (in my case, non-capturing groups) which are described on https://docs.python.org/3/library/re.html.

There are no visible ? anchors for the items in the "Regular Expression Syntax" section. Inspecting the generated HTML, there does seem to be auto-generated ids (like `#index-16` for example) but I wouldn't like to rely on those as I'm not sure how stable they are.

I couldn't find how to add the ? symbol show up next to the titles but I have a PR that adds a bunch of references so that items can be linked directly.

----------
assignee: docs at python
components: Documentation
messages: 357831
nosy: bmispelon, docs at python
priority: normal
severity: normal
status: open
title: Add direct anchors to regex syntax documentation
type: enhancement

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

From report at bugs.python.org  Wed Dec  4 16:13:10 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 04 Dec 2019 21:13:10 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575493990.61.0.277417597728.issue38974@roundup.psfhosted.org>


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

Processor type is far less likely than a shell extension.

Do you have anything like DropBox/Tortoise???/etc. installed?

----------

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

From report at bugs.python.org  Wed Dec  4 16:13:16 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2019 21:13:16 +0000
Subject: [issue38975] Add direct anchors to regex syntax documentation
In-Reply-To: <1575493951.25.0.258282311971.issue38975@roundup.psfhosted.org>
Message-ID: <1575493996.94.0.736734044812.issue38975@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16949
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17470

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

From report at bugs.python.org  Wed Dec  4 16:55:09 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 04 Dec 2019 21:55:09 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1575496509.05.0.194399701296.issue38973@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

As I see, the problem is not related to asyncio at all.

----------
components:  -asyncio

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

From report at bugs.python.org  Wed Dec  4 17:35:40 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 04 Dec 2019 22:35:40 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575498940.91.0.564622764693.issue38971@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Any reason not to just defer opening the file until after the codec has been validated, so the resource acquisition comes last?

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

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

From report at bugs.python.org  Wed Dec  4 18:00:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 Dec 2019 23:00:20 +0000
Subject: [issue38972] Link to instructions to change PowerShell execution
 policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1575500420.23.0.893908152025.issue38972@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

And where this has come up as an issue: https://github.com/microsoft/vscode-python/issues/2559.

----------

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

From report at bugs.python.org  Wed Dec  4 22:14:33 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 05 Dec 2019 03:14:33 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575515673.38.0.254874276277.issue38698@roundup.psfhosted.org>


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


New changeset bb815499af855b1759c02535f8d7a9d0358e74e8 by Miss Islington (bot) (Claudiu Popa) in branch 'master':
bpo-38698: Prevent UnboundLocalError to pop up in parse_message_id (GH-17277)
https://github.com/python/cpython/commit/bb815499af855b1759c02535f8d7a9d0358e74e8


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

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

From report at bugs.python.org  Thu Dec  5 00:13:43 2019
From: report at bugs.python.org (Jacob Taylor)
Date: Thu, 05 Dec 2019 05:13:43 +0000
Subject: [issue38976] Add support for HTTP Only flag in MozillaCookieJar
Message-ID: <1575522823.75.0.720870581486.issue38976@roundup.psfhosted.org>


New submission from Jacob Taylor <me at jacobtaylor.id.au>:

This PR adds support for the HttpOnly flag as encoded in CURL cookiejars.

This PR was mainly designed to allow the MozillaCookieJar to parse in the cookies, as previously they were considered comments and ignored. 

As HttpOnly is considered a non-standard attribute, the nonstandard attribute dict was considered the most appropriate place to persist this information.

----------
components: Library (Lib)
messages: 357837
nosy: Jacob Taylor
priority: normal
severity: normal
status: open
title: Add support for HTTP Only flag in MozillaCookieJar
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  5 00:14:26 2019
From: report at bugs.python.org (Jacob Taylor)
Date: Thu, 05 Dec 2019 05:14:26 +0000
Subject: [issue38976] Add support for HTTP Only flag in MozillaCookieJar
In-Reply-To: <1575522823.75.0.720870581486.issue38976@roundup.psfhosted.org>
Message-ID: <1575522866.34.0.418551568091.issue38976@roundup.psfhosted.org>


Change by Jacob Taylor <me at jacobtaylor.id.au>:


----------
keywords: +patch
pull_requests: +16951
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17471

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

From report at bugs.python.org  Thu Dec  5 00:26:50 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2019 05:26:50 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1575523610.78.0.402137429152.issue38971@roundup.psfhosted.org>


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

Many reasons.

1. It is simpler.
2. We will need a try/except in any case to prevent a leak if an exception be raised by other code following open().
3. It matches the behavior of io.open().

----------

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

From report at bugs.python.org  Thu Dec  5 01:00:18 2019
From: report at bugs.python.org (Greg)
Date: Thu, 05 Dec 2019 06:00:18 +0000
Subject: [issue29298] argparse fails with required subparsers, un-named dest, 
 and empty argv
In-Reply-To: <1484664769.91.0.625725054847.issue29298@psf.upfronthosting.co.za>
Message-ID: <1575525618.39.0.236559969674.issue29298@roundup.psfhosted.org>


Greg <minshall at acm.org> added the comment:

while waiting for a fix, would it be possible to document in the argparse documentation that the 'dest' parameter is required (at least temporarily) for add_subparsers()?  (somewhere near file:///usr/share/doc/python/html/library/argparse.html#sub-commands)

gratuitous diff:  the pull request from 2017 would probably fix it.  my diffs are here (from: Python 3.8.0 (default, Oct 23 2019, 18:51:26).  (the pull request changes the utility '_get_action_name'; i wasn't sure of side-effects with other callers, so changed nearer the failure location.)
----
*** new/argparse.py     2019-12-05 11:16:37.618985247 +0530
--- old/argparse.py     2019-10-24 00:21:26.000000000 +0530
***************
*** 2017,2030 ****
          for action in self._actions:
              if action not in seen_actions:
                  if action.required:
!                     ra = _get_action_name(action)
!                     if ra is None:
!                         if not action.choices == {}:
!                             choice_strs = [str(choice) for choice in action.choices]
!                             ra = '{%s}' % ','.join(choice_strs)
!                         else:
!                             ra = '<unknown>'
!                     required_actions.append(ra)
                  else:
                      # Convert action default now instead of doing it before
                      # parsing arguments to avoid calling convert functions
--- 2017,2023 ----
          for action in self._actions:
              if action not in seen_actions:
                  if action.required:
!                     required_actions.append(_get_action_name(action))
                  else:
                      # Convert action default now instead of doing it before
                      # parsing arguments to avoid calling convert functions

----------
nosy: +Minshall

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

From report at bugs.python.org  Thu Dec  5 03:04:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 05 Dec 2019 08:04:29 +0000
Subject: [issue38970] [PDB] NameError in list comprehension in PDB
In-Reply-To: <1575472624.05.0.465658492617.issue38970@roundup.psfhosted.org>
Message-ID: <1575533069.64.0.981657605357.issue38970@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this is same as https://bugs.python.org/issue26072#msg277578 and is reproducible with below sample script without depending on turbogears. The attached patch in the issue fixes this. Try using interact command from pdb as a workaround.

import pdb

def foo():
  pdb.set_trace()

foo()

----------
nosy: +xdegaye, xtreak

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

From report at bugs.python.org  Thu Dec  5 03:11:04 2019
From: report at bugs.python.org (wim glenn)
Date: Thu, 05 Dec 2019 08:11:04 +0000
Subject: [issue27413] Add an option to json.tool to bypass non-ASCII
 characters.
In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za>
Message-ID: <1575533464.9.0.690437383451.issue27413@roundup.psfhosted.org>


Change by wim glenn <wim.glenn at gmail.com>:


----------
pull_requests: +16953
pull_request: https://github.com/python/cpython/pull/17472

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

From report at bugs.python.org  Thu Dec  5 03:33:17 2019
From: report at bugs.python.org (Daniel Preston)
Date: Thu, 05 Dec 2019 08:33:17 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575534797.7.0.360161633514.issue38974@roundup.psfhosted.org>


Daniel Preston <danpreston24 at gmail.com> added the comment:

I have dropbox installed, would that be what's causing the problem?

----------

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

From report at bugs.python.org  Thu Dec  5 05:15:30 2019
From: report at bugs.python.org (Simon.yu)
Date: Thu, 05 Dec 2019 10:15:30 +0000
Subject: [issue38977] python3.8 and namedlist1.7 is Incompatible
Message-ID: <1575540930.03.0.27673784229.issue38977@roundup.psfhosted.org>


New submission from Simon.yu <ling.yu at outlook.com>:

When I use pytest based on python3.8, met a problem,it seems namedlist1.7 is incompatible!!

see blow logs:
----------------------
  File "C:\Program Files\Python38\lib\site-packages\namedlist.py", line 180, in _make_fn
    code = compile(module_node, '<string>', 'exec')
TypeError: required field "posonlyargs" missing from arguments
----------------------

----------
components: Library (Lib)
messages: 357842
nosy: ling.yu at outlook.com
priority: normal
severity: normal
status: open
title: python3.8 and namedlist1.7 is Incompatible
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Dec  5 05:22:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 05 Dec 2019 10:22:56 +0000
Subject: [issue38977] python3.8 and namedlist1.7 is Incompatible
In-Reply-To: <1575540930.03.0.27673784229.issue38977@roundup.psfhosted.org>
Message-ID: <1575541376.59.0.670965867505.issue38977@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This issue tracker is for issues related to CPython. Please report this to the respective issue tracker at https://bitbucket.org/ericvsmith/namedlist/issues. The error message looks related to handling positional only arguments that needs to be fixed in the library during ast construction at probably  https://bitbucket.org/ericvsmith/namedlist/src/8db03a94fcc15184ccdf7a58f91c48bc5bcd3331/namedlist.py#lines-159. I think this can be closed as third party.

----------
nosy: +eric.smith, xtreak

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

From report at bugs.python.org  Thu Dec  5 05:38:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 05 Dec 2019 10:38:57 +0000
Subject: [issue38977] python3.8 and namedlist1.7 is Incompatible
In-Reply-To: <1575540930.03.0.27673784229.issue38977@roundup.psfhosted.org>
Message-ID: <1575542337.52.0.409659964957.issue38977@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

>From Python 3.8, type_ignores is also mandatory for ast.Module as discussed in issue35894 which also needs to be fixed in the module. Closing this as third party as I don't see any apparent regression here in 3.8.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Dec  5 06:21:41 2019
From: report at bugs.python.org (daniel hahler)
Date: Thu, 05 Dec 2019 11:21:41 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1575544901.4.0.46373442549.issue24565@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

This is likely covered by existing/linked issues already, but wanted to leave it here nonetheless:

Given t-pdb.py:
```
import sys


def main():
    sys.stdout.write("main...\n")
    assert 0


if __name__ == "__main__":
    main()
```

Without the fix from the PR:
```
% python3.8 -m pdb -c cont t-pdb.py
main...
Traceback (most recent call last):
  File "?/pyenv/3.8.0/lib/python3.8/pdb.py", line 1702, in main
    pdb._runscript(mainpyfile)
  File "?/pyenv/3.8.0/lib/python3.8/pdb.py", line 1571, in _runscript
    self.run(statement)
  File "?/pyenv/3.8.0/lib/python3.8/bdb.py", line 587, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "?/Vcs/cpython/t-pdb.py", line 1, in <module>
    import sys
  File "?/Vcs/cpython/t-pdb.py", line 6, in main
    assert 0
AssertionError
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> ?/Vcs/cpython/t-pdb.py(6)main()
-> assert 0
(Pdb)
```

With the fix:
```
% /tmp/cpython-bisect/bin/python3.8 -m pdb -c cont t-pdb.py
main...
Traceback (most recent call last):
  File "/tmp/cpython-bisect/lib/python3.8/pdb.py", line 1703, in main
    pdb._runscript(mainpyfile)
  File "/tmp/cpython-bisect/lib/python3.8/pdb.py", line 1572, in _runscript
    self.run(statement)
  File "/tmp/cpython-bisect/lib/python3.8/bdb.py", line 583, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "?/Vcs/cpython/t-pdb.py", line 10, in <module>
    main()
  File "?/Vcs/cpython/t-pdb.py", line 6, in main
    assert 0
AssertionError
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> ?/Vcs/cpython/t-pdb.py(6)main()
-> assert 0
(Pdb)
```

As you can see the traceback in the fixed case contains `main()` correctly,
while it has `import sys` (the scripts first line) otherwise.

I can only repeat myself to ask for reviewing/merging https://github.com/python/cpython/pull/12419.

----------
nosy: +blueyed

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

From report at bugs.python.org  Thu Dec  5 07:36:19 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 05 Dec 2019 12:36:19 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1575549379.39.0.889125970043.issue38439@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

At https://mgabrail.wordpress.com/2011/08/19/5-reasons-why-you-should-learn-python-programming/ I have found https://mgabrail.files.wordpress.com/2011/08/python.png - I have no idea what is the license of this file or where it originated from, but this looks fairly like the icon in question.

Google images reveal more liek it, usually resized or jpeged.

----------
Added file: https://bugs.python.org/file48758/python.png

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

From report at bugs.python.org  Thu Dec  5 07:40:39 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 05 Dec 2019 12:40:39 +0000
Subject: [issue38951] Use threading.main_thread() check in asyncio
In-Reply-To: <1575225525.0.0.724928399081.issue38951@roundup.psfhosted.org>
Message-ID: <1575549639.9.0.545572487984.issue38951@roundup.psfhosted.org>


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


New changeset 99eb70a9eb9493602ff6ad8bb92df4318cf05a3e by Miss Islington (bot) (Hill Ma) in branch 'master':
bpo-38951: Use threading.main_thread() check in asyncio (GH-17433)
https://github.com/python/cpython/commit/99eb70a9eb9493602ff6ad8bb92df4318cf05a3e


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

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

From report at bugs.python.org  Thu Dec  5 07:41:12 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 12:41:12 +0000
Subject: [issue38951] Use threading.main_thread() check in asyncio
In-Reply-To: <1575225525.0.0.724928399081.issue38951@roundup.psfhosted.org>
Message-ID: <1575549672.26.0.305615072606.issue38951@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Dec  5 07:43:27 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 12:43:27 +0000
Subject: [issue38846] async: Return context manager from open(_unix)_connection
In-Reply-To: <1574164468.11.0.934598090921.issue38846@roundup.psfhosted.org>
Message-ID: <1575549807.54.0.955046003684.issue38846@roundup.psfhosted.org>


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


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Dec  5 07:53:23 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 12:53:23 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
Message-ID: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>


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

Typeshed declares asyncio.Future, asyncio.Task and asyncio.Queue as generic types, which is 100% correct.

The problem is that these classes don't support generic instantiation in runtime, e.g. Future[str] raises TypeError.

The feature should be implemented by adding __class_getitem__ methods which return self.

The patch is trivial but requires a few lines of C code for C Accelerated CTask and CFuture as well as updating Python code.

A volunteer is welcome!

----------
components: asyncio
keywords: easy, easy (C)
messages: 357848
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement __class_getitem__ for Future, Task, Queue
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  5 07:58:04 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 05 Dec 2019 12:58:04 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1575550684.03.0.354389165191.issue38439@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

https://bugs.python.org/issue1490384
https://www.doxdesk.com/software/py/pyicons.html

----------

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

From report at bugs.python.org  Thu Dec  5 08:04:19 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 13:04:19 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
Message-ID: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>


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

The issue is minor, I suspect nobody wants to derive from ContextVar class.

The generic implementation for __class_getitem__ is returning unmodified self argument. Yuri, is there a reason to behave differently in the case of ContextVar?

If no, we can mark the issue as easy(C) and wait for a volunteer, the fix seems trivial.

----------
components: Extension Modules
messages: 357850
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: ContextVar[str] should return ContextVar class, not None
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec  5 08:04:29 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 13:04:29 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575551069.03.0.298368130842.issue38979@roundup.psfhosted.org>


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


----------
type:  -> behavior

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

From report at bugs.python.org  Thu Dec  5 08:22:07 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 05 Dec 2019 13:22:07 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1575552127.14.0.768769124096.issue38439@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
keywords: +patch
pull_requests: +16954
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17473

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

From report at bugs.python.org  Thu Dec  5 08:22:07 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 05 Dec 2019 13:22:07 +0000
Subject: [issue1490384] PC new-logo-based icon set
Message-ID: <1575552127.35.0.855473920859.issue1490384@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
pull_requests: +16955
pull_request: https://github.com/python/cpython/pull/17473

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

From report at bugs.python.org  Thu Dec  5 08:39:03 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 05 Dec 2019 13:39:03 +0000
Subject: [issue36383] Virtual environment sysconfig.get_path() and
 distutils.sysconfig.get_python_inc() reports base Python include directory
In-Reply-To: <1553100828.16.0.35045767323.issue36383@roundup.psfhosted.org>
Message-ID: <1575553143.38.0.0516388322232.issue36383@roundup.psfhosted.org>


Tzu-ping Chung <uranusjr at gmail.com> added the comment:

I can replicate this on Linux as well. Furthormore, sysconfig.get_path('include') also returns the global path.

----------
components: +Library (Lib)
nosy: +uranusjr
title: In Windows 10 virtual environments distutils.sysconfig.get_python_inc() reports base Python include directory -> Virtual environment sysconfig.get_path() and distutils.sysconfig.get_python_inc() reports base Python include directory

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

From report at bugs.python.org  Thu Dec  5 08:45:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 13:45:10 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1575553510.48.0.936773985963.issue38439@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh ok, I confirm that https://github.com/python/cpython/pull/17473 is an icon drew by Andrew Clover.

https://www.doxdesk.com/file/software/py/v/pyicons-full-0.4.zip from https://www.doxdesk.com/software/py/pyicons.html contains py0032.png which is the same picture (same pixels), but the MD5 is different because metadata are different.

That's the website of Andrew Clover: https://www.doxdesk.com/personal/

----------
nosy: +vstinner

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

From report at bugs.python.org  Thu Dec  5 09:14:49 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 14:14:49 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1575555289.4.0.538771885136.issue38529@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16956
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17474

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

From report at bugs.python.org  Thu Dec  5 09:29:24 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2019 14:29:24 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575556164.71.0.533741824158.issue38978@roundup.psfhosted.org>


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


----------
nosy: +gvanrossum, levkivskyi

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

From report at bugs.python.org  Thu Dec  5 09:32:29 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 14:32:29 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1575556349.1.0.673819460467.issue38529@roundup.psfhosted.org>


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


----------
versions: +Python 3.9

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

From report at bugs.python.org  Thu Dec  5 09:55:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 14:55:43 +0000
Subject: [issue27961] remove support for platforms without "long long"
In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za>
Message-ID: <1575557743.37.0.0419356764936.issue27961@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1f9f69dd4c5ee232c0b2f782933a89359932a67f by Victor Stinner (Sergey Fedoseev) in branch 'master':
bpo-27961: Replace PY_LLONG_MAX, PY_LLONG_MIN and PY_ULLONG_MAX with standard macros (GH-15385)
https://github.com/python/cpython/commit/1f9f69dd4c5ee232c0b2f782933a89359932a67f


----------

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

From report at bugs.python.org  Thu Dec  5 09:55:53 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2019 14:55:53 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575557753.21.0.134038671836.issue38978@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

In principle I think this is a good idea.

If this was user code, we would inherit from typing.Generic. I understand you wanting to avoid the overhead of that. But will it work correctly at runtime with other typing constructors? I guess __annotations__ will not show the generic type's parameter. Will anybody care?

Maybe we need to walk through some detailed examples.

----------

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

From report at bugs.python.org  Thu Dec  5 10:44:44 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 05 Dec 2019 15:44:44 +0000
Subject: [issue36077] Inheritance dataclasses fields and default init statement
In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org>
Message-ID: <1575560684.84.0.975321811892.issue36077@roundup.psfhosted.org>


Martijn Pieters <mj at python.org> added the comment:

I've supported people hitting this issue before (see https://stackoverflow.com/a/53085935/100297, where I used a series of mixin classes to make use of the changing MRO when the mixins share base classes, to enforce a field order from inherited classes.

I'd be very much in favour of dataclasses using the attrs approach to field order: any field named in a base class *moves to the end*, so you can 'insert' your own fields by repeating parent fields that need to come later:

@attr.s(auto_attribs=True)
class Parent:
    foo: str
    bar: int
    baz: bool = False


@attr.s(auto_attribs=True)
class Child(Parent):
    spam: str
    baz: bool = False


The above gives you a `Child(foo: str, bar: int, spam: str, baz: bool = False)` object, note that `baz` moved to the end of the arguments.

`dataclasses` currently doesn't do this, so it'd be a breaking change.

----------
nosy: +mjpieters

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

From report at bugs.python.org  Thu Dec  5 11:00:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 16:00:31 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
Message-ID: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The Fedora packaging has been modified to compile libpython with -fno-semantic-interposition flag: it makes Python up to 1.3x faster without having to touch any line of the C code! See pyperformance results:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup#Benefit_to_Fedora

The main drawback is that -fno-semantic-interposition prevents to override Python symbols using a custom library preloaded by LD_PRELOAD. For example, override PyErr_Occurred() function.

We (authors of the Fedora change) failed to find any use case for LD_PRELOAD.

To be honest, I found *one* user in the last 10 years who used LD_PRELOAD to track memory allocations in Python 2.7. This use case is no longer relevant in Python 3 with PEP 445 which provides a supported C API to override Python memory allocators or to install hooks on Python memory allocators. Moreover, tracemalloc is a nice way to track memory allocations.

Is there anyone aware of any special use of LD_PRELOAD for libpython?

To be clear: -fno-semantic-interposition only impacts libpython. All other libraries still respect LD_PRELOAD. For example, it is still possible to override glibc malloc/free.

Why -fno-semantic-interposition makes Python faster? There are multiple reasons. For of all, libpython makes a lot of function calls to libpython. Like really a lot, especially in the hot code paths. Without -fno-semantic-interposition, function calls to libpython requires to get through "interposition": for example "Procedure Linkage Table" (PLT) indirection on Linux. It prevents function inlining which has a major impact on performance (missed optimization). In short, even with PGO and LTO, libpython function calls have two performance "penalities":

* indirect function calls (PLT)
* no inlining

I'm comparing Python performance of "statically linked Python" (Debian/Ubuntu choice: don't use ./configure --enable-shared, python is not linked to libpython) to "dynamically linked Python" (Fedora choice: use "./configure --enable-shared", python is dynamically linked to libpython).

With -fno-semantic-interposition, function calls are direct and can be inlined when appropriate. You don't have to trust me, look at pyperformance benchmark results ;-)

When using ./configure --enable-shared (libpython), the "python" binary is exactly one function call and that's all:

int main(int argc, char **argv)
{ return Py_BytesMain(argc, argv); }

So 100% of the time is only spent in libpython.

For a longer rationale, see the accepted Fedora change:
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup

----------
components: Build
messages: 357856
nosy: inada.naoki, pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Compile libpython with -fno-semantic-interposition
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  5 11:01:20 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 05 Dec 2019 16:01:20 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575561680.53.0.527773228466.issue38978@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I thought __class_getitem__ was invented exactly to simplify generic types support.

The only thing that confuses me an example from PEP 560:

class MyList:
    def __getitem__(self, index):
        return index + 1
    def __class_getitem__(cls, item):
        return f"{cls.__name__}[{item.__name__}]"

It prevents from instantiating a generic on inheritance, e.g. the following code raises TypeError:

class MyOtherList(MyList[int]):
    pass

It would be nice if Ivan clarifies what is the best practice in this case.
I think the method should return unmodified class, not a string.

----------

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

From report at bugs.python.org  Thu Dec  5 11:02:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 16:02:37 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575561757.82.0.311358305192.issue38980@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Maybe we need to offer a way to *opt out* from -fno-semantic-interposition. For example, ./configure --with-interposition. The default would be --without-interposition.

----------

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

From report at bugs.python.org  Thu Dec  5 11:02:56 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 05 Dec 2019 16:02:56 +0000
Subject: [issue37096] Add large-file tests for modules using sendfile(2)
In-Reply-To: <1559200699.13.0.758657145229.issue37096@roundup.psfhosted.org>
Message-ID: <1575561776.11.0.168462502231.issue37096@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

It seems that the test actually requires >4GB disk space, because it's copying a 2GB file from one place to another.

Also, it's using a temporary directory. On Fedora /tmp is memory-backed by default, it doesn't use regular disk space.

----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Thu Dec  5 11:06:11 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Thu, 05 Dec 2019 16:06:11 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575561971.75.0.990507299479.issue38980@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy: +hroncok

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

From report at bugs.python.org  Thu Dec  5 11:13:47 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 05 Dec 2019 16:13:47 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575562427.7.0.141692826647.issue38980@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have seen people using LD_PRELOAD to interpose some auditing functions that can modify the actual call into libpython, or to interpose faster versions of some functions or to collect metrics (although there are better ways).

If we do this by default, once functions will be inlined these use cases will be broken.

----------

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

From report at bugs.python.org  Thu Dec  5 11:17:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 16:17:59 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575562679.66.0.196946415346.issue38980@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> If we do this by default, once functions will be inlined these use cases will be broken.

Could these user use a "./configure --with-interposition --enable-shared" build?

----------

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

From report at bugs.python.org  Thu Dec  5 11:21:59 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 05 Dec 2019 16:21:59 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575562919.16.0.856300121544.issue38980@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Could these user use a "./configure --with-interposition --enable-shared" build?

Sure, but the problem is the default value, no?

Maybe it should only be default when using --with-optimizations

----------

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

From report at bugs.python.org  Thu Dec  5 11:26:30 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 05 Dec 2019 16:26:30 +0000
Subject: [issue37096] Add large-file tests for modules using sendfile(2)
In-Reply-To: <1559200699.13.0.758657145229.issue37096@roundup.psfhosted.org>
Message-ID: <1575563190.56.0.657604690291.issue37096@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The test passes with a 8GB /tmp, but not a 6GB one.

That could suggest the test needs 3*2GB disk space for temporary files, plus something extra.

----------

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

From report at bugs.python.org  Thu Dec  5 11:34:22 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2019 16:34:22 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575561680.53.0.527773228466.issue38978@roundup.psfhosted.org>
Message-ID: <CAP7+vJJS42b6jUHMRKMmZAt8g1XHorx1w50TY_5LJRc31Wvn6Q@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Well, __class_getitem__ was added primarily to allow classes implemented in
*C* to support "generics". This is helpful to support PEP 585. For classes
written in Python I don't see the point.

But I'll leave the rest of this to Ivan.

----------

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

From report at bugs.python.org  Thu Dec  5 11:47:36 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 05 Dec 2019 16:47:36 +0000
Subject: [issue38955] Non indemnpotent behavior of asyncio.get_event_loop and
 asyncio.run sequence.
In-Reply-To: <1575311987.47.0.389219942485.issue38955@roundup.psfhosted.org>
Message-ID: <1575564456.92.0.895802292019.issue38955@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

Thanks Andrew; 

I'd still would love to have a way to get the current eventloop outside of async code that is consistent. 

I guess throwing an error with `get_event_loop()` is ok, it's just that `RuntimeError` feel like a weird thing to catch.

Alternatively is the current event loop is None I feel like returning None would also make sens imho. 

Feel free to close if you think this will not get fixed/updated.

----------

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

From report at bugs.python.org  Thu Dec  5 11:51:37 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 05 Dec 2019 16:51:37 +0000
Subject: [issue38270] Tests: Avoid MD5 or check for MD5 availablity
In-Reply-To: <1569406198.76.0.145895264341.issue38270@roundup.psfhosted.org>
Message-ID: <1575564697.35.0.643426624643.issue38270@roundup.psfhosted.org>


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


New changeset cfdaf92221da3c264d0da9c588994fefe4073196 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-38270: Fix indentation of test_hmac assertions (GH-17446) (GH-17450)
https://github.com/python/cpython/commit/cfdaf92221da3c264d0da9c588994fefe4073196


----------

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

From report at bugs.python.org  Thu Dec  5 11:56:07 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 05 Dec 2019 16:56:07 +0000
Subject: [issue38981] better name for re.error Exception class.
Message-ID: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>


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

better error/exception name for re.compile error. 

Currently the error raise by re.compile when it fails to compile is `error` defined in sre_constants.py: 

```
class error(Exception):
    """Exception raised for invalid regular expressions.

```

This is quite disturbing as most exception start with an uppercase and have a tiny bit more descriptive name. 

Would it be possible to have it renamed as something more explicit like `ReCompileError`, and still keeping the potential `error` alias as deprecated ?

----------
components: Regular Expressions
messages: 357867
nosy: ezio.melotti, mbussonn, mrabarnett
priority: normal
severity: normal
status: open
title: better name for re.error Exception class.

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

From report at bugs.python.org  Thu Dec  5 11:58:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Dec 2019 16:58:27 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575565107.14.0.660733766239.issue38974@roundup.psfhosted.org>


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

Potentially. I don't have it installed, so I can't test, but I know in the past it added a shell extension that would display overlays over files it controlled.

That shell extension will be loaded into most system file picker dialogs, and at various points has executed Python code. I doubt they're on 3.8, but it's possible that there is some kind of conflict.

Can you try uninstalling or disabling its shell integration?

----------

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

From report at bugs.python.org  Thu Dec  5 12:09:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 17:09:02 +0000
Subject: [issue38982] test_asyncio:
 SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file
 descriptor
Message-ID: <1575565741.97.0.071963111218.issue38982@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

See on AMD64 Fedora Rawhide Refleaks 3.x:
https://buildbot.python.org/all/#/builders/82/builds/7

I found the leaking test using test.bisect_cmd:

$ ./python -m test test_asyncio -R 3:3 --fail-env-changed -v -m test.test_asyncio.test_subprocess.SubprocessPidfdWatcherTests.test_close_dont_kill_finished
...
test_asyncio leaked [1, 1, 1] file descriptors, sum=3

----------
components: Tests, asyncio
messages: 357869
nosy: asvetlov, pablogsal, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file descriptor
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  5 12:20:13 2019
From: report at bugs.python.org (Daniel Preston)
Date: Thu, 05 Dec 2019 17:20:13 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575566413.45.0.826456167304.issue38974@roundup.psfhosted.org>


Daniel Preston <danpreston24 at gmail.com> added the comment:

How would I do that?

----------

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

From report at bugs.python.org  Thu Dec  5 12:22:46 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 05 Dec 2019 17:22:46 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575566566.75.0.269769712401.issue38698@roundup.psfhosted.org>


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


----------
pull_requests: +16957
pull_request: https://github.com/python/cpython/pull/17476

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

From report at bugs.python.org  Thu Dec  5 12:24:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 17:24:02 +0000
Subject: [issue38982] test_asyncio:
 SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file
 descriptor
In-Reply-To: <1575565741.97.0.071963111218.issue38982@roundup.psfhosted.org>
Message-ID: <1575566642.58.0.359881462807.issue38982@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +16958
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17477

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

From report at bugs.python.org  Thu Dec  5 12:25:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 17:25:08 +0000
Subject: [issue38982] test_asyncio:
 SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file
 descriptor
In-Reply-To: <1575565741.97.0.071963111218.issue38982@roundup.psfhosted.org>
Message-ID: <1575566708.77.0.54164260384.issue38982@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Attached PR 17477 fix the leak.

PidfdChildWatcher was added to asyncio by bpo-38692:

commit 3ccdd9b180f9a3f29c8ddc8ad1b331fe8df26519
Author: Benjamin Peterson <benjamin at python.org>
Date:   Wed Nov 13 19:08:50 2019 -0800

    closes bpo-38692: Add a pidfd child process watcher to asyncio. (GH-17069)

----------

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

From report at bugs.python.org  Thu Dec  5 12:28:41 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Dec 2019 17:28:41 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575566921.94.0.539123333593.issue38974@roundup.psfhosted.org>


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

Temporarily uninstalling your Dropbox client is the easiest way.

----------

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

From report at bugs.python.org  Thu Dec  5 12:29:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 17:29:17 +0000
Subject: [issue38982] test_asyncio:
 SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file
 descriptor
In-Reply-To: <1575565741.97.0.071963111218.issue38982@roundup.psfhosted.org>
Message-ID: <1575566957.3.0.622295950954.issue38982@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The test only fails on the Fedora Rawhide buildbot, likely because other Linux Refleak buildbots are using a kernel or libc without pidfd_open() ;-)

----------

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

From report at bugs.python.org  Thu Dec  5 12:42:08 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 05 Dec 2019 17:42:08 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575567728.61.0.800804059954.issue38698@roundup.psfhosted.org>


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


New changeset e21aa61e96f8343200e765d119ebe778873a6bf1 by Miss Islington (bot) in branch '3.8':
bpo-38698: Prevent UnboundLocalError to pop up in parse_message_id (GH-17277)
https://github.com/python/cpython/commit/e21aa61e96f8343200e765d119ebe778873a6bf1


----------

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

From report at bugs.python.org  Thu Dec  5 13:04:30 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 05 Dec 2019 18:04:30 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575569070.51.0.0257039163178.issue38978@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

I see the point in using ``__class_getitem__`` in Python classes too, we can probably start using a dummy method returning class object itself now. Also PEP 585 already has a long list of candidates for "proper" ``__class_getitem__`` support. Maybe we can add these classes to that list? Maybe it would make sense to also have ``PathLike`` there?

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Thu Dec  5 13:15:25 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 05 Dec 2019 18:15:25 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575569725.27.0.334147838834.issue38978@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I want to be a volunteer, if no one is working on this.

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Thu Dec  5 13:18:11 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 05 Dec 2019 18:18:11 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575569891.83.0.835987095606.issue38979@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The issue is minor, I suspect nobody wants to derive from ContextVar class.

I don't think that's allowed, actually.

> The generic implementation for __class_getitem__ is returning unmodified self argument. Yuri, is there a reason to behave differently in the case of ContextVar?

No, just an oversight, probably.

----------

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

From report at bugs.python.org  Thu Dec  5 13:19:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2019 18:19:20 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575569960.24.0.0232889595319.issue38979@roundup.psfhosted.org>


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


----------
nosy: +gvanrossum, levkivskyi

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

From report at bugs.python.org  Thu Dec  5 13:26:10 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2019 18:26:10 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575570370.24.0.435763118002.issue38981@roundup.psfhosted.org>


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

It is common practice that the module specific exception is called just "error". There is nothing wrong with this.

I do not see a need to introduce a different alias.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Dec  5 13:26:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 18:26:35 +0000
Subject: [issue36732] Windows: test_asyncio: test_huge_content_recvinto()
 fails randomly with ProactorEventLoop
In-Reply-To: <1556264661.54.0.31283754406.issue36732@roundup.psfhosted.org>
Message-ID: <1575570395.14.0.813118568358.issue36732@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New failure on AMD64 Windows7 SP1 3.x:
https://buildbot.python.org/all/#/builders/81/builds/16

ERROR: test_huge_content_recvinto (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests)

also:

ERROR: test_pipe_handle (test.test_asyncio.test_windows_utils.PipeTests)

----------

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

From report at bugs.python.org  Thu Dec  5 13:28:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 18:28:11 +0000
Subject: [issue38887] test_asyncio: test_pipe_handle() failed on AMD64
 Windows7 SP1 3.x
In-Reply-To: <1574371987.32.0.39878951325.issue38887@roundup.psfhosted.org>
Message-ID: <1575570491.06.0.5201578887.issue38887@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New failure on AMD64 Windows7 SP1 3.x:
https://buildbot.python.org/all/#/builders/81/builds/16

ERROR: test_pipe_handle (test.test_asyncio.test_windows_utils.PipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_windows_utils.py", line 78, in test_pipe_handle
    raise RuntimeError('expected ERROR_INVALID_HANDLE')
RuntimeError: expected ERROR_INVALID_HANDLE

----------

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

From report at bugs.python.org  Thu Dec  5 13:29:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2019 18:29:36 +0000
Subject: [issue38983] test_venv: test_overwrite_existing() failed on AMD64
 Windows7 SP1 3.x
Message-ID: <1575570576.83.0.24142874902.issue38983@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Failure on AMD64 Windows7 SP1 3.x:
https://buildbot.python.org/all/#builders/81/builds/16

======================================================================
ERROR: test_overwrite_existing (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 225, in test_overwrite_existing
    builder.create(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 65, in create
    context = self.ensure_directories(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 108, in ensure_directories
    self.clear_directory(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 91, in clear_directory
    shutil.rmtree(fn)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 731, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 613, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 611, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp9y0m6j7z\\Scripts'

======================================================================
ERROR: test_overwrite_existing (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 380, in _force_run
    return func(*args)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp9y0m6j7z\\Scripts\\activate.bat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 71, in tearDown
    rmtree(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 502, in rmtree
    _rmtree(path)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 443, in _rmtree
    _waitfor(_rmtree_inner, path, waitall=True)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 391, in _waitfor
    func(pathname)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 439, in _rmtree_inner
    _waitfor(_rmtree_inner, fullname, waitall=True)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 391, in _waitfor
    func(pathname)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 442, in _rmtree_inner
    _force_run(fullname, os.unlink, fullname)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 385, in _force_run
    os.chmod(path, stat.S_IRWXU)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp9y0m6j7z\\Scripts\\activate.bat'

----------
components: Tests
messages: 357881
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_venv: test_overwrite_existing() failed on AMD64 Windows7 SP1 3.x
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  5 13:29:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2019 18:29:41 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575570581.7.0.259650470229.issue38981@roundup.psfhosted.org>


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

See also the discussion about renaming json.loads(): https://mail.python.org/archives/list/python-ideas at python.org/thread/EJTIVQ2ZFSVHALTLRGFCOMOYGZYMKGQU/

----------

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

From report at bugs.python.org  Thu Dec  5 13:33:33 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 05 Dec 2019 18:33:33 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575570813.0.0.117698717488.issue38979@roundup.psfhosted.org>


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


----------
keywords: +easy (C)

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

From report at bugs.python.org  Thu Dec  5 13:34:05 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 05 Dec 2019 18:34:05 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575570845.13.0.107866594818.issue38981@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

Most of the module specific classes are `Error`, not `error`, at least with an uppercase E you know it's a class. 

if a novice sees :

> error: missing ), unterminated subpattern at position 0

It will be relatively tough or them to figure out that `error` is the type of the exception. 

Also it's not because something works that you can't improve it ...

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

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

From report at bugs.python.org  Thu Dec  5 13:42:23 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2019 18:42:23 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575571343.29.0.695422195053.issue38981@roundup.psfhosted.org>


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

Since it affects more than one module I suggest to discuss the idea about renaming exceptions of the Python-Ideas maillist first. Until different decision be made I am closing. Personally I think this is a duplicate of just discussed and rejected idea.

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

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

From report at bugs.python.org  Thu Dec  5 14:03:08 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2019 19:03:08 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575572588.47.0.935406901491.issue38978@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I'm actually missing context, so I will leave this up to you all.

----------

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

From report at bugs.python.org  Thu Dec  5 14:07:52 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 05 Dec 2019 19:07:52 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1575572872.12.0.104629710378.issue38973@roundup.psfhosted.org>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec  5 14:33:33 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 05 Dec 2019 19:33:33 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575574413.8.0.828477998386.issue38981@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

Thanks for the advice I've done that ! 

Have a good day.

----------

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

From report at bugs.python.org  Thu Dec  5 15:02:04 2019
From: report at bugs.python.org (Florian Dahlitz)
Date: Thu, 05 Dec 2019 20:02:04 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575576124.08.0.812720506027.issue38979@roundup.psfhosted.org>


Florian Dahlitz <f2dahlitz at freenet.de> added the comment:

I'd be happy to work on this!

----------
nosy: +DahlitzFlorian

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

From report at bugs.python.org  Thu Dec  5 16:05:01 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 05 Dec 2019 21:05:01 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575579901.17.0.828275614524.issue38980@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

> Maybe it should only be default when using --with-optimizations

I think it will add to the complexity of the --with-optimizations flag which already implies PGO and LTO.

Maybe an opt-in flag would be better IMHO.

----------
nosy: +cstratak

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

From report at bugs.python.org  Thu Dec  5 16:08:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 05 Dec 2019 21:08:43 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575580123.21.0.128697375325.issue38980@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I think it will add to the complexity of the --with-optimizations flag which already implies PGO and LTO.

That is why I was suggesting it: --with-optimizations for me means "activate everything that you can to make python faster".

----------

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

From report at bugs.python.org  Thu Dec  5 16:23:06 2019
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 05 Dec 2019 21:23:06 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575580986.43.0.438909096958.issue38980@roundup.psfhosted.org>


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

Just for a quick datapoint: llvm/clang do this by default and you need an explicit `-fsemantic-interposition` to disable it http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html

It seems to me that the performance gains here really outweigh any weird usage of LD_PRELOAD.

----------
nosy: +ammar2

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

From report at bugs.python.org  Thu Dec  5 16:44:31 2019
From: report at bugs.python.org (Andreas Kloeckner)
Date: Thu, 05 Dec 2019 21:44:31 +0000
Subject: [issue21161] list comprehensions don't see local variables in pdb in
 python3
In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za>
Message-ID: <1575582271.57.0.394455554354.issue21161@roundup.psfhosted.org>


Change by Andreas Kloeckner <inform at tiker.net>:


----------
nosy: +inducer

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

From report at bugs.python.org  Thu Dec  5 16:53:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 05 Dec 2019 21:53:17 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575582797.07.0.918546278469.issue38980@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> It seems to me that the performance gains here really outweigh any weird usage of LD_PRELOAD.

I am very convinced of this assertion, but other users could not be, I think the discussion is how to provide/activate the option in the less intrusive way and without breaking too many use cases.

To be honest, I think it would be very rare for users to use LD_PRELOAD in this way, so I am fine if we activate it by default. But I still think it would be good to discuss these cases and take them into consideration :)

----------

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

From report at bugs.python.org  Thu Dec  5 18:09:02 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 05 Dec 2019 23:09:02 +0000
Subject: [issue38948] os.path.ismount() returns False for current working drive
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575587342.15.0.168193336262.issue38948@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The only thing 'F:' can ever be is a mount point.

"F:" is a relative path that has to be resolved via abspath() (i.e. GetFullPathNameW in Windows) before we can determine whether it's a mount point. ntpath.ismount handles this correctly in 3.4+. 

The working directory on drive F: is the process working directory if it's the same drive, else it's the value of the "=F:" environment variable if defined, else it defaults to the root directory. The Windows API uses "=X:" environment variables, but it does not create them. They're optionally created by applications (e.g. CMD sets them, as does Python's os.chdir). Since they're just environment variables (albeit hidden because they begin with "="), per-drive working directories are inherited by child processes by default.

The main problem that I see here is that, in Windows (not POSIX), ntpath.ismount fails to verify that a potential mount point is an existing directory via os.stat and stat.S_ISDIR. This includes junctions that potentially target non-existing volumes (e.g. a junction to a removable volume that's unavailable or a volume with removable media that's not ready). This would be a breaking change, but I think it's important enough. Returning true for non-existing 'mount points' is nonsensical, since no filesystem actually mounts the path and the path itself may not even exist (e.g. an undefined drive or device). It needs to be and existing path in a device namespace (a device namespace is not necessarily a filesystem; all devices in NT have their own namespace, with a root path, whether mounted or not), and it has to at least be a subdirectory of a filesystem, if not the root directory. 

A common example of a mount point that's not at the root path of a device is a UNC share. For example, "\\;LanmanRedirector\;X:<logon ID>\server\share" resolves to opening "\Device\Mup\;LanmanRedirector\;X:<logon ID>\server\share", which is the form that's used for mapping an SMB share as a drive, except that a mapped drive can also target a subdirectory of a share. The opened path includes an explicit reference to the redirector device (to bypass prefix resolution), the drive and logon session for the cached connection (to bypass connecting), and an arbitrary number of prefix components (typically just "server\share"). 

Another related concern is the test for a root directory, `rest in seps`, which makes ntpath.ismount("F:") true in POSIX for the wrong reason. Since `seps` is a string, this check should actually be `rest and rest in seps' in order to avoid the vacuous truth when `rest` is an empty string. This problem is particular to POSIX because ntpath._abspath_fallback mishandles drive-relative paths. For example, ntpath.abspath("F:") returns "F:" in POSIX. It should special case a drive-relative path to insert a backslash (e.g. "F:" -> "F:\\", and "F:spam\\eggs" -> "F:\\spam\\eggs").

---

On the subject of junctions, a UNC path should not short-circuit out of checking for a junction, as it currently does. UNC paths can contain mount points, which get evaluated on the server.

In 3.8+, ntpath.ismount could also (and IMO should) support junctions that are bind mount points (i.e. mounting a subdirectory of a filesystem to a non-root path of a device) -- as posixpath.ismount does in POSIX. We already support bind mounts as subst and mapped drives and UNC shares, so it's just making ismount consistent, and for the better. This would require an os.lstat call to check st_file_attributes for stat.FILE_ATTRIBUTE_REPARSE_POINT and whether st_reparse_tag is stat.IO_REPARSE_TAG_MOUNT_POINT. It would still need an os.stat call and stat.S_ISDIR to verify that the target is an existing directory.

----------

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

From report at bugs.python.org  Thu Dec  5 18:19:13 2019
From: report at bugs.python.org (Sterling Smith)
Date: Thu, 05 Dec 2019 23:19:13 +0000
Subject: [issue35048] Can't reassign __class__ despite the assigned class
 having identical slots
In-Reply-To: <1540289238.37.0.788709270274.issue35048@psf.upfronthosting.co.za>
Message-ID: <1575587953.36.0.408867239115.issue35048@roundup.psfhosted.org>


Change by Sterling Smith <smithfamilynj at gmail.com>:


----------
nosy: +Sterling Smith

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

From report at bugs.python.org  Thu Dec  5 18:33:55 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Dec 2019 23:33:55 +0000
Subject: [issue38948] os.path.ismount() returns False for current working drive
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575588835.01.0.404366350894.issue38948@roundup.psfhosted.org>


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

> The main problem that I see here is that, in Windows (not POSIX), ntpath.ismount fails to verify that a potential mount point is an existing directory via os.stat and stat.S_ISDIR. ... This would be a breaking change, but I think it's important enough.

So essentially, you say the check should always be "ntpath.isdir(d) and ntpath.ismount(d)" (plus the non-breaking improvements to ismount)? And we should just do the isdir() inside ismount() because otherwise the result is nonsense.

I'm inclined to agree, and I'm not concerned about breaking a nonsense result. 

On the other hand, this will make ntpath.ismount meaningless on POSIX, as it will always require real access to the file system. Is it worth having a "pure" implementation for best effort in this case? Based on the splitdrive() patterns we support (plus the fixes to support them properly)?

----------

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

From report at bugs.python.org  Thu Dec  5 18:46:03 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Dec 2019 23:46:03 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1575589563.29.0.731067398307.issue33125@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +16959
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/17480

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

From report at bugs.python.org  Thu Dec  5 19:22:50 2019
From: report at bugs.python.org (Gabriele)
Date: Fri, 06 Dec 2019 00:22:50 +0000
Subject: [issue38984] Value add to the wrong key in a dictionary
Message-ID: <1575591770.15.0.618190193616.issue38984@roundup.psfhosted.org>


New submission from Gabriele <gabriele.marras85 at gmail.com>:

hello,
I found this strange issue in my program:

I?m reading a file with 5 columns separated by ?;? . Columns 3,4 and 5 can have multiple values and in this case, are separated by ?,? .
Some values in column 3 can be repeated in each line in the same column.

Goal:
I want create a dictionary for each line using as a key the value in the first column and another key using the values that are in column 3.
If the key in column 3 is already in the dictionary, I want add the value in column 4 to the dictionary for the key that is repeated.

Example file:
col1;col2;col3;col4;col5
id1;i1;val1;Si1;Da1
id2;i2;val2,val1;Si2,Si1;Da2
id3;i3;val3;Si3;Da3

Expected Result:
{?id1? : [ 'id1','i1',['val1'],['Si1'],['Da1?] ] ,
 ?id2? : [? id2','i2',['val2','val1'] ,[Si2,Si1] ,['Da2?] ] , 
 ?val1? : [ 'id1','i1',['val2','val1'],['Si2','Si1'],['Da1','Da2?] ] , 
 ?val2? : [ 'id2','i2',['val2','val1'],[Si2,Si1]    ,['Da2?] ] , 
 'id3? : [ 'id3','i3','val3',['Si3'],['Da3?] ] , 
 ?val3? : [ 'id3','i3','val3',['Si3'],['Da3?] ] }

But what I obtaining is 
{'id2': ['id2', 'i2', ['val2', 'val1'], ['Si2', 'Si1'], ['Da2'], '5'], 
'id3': ['id3', 'i3', ['val3'], ['Si3'], ['Da3'], '5?],
'id1': ['id1', 'i1', ['val1'], ['Si1', 'Si2', 'Si1'], ['Da1', 'Da2'], '5'], 
'val3': ['id3', 'i3', ['val3'], ['Si3'], ['Da3'], '5'], 
'val2': ['id2', 'i2', ['val2', 'val1'], ['Si2', 'Si1'], ['Da2'], '5'], 
'val1': ['id1', 'i1', ['val1'], ['Si1', 'Si2', 'Si1'], ['Da1', 'Da2'], '5']} 

My bug:
Key id1 was called just one time in my program, but in my results, I can find that list in position 3 is with 3 value (Si1 , Si2 , Si1) when it supposes to have just Si1.

Am I doing something wrong or this is a potential bug?
I ran the program using a different machines and different python versions, but results don't change.

----------
files: program.py
messages: 357894
nosy: malbianco
priority: normal
severity: normal
status: open
title: Value add to the wrong key in a dictionary
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48759/program.py

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

From report at bugs.python.org  Thu Dec  5 20:06:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 01:06:55 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575594415.21.0.411784273483.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16960
pull_request: https://github.com/python/cpython/pull/17481

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

From report at bugs.python.org  Thu Dec  5 20:12:24 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 Dec 2019 01:12:24 +0000
Subject: [issue38984] Value add to the wrong key in a dictionary
In-Reply-To: <1575591770.15.0.618190193616.issue38984@roundup.psfhosted.org>
Message-ID: <1575594744.46.0.820340271952.issue38984@roundup.psfhosted.org>


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

This is almost certainly not a bug in Python.

The bug tracker isn't for giving help with your code. I suggest you ask on the python-list mailing list https://mail.python.org/mailman/listinfo/python-list

If you still think this is a bug in Python, you should create a simpler program to reproduce the problem, and one that doesn't use any third-party code.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Dec  5 20:12:41 2019
From: report at bugs.python.org (Daniel Himmelstein)
Date: Fri, 06 Dec 2019 01:12:41 +0000
Subject: [issue29636] Specifying indent in the json.tool command
In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za>
Message-ID: <1575594761.81.0.237155433789.issue29636@roundup.psfhosted.org>


Change by Daniel Himmelstein <daniel.himmelstein at gmail.com>:


----------
pull_requests: +16961
pull_request: https://github.com/python/cpython/pull/17482

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

From report at bugs.python.org  Thu Dec  5 20:19:44 2019
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 06 Dec 2019 01:19:44 +0000
Subject: [issue38948] os.path.ismount() returns False for current working drive
In-Reply-To: <1575196854.18.0.0543230038393.issue38948@roundup.psfhosted.org>
Message-ID: <1575595184.72.0.918259335713.issue38948@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> So essentially, you say the check should always be "ntpath.isdir(d) 

I forgot that ntpath.isdir is now genericpath.isdir, so that will work. The old nt._isdir wouldn't work because it was equivalent to an lstat. Apparently a vestigial import of nt._isdir remains in ntpath.py, even though nt._isdir was removed:

https://hg.python.org/cpython/file/v3.3.0/Lib/ntpath.py#l677

> On the other hand, this will make ntpath.ismount meaningless on POSIX, 
> as it will always require real access to the file system. Is it worth 
> having a "pure" implementation for best effort in this case? 

I'm not suggesting an existence check in POSIX. Whoever uses ntpath in POSIX must be aware that ntpath.ismount is useless for detecting Unix mount points. It's only useful for identifying potential mount points in a pure Windows path. I see no reason to break this use case.

For POSIX, I'd like ntpath._abspath_fallback to handle drive-relative paths, so we can fix the check in ismount to use `rest and rest in seps`. It seems wrong for _abspath_fallback("F:") to return the relative path "F:". No drives exist in POSIX, so it's harmless to assume that the working directory on each drive is the root directory, which is the default value in Windows anyway.

> Based on the splitdrive() 

Note that splitdrive currently doesn't support "UNC" device paths (issue 37609). For example, "//?/UNC/server/share" splits as ("//?/UNC", "/server/share"). "GLOBAL" device paths also aren't supported, which I'd prefer, but it's less important because they're only useful rarely, and I don't know of an existing path library that handles them. splitdrive also doesn't support repeated separators between the server and share components, such as "//server///share", which GetFullPathNameW handles nowadays. Maybe it didn't circa NT 5.0. The only place that's strict is the UNC root, which must be exactly two separators. I uploaded an implementation to issue 37609 that supports "UNC" and "GLOBAL" device paths, with support for repeated separators. Here's a complex example split: ("//?///Global///UNC///server///share", "///path").

Anyway, ntpath.ismount needs to distinguish between UNC and "UNC" device paths vs all other device paths, because a root path is only optional in the UNC case. For example, "//?/C:" or "//?/BootPartition" is a volume device, and "//?C:/" or "//?/BootPartition/" is a filesystem mount point. In Windows we can detect that "//?/C:" or "//?/BootPartition" isn't a directory, but in POSIX we need to get it right as a pure path.

----------

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

From report at bugs.python.org  Thu Dec  5 20:43:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 01:43:37 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575596617.02.0.550998335208.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 81fe5bd3d78f9bb955f8255404d99df27a31c36a by Victor Stinner in branch 'master':
bpo-38858: new_interpreter() reuses _PySys_Create() (GH-17481)
https://github.com/python/cpython/commit/81fe5bd3d78f9bb955f8255404d99df27a31c36a


----------

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

From report at bugs.python.org  Thu Dec  5 20:47:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 01:47:10 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575596830.26.0.865146210181.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16962
pull_request: https://github.com/python/cpython/pull/17483

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

From report at bugs.python.org  Thu Dec  5 20:55:03 2019
From: report at bugs.python.org (Gabriele)
Date: Fri, 06 Dec 2019 01:55:03 +0000
Subject: [issue38984] Value add to the wrong key in a dictionary
In-Reply-To: <1575591770.15.0.618190193616.issue38984@roundup.psfhosted.org>
Message-ID: <1575597303.82.0.930964556319.issue38984@roundup.psfhosted.org>


Change by Gabriele <gabriele.marras85 at gmail.com>:


Added file: https://bugs.python.org/file48760/programTEST.py

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

From report at bugs.python.org  Thu Dec  5 20:59:17 2019
From: report at bugs.python.org (Gabriele)
Date: Fri, 06 Dec 2019 01:59:17 +0000
Subject: [issue38984] Value add to the wrong key in a dictionary
In-Reply-To: <1575591770.15.0.618190193616.issue38984@roundup.psfhosted.org>
Message-ID: <1575597557.29.0.927992976364.issue38984@roundup.psfhosted.org>


Gabriele <gabriele.marras85 at gmail.com> added the comment:

Hi Eric,
I think is a bug and not a simple coding error. 
python is adding new value into another key in a dictionary when the key is not called.
I updated my code (check "programTEST.py") that can replicate perfectly my problem. 

Please try my program and let me know if you think is a bug or a "coding" error.

----------

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

From report at bugs.python.org  Thu Dec  5 21:37:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 02:37:11 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575599831.65.0.657631034237.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d863ade0c7fa4826e8b71aa467809c83a711f019 by Victor Stinner in branch 'master':
bpo-38858: Add pycore_interp_init() code to factorize code (GH-17483)
https://github.com/python/cpython/commit/d863ade0c7fa4826e8b71aa467809c83a711f019


----------

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

From report at bugs.python.org  Thu Dec  5 22:01:17 2019
From: report at bugs.python.org (Ahmed Ramadan)
Date: Fri, 06 Dec 2019 03:01:17 +0000
Subject: [issue38984] Value add to the wrong key in a dictionary
In-Reply-To: <1575591770.15.0.618190193616.issue38984@roundup.psfhosted.org>
Message-ID: <1575601277.73.0.325315304992.issue38984@roundup.psfhosted.org>


Ahmed Ramadan <abdulshafy at gmail.com> added the comment:

It's a bug in your code.

masterInfoDict['id1'][4] and masterInfoDict['val1'][4] point to the same list object ['Si1'], to which 'Si2' and 'Si1' get appended when col1ID='id2'.

----------
nosy: +ramahmed

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

From report at bugs.python.org  Fri Dec  6 00:22:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 06 Dec 2019 05:22:40 +0000
Subject: [issue38983] test_venv: test_overwrite_existing() failed on AMD64
 Windows7 SP1 3.x
In-Reply-To: <1575570576.83.0.24142874902.issue38983@roundup.psfhosted.org>
Message-ID: <1575609760.68.0.469479428958.issue38983@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://bugs.python.org/issue38544#msg355041 seems like a related old report

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Dec  6 00:29:06 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 Dec 2019 05:29:06 +0000
Subject: [issue35048] Can't reassign __class__ despite the assigned class
 having identical slots
In-Reply-To: <1540289238.37.0.788709270274.issue35048@psf.upfronthosting.co.za>
Message-ID: <1575610146.55.0.324573601968.issue35048@roundup.psfhosted.org>


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


----------
nosy: +rhettinger

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

From report at bugs.python.org  Fri Dec  6 01:44:05 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 06 Dec 2019 06:44:05 +0000
Subject: [issue27413] Add an option to json.tool to bypass non-ASCII
 characters.
In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za>
Message-ID: <1575614645.52.0.399285917656.issue27413@roundup.psfhosted.org>


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


New changeset efefe25443c56988841ab96cdac01352123ba268 by Inada Naoki (wim glenn) in branch 'master':
bpo-27413: json.tool: Add --no-ensure-ascii option. (GH-17472)
https://github.com/python/cpython/commit/efefe25443c56988841ab96cdac01352123ba268


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

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

From report at bugs.python.org  Fri Dec  6 01:44:23 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 06 Dec 2019 06:44:23 +0000
Subject: [issue27413] Add an option to json.tool to bypass non-ASCII
 characters.
In-Reply-To: <1467200969.47.0.983958211319.issue27413@psf.upfronthosting.co.za>
Message-ID: <1575614663.44.0.916750626855.issue27413@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.7

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

From report at bugs.python.org  Fri Dec  6 01:59:42 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 Dec 2019 06:59:42 +0000
Subject: [issue26628] Undefined behavior calling C functions with ctypes.Union
 arguments
In-Reply-To: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za>
Message-ID: <1575615582.35.0.412823297689.issue26628@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is now fixed as a result of fixing bpo-16575. The unioncrash.py script now gives an error message:

$ python3.9 ~/tmp/unioncrash.py 
Traceback (most recent call last):
  File "/home/vinay/tmp/unioncrash.py", line 10, in <module>
    sin.argtypes = [MyUnion]
TypeError: item 1 in _argtypes_ passes a union by value, which is unsupported.

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

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

From report at bugs.python.org  Fri Dec  6 02:01:49 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 Dec 2019 07:01:49 +0000
Subject: [issue28404] Logging SyslogHandler not appending '\n' to the end
In-Reply-To: <1476101662.48.0.994997122347.issue28404@psf.upfronthosting.co.za>
Message-ID: <1575615709.1.0.148845680127.issue28404@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution: not a bug -> out of date
status: pending -> closed

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

From report at bugs.python.org  Fri Dec  6 02:16:35 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 Dec 2019 07:16:35 +0000
Subject: [issue12769] String with NUL characters truncated by ctypes when
 assigning to a char array
In-Reply-To: <1313586371.99.0.0572825103199.issue12769@psf.upfronthosting.co.za>
Message-ID: <1575616595.01.0.952823687363.issue12769@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Dec  6 02:25:25 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 Dec 2019 07:25:25 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
In-Reply-To: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>
Message-ID: <1575617125.98.0.82962684832.issue38921@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'll flag this as pending, and close in a week if no minimal needed-to-reproduce script is posted. Let me know if you are working on producing such a minimal script and need more time.

----------
status: open -> pending

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

From report at bugs.python.org  Fri Dec  6 03:48:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2019 08:48:39 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575622119.91.0.597911963065.issue38980@roundup.psfhosted.org>


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

In case of malloc, every memory allocating code need to use malloc/calloc/realloc. This is official and the only way to allocate a memory. But we do not guarantee that Python core uses only public C API like PyErr_Occurred(). It can use more low-level and efficient but less safer C API internally. It can replace the function with a macro which access internal structures directly (for compiling the core only). And this is actually the case. Overridding the public C API functions not always has an effect on the core.

So I think that adding -fno-semantic-interposition will likely not break many things which were not broken before.

But this should be discussed on Python-Dev. I am sure some C API functions are purposed to be overridden.

----------

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

From report at bugs.python.org  Fri Dec  6 04:29:05 2019
From: report at bugs.python.org (Koh)
Date: Fri, 06 Dec 2019 09:29:05 +0000
Subject: [issue38985] `compile` returns the first line of file on termination
Message-ID: <1575624545.38.0.942954446264.issue38985@roundup.psfhosted.org>


New submission from Koh <kohyouliang at gmail.com>:

By specifying a filename in the compile function and then improperly terminating it, we are able to return the first line of any file.

>> compile('yield', '/etc/passwd', 'exec')
File "/etc/passwd", line 1
    root:x:0:0:root:/root:/bin/bash
    ^
SyntaxError: 'yield' outside function

Is this intended behavior? I have been able to use it to escape sandboxes.

----------
messages: 357906
nosy: iso
priority: normal
severity: normal
status: open
title: `compile` returns the first line of file on termination
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec  6 05:21:47 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2019 10:21:47 +0000
Subject: [issue38984] Value add to the wrong key in a dictionary
In-Reply-To: <1575591770.15.0.618190193616.issue38984@roundup.psfhosted.org>
Message-ID: <1575627706.99.0.359342511347.issue38984@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Fri Dec  6 05:22:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 06 Dec 2019 10:22:08 +0000
Subject: [issue38985] `compile` returns the first line of file on termination
In-Reply-To: <1575624545.38.0.942954446264.issue38985@roundup.psfhosted.org>
Message-ID: <1575627728.61.0.777451606741.issue38985@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It's not necessarily the first line. The code is executed with the context of the given file. Hence the corresponding line number of error from traceback with respect to file is printed.

$ cat /tmp/passwd
line 1
line 2
line 3
line 4

$ python3 -c 'compile("\n\n\nyield", "/tmp/passwd", "exec")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/passwd", line 4
    line 4
    ^
SyntaxError: 'yield' outside function

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Dec  6 05:26:13 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2019 10:26:13 +0000
Subject: [issue38985] `compile` returns the first line of file on termination
In-Reply-To: <1575624545.38.0.942954446264.issue38985@roundup.psfhosted.org>
Message-ID: <1575627973.18.0.207079992955.issue38985@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Yes, that is expected behavior.

 Python is not designed for sandboxing and doesn't support sandboxing. *If* Python would support sandboxing, then compile() would be one of the first functions to go, because it allows an attacker to construct custom executable code.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Fri Dec  6 05:32:34 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 10:32:34 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1575628354.47.0.61856174602.issue38973@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Antoine is marked as the multiprocessing expert

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

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

From report at bugs.python.org  Fri Dec  6 05:32:42 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 10:32:42 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1575628362.93.0.635063537593.issue38973@roundup.psfhosted.org>


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


----------
nosy:  -asvetlov

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

From report at bugs.python.org  Fri Dec  6 05:33:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2019 10:33:42 +0000
Subject: [issue38985] `compile` returns the first line of file on termination
In-Reply-To: <1575624545.38.0.942954446264.issue38985@roundup.psfhosted.org>
Message-ID: <1575628422.62.0.168855283316.issue38985@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/issue38985>
_______________________________________

From report at bugs.python.org  Fri Dec  6 05:52:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 06 Dec 2019 10:52:01 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1575629521.01.0.0565553907523.issue38973@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +davin

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

From report at bugs.python.org  Fri Dec  6 06:04:05 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 11:04:05 +0000
Subject: [issue38955] Non indemnpotent behavior of asyncio.get_event_loop and
 asyncio.run sequence.
In-Reply-To: <1575311987.47.0.389219942485.issue38955@roundup.psfhosted.org>
Message-ID: <1575630245.14.0.625115529163.issue38955@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Asyncio has a few own exceptions, the library tries to utilize existing ones, e.g. ValueError, TypeError, and OSError family. RuntimeError falls into this category.

get_event_loop() never returns None, it was from very beginning. If we change it existing third-party code will be broken. So, no way, sorry.

I really don't think we can change anything here.

Would you describe cases when you need an implicit loop instance but there is no running loop currently?

----------

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

From report at bugs.python.org  Fri Dec  6 06:51:47 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 06 Dec 2019 11:51:47 +0000
Subject: [issue38706] What should the error message in the exception raised by
 assertTrue and assertFalse be?
In-Reply-To: <1573028141.58.0.581208867224.issue38706@roundup.psfhosted.org>
Message-ID: <20191106115135.GJ3574@ando.pearwood.info>


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

I tried sending this message earlier, but it seems to have disappeared 
into the void, so I'm trying again. Apologies if it turns up twice.

* * *

> There are almost 500 occurrences of "is true".

We can worry about them if and when somebody raises them as a "bug 
report" or feature request. Without reading each one in context, I have 
no idea whether they are good, bad or indifferent. Doing a massive 
search and replace would be a bad idea.

Right now we have a simple feature request: improve the assertIsTrue and 
assertIsFalse messages. There is a simple way to improve them. We don't 
have to touch any other message, just these two.

Personally, I prefer "truthy and falsey" or "true-like and false-like" 
over "true and false" to distinguish between "duck-typed bools" and the 
actual bool singletons True and False. But I don't prefer them enough to 
fight over the terms. If you prefer "true and false", that's okay with 
me too :-)

"False is not true" suggests to the user that the test is doing an 
identity check. We have proof from the OP's bug report that at least one 
person thought that. I had to read the source code to check.

A better failure message would be helpful to make it clear that it 
checks by value not identity ``if value is True``.

----------

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

From report at bugs.python.org  Fri Dec  6 07:21:25 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 06 Dec 2019 12:21:25 +0000
Subject: [issue38906] copy2 doesn't copy metadata on Windows and MacOS
In-Reply-To: <1574597606.02.0.586122584542.issue38906@roundup.psfhosted.org>
Message-ID: <1575634885.44.0.686688261792.issue38906@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The relevant API on macOS is [f]copyfile(3) which is at the POSIX layer. The copyFile API linked to in msg357395 is a higher-level ObjC/Swift API.

Using the copyfile(3) API has another advantage beyond this issue: This API can perform a clone action on APFS when the right flags are used.

----------

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

From report at bugs.python.org  Fri Dec  6 08:09:22 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 13:09:22 +0000
Subject: [issue38986] Suppport TaskWakeupMethWrapper.__self__ to conform
 asyncio _format_handle logic
Message-ID: <1575637762.64.0.656469338348.issue38986@roundup.psfhosted.org>


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

_format_handle() behaves differently if handle._callback.__self__ is asyncio.Task instance.

To follow this logic TaskWakeupMethWrapper from _asynciomodule.c should support the corresponding member.

The fix is very desired for analyzing slow callbacks, without it the output doesn't point on slow coroutine but mentions <TaskWakeupMethWrapper at 0x...> only.

See also #38608

----------
components: asyncio
messages: 357913
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Suppport TaskWakeupMethWrapper.__self__ to conform asyncio _format_handle logic
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec  6 08:10:10 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 13:10:10 +0000
Subject: [issue38608] Undocumented behavior that IsolatedAsyncioTestCase would
 enable event loop debug mode
In-Reply-To: <1572227413.17.0.184690601558.issue38608@roundup.psfhosted.org>
Message-ID: <1575637810.57.0.216696354638.issue38608@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The output will be fixed by #38986
Nothing to do here.

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

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

From report at bugs.python.org  Fri Dec  6 08:13:01 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 13:13:01 +0000
Subject: [issue38986] Suppport TaskWakeupMethWrapper.__self__ to conform
 asyncio _format_handle logic
In-Reply-To: <1575637762.64.0.656469338348.issue38986@roundup.psfhosted.org>
Message-ID: <1575637981.08.0.707477893176.issue38986@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16963
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17484

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

From report at bugs.python.org  Fri Dec  6 08:14:49 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 06 Dec 2019 13:14:49 +0000
Subject: [issue38986] Suppport TaskWakeupMethWrapper.__self__ to conform
 asyncio _format_handle logic
In-Reply-To: <1575637762.64.0.656469338348.issue38986@roundup.psfhosted.org>
Message-ID: <1575638089.86.0.58661988704.issue38986@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

For the note: TaskStepMethWrapper has the same fix already, TaskWakeupMethWrapper was accidentally missed.

----------

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

From report at bugs.python.org  Fri Dec  6 09:27:48 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 14:27:48 +0000
Subject: [issue36820] Captured exceptions are keeping user objects alive
 unnecessarily in the stdlib
In-Reply-To: <1557171135.51.0.216377454002.issue36820@roundup.psfhosted.org>
Message-ID: <1575642468.3.0.911097724198.issue36820@roundup.psfhosted.org>


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


New changeset b64334cb93d0ddbb551c8cd712942bab2fc72772 by Miss Islington (bot) (Mario Corchero) in branch 'master':
bpo-36820: Break unnecessary cycle in socket.py, codeop.py and dyld.py (GH-13135)
https://github.com/python/cpython/commit/b64334cb93d0ddbb551c8cd712942bab2fc72772


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

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

From report at bugs.python.org  Fri Dec  6 09:43:18 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 14:43:18 +0000
Subject: [issue36820] Captured exceptions are keeping user objects alive
 unnecessarily in the stdlib
In-Reply-To: <1557171135.51.0.216377454002.issue36820@roundup.psfhosted.org>
Message-ID: <1575643398.61.0.383020482763.issue36820@roundup.psfhosted.org>


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


----------
pull_requests: +16964
pull_request: https://github.com/python/cpython/pull/17485

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

From report at bugs.python.org  Fri Dec  6 09:43:24 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 14:43:24 +0000
Subject: [issue36820] Captured exceptions are keeping user objects alive
 unnecessarily in the stdlib
In-Reply-To: <1557171135.51.0.216377454002.issue36820@roundup.psfhosted.org>
Message-ID: <1575643404.78.0.0567208241993.issue36820@roundup.psfhosted.org>


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


----------
pull_requests: +16965
pull_request: https://github.com/python/cpython/pull/17486

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

From report at bugs.python.org  Fri Dec  6 09:49:38 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 06 Dec 2019 14:49:38 +0000
Subject: [issue36820] Captured exceptions are keeping user objects alive
 unnecessarily in the stdlib
In-Reply-To: <1557171135.51.0.216377454002.issue36820@roundup.psfhosted.org>
Message-ID: <1575643778.01.0.407404917758.issue36820@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/issue36820>
_______________________________________

From report at bugs.python.org  Fri Dec  6 09:59:56 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 14:59:56 +0000
Subject: [issue36820] Captured exceptions are keeping user objects alive
 unnecessarily in the stdlib
In-Reply-To: <1557171135.51.0.216377454002.issue36820@roundup.psfhosted.org>
Message-ID: <1575644396.07.0.58337868358.issue36820@roundup.psfhosted.org>


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


New changeset 681285d052977e3a3a82ef665e788946fca1ac59 by Miss Islington (bot) in branch '3.8':
bpo-36820: Break unnecessary cycle in socket.py, codeop.py and dyld.py (GH-13135)
https://github.com/python/cpython/commit/681285d052977e3a3a82ef665e788946fca1ac59


----------

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

From report at bugs.python.org  Fri Dec  6 10:01:35 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 15:01:35 +0000
Subject: [issue36820] Captured exceptions are keeping user objects alive
 unnecessarily in the stdlib
In-Reply-To: <1557171135.51.0.216377454002.issue36820@roundup.psfhosted.org>
Message-ID: <1575644495.18.0.693515793979.issue36820@roundup.psfhosted.org>


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


New changeset 5ba591fa2c1f74c4a84372fb4ffc0b16863f1ad7 by Miss Islington (bot) in branch '3.7':
bpo-36820: Break unnecessary cycle in socket.py, codeop.py and dyld.py (GH-13135)
https://github.com/python/cpython/commit/5ba591fa2c1f74c4a84372fb4ffc0b16863f1ad7


----------

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

From report at bugs.python.org  Fri Dec  6 10:32:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 15:32:46 +0000
Subject: [issue38982] test_asyncio:
 SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file
 descriptor
In-Reply-To: <1575565741.97.0.071963111218.issue38982@roundup.psfhosted.org>
Message-ID: <1575646366.41.0.527818521903.issue38982@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e76ee1a72b9e3f5da287663ea3daec4bb3f67612 by Victor Stinner in branch 'master':
bpo-38982: Fix asyncio PidfdChildWatcher on waitpid() error (GH-17477)
https://github.com/python/cpython/commit/e76ee1a72b9e3f5da287663ea3daec4bb3f67612


----------

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

From report at bugs.python.org  Fri Dec  6 11:01:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 16:01:54 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575648114.92.0.973776231176.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Py_NewInterpreter() (new_interpreter() in practice) and Py_InitializeEx() now share almost all their code.

Py_EndInterpreter() shares almost all its code with Py_Finalizer(). It's not perfect, but it's way better than previously.

Py_NewInterpreter() now isolates more things from the main interpreter. For example, builtins and sys modules no longer copy the module dictionary of the main interpreter, but create their own dictionary from scratch.

See each commit for the details.

Py_Finalizer() could share more code with Py_EndInterpreter(), but each Py_Finalizer() change is really tricky and require to pay a lot attention. The Python finalization is really fragile. I started to take notes on this fragile code:
https://pythondev.readthedocs.io/finalization.html

I consider that the initial issue is fixed, so I close the issue.

----------
nosy: +eric.snow
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  6 11:05:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 16:05:09 +0000
Subject: [issue38983] test_venv: test_overwrite_existing() failed on AMD64
 Windows7 SP1 3.x
In-Reply-To: <1575570576.83.0.24142874902.issue38983@roundup.psfhosted.org>
Message-ID: <1575648309.36.0.522337155102.issue38983@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> https://bugs.python.org/issue38544#msg355041 seems like a related old report

Right, same error in the same function (clear_directory()). I mark it as a duplicate of bpo-38544.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_venv: test_isolation() failed on AMD64 Windows7 SP1 3.x: directory not empty: Scripts\

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

From report at bugs.python.org  Fri Dec  6 11:09:44 2019
From: report at bugs.python.org (wayo man)
Date: Fri, 06 Dec 2019 16:09:44 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1575648584.3.0.628712489846.issue33125@roundup.psfhosted.org>


wayo man <usaads223 at gmail.com> added the comment:

Have you heard of this songs


https://fakazamusic.co/khuzani-isilingo/
https://fakazamusic.co/kabza-de-small-dj-maphorisa-sha-sha-kea-go-rata/
https://fakazamusic.co/amabhotela-uzongithola-ematshwaleni/
https://fakazamusic.co/khuzani-new-album-2019/
https://fakazamusic.co/khuzani-inhloko-nesxhanti-album-tracklist/
https://fakazamusic.co/amapiano-mix-1-december-2019-ft-vigro-deep-dj-big-sky-kabza-de-small-mixed-by-tkm/
https://fakazamusic.co/album-mashbeatz-fire-in-the-water-zip-file/
https://fakazamusic.co/ep-starboy-soundman-vol-1-zip-file/
https://fakazamusic.co/da-fresh-athie-x-mr-thela-religious-sounds/


<a href="https://fakazamusic.co">mixtapes download</a>

<a href="https://fakazamusic.co">latest gospel songs mp3 download</a>

<a href="https://safakaza.com">south africa songs download</a>


<a href="https://fakazamusic.co">pro.tee no eric gqom songs</a>

<a href="https://fakazamusic.co"> song lyrics </a>

<a href="https://forible.xyz">deephouse News & Entertainment</a>

 <a href="https://dfactual.com">deephouse News & Entertainment</a>

<a target="_blank" href="https://fakazamusic.co">pelco songs download</a>

<a target="_blank" href="https://fakazamusic.co">apiano vigro deep</a>  

<a target="_blank" href="https://fakazamusic.co">pro tee songs 2019</a>

----------
nosy: +wayoman

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

From report at bugs.python.org  Fri Dec  6 11:33:18 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 06 Dec 2019 16:33:18 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1575649998.66.0.995309278236.issue33125@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Dec  6 11:43:25 2019
From: report at bugs.python.org (Svetlana Vodianova)
Date: Fri, 06 Dec 2019 16:43:25 +0000
Subject: [issue38868] Shutil cannot delete a folder that contains an .ini file
In-Reply-To: <1574280283.41.0.914167266294.issue38868@roundup.psfhosted.org>
Message-ID: <1575650605.05.0.417787611512.issue38868@roundup.psfhosted.org>


Svetlana Vodianova <svetlana.vodianova69 at gmx.com> added the comment:

I think eryksun is correct.

I agree. The code sample provided by him, and the Python docs, mean I'm able to remove a folder with a .ini file without getting WinError 5.

I should mark this as closed as he solved my problem.

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

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

From report at bugs.python.org  Fri Dec  6 12:19:12 2019
From: report at bugs.python.org (Kevin Buchs)
Date: Fri, 06 Dec 2019 17:19:12 +0000
Subject: [issue38987] 3.8.0 on GNU/Linux fails to find shared library
Message-ID: <1575652752.94.0.770020872085.issue38987@roundup.psfhosted.org>


New submission from Kevin Buchs <kevin.buchs at gmail.com>:

I just downloaded Python 3.8.0 and built (from source) on Ubuntu 18.04. I used these options to configure:

  ./configure --enable-shared --enable-ipv6 --enable-optimizations

The shared library gets installed into /usr/local/lib:

  find / -type f -name libpython3.8.so.1.0
  /usr/local/src/Python-3.8.0/libpython3.8.so.1.0
  /usr/local/lib/libpython3.8.so.1.0
  
/usr/local/lib is defined as a path to search for shared libraries: 

  # /etc/ld.so.conf loads all /etc/ld.so.conf.d/*.conf
  grep /usr/local  /etc/ld.so.conf.d/*.conf
  /etc/ld.so.conf.d/i386-linux-gnu.conf:/usr/local/lib/i386-linux-gnu
  /etc/ld.so.conf.d/i386-linux-gnu.conf:/usr/local/lib/i686-linux-gnu
  /etc/ld.so.conf.d/libc.conf:/usr/local/lib
  /etc/ld.so.conf.d/x86_64-linux-gnu.conf:/usr/local/lib/x86_64-linux-gnu

But, the python executable is unable to find it:
  /usr/local/bin/python3.8
  /usr/local/bin/python3.8: error while loading shared libraries: 
    libpython3.8.so.1.0: cannot open shared object file: No such file
    or directory

----------
components: Installation
messages: 357924
nosy: buchs
priority: normal
severity: normal
status: open
title: 3.8.0 on GNU/Linux fails to find shared library
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Fri Dec  6 12:27:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:27:35 +0000
Subject: [issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1
 3.x: directory not empty: Scripts\
In-Reply-To: <1571653144.99.0.203555280128.issue38544@roundup.psfhosted.org>
Message-ID: <1575653255.85.0.0232493368239.issue38544@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-38983 as a duplicate of this issue. It's the same error in the same function (clear_directory()). Copy of the first message:

Failure on AMD64 Windows7 SP1 3.x:
https://buildbot.python.org/all/#builders/81/builds/16

======================================================================
ERROR: test_overwrite_existing (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 225, in test_overwrite_existing
    builder.create(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 65, in create
    context = self.ensure_directories(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 108, in ensure_directories
    self.clear_directory(env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\venv\__init__.py", line 91, in clear_directory
    shutil.rmtree(fn)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 731, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 613, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 611, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp9y0m6j7z\\Scripts'

======================================================================
ERROR: test_overwrite_existing (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 380, in _force_run
    return func(*args)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp9y0m6j7z\\Scripts\\activate.bat'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 71, in tearDown
    rmtree(self.env_dir)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 502, in rmtree
    _rmtree(path)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 443, in _rmtree
    _waitfor(_rmtree_inner, path, waitall=True)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 391, in _waitfor
    func(pathname)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 439, in _rmtree_inner
    _waitfor(_rmtree_inner, fullname, waitall=True)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 391, in _waitfor
    func(pathname)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 442, in _rmtree_inner
    _force_run(fullname, os.unlink, fullname)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 385, in _force_run
    os.chmod(path, stat.S_IRWXU)
PermissionError: [WinError 5] Access is denied: 'C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmp9y0m6j7z\\Scripts\\activate.bat

----------

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

From report at bugs.python.org  Fri Dec  6 12:31:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:31:06 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1575653466.2.0.19457637917.issue38980@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> In case of malloc, every memory allocating code need to use malloc/calloc/realloc. This is official and the only way to allocate a memory. But we do not guarantee that Python core uses only public C API like PyErr_Occurred(). It can use more low-level and efficient but less safer C API internally. It can replace the function with a macro which access internal structures directly (for compiling the core only). And this is actually the case. Overridding the public C API functions not always has an effect on the core.

To confirm what you said: if we take the specific example of PyErr_Occurred(), I recently added a new _PyErr_Occurred() function which is declared as a static inline function. _PyErr_Occurred() cannot be overriden.

static inline PyObject* _PyErr_Occurred(PyThreadState *tstate)
{
    assert(tstate != NULL);
    return tstate->curexc_type;
}

----------

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

From report at bugs.python.org  Fri Dec  6 12:31:25 2019
From: report at bugs.python.org (Logan Gunthorpe)
Date: Fri, 06 Dec 2019 17:31:25 +0000
Subject: [issue5396] os.read not handling O_DIRECT flag
In-Reply-To: <1235847751.77.0.558509867366.issue5396@psf.upfronthosting.co.za>
Message-ID: <1575653485.64.0.374385626784.issue5396@roundup.psfhosted.org>


Logan Gunthorpe <logang at deltatee.com> added the comment:

Paul's solution works in 3.7 if you set the buffer size to zero when calling fdopen.

fd = os.open("my_file", os.O_DIRECT | os.O_RDWR)
f = os.fdopen(fd, "rb+", 0)
m = mmap.mmap(-1, 4096)
f.readinto(m)

This is according to a comment in _pyio.py:

# If remaining space in callers buffer is larger than
# internal buffer, read directly into callers buffer

So by simply disabling the buffer (which is what we'd want for O_DIRECT anyway) readinto() works as expected. 

However, based on this issue, I'm a little concerned this won't be fully supported by python going forward; so use with care.

----------
nosy: +logang

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

From report at bugs.python.org  Fri Dec  6 12:36:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:36:33 +0000
Subject: [issue38982] test_asyncio:
 SubprocessPidfdWatcherTests..test_close_dont_kill_finished() leaks a file
 descriptor
In-Reply-To: <1575565741.97.0.071963111218.issue38982@roundup.psfhosted.org>
Message-ID: <1575653793.82.0.609441233318.issue38982@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I manually validated that my change fixed the test_asyncio leak:

$ ./python -m test test_asyncio -R 3:3 --fail-env-changed -v -m test_subprocess
(...)
Tests result: SUCCESS

I close the issue. Thanks Pablo for the review ;-)

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

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

From report at bugs.python.org  Fri Dec  6 12:38:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:38:16 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1575653896.22.0.802861355281.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

New failure on AMD64 RHEL7 LTO 3.x:
https://buildbot.python.org/all/#/builders/103/builds/17

test_interpreter_shutdown
(test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest)
... 1.61s Warning -- reap_children() reaped child process 9934

----------

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

From report at bugs.python.org  Fri Dec  6 12:41:00 2019
From: report at bugs.python.org (dontbugme)
Date: Fri, 06 Dec 2019 17:41:00 +0000
Subject: [issue38988] Killing asyncio subprocesses on timeout?
Message-ID: <1575654060.86.0.979877919031.issue38988@roundup.psfhosted.org>


New submission from dontbugme <pythonbugsbugmenot at spamavert.com>:

I'm trying to use asyncio.subproceess and am having difficulty killing the subprocesses after timeout. My use case is launching processes that hold on to file handles and other exclusive resources, so subsequent processes can only be launched after the first ones are fully stopped.


The documentation on https://docs.python.org/3/library/asyncio-subprocess.html#asyncio.asyncio.subprocess.Process say there is no timeout-parameter and suggests using wait_for() instead.
I tried this but it's kind of a footgun because the wait_for() times out but the process still lives on in the background. See Fail(1) and Fail(2) in attached test1().


To solve this i tried to catch the CancelledError and in the exception handler kill the process myself. While this worked it's also semi dangerous because it takes some time for the process to get killed and the wait() after kill() runs in the background as some kind of detached task. See Fail(3) in attached test2().
This i can sortof understand because after TimeoutError something would have to block for wait() to actually finish and this is impossible.

After writing this i feel myself there is no good solution for Fail#3 because again, timeouts can't be blocking. Maybe some warning in the documentation would be appropriate for Fail(1+2) because the suggestion in the documentation right now is quite misleading, the wait_for()-alternative to timeout-parameter does not behave like the timeout-parameter in ordinary subprocess.Popen.wait()

----------
components: asyncio
files: subprocess_timeout.py
messages: 357930
nosy: asvetlov, dontbugme, yselivanov
priority: normal
severity: normal
status: open
title: Killing asyncio subprocesses on timeout?
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48761/subprocess_timeout.py

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

From report at bugs.python.org  Fri Dec  6 12:41:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Dec 2019 17:41:02 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1575654061.99.0.071672933075.issue33125@roundup.psfhosted.org>


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


New changeset c9f480d2ccda9de46584cabe086f0acfa45f2faf by Steve Dower in branch '3.8':
bpo-33125: Add support for building and releasing Windows ARM64 packages (GH-17480)
https://github.com/python/cpython/commit/c9f480d2ccda9de46584cabe086f0acfa45f2faf


----------

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

From report at bugs.python.org  Fri Dec  6 12:43:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:43:46 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575654226.05.0.233487616929.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> If it was documented as deprecated and raising a deprecation warning then 3.2 is definitely far enough back to warrant removing it.

Exactly. I'm in favor of removing fromstring() and tostring() methods right now, and update 3.7 and 3.8 documentation to mention that the methods are removed in Python 3.9, not Python 4.0.

Either do it right now, or wait the beginning of the next Python 3.x release cycle. I prefer to push some incompatible changes at the beginning of dev cycles, to get enough time to measure the feedback from users.

--

Brett opened a more generic discussion about the deprecation process, since PEP 602 has been accepted:
https://mail.python.org/archives/list/python-dev at python.org/thread/BRA7G4UIGGW2X7YY55KQZBOGJEYNUV6O/

----------

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

From report at bugs.python.org  Fri Dec  6 12:50:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:50:30 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575654630.45.0.54038243289.issue38916@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +16966
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17487

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

From report at bugs.python.org  Fri Dec  6 12:52:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 17:52:50 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575654770.15.0.881667819715.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I chose to write PR 17487 even if the issue was tagged as "easy (C)", just to make sure that the change is done as soon as possible in the 3.9 dev cycle.

----------

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

From report at bugs.python.org  Fri Dec  6 12:55:43 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Dec 2019 17:55:43 +0000
Subject: [issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1
 3.x: directory not empty: Scripts\
In-Reply-To: <1571653144.99.0.203555280128.issue38544@roundup.psfhosted.org>
Message-ID: <1575654943.01.0.0163275766908.issue38544@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Fri Dec  6 13:42:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Dec 2019 18:42:46 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1575657766.09.0.0549233142501.issue33125@roundup.psfhosted.org>


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

Closing this as the work we need for support is now added. Whether we start releasing binaries from python.org is a discussion to have on python-dev and with the broader community.

Right now, I don't think the ecosystem is ready to add support (mainly because there is no CI system that can build/test easily). And most of our tooling isn't up to the task either. Until that can be improved, it's not fair to expect third party packagers to provide wheels or support the platform.

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

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

From report at bugs.python.org  Fri Dec  6 13:45:01 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Dec 2019 18:45:01 +0000
Subject: [issue33125] Windows 10 ARM64 platform support
In-Reply-To: <1521767011.97.0.467229070634.issue33125@psf.upfronthosting.co.za>
Message-ID: <1575657901.02.0.481653889115.issue33125@roundup.psfhosted.org>


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

This site seems like a pretty good aggregation of news around Windows on ARM64 devices: https://www.windows-arm.com/

Short story is, it's a real thing, but for (what I consider) obvious reasons the OSS developer experience isn't great yet.

----------

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

From report at bugs.python.org  Fri Dec  6 13:49:45 2019
From: report at bugs.python.org (Ryan Thornton)
Date: Fri, 06 Dec 2019 18:49:45 +0000
Subject: [issue38989] pip install selects 32 bit wheels for 64 bit python if
 vcvarsall.bat amd64_x86 in environment
Message-ID: <1575658185.88.0.621824601443.issue38989@roundup.psfhosted.org>


New submission from Ryan Thornton <thornto4 at gmail.com>:

## Expected Behavior

pip install should download dependencies matching the architecture of the python executable being used.

## Actual Behavior

When calling pip install from a Visual Studio command prompt configured to cross compile from x64 to x86, pip installs wheels matching the architecture of Visual Studio's cross compile target (i.e. `VSCMD_ARG_TGT_ARCH=x86`) and not the architecture of python itself (x64).

This results in a broken installation of core libraries.

## Steps to Reproduce

System Details:
Windows 10 x64
Python 3.8 x64
Visual Studio 2017 15.9.14

Environment Details:
vcvarsall.bat amd64_x86

1. "C:\Program Files\Python38\python.exe" -mvenv "test"
2. cd test\Scripts
3. pip install cffi==1.13.2

Results in the following:

> Collecting cffi
>  Using cached https://files.pythonhosted.org/packages/f8/26/5da5cafef77586e4f7a136b8a24bc81fd2cf1ecb71b6ec3998ffe78ea2cf/cffi-1.13.2-cp38-cp38-win32.whl

## Context

I think the regression was introduced here:
62dfd7d6fe11bfa0cd1d7376382c8e7b1275e38c

https://github.com/python/cpython/commit/62dfd7d6fe11bfa0cd1d7376382c8e7b1275e38c

----------
components: Distutils
messages: 357936
nosy: Ryan Thornton, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Dec  6 13:57:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 18:57:40 +0000
Subject: [issue27822] Fail to create _SelectorTransport with unbound socket
In-Reply-To: <1471776053.58.0.243290742982.issue27822@psf.upfronthosting.co.za>
Message-ID: <1575658659.99.0.711709572598.issue27822@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> In writing a simple UDP client using asyncio, I tripped over a call to getsockname() in the _SelectorTransport class in asyncio/selector_events.py. (...)

This bug has been fixed recently by:

commit 63deaa5b70108ef441c57728322da6b4321db4fc
Author: Vincent Michel <vxgmichel at gmail.com>
Date:   Tue May 7 19:18:49 2019 +0200

    bpo-31922: Do not connect UDP sockets when broadcast is allowed (GH-423)


Extract of the change:

diff --git a/Lib/asyncio/selector_events.py b/Lib/asyncio/selector_events.py
index 93b6889509..29968214f8 100644
--- a/Lib/asyncio/selector_events.py
+++ b/Lib/asyncio/selector_events.py
@@ -587,7 +587,10 @@ class _SelectorTransport(transports._FlowControlMixin,
     def __init__(self, loop, sock, protocol, extra=None, server=None):
         super().__init__(extra, loop)
         self._extra['socket'] = sock
-        self._extra['sockname'] = sock.getsockname()
+        try:
+            self._extra['sockname'] = sock.getsockname()
+        except OSError:
+            self._extra['sockname'] = None
         if 'peername' not in self._extra:
             try:
                 self._extra['peername'] = sock.getpeername()


Thanks for your contribution and your proposed patch Paul McGuire! Sorry for the late reply. I mark this change as a duplicate of bpo-31922.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Can't receive replies from multicast UDP with asyncio
versions: +Python 3.9 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Dec  6 14:08:12 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 06 Dec 2019 19:08:12 +0000
Subject: [issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1
 3.x: directory not empty: Scripts\
In-Reply-To: <1571653144.99.0.203555280128.issue38544@roundup.psfhosted.org>
Message-ID: <1575659292.05.0.737562813298.issue38544@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Not sure what's changed in this area, if anything, to cause this. Can we check if there is anti-virus software running on the buildbot box? This can sometimes hold files open for short periods while scanning for malware, causing this type of permission error fairly randomly.

----------

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

From report at bugs.python.org  Fri Dec  6 14:12:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 19:12:33 +0000
Subject: [issue38544] test_venv: test_isolation() failed on AMD64 Windows7 SP1
 3.x: directory not empty: Scripts\
In-Reply-To: <1571653144.99.0.203555280128.issue38544@roundup.psfhosted.org>
Message-ID: <1575659553.24.0.0372951705749.issue38544@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Maybe the test can replace shutil.rmtree() with test.support.rmtree() temporarily in test_venv, since test.support.rmtree() handles the anti-malwares protections by retrying and/or sleep (if I recall correctly).

----------

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

From report at bugs.python.org  Fri Dec  6 14:15:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 19:15:16 +0000
Subject: [issue37931] crash reimporting posix after Py_Finalize on mac
In-Reply-To: <1566574787.75.0.458129578699.issue37931@roundup.psfhosted.org>
Message-ID: <1575659716.43.0.167983720168.issue37931@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 723f71abf7ab0a7be394f9f7b2daa9ecdf6fb1eb by Victor Stinner (Benoit Hudson) in branch 'master':
bpo-37931: Fix crash on OSX re-initializing os.environ (GH-15428)
https://github.com/python/cpython/commit/723f71abf7ab0a7be394f9f7b2daa9ecdf6fb1eb


----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Dec  6 14:15:17 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 19:15:17 +0000
Subject: [issue37931] crash reimporting posix after Py_Finalize on mac
In-Reply-To: <1566574787.75.0.458129578699.issue37931@roundup.psfhosted.org>
Message-ID: <1575659717.57.0.360090501548.issue37931@roundup.psfhosted.org>


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


----------
pull_requests: +16967
pull_request: https://github.com/python/cpython/pull/17488

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

From report at bugs.python.org  Fri Dec  6 14:22:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 19:22:57 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575660177.26.0.233273085805.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-38897 removed usage of deprecated array.fromstring() method. Commit in master:

https://github.com/python/cpython/commit/386d00cc341b549800776b906bfc6b20ea40c7db

----------

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

From report at bugs.python.org  Fri Dec  6 14:32:39 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 06 Dec 2019 19:32:39 +0000
Subject: [issue37931] crash reimporting posix after Py_Finalize on mac
In-Reply-To: <1566574787.75.0.458129578699.issue37931@roundup.psfhosted.org>
Message-ID: <1575660759.39.0.124195122424.issue37931@roundup.psfhosted.org>


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


New changeset 836cf31a3cf468ed9598a220b8e194b366287bfe by Miss Islington (bot) in branch '3.8':
bpo-37931: Fix crash on OSX re-initializing os.environ (GH-15428)
https://github.com/python/cpython/commit/836cf31a3cf468ed9598a220b8e194b366287bfe


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

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

From report at bugs.python.org  Fri Dec  6 15:26:23 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Fri, 06 Dec 2019 20:26:23 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575663983.34.0.838718450217.issue38965@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Would it make sense to also backport this fix to the 3.6 release?

People compiling 3.6 with gcc 10 will stumble upon that.

----------
nosy: +cstratak

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

From report at bugs.python.org  Fri Dec  6 15:35:51 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Fri, 06 Dec 2019 20:35:51 +0000
Subject: [issue37096] Add large-file tests for modules using sendfile(2)
In-Reply-To: <1559200699.13.0.758657145229.issue37096@roundup.psfhosted.org>
Message-ID: <1575664551.13.0.902844530624.issue37096@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Can we reopen the issue?

Clearly this change modifies the expectations of free disk space for the temp files created by the tests.

Or at least clarify that those tests require more than 6gb of free disk space in /tmp for unix

----------

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

From report at bugs.python.org  Fri Dec  6 16:31:20 2019
From: report at bugs.python.org (Kevin Puetz)
Date: Fri, 06 Dec 2019 21:31:20 +0000
Subject: [issue38989] pip install selects 32 bit wheels for 64 bit python if
 vcvarsall.bat amd64_x86 in environment
In-Reply-To: <1575658185.88.0.621824601443.issue38989@roundup.psfhosted.org>
Message-ID: <1575667880.91.0.027081343224.issue38989@roundup.psfhosted.org>


Kevin Puetz <puetzk at puetzk.org> added the comment:

Besides the fact the MSVC's target platform isn't really related to the architecture for dependencies being installed, I'm not sure VSCMD_ARG_TGT_ARCH is an appropriate variable to look at in the first place. It doesn't seem to be at all documented, and (from looking at the implemenation) it seems to be meant as how parse_cmd.bat communicates with vcvars.bat, dotnet.bat, winsdk.bat, etc (these are all sub-programms that make up vcvarsall.bat)

I think %PLATFORM% (which generally ends up set equal to %VSCMD_ARG_TGT_ARCH% once vsdevcmd\ext\vcvars.bat has done its thing) is might be a better variable that cross-compiling should actually look at when it wants to know what architecture MSVC will compile to.

----------
nosy: +puetzk

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

From report at bugs.python.org  Fri Dec  6 16:42:19 2019
From: report at bugs.python.org (Brittany Reynoso)
Date: Fri, 06 Dec 2019 21:42:19 +0000
Subject: [issue38990] Import genericpath fails with python -S
Message-ID: <1575668539.27.0.598357359198.issue38990@roundup.psfhosted.org>


New submission from Brittany Reynoso <breynoso at fb.com>:

When running python -S, attempting to run "import genericpath" fails with an attribute error due to a circular dependency between posixpath and genericpath that's triggered when "import os" is called from within genericpath.py. 

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/fbcode/platform007/lib/python3.7/genericpath.py", line 6, in <module>
    import os
  File "/usr/local/fbcode/platform007/lib/python3.7/os.py", line 57, in <module>
    import posixpath as path
  File "/usr/local/fbcode/platform007/lib/python3.7/posixpath.py", line 130, in <module>
    splitext.__doc__ = genericpath._splitext.__doc__
AttributeError: module 'genericpath' has no attribute '_splitext'

----------
components: Library (Lib)
messages: 357947
nosy: brittanyrey
priority: normal
severity: normal
status: open
title: Import genericpath fails with python -S
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Dec  6 16:42:19 2019
From: report at bugs.python.org (Kevin Puetz)
Date: Fri, 06 Dec 2019 21:42:19 +0000
Subject: [issue38989] pip install selects 32 bit wheels for 64 bit python if
 vcvarsall.bat amd64_x86 in environment
In-Reply-To: <1575658185.88.0.621824601443.issue38989@roundup.psfhosted.org>
Message-ID: <1575668539.2.0.409419471429.issue38989@roundup.psfhosted.org>


Kevin Puetz <puetzk at puetzk.org> added the comment:

Just to link the various pieces together: I think 

https://bitbucket.org/pypa/distlib/src/2d145da7cb42590039fbd56a9ab764d5d4716a98/distlib/wheel.py#lines-53

is the place in distlib that's being breaking pip due to redefining distutils.util.get_platform() as the cross-compile target architecture  rather than the build architecture.

https://docs.python.org/3/distutils/apiref.html doesn't show it as a documented public function, but the commit Ryan linked did introduce a new get_host_plaform() that matches the old behavior; if that became public and distlib used itinstead (conditional on the python version?) that would also be a way to fix the symptom Ryan noted (pip now choosing the wrong wheel to install).

I don't know how the pieces here fit together well enough to now which side should change.

@zooba: adding you to the Cc since it was your comments at https://github.com/python/cpython/pull/11774#discussion_r254461961 that seem to have led to the decision to re-define get_platform, maybe you have some relevant context?

----------
nosy: +steve.dower

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

From report at bugs.python.org  Fri Dec  6 17:09:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2019 22:09:09 +0000
Subject: [issue38952] asyncio cannot handle Python3 IPv4Address
In-Reply-To: <1575248866.63.0.518271436447.issue38952@roundup.psfhosted.org>
Message-ID: <1575670149.75.0.711913638098.issue38952@roundup.psfhosted.org>


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

If this is a duplicate of #35019, then this issue should be closed, the original post here should be copied over, and the PR should be edited to point to the original issue, both in the title and the box below the title.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Dec  6 17:12:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2019 22:12:32 +0000
Subject: [issue38953] Untokenize and retokenize does not round-trip
In-Reply-To: <1575284774.35.0.371169137429.issue38953@roundup.psfhosted.org>
Message-ID: <1575670352.38.0.286478231514.issue38953@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/issue38953>
_______________________________________

From report at bugs.python.org  Fri Dec  6 17:18:24 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2019 22:18:24 +0000
Subject: [issue38961] Flaky detection of compiler vendor
In-Reply-To: <1575391239.52.0.258963452733.issue38961@roundup.psfhosted.org>
Message-ID: <1575670704.04.0.673740053865.issue38961@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Dec  6 17:43:52 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2019 22:43:52 +0000
Subject: [issue38974] using tkinter.filedialog.askopenfilename() freezes
 python 3.8
In-Reply-To: <1575488682.09.0.412861821421.issue38974@roundup.psfhosted.org>
Message-ID: <1575672232.08.0.305268675422.issue38974@roundup.psfhosted.org>


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

filedialog.askopenfilename returns 'Open(**options).show()'.  IDLE's File => Open (^O) calls Open and show directly.  It continues to run on all versions on my machine (and presumably those of numerous others).  I have TortoiseGit now and only recently removed TortoiseHG, so those two seem well-enough behaved.  This is almost certainly not a cpython issue, but it would be good to know where the problem lies.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Dec  6 17:47:09 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 06 Dec 2019 22:47:09 +0000
Subject: [issue38947] dataclass defaults behave inconsistently for
 init=True/init=False when default is a descriptor
In-Reply-To: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>
Message-ID: <1575672429.64.0.764172485776.issue38947@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Dec  6 17:48:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 22:48:54 +0000
Subject: [issue38965] test_stack_overflow
 (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10
In-Reply-To: <1575448401.0.0.574576942819.issue38965@roundup.psfhosted.org>
Message-ID: <1575672534.78.0.131548661687.issue38965@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Would it make sense to also backport this fix to the 3.6 release?

Sadly, 3.6 no longer accept bugfixes:
https://devguide.python.org/#status-of-python-branches

----------

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

From report at bugs.python.org  Fri Dec  6 17:53:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2019 22:53:17 +0000
Subject: [issue38975] Add direct anchors to regex syntax documentation
In-Reply-To: <1575493951.25.0.258282311971.issue38975@roundup.psfhosted.org>
Message-ID: <1575672797.33.0.208571273768.issue38975@roundup.psfhosted.org>


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

? anchors are generated automatically for headers, but I don't know what the policy might be for items within section.  It might be useful to add some subsection headers within the Regular Expression Syntax section.

----------
nosy: +serhiy.storchaka, terry.reedy

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

From report at bugs.python.org  Fri Dec  6 17:56:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2019 22:56:09 +0000
Subject: [issue38988] Killing asyncio subprocesses on timeout?
In-Reply-To: <1575654060.86.0.979877919031.issue38988@roundup.psfhosted.org>
Message-ID: <1575672969.59.0.697764765879.issue38988@roundup.psfhosted.org>


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

There have been changes to asyncio since 3.6.  I you have not, please check the 3.8 version to see if any of them are relevant to your issue.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Dec  6 17:56:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 22:56:38 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1575672998.54.0.606299023964.issue38699@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +njs, yselivanov

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

From report at bugs.python.org  Fri Dec  6 18:08:38 2019
From: report at bugs.python.org (Ella Sharakanski)
Date: Fri, 06 Dec 2019 23:08:38 +0000
Subject: [issue21820] unittest: unhelpful truncating of long strings.
In-Reply-To: <1403346886.23.0.538670310002.issue21820@psf.upfronthosting.co.za>
Message-ID: <1575673718.97.0.429856506288.issue21820@roundup.psfhosted.org>


Ella Sharakanski <ella10004 at gmail.com> added the comment:

Any news on this? I also consider this a bug.

----------
nosy: +Ella Sharakanski

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

From report at bugs.python.org  Fri Dec  6 18:10:04 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 06 Dec 2019 23:10:04 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1575673804.22.0.770460374801.issue38594@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee: docs at python -> jaraco

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

From report at bugs.python.org  Fri Dec  6 18:10:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 23:10:15 +0000
Subject: [issue38697] test.support.find_unused_port() race condition:
 test_socket fails with OSError: [Errno 98] Address already in use
In-Reply-To: <1572951685.78.0.141334829591.issue38697@roundup.psfhosted.org>
Message-ID: <1575673815.73.0.14152313328.issue38697@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

support.find_unused_port() has a race condition by design, but tests are re-run sequentially by buildbots and so the rare race condition is worked around in practice.

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

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

From report at bugs.python.org  Fri Dec  6 18:10:31 2019
From: report at bugs.python.org (Kevin Puetz)
Date: Fri, 06 Dec 2019 23:10:31 +0000
Subject: [issue38989] pip install selects 32 bit wheels for 64 bit python if
 vcvarsall.bat amd64_x86 in environment
In-Reply-To: <1575658185.88.0.621824601443.issue38989@roundup.psfhosted.org>
Message-ID: <1575673831.76.0.724232087717.issue38989@roundup.psfhosted.org>


Change by Kevin Puetz <puetzk at puetzk.org>:


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Fri Dec  6 18:39:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 23:39:15 +0000
Subject: [issue38991] Remove test.support.strip_python_stderr()
Message-ID: <1575675555.17.0.954661823697.issue38991@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Python 3.3 compiled in debug mode dumps the total number of references at exit into stderr. Something like:

$ python3.3-dbg -X showrefcount -c pass
[18563 refs, 6496 blocks]

In Python 3.4, bpo-17323 disabled this feature by default and added -X showrefcount command line option:

commit 1f8898a5916b942c86ee8716c37d2db388e7bf2f
Author: Ezio Melotti <ezio.melotti at gmail.com>
Date:   Tue Mar 26 01:59:56 2013 +0200

    #17323: The "[X refs, Y blocks]" printed by debug builds has been disabled by default.  It can be re-enabled with the `-X showrefcount` option.

test.support module still has strip_python_stderr() function to remove "[18563 refs, 6496 blocks]" from stderr, but it's now useless.

Attached PR removes the function. The PR also avoids calling str.strip().

----------
components: Tests
messages: 357955
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove test.support.strip_python_stderr()
versions: Python 3.9

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

From report at bugs.python.org  Fri Dec  6 18:41:43 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 06 Dec 2019 23:41:43 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1575675703.97.0.364688715044.issue38699@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Trio uses 65535 as the default backlog argument. There's a big comment here explaining why: https://github.com/python-trio/trio/blob/master/trio/_highlevel_open_tcp_listeners.py

This doesn't actually set the backlog to 65635; instead it tells the kernel to use the biggest backlog that it feels comfortable with (e.g. /proc/sys/net/core/somaxconn on Linux).

----------

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

From report at bugs.python.org  Fri Dec  6 18:49:42 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 06 Dec 2019 23:49:42 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1575676182.66.0.473498901125.issue38699@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Another subtlety that that code handles, and that the stdlib socket module might also want to handle: if the user passes in a custom backlog argument that's >65535, then we silently replace it with 66535 before passing it to the system. The reason is that many systems will silently truncate this value to 16 bits, so if a user explicitly passes in 65536, what they get is a backlog of 1, which is probably not what they were hoping for.

----------

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

From report at bugs.python.org  Fri Dec  6 18:53:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Dec 2019 23:53:40 +0000
Subject: [issue38991] Remove test.support.strip_python_stderr()
In-Reply-To: <1575675555.17.0.954661823697.issue38991@roundup.psfhosted.org>
Message-ID: <1575676420.71.0.484282273407.issue38991@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +16968
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17490

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

From report at bugs.python.org  Fri Dec  6 19:32:07 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Dec 2019 00:32:07 +0000
Subject: [issue38991] Remove test.support.strip_python_stderr()
In-Reply-To: <1575675555.17.0.954661823697.issue38991@roundup.psfhosted.org>
Message-ID: <1575678727.78.0.993841735463.issue38991@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

do we have any buildbots using -X showrefcount?

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

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

From report at bugs.python.org  Fri Dec  6 19:41:37 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 00:41:37 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1575679297.54.0.460890774794.issue38815@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

@koobs, FWIW, unlike for most other third-party libs, there now is a configure option to allow specifying the path to the desired OpenSSL version, actually two ways.  Either use the --with-openssl= option to ./configure. Otherwise, if pkg-config info is availble, ./configure will try to use that for OpenSSL.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Dec  6 19:42:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Dec 2019 00:42:25 +0000
Subject: [issue38991] Remove test.support.strip_python_stderr()
In-Reply-To: <1575675555.17.0.954661823697.issue38991@roundup.psfhosted.org>
Message-ID: <1575679345.89.0.128102623737.issue38991@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> do we have any buildbots using -X showrefcount?

No. What would be the purpose of such buildbot?

-X showrefcount is tested by test_cmd_line.test_showrefcount().

I ran "./python -X showrefcount -m test -j0 -r": all tests pass. (test_pty fail when run in parallel, but pass when run sequentially: bpo-38547, it's unrelated to this change).

----------

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

From report at bugs.python.org  Fri Dec  6 20:38:10 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 01:38:10 +0000
Subject: [issue38975] Add direct anchors to regex syntax documentation
In-Reply-To: <1575493951.25.0.258282311971.issue38975@roundup.psfhosted.org>
Message-ID: <1575682690.28.0.6525104036.issue38975@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mdk

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

From report at bugs.python.org  Fri Dec  6 22:09:48 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 07 Dec 2019 03:09:48 +0000
Subject: [issue38887] test_asyncio: test_pipe_handle() failed on AMD64
 Windows7 SP1 3.x
In-Reply-To: <1574371987.32.0.39878951325.issue38887@roundup.psfhosted.org>
Message-ID: <1575688188.22.0.622476075739.issue38887@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Similar past report : issue31007

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Dec  6 22:11:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 07 Dec 2019 03:11:26 +0000
Subject: [issue38990] Import genericpath fails with python -S
In-Reply-To: <1575668539.27.0.598357359198.issue38990@roundup.psfhosted.org>
Message-ID: <1575688286.87.0.814067986776.issue38990@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +brett.cannon, pitrou

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

From report at bugs.python.org  Sat Dec  7 02:05:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2019 07:05:42 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575702342.52.0.278123958215.issue38981@roundup.psfhosted.org>


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

Reopened after discussing on Python-ideas: https://mail.python.org/archives/list/python-ideas at python.org/thread/64NHNY6RD4HQWBSBV6J7XIN7UAHNTQBR/.

----------
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
type:  -> enhancement
versions: +Python 3.9

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

From report at bugs.python.org  Sat Dec  7 02:06:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2019 07:06:21 +0000
Subject: [issue9529] Make re match object iterable
In-Reply-To: <1281073264.71.0.30355123146.issue9529@psf.upfronthosting.co.za>
Message-ID: <1575702381.67.0.853145293446.issue9529@roundup.psfhosted.org>


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


----------
keywords: +easy -patch

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

From report at bugs.python.org  Sat Dec  7 04:07:51 2019
From: report at bugs.python.org (Amir Mohamadi)
Date: Sat, 07 Dec 2019 09:07:51 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575709671.89.0.167114752846.issue38979@roundup.psfhosted.org>


Amir Mohamadi <amiremohamadi at yahoo.com> added the comment:

@asvetlov I have a question! Should "contextvar_cls_getitem" function be changed? And can you please help me figure out how to change it?

----------
nosy: +Amir -DahlitzFlorian, gvanrossum, levkivskyi, yselivanov

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

From report at bugs.python.org  Sat Dec  7 04:31:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2019 09:31:53 +0000
Subject: [issue9529] Make re match object iterable
In-Reply-To: <1281073264.71.0.30355123146.issue9529@psf.upfronthosting.co.za>
Message-ID: <1575711113.02.0.774192891019.issue9529@roundup.psfhosted.org>


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


----------
keywords: +patch -easy
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Dec  7 04:32:23 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2019 09:32:23 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575711143.55.0.886310993609.issue38981@roundup.psfhosted.org>


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


----------
keywords: +easy

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

From report at bugs.python.org  Sat Dec  7 04:39:35 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Dec 2019 09:39:35 +0000
Subject: [issue35048] Can't reassign __class__ despite the assigned class
 having identical slots
In-Reply-To: <1540289238.37.0.788709270274.issue35048@psf.upfronthosting.co.za>
Message-ID: <1575711575.38.0.463517038363.issue35048@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/issue35048>
_______________________________________

From report at bugs.python.org  Sat Dec  7 04:46:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2019 09:46:42 +0000
Subject: [issue35048] Can't reassign __class__ despite the assigned class
 having identical slots
In-Reply-To: <1540289238.37.0.788709270274.issue35048@psf.upfronthosting.co.za>
Message-ID: <1575712002.64.0.167541701787.issue35048@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Dec  7 05:28:55 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 10:28:55 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575714535.48.0.906887194116.issue38979@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I think it should look like the corresponding function from multidict: https://github.com/aio-libs/multidict/blob/master/multidict/_multidict.c#L803-L808

Please note, the method definition also should be updated, see https://github.com/aio-libs/multidict/blob/master/multidict/_multidict.c#L923-L928 for inspiration.

----------

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

From report at bugs.python.org  Sat Dec  7 05:43:03 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 07 Dec 2019 10:43:03 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575715383.65.0.224528449938.issue38978@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +16969
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17491

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

From report at bugs.python.org  Sat Dec  7 06:05:12 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 11:05:12 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575716712.49.0.787610563177.issue38978@roundup.psfhosted.org>


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


New changeset dec367261e7e2bb4dd42feeb58031abed2ade683 by Miss Islington (bot) (Batuhan Ta?kaya) in branch 'master':
bpo-38978: Implement __class_getitem__ for asyncio objects (GH-17491)
https://github.com/python/cpython/commit/dec367261e7e2bb4dd42feeb58031abed2ade683


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

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

From report at bugs.python.org  Sat Dec  7 06:05:46 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:05:46 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575716746.38.0.627970420855.issue38978@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Dec  7 06:06:49 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:06:49 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575716809.04.0.890967170308.issue38978@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Done.
I think that applying the same to PathLike makes sense as well, but it deserves another issue.

----------

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

From report at bugs.python.org  Sat Dec  7 06:07:09 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:07:09 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575716829.57.0.892485733156.issue38978@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks, Batuhan!

----------

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

From report at bugs.python.org  Sat Dec  7 06:22:04 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:22:04 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1575717724.35.0.863928736838.issue38529@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 7ddcd0caa4c2e6b43265df144f59c5aa508a94f2 by Andrew Svetlov in branch 'master':
bpo-38529: Fix asyncio stream warning (GH-17474)
https://github.com/python/cpython/commit/7ddcd0caa4c2e6b43265df144f59c5aa508a94f2


----------

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

From report at bugs.python.org  Sat Dec  7 06:22:23 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 11:22:23 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1575717743.42.0.185746645864.issue38529@roundup.psfhosted.org>


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


----------
pull_requests: +16970
pull_request: https://github.com/python/cpython/pull/17492

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

From report at bugs.python.org  Sat Dec  7 06:24:07 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 11:24:07 +0000
Subject: [issue38986] Suppport TaskWakeupMethWrapper.__self__ to conform
 asyncio _format_handle logic
In-Reply-To: <1575637762.64.0.656469338348.issue38986@roundup.psfhosted.org>
Message-ID: <1575717847.68.0.977175197433.issue38986@roundup.psfhosted.org>


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


----------
pull_requests: +16971
pull_request: https://github.com/python/cpython/pull/17493

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

From report at bugs.python.org  Sat Dec  7 06:29:59 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:29:59 +0000
Subject: [issue38986] Suppport TaskWakeupMethWrapper.__self__ to conform
 asyncio _format_handle logic
In-Reply-To: <1575637762.64.0.656469338348.issue38986@roundup.psfhosted.org>
Message-ID: <1575718199.94.0.709807297242.issue38986@roundup.psfhosted.org>


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


----------
pull_requests: +16972
pull_request: https://github.com/python/cpython/pull/17494

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

From report at bugs.python.org  Sat Dec  7 06:32:08 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 Dec 2019 11:32:08 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
Message-ID: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Title: testFsum failure caused by constant folding of a float expression

Description:
------------
Python (Python 3.9.0a1+ heads/master-dirty:ea9835c5d1) is built on a Linux x86_64. This native interpreter is used to cross-compile Python (using the same source) to Android API 24. Next the installation is done locally to DESTDIR by running 'make install' with the env var DESTDIR set and the standard library modules are compiled by the native interpreter during this process.  The content of DESTDIR is then copied to an arm64 android device (Huawei FWIW). The test_math.MathTests.testFsum test fails on the android device with:

AssertionError: -4.309103330548428e+214 != -1.0

This occurs when testing '([1.7**(i+1)-1.7**i for i in range(1000)] + [-1.7**1000], -1.0)' in test_values.

Next the test_math.py file is touched on the android device to force recompilation of the module and testFsum becomes surprisingly successful.

Investigation:
--------------
The hexadecimal representation of 1.7**n on x86_64 and arm64 are:
* different for n in (10, 100, 1000)
* equal for n in [0, 9] or 11

on x86_64:
>>> 1.7**10
201.59939004489993
>>> (1.7**10).hex()
'0x1.9332e34080c95p+7'

on arm64:
>>> 1.7**10
201.59939004489996
>>> (1.7**10).hex()
'0x1.9332e34080c96p+7'

The output of the following foo.py module that has been run on x86_64 and arm64 are attached to this issue:

#######################
import math, dis

def test_fsum():
    x = [1.7**(i+1)-1.7**i for i in range(10)] + [-1.7**10]
    return x

y = test_fsum()
print(y)
print(math.fsum(y))
dis.dis(test_fsum)
#######################

The only difference between both dissasembly of test_fsum() is at bytecode 16 that loads the folded constant 1.7**10.

Conclusion:
-----------
The compilation of the expression '[1.7**(i+1)-1.7**i for i in range(1000)] + [-1.7**1000]' on x86_64 folds '1.7**1000' to 2.8113918290273277e+230 When the list comprehension (the first term of the expression) is executed on arm64, then 1.7**1000 is evaluated as 2.8113918290273273e+230.  On arm64 1.7**1000 - 2.8113918290273277e+230 = -4.309103330548428e+214, hence the AssertionError above.

This is confirmed by changing testFsum to prevent constant folding by replacing 1000 in the testFsum expression with a variable whose value is 1000.  In that case the test_math module compiled on x86_64 is successful on arm64. This could be a fix for this issue unless this fix would be hiding another problem such as .pyc files portability across different platforms and my knowledge of IEEE 754 is too superficial to answer that point.

----------
components: Tests
files: foo.x86_64
messages: 357969
nosy: tim.peters, vstinner, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: testFsum failure caused by constant folding of a float expression
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48762/foo.x86_64

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

From report at bugs.python.org  Sat Dec  7 06:34:20 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 Dec 2019 11:34:20 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575718460.32.0.82003842617.issue38992@roundup.psfhosted.org>


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


Added file: https://bugs.python.org/file48763/foo.arm64

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

From report at bugs.python.org  Sat Dec  7 06:40:00 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 11:40:00 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1575718800.69.0.676081379127.issue38529@roundup.psfhosted.org>


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


New changeset 7fde4f446a3dcfed780a38fbfcd7c0b4d9d73b93 by Miss Islington (bot) in branch '3.8':
bpo-38529: Fix asyncio stream warning (GH-17474)
https://github.com/python/cpython/commit/7fde4f446a3dcfed780a38fbfcd7c0b4d9d73b93


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

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

From report at bugs.python.org  Sat Dec  7 06:40:47 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:40:47 +0000
Subject: [issue38529] Python 3.8 improperly warns about closing properly
 closed streams
In-Reply-To: <1571510429.0.0.996597968813.issue38529@roundup.psfhosted.org>
Message-ID: <1575718847.26.0.443640458295.issue38529@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Dec  7 06:50:58 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:50:58 +0000
Subject: [issue38986] Suppport TaskWakeupMethWrapper.__self__ to conform
 asyncio _format_handle logic
In-Reply-To: <1575637762.64.0.656469338348.issue38986@roundup.psfhosted.org>
Message-ID: <1575719458.2.0.695075262428.issue38986@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Dec  7 06:52:39 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 11:52:39 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575719559.57.0.806805004577.issue37404@roundup.psfhosted.org>


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


New changeset 892f9e0777f262d366d4747a54c33a1c15a49da6 by Miss Islington (bot) (idomic) in branch 'master':
 bpo-37404: Raising value error if an SSLSocket is passed to asyncio functions (GH-16457)
https://github.com/python/cpython/commit/892f9e0777f262d366d4747a54c33a1c15a49da6


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

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

From report at bugs.python.org  Sat Dec  7 06:52:50 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 11:52:50 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575719570.43.0.871225072133.issue37404@roundup.psfhosted.org>


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


----------
pull_requests: +16973
pull_request: https://github.com/python/cpython/pull/17495

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

From report at bugs.python.org  Sat Dec  7 06:54:04 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 11:54:04 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575719644.55.0.495538221466.issue37404@roundup.psfhosted.org>


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


----------
pull_requests: +16974
pull_request: https://github.com/python/cpython/pull/17496

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

From report at bugs.python.org  Sat Dec  7 06:57:12 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 07 Dec 2019 11:57:12 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575719832.76.0.899988226264.issue38992@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sat Dec  7 07:44:24 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 12:44:24 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575722664.2.0.0618188177485.issue37404@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 930cef2770b641f49e69b67840daaa53b65cd0e0 by Andrew Svetlov in branch '3.8':
[3.8] bpo-37404: Raising value error if an SSLSocket is passed to asyncio functions (GH-16457) (#17496)
https://github.com/python/cpython/commit/930cef2770b641f49e69b67840daaa53b65cd0e0


----------

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

From report at bugs.python.org  Sat Dec  7 07:45:10 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 12:45:10 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575722710.73.0.518542110539.issue37404@roundup.psfhosted.org>


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


New changeset a85066df9423d381e6b233469b00db55563a9f80 by Miss Islington (bot) in branch '3.7':
bpo-37404: Raising value error if an SSLSocket is passed to asyncio functions (GH-16457)
https://github.com/python/cpython/commit/a85066df9423d381e6b233469b00db55563a9f80


----------

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

From report at bugs.python.org  Sat Dec  7 07:45:27 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 12:45:27 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575722727.26.0.618375600118.issue37404@roundup.psfhosted.org>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Dec  7 07:45:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2019 12:45:27 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575722727.6.0.387138880267.issue38992@roundup.psfhosted.org>


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


----------
nosy: +lemburg, mark.dickinson, rhettinger, stutzbach

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

From report at bugs.python.org  Sat Dec  7 07:53:16 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 12:53:16 +0000
Subject: [issue38652] Remove/update provisional note for
 asyncio.BufferedProtocol
In-Reply-To: <1572502481.2.0.695475270667.issue38652@roundup.psfhosted.org>
Message-ID: <1575723196.44.0.687380868326.issue38652@roundup.psfhosted.org>


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


New changeset 4443450fdaf248427cf4a00a6ee36229e6402ec6 by Miss Islington (bot) (Anj-A) in branch 'master':
bpo-38652: Remove provisional note for asyncio.BufferedProtocol (GH-17047)
https://github.com/python/cpython/commit/4443450fdaf248427cf4a00a6ee36229e6402ec6


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

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

From report at bugs.python.org  Sat Dec  7 07:54:05 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 07 Dec 2019 12:54:05 +0000
Subject: [issue38652] Remove/update provisional note for
 asyncio.BufferedProtocol
In-Reply-To: <1572502481.2.0.695475270667.issue38652@roundup.psfhosted.org>
Message-ID: <1575723245.8.0.270730720939.issue38652@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Dec  7 08:10:38 2019
From: report at bugs.python.org (Amir Mohamadi)
Date: Sat, 07 Dec 2019 13:10:38 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575724238.91.0.785440142751.issue38979@roundup.psfhosted.org>


Change by Amir Mohamadi <amiremohamadi at yahoo.com>:


----------
keywords: +patch
pull_requests: +16975
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17497

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

From report at bugs.python.org  Sat Dec  7 08:24:12 2019
From: report at bugs.python.org (AVicennA)
Date: Sat, 07 Dec 2019 13:24:12 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
Message-ID: <1575725052.32.0.828064495717.issue38993@roundup.psfhosted.org>


Change by AVicennA <tural.jalilov.92 at gmail.com>:


----------
components: Library (Lib)
files: cProfiling.txt
nosy: AvicennA
priority: normal
severity: normal
status: open
title: cProfile behaviour issue with decorator and math.factorial() lib.
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48764/cProfiling.txt

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

From report at bugs.python.org  Sat Dec  7 08:31:59 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 07 Dec 2019 13:31:59 +0000
Subject: [issue25160] Stop using deprecated imp module;
 imp should now emit a real DeprecationWarning
In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za>
Message-ID: <1575725519.24.0.829984146241.issue25160@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@vstinner 

> Tools/importbench/importbench.py:10:import imp
> I think that it's fine to keep imp there. 

Any reason to keep imp there? We can just port it to sole importlib (it already uses it in some places)

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sat Dec  7 09:14:45 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 07 Dec 2019 14:14:45 +0000
Subject: [issue29636] Specifying indent in the json.tool command
In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za>
Message-ID: <1575728085.96.0.460351200945.issue29636@roundup.psfhosted.org>


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


New changeset 15fb7fa88187f5841088721a43609bffe64a8dc7 by Inada Naoki (Daniel Himmelstein) in branch 'master':
bpo-29636: json.tool: Add document for indentation options. (GH-17482)
https://github.com/python/cpython/commit/15fb7fa88187f5841088721a43609bffe64a8dc7


----------

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

From report at bugs.python.org  Sat Dec  7 10:49:04 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 07 Dec 2019 15:49:04 +0000
Subject: [issue38978] Implement __class_getitem__ for Future, Task, Queue
In-Reply-To: <1575550403.72.0.0854877987028.issue38978@roundup.psfhosted.org>
Message-ID: <1575733744.76.0.793458520145.issue38978@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> I think that applying the same to PathLike makes sense as well, but it deserves another issue.

Yes, it looks like they are using that in typeshed. I'm opening another issue with a patch. Thanks for reminding that

----------

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

From report at bugs.python.org  Sat Dec  7 10:57:34 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 07 Dec 2019 15:57:34 +0000
Subject: [issue38994] Implement __class_getitem__ for PathLike
Message-ID: <1575734254.5.0.717990589072.issue38994@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

Typeshed already using __class_getitem__ syntax for PathLike
https://github.com/python/typeshed/search?q=PathLike&unscoped_q=PathLike

----------
components: Library (Lib)
messages: 357978
nosy: BTaskaya, asvetlov
priority: normal
severity: normal
status: open
title: Implement __class_getitem__ for PathLike
versions: Python 3.9

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

From report at bugs.python.org  Sat Dec  7 11:04:04 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 07 Dec 2019 16:04:04 +0000
Subject: [issue38994] Implement __class_getitem__ for PathLike
In-Reply-To: <1575734254.5.0.717990589072.issue38994@roundup.psfhosted.org>
Message-ID: <1575734644.31.0.112894289077.issue38994@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +16976
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17498

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

From report at bugs.python.org  Sat Dec  7 11:59:40 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 16:59:40 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1575737980.49.0.11357392923.issue38820@roundup.psfhosted.org>


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


New changeset 2b7de6696bf2f924cd2cd9ff0a539c8aa37c6244 by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-38820: OpenSSL 3.0.0 compatibility. (GH-17190)
https://github.com/python/cpython/commit/2b7de6696bf2f924cd2cd9ff0a539c8aa37c6244


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

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

From report at bugs.python.org  Sat Dec  7 11:59:49 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 16:59:49 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1575737989.37.0.0503922014687.issue38820@roundup.psfhosted.org>


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


----------
pull_requests: +16977
pull_request: https://github.com/python/cpython/pull/17499

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

From report at bugs.python.org  Sat Dec  7 11:59:55 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 16:59:55 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1575737995.96.0.375878444244.issue38820@roundup.psfhosted.org>


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


----------
pull_requests: +16978
pull_request: https://github.com/python/cpython/pull/17500

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

From report at bugs.python.org  Sat Dec  7 12:20:31 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 17:20:31 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1575739231.32.0.560915174182.issue38820@roundup.psfhosted.org>


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


New changeset 9d3cacd5901f8fbbc4f8b78fc35abad01a0e6546 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-38820: OpenSSL 3.0.0 compatibility. (GH-17190) (GH-17499)
https://github.com/python/cpython/commit/9d3cacd5901f8fbbc4f8b78fc35abad01a0e6546


----------

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

From report at bugs.python.org  Sat Dec  7 12:20:46 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 07 Dec 2019 17:20:46 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1575739246.52.0.467889508801.issue38820@roundup.psfhosted.org>


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


New changeset a197f8aa7493e66bc54c3db8f796d00cef1c3042 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-38820: OpenSSL 3.0.0 compatibility. (GH-17190) (GH-17500)
https://github.com/python/cpython/commit/a197f8aa7493e66bc54c3db8f796d00cef1c3042


----------

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

From report at bugs.python.org  Sat Dec  7 13:04:07 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sat, 07 Dec 2019 18:04:07 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575741847.06.0.774183067212.issue38981@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

Thanks Serhiy, 

Here is a rough idea of how many places would be touched by renaming in the `re` module:

https://github.com/Carreau/cpython/commit/59e4c5150c842f849ff3a9ba8a94df1df7a5eb1c (50 additions and 42 deletions.). 

I haven't found any places that need changes in the C code, and need to polish documentation, rebuild and run the test suite before sending a PR.

----------

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

From report at bugs.python.org  Sat Dec  7 13:56:57 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Dec 2019 18:56:57 +0000
Subject: [issue35048] Can't reassign __class__ despite the assigned class
 having identical slots
In-Reply-To: <1540289238.37.0.788709270274.issue35048@psf.upfronthosting.co.za>
Message-ID: <1575745017.12.0.86778120237.issue35048@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The relevant logic is in the compatible_for_assignment() function on line 3972 in Objects/typeobject.c.

After checking that the tp_free slots are the same, it proceeds as follows:

    /*
     It's tricky to tell if two arbitrary types are sufficiently compatible as
     to be interchangeable; e.g., even if they have the same tp_basicsize, they
     might have totally different struct fields. It's much easier to tell if a
     type and its supertype are compatible; e.g., if they have the same
     tp_basicsize, then that means they have identical fields. So to check
     whether two arbitrary types are compatible, we first find the highest
     supertype that each is compatible with, and then if those supertypes are
     compatible then the original types must also be compatible.
    */

So what is happening is that "class a" and "class b" aren't being directly compared to one another.  Instead, they are being compared to their parent "dict".   Since *dict* doesn't have __dict__ or __weakref__, "a" and "b" are deemed to have incompatible layouts.   See lines 3951 to 3954 in same_slots_added() in Objects/typeobject.c.

----------
nosy: +benjamin.peterson, pitrou

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

From report at bugs.python.org  Sat Dec  7 15:10:28 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 20:10:28 +0000
Subject: [issue22367] Add open_file_descriptor parameter to fcntl.lockf() (use
 the new F_OFD_SETLK flag)
In-Reply-To: <1410207529.54.0.778133775349.issue22367@psf.upfronthosting.co.za>
Message-ID: <1575749428.8.0.07049865638.issue22367@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

It looks like the only thing left to do yet for this issue is to finish the review of and merge the PR that actually implements the new parameter.  Removing the Deferred Blocker status and deselecting releases other than 3.9.

----------
priority: deferred blocker -> 
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Dec  7 15:33:50 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 20:33:50 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575750829.99.0.432226125708.issue37228@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Where are we with this?  The deadline for 3.8.1 and 3.7.6 is coming up in a few days.

----------

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

From report at bugs.python.org  Sat Dec  7 15:37:37 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Dec 2019 20:37:37 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575751057.76.0.187266052446.issue38981@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Strictly speaking not all of those _need_ to be touched given the old name is always going to exist for backwards compatibility.  But I agree that we should update them as part of this regardless.

I'd go forward with a PR.

The only fallout I expect a change like this to have on users is in the very odd test scenario where someone has hardcoded the error name in a string.  That is rare, especially for an re.error which is generally not an expected exception.

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

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

From report at bugs.python.org  Sat Dec  7 15:39:18 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 20:39:18 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575751158.24.0.158102111815.issue34776@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

>  I'll elevate the status so that I don't forget before 3.8.1.

Ping, 3.8.1 cutoff is coming up very soon.

----------

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

From report at bugs.python.org  Sat Dec  7 15:45:10 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 20:45:10 +0000
Subject: [issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header
 Injection (follow-up of CVE-2016-5699)
In-Reply-To: <1495638091.75.0.96439752743.issue30458@psf.upfronthosting.co.za>
Message-ID: <1575751510.65.0.09557408753.issue30458@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

What is the status of this issue?  Now that Issue38576 has been opened to cover the host address part, can this issue be closed or downgraded?  Should Issue38576 be a release blocker?

----------

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

From report at bugs.python.org  Sat Dec  7 15:48:28 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Dec 2019 20:48:28 +0000
Subject: [issue30064] BaseSelectorEventLoop.sock_{recv,
 sendall}() don't remove their callbacks when canceled
In-Reply-To: <1492073709.93.0.33740565749.issue30064@psf.upfronthosting.co.za>
Message-ID: <1575751708.58.0.144940952444.issue30064@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> I'll elevate the status so that we don't forget before 3.8.1 is too close

Andrew, Yury: ping. 3.8.1 cutoff is approaching.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Dec  7 16:29:31 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sat, 07 Dec 2019 21:29:31 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575754171.42.0.436705363655.issue38981@roundup.psfhosted.org>


Change by Matthias Bussonnier <bussonniermatthias at gmail.com>:


----------
keywords: +patch
pull_requests: +16979
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17501

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

From report at bugs.python.org  Sat Dec  7 18:32:04 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 07 Dec 2019 23:32:04 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575761524.11.0.95544104138.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Where are we with this?  The deadline for 3.8.1 and 3.7.6 is coming up in a few days.

I believe we're just waiting on review and additional feedback on GH-17311, which implements Antoine's proposal. The only remaining component I can think of is the "What's New" entry, but I was planning on doing that in a separate PR so that we could get the security fix out there first (and simplify the merge conflicts for the backports).

----------

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

From report at bugs.python.org  Sat Dec  7 20:04:55 2019
From: report at bugs.python.org (sush)
Date: Sun, 08 Dec 2019 01:04:55 +0000
Subject: [issue38995] reverse search (ctrl-r) doest not work
Message-ID: <1575767095.84.0.787675686179.issue38995@roundup.psfhosted.org>


New submission from sush <sushsada at gmail.com>:

On my MacOS Mojave 10.14.6 (18G103), after upgrading python to python 3.8, the ctrl-r on the python interpreter does not work.

Here is the working python 3.7 version:
```
$ python3.7 --version 
Python 3.7.3
$ python3.7     
Python 3.7.3 (default, Mar 27 2019, 09:23:15) 
[Clang 10.0.1 (clang-1001.0.46.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 10
(reverse-i-search)`a': a = 10
``` 
Note that I pressed 'ctrl-r' on my keyboard to bring up the 'reverse-i-search'.

On python3.8, ctrl-r has no response from the interpreter:
```
$ python3.8 --version
Python 3.8.0
$ python3.8          
Python 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 10
>>> 
```

Interestingly, the ~/.python_history files seems to be updated. Also, when I enter the 'UP' key, the older command comes up. Just that ctrl-r doesn't work.

Here is the output showing that python_history files is being written to:
```
$ rm  ~/.python_history  
$ python3.8               
Python 3.8.0 (v3.8.0:fa919fdf25, Oct 14 2019, 10:23:27) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 33
>>> ^D
$ cat  ~/.python_history 
_HiStOrY_V2_
a\040=\04033
```

----------
components: Interpreter Core
messages: 357991
nosy: sush
priority: normal
severity: normal
status: open
title: reverse search (ctrl-r) doest not work
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Dec  7 23:40:34 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Dec 2019 04:40:34 +0000
Subject: [issue38995] reverse search (ctrl-r) doest not work
In-Reply-To: <1575767095.84.0.787675686179.issue38995@roundup.psfhosted.org>
Message-ID: <1575780034.49.0.37776943686.issue38995@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Most likely what is happening is that the two Python instances you are using are linked to different versions of the external readline library.  From the version information, it's clear that you are using the Python 3.8.0 from the python.org macOS installer.  That Python uses the macOS-supplied BSD editline (AKA libedit) for readline functionality.  The Python 3.7.3 you have is not from python.org and based on the prompt it looks like it was linked with a version of GNU readline which probably does bind ^R to the reverse search function by default.  As described in the Python Library Reference page for readline (https://docs.python.org/3/library/readline.html), both GNU readline and BSD editline can be tailored via configuration files; GNU readline uses ~/.inputrc while BSD editline uses ~/.editrc.

On macOS, the available configuration commands for editline are described in the man page for editrc:

man 5 editrc

In particular, you should be able to enable editline's reverse search functionality by adding the following line to ~/.editrc:

bind ^R em-inc-search-prev

where ^R is two characters, not the single character CTRL-R.

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Dec  7 23:46:03 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Dec 2019 04:46:03 +0000
Subject: [issue38987] 3.8.0 on GNU/Linux fails to find shared library
In-Reply-To: <1575652752.94.0.770020872085.issue38987@roundup.psfhosted.org>
Message-ID: <1575780363.75.0.215892659995.issue38987@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +doko

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

From report at bugs.python.org  Sun Dec  8 00:56:27 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 08 Dec 2019 05:56:27 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575784587.4.0.0490229503014.issue38698@roundup.psfhosted.org>


Change by Abhilash Raj <raj.abhilash1 at gmail.com>:


----------
pull_requests: +16980
pull_request: https://github.com/python/cpython/pull/17503

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

From report at bugs.python.org  Sun Dec  8 01:29:36 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 08 Dec 2019 06:29:36 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1575786576.66.0.951810351643.issue38708@roundup.psfhosted.org>


Change by Abhilash Raj <raj.abhilash1 at gmail.com>:


----------
keywords: +patch
pull_requests: +16981
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17504

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

From report at bugs.python.org  Sun Dec  8 02:38:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 07:38:22 +0000
Subject: [issue38991] Remove test.support.strip_python_stderr()
In-Reply-To: <1575675555.17.0.954661823697.issue38991@roundup.psfhosted.org>
Message-ID: <1575790702.07.0.201612422893.issue38991@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 6cac1136665b70f72db291b95876d7affcf1d2db by Victor Stinner in branch 'master':
bpo-38991: Remove test.support.strip_python_stderr() (GH-17490)
https://github.com/python/cpython/commit/6cac1136665b70f72db291b95876d7affcf1d2db


----------

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

From report at bugs.python.org  Sun Dec  8 02:38:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 07:38:43 +0000
Subject: [issue38991] Remove test.support.strip_python_stderr()
In-Reply-To: <1575675555.17.0.954661823697.issue38991@roundup.psfhosted.org>
Message-ID: <1575790723.5.0.782716931369.issue38991@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Sun Dec  8 02:40:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 07:40:18 +0000
Subject: [issue38852] test_recursion_limit in test_threading crashes with
 SIGSEGV on android
In-Reply-To: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>
Message-ID: <1575790818.12.0.859726613694.issue38852@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 00ada2c1d57c5b8b468bad32ff24fa14113ae5c7 by Victor Stinner (xdegaye) in branch 'master':
bpo-38852: Set thread stack size to 8 Mb for debug builds on android platforms (GH-17337)
https://github.com/python/cpython/commit/00ada2c1d57c5b8b468bad32ff24fa14113ae5c7


----------
nosy: +vstinner

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

From report at bugs.python.org  Sun Dec  8 03:37:02 2019
From: report at bugs.python.org (sush)
Date: Sun, 08 Dec 2019 08:37:02 +0000
Subject: [issue38995] reverse search (ctrl-r) doest not work
In-Reply-To: <1575767095.84.0.787675686179.issue38995@roundup.psfhosted.org>
Message-ID: <1575794222.13.0.5138337694.issue38995@roundup.psfhosted.org>


sush <sushsada at gmail.com> added the comment:

That worked, thanks for the prompt help.

----------

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

From report at bugs.python.org  Sun Dec  8 03:47:20 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 08 Dec 2019 08:47:20 +0000
Subject: [issue33880] namedtuple should use NFKD to find duplicate members
In-Reply-To: <1529169153.27.0.56676864532.issue33880@psf.upfronthosting.co.za>
Message-ID: <1575794840.12.0.485483652185.issue33880@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Hey @rhettinger, what is the status of this issue? Is there a consensus about fixing it or can this issue be closed?

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  8 06:36:06 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 11:36:06 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575804966.59.0.428079938644.issue38979@roundup.psfhosted.org>


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


New changeset 28c91631c24e53713ad0e8a2bbae716373f5e53d by Miss Islington (bot) (AMIR) in branch 'master':
bpo-38979: fix ContextVar "__class_getitem__" method (GH-17497)
https://github.com/python/cpython/commit/28c91631c24e53713ad0e8a2bbae716373f5e53d


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

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

From report at bugs.python.org  Sun Dec  8 06:36:33 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 11:36:33 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575804993.26.0.86109480122.issue38979@roundup.psfhosted.org>


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


----------
pull_requests: +16982
pull_request: https://github.com/python/cpython/pull/17505

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

From report at bugs.python.org  Sun Dec  8 06:36:40 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 11:36:40 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575805000.34.0.715734508777.issue38979@roundup.psfhosted.org>


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


----------
pull_requests: +16983
pull_request: https://github.com/python/cpython/pull/17506

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

From report at bugs.python.org  Sun Dec  8 06:53:11 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 11:53:11 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575805991.91.0.0504599711898.issue38979@roundup.psfhosted.org>


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


New changeset 9baa870c27b54c26f9dd292c26936b70bdb64a06 by Miss Islington (bot) in branch '3.7':
bpo-38979: fix ContextVar "__class_getitem__" method (GH-17497)
https://github.com/python/cpython/commit/9baa870c27b54c26f9dd292c26936b70bdb64a06


----------

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

From report at bugs.python.org  Sun Dec  8 07:11:35 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2019 12:11:35 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1575807095.58.0.402010319248.issue38021@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Removing 3.9 from the target versions, as similar to other platform tag improvements, emulation on older release versions will be the domain of cross-version libraries, rather than changing the standard library in a maintenance.

----------
versions:  -Python 3.8

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

From report at bugs.python.org  Sun Dec  8 07:25:10 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 12:25:10 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575807910.76.0.222731713698.issue38979@roundup.psfhosted.org>


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


----------
pull_requests: +16984
pull_request: https://github.com/python/cpython/pull/17507

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

From report at bugs.python.org  Sun Dec  8 07:45:59 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2019 12:45:59 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1575809159.22.0.248525320226.issue38021@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There's a compatibility problem with changing the AIX distutils platform prefix from aix to AIX: any existing code that does "distutils.get_platform().startswith('aix')" will break. (There isn't any code in the standard library that does that, it all checks sys.platform() instead, but it's a reasonable assumption that there's going to be code in the wild that does a prefix check on the distutils API output).

So I think we'll want to make the distinction between the two formats based on the number of hyphens they contain, rather than changing the prefix.

I *haven't* made that change directly to the PR myself, as I want to give you a chance to consider the question first, but I do think it's a required compatibility improvement before we move ahead with this.

----------

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

From report at bugs.python.org  Sun Dec  8 07:49:11 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 12:49:11 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575809351.34.0.902588396742.issue38979@roundup.psfhosted.org>


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


New changeset 960fca1a5887a277fd6031cf4c4b6fb31b08ebf5 by Miss Islington (bot) in branch '3.8':
bpo-38979: fix ContextVar "__class_getitem__" method (GH-17497)
https://github.com/python/cpython/commit/960fca1a5887a277fd6031cf4c4b6fb31b08ebf5


----------

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

From report at bugs.python.org  Sun Dec  8 07:49:21 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 08 Dec 2019 12:49:21 +0000
Subject: [issue38979] ContextVar[str] should return ContextVar class, not None
In-Reply-To: <1575551058.99.0.903743507965.issue38979@roundup.psfhosted.org>
Message-ID: <1575809361.8.0.627099716096.issue38979@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Dec  8 08:32:11 2019
From: report at bugs.python.org (Arno-Can Uestuensoez)
Date: Sun, 08 Dec 2019 13:32:11 +0000
Subject: [issue38996] introduction of default values for collection.namedtuple
Message-ID: <1575811931.27.0.501884177047.issue38996@roundup.psfhosted.org>


New submission from Arno-Can Uestuensoez <acue.opensource at gmail.com>:

Hello,
I had the requirement to make excessive use of named tuples in an extended way. The applications are variable data sets with optional items. Typical in protocol dat a units, or e.g. mixed abstract filesystem types for heterogeneous file system types including URL and UNC.

As I saw the required changes are a couple of lines which I see as harmless. The implementation is available for Python2.7 and Python3.5+ in the project namedtupledefs, which is the patched code extracted from the *collections*.

The detailed descriptions for both versions are available at:
Python3: https://namedtupledefs3.sourceforge.io/
Python3: https://namedtupledefs.sourceforge.io/
Python2: https://namedtupledefs2.sourceforge.io/

Checked in PyPi + Sourceforge + github - the links are in the documents.

https://github.com/ArnoCan/namedtupledefs3/
https://github.com/ArnoCan/namedtupledefs2/
https://github.com/ArnoCan/namedtupledefs/

https://pypi.org/project/namedtupledefs[23]/

My proposal is to introduce the changes. It would be great for Python2.7 too, before the EOL.

WKR

WKR

----------
components: Library (Lib)
files: namedtupled-uml-patches.jpg
messages: 358002
nosy: acue
priority: normal
severity: normal
status: open
title: introduction of default values for collection.namedtuple
type: enhancement
versions: Python 2.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48765/namedtupled-uml-patches.jpg

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

From report at bugs.python.org  Sun Dec  8 09:52:12 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 Dec 2019 14:52:12 +0000
Subject: [issue38996] introduction of default values for collection.namedtuple
In-Reply-To: <1575811931.27.0.501884177047.issue38996@roundup.psfhosted.org>
Message-ID: <1575816732.62.0.0396296522009.issue38996@roundup.psfhosted.org>


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

Is there something that your module can do that typing.NamedTuple can't do?

This won't be added to 2.7: 3.9 would be the first possible version to add a feature to.

----------
assignee:  -> rhettinger
nosy: +eric.smith, rhettinger
versions:  -Python 2.7, Python 3.8

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

From report at bugs.python.org  Sun Dec  8 10:08:21 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 08 Dec 2019 15:08:21 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1575809159.22.0.248525320226.issue38021@roundup.psfhosted.org>
Message-ID: <48148a0e-e117-d888-e689-f6617e32d1ba@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Well, I certainly had not considered people would be using
distutils.get_platform().startswith('aix') as I have, in my limited
reading, only seen sys.platform.startswith("aix"). Likewise, do not want
to break things.

I thought this was easier to grasp than my first idea: e.g., tag[-2:] in
["32", "64"].

I'll start counting hypens, but am also curious about what is good/bad
about looking how the string ends, e.g., would there be a clear
performance difference?

Many thanks for the review!

On 12/8/2019 1:45 PM, Nick Coghlan wrote:
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> There's a compatibility problem with changing the AIX distutils platform prefix from aix to AIX: any existing code that does "distutils.get_platform().startswith('aix')" will break. (There isn't any code in the standard library that does that, it all checks sys.platform() instead, but it's a reasonable assumption that there's going to be code in the wild that does a prefix check on the distutils API output).
>
> So I think we'll want to make the distinction between the two formats based on the number of hyphens they contain, rather than changing the prefix.
>
> I *haven't* made that change directly to the PR myself, as I want to give you a chance to consider the question first, but I do think it's a required compatibility improvement before we move ahead with this.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38021>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Dec  8 10:25:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 08 Dec 2019 15:25:33 +0000
Subject: [issue38996] introduction of default values for collection.namedtuple
In-Reply-To: <1575811931.27.0.501884177047.issue38996@roundup.psfhosted.org>
Message-ID: <1575818733.12.0.834015735319.issue38996@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is it different from the defaults parameter added in 3.7 with https://github.com/python/cpython/commit/3948207c610e931831828d33aaef258185df31db . The linked pypi package seems to do the same thing.

----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Dec  8 10:35:12 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 15:35:12 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
Message-ID: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>


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

Similar to https://bugs.python.org/issue38962, test__xxsubinterpreters test_atexit test_capi test_threading are leaking references. Example:

https://buildbot.python.org/all/#/builders/158/builds/10
https://buildbot.python.org/all/#/builders/16/builds/11
https://buildbot.python.org/all/#/builders/157/builds/11

    test__xxsubinterpreters test_atexit test_capi test_threading
== Tests result: FAILURE then FAILURE ==
386 tests OK.
10 slowest tests:
- test_multiprocessing_spawn: 26 min 23 sec
- test_mailbox: 23 min 17 sec
- test_asyncio: 20 min 25 sec
- test_venv: 14 min 54 sec
- test_concurrent_futures: 13 min 35 sec
- test_zipfile: 11 min 10 sec
- test_regrtest: 9 min 34 sec
- test_distutils: 9 min 19 sec
- test_compileall: 9 min 9 sec
- test_lib2to3: 5 min 52 sec
4 tests failed:
    test__xxsubinterpreters test_atexit test_capi test_threading

----------
assignee: pablogsal
components: Tests
messages: 358006
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters test_atexit test_capi test_threading are leaking references
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun Dec  8 10:35:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 15:35:36 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575819336.63.0.681163486143.issue38997@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Bisecting points to:

commit 81fe5bd3d78f9bb955f8255404d99df27a31c36a
Author: Victor Stinner <vstinner at python.org>
Date:   Fri Dec 6 02:43:30 2019 +0100

    bpo-38858: new_interpreter() reuses _PySys_Create() (GH-17481)
    
    new_interpreter() now calls _PySys_Create() to create a new sys
    module isolated from the main interpreter. It now calls
    _PySys_InitCore() and _PyImport_FixupBuiltin().
    
    init_interp_main() now calls _PySys_InitMain().

----------

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

From report at bugs.python.org  Sun Dec  8 10:36:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 15:36:17 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575819377.95.0.272470748243.issue38997@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Per or policy, I will initiate the revert of the commit (and any dependent commit) and will merge if an alternative fix is not done in 1-2 days.

----------

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

From report at bugs.python.org  Sun Dec  8 10:37:31 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 15:37:31 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575819451.84.0.647716105822.issue38997@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +16985
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17509

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

From report at bugs.python.org  Sun Dec  8 10:39:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 15:39:36 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575819576.81.0.34550329192.issue38997@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I will try to work on an alternative fix meanwhile, but I need to search for what exactly is leaking first.

----------

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

From report at bugs.python.org  Sun Dec  8 10:54:28 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 15:54:28 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
Message-ID: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>


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

Please, could you write a description to this issue here instead of the attached file?

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

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

From report at bugs.python.org  Sun Dec  8 11:02:29 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 16:02:29 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575820949.89.0.629933355754.issue38992@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Sun Dec  8 11:37:21 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 08 Dec 2019 16:37:21 +0000
Subject: [issue30064] BaseSelectorEventLoop.sock_{recv,
 sendall}() don't remove their callbacks when canceled
In-Reply-To: <1492073709.93.0.33740565749.issue30064@psf.upfronthosting.co.za>
Message-ID: <1575823041.31.0.0737945344707.issue30064@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Not sure if failed uvloop tests are correct.
The scenario is like the following:
1. Suppose we have an unblocking socket connected to peer.
2. Create a task for reading data: 
  task = asyncio.create_task(loop.sock_read(sock, 1))
 Note, the task is not started yet.
3. Just after it, cancel the task without waiting for the actual cancellation
  task.cancel()
4. Finally, read from the socket again:
  data = await loop.sock_read(sock, 1)

If I put context switch (await asyncio.sleep(0)) between 3) and 4) *or* replace direct sock_read() call in 4) with creation a task (data = await asyncio.create_task(loop.sock_read(sock, 1))) the cancellation of former read is performed and test passes.

I very doubt if any sane code is organizing like this test: start delayed reading, cancel it and read again.

The worse, neither previous not current sock_read() implementation doesn't prevent the concurrent reading which basically delivers data in an unpredictable order. Honestly, I'm not sure if we need to provide the concurrency guarantee for such low-level functions.  The code built on top of these low-level primitives should handle the cuncurrent access problem IMHO.

----------

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

From report at bugs.python.org  Sun Dec  8 11:46:58 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 08 Dec 2019 16:46:58 +0000
Subject: [issue38242] Revert the new asyncio Streams API
In-Reply-To: <1569020325.08.0.390897413838.issue38242@roundup.psfhosted.org>
Message-ID: <1575823618.4.0.36433312676.issue38242@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Dec  8 12:26:38 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 08 Dec 2019 17:26:38 +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: <1575825998.57.0.846838687731.issue35805@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Closing this since it has been fixed in Python 3.8.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions:  -Python 3.7

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

From report at bugs.python.org  Sun Dec  8 12:51:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Dec 2019 17:51:19 +0000
Subject: [issue33880] namedtuple should use NFKD to find duplicate members
In-Reply-To: <1529169153.27.0.56676864532.issue33880@psf.upfronthosting.co.za>
Message-ID: <1575827479.46.0.624723394395.issue33880@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking as closed for the reasons listed above.

Other thoughts:
* In the class form with types.NamedTuple, no error is raised.
* In the function form with collections.namedtuple, the various
  TypeErrors and ValueErrors are just courtesy checks
  intended to provide slightly nicer error messages when possible.
  It wasn't the goal to upstage all possible syntax errors.

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

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

From report at bugs.python.org  Sun Dec  8 13:07:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Dec 2019 18:07:51 +0000
Subject: [issue38996] introduction of default values for collection.namedtuple
In-Reply-To: <1575811931.27.0.501884177047.issue38996@roundup.psfhosted.org>
Message-ID: <1575828471.58.0.269121428998.issue38996@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's the status of the various ways to do it:

1) In 3.7, collections.namedtuple() added the *defaults* parameter and the *_field_defaults* attribute.

2) In 3.6.1, typing.NamedTuple added support for default values.

3) In older versions of Python, it was always possible to directly attach default values:

    >>> from collections import namedtuple
    >>> Point = namedtuple('Point', ('x', 'y'))
    >>> Point.__new__.__defaults__ = (10, )
    >>> Point(5)
    Point(x=5, y=10)

Given that we can't introduce new features to old versions of Python, it looks like this can be closed as "out-of-date".

----------

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

From report at bugs.python.org  Sun Dec  8 13:13:03 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 Dec 2019 18:13:03 +0000
Subject: [issue38996] introduction of default values for collection.namedtuple
In-Reply-To: <1575828471.58.0.269121428998.issue38996@roundup.psfhosted.org>
Message-ID: <690607EF-C521-4EB7-AB9C-AD363293A969@trueblade.com>


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

Agreed on closing this issue.

----------

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

From report at bugs.python.org  Sun Dec  8 13:47:23 2019
From: report at bugs.python.org (da-dada)
Date: Sun, 08 Dec 2019 18:47:23 +0000
Subject: [issue38998] dict.setdefault (setdefault of dictionary)
Message-ID: <1575830842.98.0.261556946938.issue38998@roundup.psfhosted.org>


New submission from da-dada <georg.klingenberg at travedsl.de>:

from the docu I expected at the second call just a return of value and not a second calculation: there is room for improvement, as Elon Musk would say..

class Ddefault:

    def __init__(self):
        vars(self).setdefault('default', self.set_default())
        vars(self).setdefault('default', self.set_default())

    def set_default(self):
        print(vars(self))
        return 'default'

if __name__ == "__main__":
    Ddefault()

----------
messages: 358016
nosy: da-dada
priority: normal
severity: normal
status: open
title: dict.setdefault (setdefault of dictionary)
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Dec  8 13:49:03 2019
From: report at bugs.python.org (Alexandros Karypidis)
Date: Sun, 08 Dec 2019 18:49:03 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
Message-ID: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>


New submission from Alexandros Karypidis <karypid at gmail.com>:

When you activate a venv on Windows and use a shebang with a major verion qualifier, the python launcer does not properly detect that a venv is active and uses the system installation instead.

The incorrect behavior is documented in this SO question where another user has confirmed and suggested it is a bug: https://stackoverflow.com/questions/59238326

Steps to reproduce (needs script.py attached below):

1. Install Python 3.7 on Windows 10 (64 bit)
2. Run script.py you should see:
PS C:\pytest> .\script.py
EXECUTABLE: C:\Program Files\Python37\python.exe
PREFIX: C:\Program Files\Python37
BASE PREFIX: C:\Program Files\Python37

3. Create and activate a virtual environment with:
PS C:\pytest> python -m venv .venv
PS C:\pytest> . .\.venv\Scripts\Activate.ps1

4. Run script.py you should see it ignore the active virtual environment:
(.venv) PS C:\pytest> .\script.py
EXECUTABLE: C:\Program Files\Python37\python.exe
PREFIX: C:\Program Files\Python37
BASE PREFIX: C:\Program Files\Python37

I am using Windows 10 64-bit, update 1903 and Python 3.7.5-64

----------
components: Windows
messages: 358017
nosy: Alexandros Karypidis, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python launcher on Windows does not detect active venv
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Dec  8 13:49:45 2019
From: report at bugs.python.org (Alexandros Karypidis)
Date: Sun, 08 Dec 2019 18:49:45 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575830985.39.0.422306881144.issue38999@roundup.psfhosted.org>


Alexandros Karypidis <karypid at gmail.com> added the comment:

Forgot the simple script:

#!/usr/bin/env python3

import os, sys, platform

print('EXECUTABLE: ' + sys.executable)
print('PREFIX: ' + sys.prefix)
print('BASE PREFIX: ' + sys.base_prefix)

----------

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

From report at bugs.python.org  Sun Dec  8 13:55:43 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 08 Dec 2019 18:55:43 +0000
Subject: [issue38998] dict.setdefault (setdefault of dictionary)
In-Reply-To: <1575830842.98.0.261556946938.issue38998@roundup.psfhosted.org>
Message-ID: <CA+jiYFBJnPzXRdMLRkgfONczZsaugBzbxWvawmabPaubKO+tgw@mail.gmail.com>


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

>
>
>     def __init__(self):
>         vars(self).setdefault('default', self.set_default())
>         vars(self).setdefault('default', self.set_default())
>

This code is equivalent to

    def __init__(self):
        x = self.set_default()
        vars(self).setdefault('default', x)

        x = self.set_default()
        vars(self).setdefault('default', x)

>
because the argument is evaluated before the call to setdefault() so you
can't optimise anything here.

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

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

From report at bugs.python.org  Sun Dec  8 14:14:42 2019
From: report at bugs.python.org (Alexandros Karypidis)
Date: Sun, 08 Dec 2019 19:14:42 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575832482.53.0.655464530173.issue38999@roundup.psfhosted.org>


Alexandros Karypidis <karypid at gmail.com> added the comment:

As confirmed by debug information when setting PYLAUNCH_DEBUG=1, the shebang seems to be ignored when using '#!//usr/bin/env python3' but works fine when using '#!//usr/bin/env python'.

This is with '#!//usr/bin/env python' (proper):
------------------------------------------------
(.venv) PS C:\pytest> .\script.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\karypid\AppData\Local\py.ini' non-existent
File 'C:\WINDOWS\py.ini' non-existent
Called with command line: "C:\pytest\script.py"
maybe_handle_shebang: read 167 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python
searching PATH for python executable
Python on path: C:\pytest\.venv\Scripts\python.exe
...


This is with '#!//usr/bin/env python3' (wrong):
------------------------------------------------
(.venv) PS C:\pytest> .\script.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\karypid\AppData\Local\py.ini' non-existent
File 'C:\WINDOWS\py.ini' non-existent
Called with command line: "C:\pytest\script.py"
maybe_handle_shebang: read 168 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 64bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
...


As you can see in the second case even though it regognises the python3 command, it makes no attempt to find it in the path.

Note that it appears that Windows installations only carry 'python.exe' and do not have a 'python3.exe' (neither in the native installation folder, nor in the virtual environment folder) so searching on the path would only 'work' if the user has copied python.exe to python3.exe in their <venv>\Scripts folder. (I actually tried that and it did not work).

A proper solution would probably need to search for 'python.exe' even for the '#!//usr/bin/env python3' shebang to detect if a virtual environment is present, possibly even confirming that the virtual environment is of the appropriate version.

----------

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

From report at bugs.python.org  Sun Dec  8 14:35:12 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 19:35:12 +0000
Subject: [issue38996] introduction of default values for collection.namedtuple
In-Reply-To: <1575811931.27.0.501884177047.issue38996@roundup.psfhosted.org>
Message-ID: <1575833712.68.0.95508263766.issue38996@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Dec  8 14:39:29 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 Dec 2019 19:39:29 +0000
Subject: [issue38998] dict.setdefault (setdefault of dictionary)
In-Reply-To: <1575830842.98.0.261556946938.issue38998@roundup.psfhosted.org>
Message-ID: <1575833969.86.0.710742238017.issue38998@roundup.psfhosted.org>


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

Right. If you want the value only calculated once, then just call it once.

You might be interested in collections.defaultdict, which takes a factory function, and only calls it as needed.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Dec  8 15:09:03 2019
From: report at bugs.python.org (Sean Moss)
Date: Sun, 08 Dec 2019 20:09:03 +0000
Subject: [issue39000] Range causing unstable output(Windows64)
Message-ID: <1575835743.62.0.012269649572.issue39000@roundup.psfhosted.org>


New submission from Sean Moss <smoss117 at gmail.com>:

I was doing this year's Advent of Code and found that the following program produces unstable output when run using the given file as input:
"""
from itertools import permutations
import gc

def runProgram(amp_input, program, counter):
    while program[counter] != 99:
        # print('*' * 99)
        instruction = str(program[counter])
        opcode = instruction[-2:]
        value1 = program[counter + 1]
        # print('2:{}'.format(counter))
        try:
            if opcode in ['01', '02', '1', '2', '5', '05', '6', '06', '7', '07', '8', '08']:
                value1 = program[counter + 1]
                value2 = program[counter + 2]
                param_modes = instruction[::-1][2:]
                # print('{} {} {} {}'.format(instruction, value1, value2, value3))
                param_modes += '0' * (3 - len(param_modes))
                # print(param_modes)
                if param_modes[0] == '0':
                    value1 = program[value1]
                if param_modes[1] == '0':
                    value2 = program[value2]
                # print('{} {} {} {}'.format(instruction, value1, value2, value3))
                if opcode in ['01', '02', '1', '2', '7', '07', '8', '08']:
                    value3 = program[counter + 3]
                    if opcode.endswith('1'):
                        program[value3] = value1 + value2
                    elif opcode.endswith('2'):
                        program[value3] = value1 * value2
                    elif opcode in ['7', '07']:
                        program[value3] = 1 if value1 < value2 else 0
                    elif opcode in ['8', '08']:
                        program[value3] = 1 if value1 == value2 else 0
                    counter += 4
                elif opcode in ['5', '05']:
                    if value1 != 0:
                        counter = value2
                    else:
                        counter += 3
                elif opcode in ['6', '06']:
                    if value1 == 0:
                        counter = value2
                    else:
                        counter += 3
            elif opcode in ['03', '3']:
                program[value1] = amp_input.pop(0)
                counter += 2
            elif opcode in ['4', '04']:
                # print('{} {}'.format(instruction, value1))
                if instruction != '104':
                    value1 = program[value1]
                # print('Output value: {}'.format(value1))
                counter += 2
                return value1, counter
            else:
                print("Something broke at {}".format(counter))
                print("program state {}".format(program))
                print(instruction)
                return False
        except Exception as e:
            print("Out of bounds at {}".format(counter))
            print("program state {}".format(program))
            print(instruction)
            print(e)
            print(len(program))
            return
    return program, True

outputs = []
max_output = 0
# initial_program = list(map(int, open('input7.txt').read().split(',')))
amp_ids = ['A', 'B', 'C', 'D', 'E']
permutation = [5, 6, 7, 8, 9]
# for permutation in permutations([5, 6, 7, 8, 9]):
amp_programs = {amp_id: [list(map(int, open('input7.txt').read().split(',')))[:], 0] for amp_id in ['A', 'B', 'C', 'D', 'E']}
loops = 0
prev_output = 0
for x in range(0, 5):
    gc.collect()
    new_output, outer_counter = runProgram([permutation[x], prev_output], amp_programs[amp_ids[x]][0], amp_programs[amp_ids[x]][1])
    if outer_counter is not True:
        prev_output = new_output
    amp_programs[amp_ids[x]][1] = outer_counter
    # print(new_output)
while amp_programs['E'][1] is not True:
    gc.collect()
    for amp_id in amp_programs.keys():
        amp = amp_programs[amp_id]
        # print(prev_output)
        # print('1:{}'.format(amp[1]))
        new_output, outer_counter = runProgram([prev_output], amp[0], amp[1])
        if outer_counter is not True:
            prev_output = new_output
        amp[1] = outer_counter
        # print('{}, {}'.format(amp[1], outer_counter))
# outputs.append(prev_output)
# print(prev_output)
outputs.append(prev_output)
    # if prev_output > max_output:
    #     max_output = prev_output

print(max(outputs))
# print(outputs)
"""
However when this program is run on the same input it produces stable input:
"""
from itertools import permutations

def runProgram(amp_input, program, counter):
    while program[counter] != 99:
        # print('*' * 99)
        instruction = str(program[counter])
        opcode = instruction[-2:]
        value1 = program[counter + 1]
        # print('2:{}'.format(counter))
        try:
            if opcode in ['01', '02', '1', '2', '5', '05', '6', '06', '7', '07', '8', '08']:
                value1 = program[counter + 1]
                value2 = program[counter + 2]
                param_modes = instruction[::-1][2:]
                # print('{} {} {} {}'.format(instruction, value1, value2, value3))
                param_modes += '0' * (3 - len(param_modes))
                # print(param_modes)
                if param_modes[0] == '0':
                    value1 = program[value1]
                if param_modes[1] == '0':
                    value2 = program[value2]
                # print('{} {} {} {}'.format(instruction, value1, value2, value3))
                if opcode in ['01', '02', '1', '2', '7', '07', '8', '08']:
                    value3 = program[counter + 3]
                    if opcode.endswith('1'):
                        program[value3] = value1 + value2
                    elif opcode.endswith('2'):
                        program[value3] = value1 * value2
                    elif opcode in ['7', '07']:
                        program[value3] = 1 if value1 < value2 else 0
                    elif opcode in ['8', '08']:
                        program[value3] = 1 if value1 == value2 else 0
                    counter += 4
                elif opcode in ['5', '05']:
                    if value1 != 0:
                        counter = value2
                    else:
                        counter += 3
                elif opcode in ['6', '06']:
                    if value1 == 0:
                        counter = value2
                    else:
                        counter += 3
            elif opcode in ['03', '3']:
                program[value1] = amp_input.pop(0)
                counter += 2
            elif opcode in ['4', '04']:
                # print('{} {}'.format(instruction, value1))
                if instruction != '104':
                    value1 = program[value1]
                # print('Output value: {}'.format(value1))
                counter += 2
                return value1, counter
            else:
                print("Something broke at {}".format(counter))
                print("program state {}".format(program))
                print(instruction)
                return False
        except Exception as e:
            print("Out of bounds at {}".format(counter))
            print("program state {}".format(program))
            print(instruction)
            print(e)
            print(len(program))
            return
    return program, True

outputs = []
max_output = 0
# initial_program = list(map(int, open('input7.txt').read().split(',')))
amp_ids = ['A', 'B', 'C', 'D', 'E']
permutation = [5, 6, 7, 8, 9]
# for permutation in permutations([5, 6, 7, 8, 9]):
amp_programs = {amp_id: [list(map(int, open('input7.txt').read().split(',')))[:], 0] for amp_id in ['A', 'B', 'C', 'D', 'E']}
loops = 0
prev_output = 0
for amp, perm in zip(amp_programs.values(), permutation):
    new_output, outer_counter = runProgram([perm, prev_output], amp[0], amp[1])
    if outer_counter is not True:
        prev_output = new_output
    amp[1] = outer_counter
    # print(new_output)
while amp_programs['E'][1] is not True:
    for amp_id in amp_programs.keys():
        amp = amp_programs[amp_id]
        # print(prev_output)
        # print('1:{}'.format(amp[1]))
        new_output, outer_counter = runProgram([prev_output], amp[0], amp[1])
        if outer_counter is not True:
            prev_output = new_output
        amp[1] = outer_counter
        # print('{}, {}'.format(amp[1], outer_counter))
# outputs.append(prev_output)
# print(prev_output)
outputs.append(prev_output)
    # if prev_output > max_output:
    #     max_output = prev_output

print(max(outputs))
# print(outputs)
"""
The only difference is that the second program uses the zip function to iterate while the first uses the range function to iterate. Again this is not a case of divergent output, it's that the first program doesn't always have the same output, the second program always has the same output.

----------
components: Library (Lib)
files: input7.txt
messages: 358022
nosy: Sean Moss
priority: normal
severity: normal
status: open
title: Range causing unstable output(Windows64)
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file48766/input7.txt

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

From report at bugs.python.org  Sun Dec  8 15:14:44 2019
From: report at bugs.python.org (Chris Withers)
Date: Sun, 08 Dec 2019 20:14:44 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1575836084.6.0.0173535614588.issue38669@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset cd90a52983db34896a6335a572d55bdda274778f by Chris Withers (Elena Oat) in branch 'master':
bpo-38669: patch.object now raises a helpful error (GH17034)
https://github.com/python/cpython/commit/cd90a52983db34896a6335a572d55bdda274778f


----------

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

From report at bugs.python.org  Sun Dec  8 15:15:08 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 20:15:08 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1575836108.35.0.893632500074.issue38669@roundup.psfhosted.org>


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


----------
pull_requests: +16986
pull_request: https://github.com/python/cpython/pull/17510

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

From report at bugs.python.org  Sun Dec  8 15:18:10 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 20:18:10 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1575836290.05.0.340659607067.issue38669@roundup.psfhosted.org>


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


----------
pull_requests: +16987
pull_request: https://github.com/python/cpython/pull/17511

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

From report at bugs.python.org  Sun Dec  8 15:24:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 20:24:03 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575836643.39.0.985354756528.issue38997@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16989
pull_request: https://github.com/python/cpython/pull/17512

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

From report at bugs.python.org  Sun Dec  8 15:24:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 20:24:03 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575836643.26.0.76933270652.issue38858@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +16988
pull_request: https://github.com/python/cpython/pull/17512

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

From report at bugs.python.org  Sun Dec  8 15:28:01 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Dec 2019 20:28:01 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575836881.44.0.404510292154.issue38992@roundup.psfhosted.org>


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

So if I'm understanding correctly, the cause of the issue is that the value `1.7**(i+1)` computed in the last iteration (i=999) of the list comprehension doesn't exactly match the `-1.7**1000` value, because the former is computed at runtime using the libm's pow, while the latter is constant-folded and likely uses something more accurate than `pow`.

I think it should be easy to rewrite the test so that it precomputes the powers of `1.7`, and then makes sure to use those computed values (i.e., so that we're only computing `1.7**1000` once rather than twice, eliminating the possibility of getting different results).

----------

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

From report at bugs.python.org  Sun Dec  8 15:30:19 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Dec 2019 20:30:19 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575837019.86.0.808454814153.issue38992@roundup.psfhosted.org>


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

Note that the exact values of `1.7**i` don't matter here - some sloppiness in the `pow` results should not cause a test failure. The key point is that under fairly mild assumptions about IEEE 754 conformance, the subtractions `1.7**(i+1) - 1.7**i` are always performed exactly, thanks to Sterbenz's lemma.

----------

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

From report at bugs.python.org  Sun Dec  8 15:31:22 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 08 Dec 2019 20:31:22 +0000
Subject: [issue38994] Implement __class_getitem__ for PathLike
In-Reply-To: <1575734254.5.0.717990589072.issue38994@roundup.psfhosted.org>
Message-ID: <1575837082.63.0.767336693094.issue38994@roundup.psfhosted.org>


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


New changeset 526606baf76e7a5309bb00f3bfaefa861a2014ba by Miss Islington (bot) (Batuhan Ta?kaya) in branch 'master':
bpo-38994: Implement __class_getitem__ for PathLike (GH-17498)
https://github.com/python/cpython/commit/526606baf76e7a5309bb00f3bfaefa861a2014ba


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

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

From report at bugs.python.org  Sun Dec  8 15:31:41 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 08 Dec 2019 20:31:41 +0000
Subject: [issue38994] Implement __class_getitem__ for PathLike
In-Reply-To: <1575734254.5.0.717990589072.issue38994@roundup.psfhosted.org>
Message-ID: <1575837101.46.0.184645882013.issue38994@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Dec  8 15:54:21 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Dec 2019 20:54:21 +0000
Subject: [issue39000] Range causing unstable output(Windows64)
In-Reply-To: <1575835743.62.0.012269649572.issue39000@roundup.psfhosted.org>
Message-ID: <1575838461.36.0.375879584954.issue39000@roundup.psfhosted.org>


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

This has nothing to do with range. The source of indeterminacy is this line in your code:

    for amp_id in amp_programs.keys():

In Python 3.5, the ordering of `amp_programs.keys()` could differ from run to run. (With Python 3.6 and later, that won't happen.)

If you want a deterministic result in Python 3.5, you could for example replace that line with:

    for amp_id in sorted(amp_programs):

Closing here; this isn't a Python bug.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Dec  8 15:56:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 20:56:04 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1575838564.45.0.0577921299155.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 080ee5a88406fb68aaab741145cd5d2a7c5f2ad6 by Victor Stinner in branch 'master':
bpo-38858: Fix ref leak in pycore_interp_init() (GH-17512)
https://github.com/python/cpython/commit/080ee5a88406fb68aaab741145cd5d2a7c5f2ad6


----------

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

From report at bugs.python.org  Sun Dec  8 15:56:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 20:56:04 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575838564.56.0.195972968293.issue38997@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 080ee5a88406fb68aaab741145cd5d2a7c5f2ad6 by Victor Stinner in branch 'master':
bpo-38858: Fix ref leak in pycore_interp_init() (GH-17512)
https://github.com/python/cpython/commit/080ee5a88406fb68aaab741145cd5d2a7c5f2ad6


----------

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

From report at bugs.python.org  Sun Dec  8 16:03:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 21:03:30 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575839010.84.0.758314080839.issue38997@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This reference leak is not new :-) It exists since at least Python 2.7. Extract of Python 2.7, Python/pythonrun.c:

    sysmod = _PySys_Init();
    if (sysmod == NULL)
        Py_FatalError("Py_Initialize: can't initialize sys");
    interp->sysdict = PyModule_GetDict(sysmod);

There is a missing Py_DECREF(sysmod). It was the same bug here, except that the code was deeply refactored in the meanwhile. I fixed the reference leak in commit 080ee5a88406fb68aaab741145cd5d2a7c5f2ad6.

Next question: why did the buildbot turn red? Well, at Python exit, there are like 18k references which are never decremented at Python exit:

$ ./python -X showrefcount -c pass
[18562 refs, 6494 blocks]

Previously, the subinterpreter sys module somehow shared references with the main interpreter. With my latest changes, the subinterpreter better isolates its own sys module from the main interpreter, and so the very old bug suddenyl is "releaved".

Getting subinterpreter "right" requires to fix all these very old bugs, one by one...

----------

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

From report at bugs.python.org  Sun Dec  8 16:03:53 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Dec 2019 21:03:53 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575839033.76.0.408475684994.issue38992@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +16990
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17513

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

From report at bugs.python.org  Sun Dec  8 16:04:36 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Dec 2019 21:04:36 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575839076.11.0.238072045609.issue38992@roundup.psfhosted.org>


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

@xdegaye Please could you test whether the PR GH-17513 fixes the issue for you?

----------

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

From report at bugs.python.org  Sun Dec  8 16:05:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 21:05:20 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575839120.15.0.354427467518.issue38997@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I validated that my commit 080ee5a88406fb68aaab741145cd5d2a7c5f2ad6 fixed the leaks, so I closed PR 17509 and I close this issue. Thanks for the bug report Pablo! I was also awaiting Refleak buildbot results!

$ ./python -m test -R 3:3 -j0  test__xxsubinterpreters test_atexit test_capi test_threading
(...)
All 4 tests OK.

Total duration: 1 min 4 sec
Tests result: SUCCESS

----------

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

From report at bugs.python.org  Sun Dec  8 16:05:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2019 21:05:48 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575839148.4.0.0966609046168.issue38997@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Sun Dec  8 16:07:59 2019
From: report at bugs.python.org (Dave Lawrence)
Date: Sun, 08 Dec 2019 21:07:59 +0000
Subject: [issue39001] possible problem with 64-bit mingw DECREF
Message-ID: <1575839278.99.0.426657382539.issue39001@roundup.psfhosted.org>


New submission from Dave Lawrence <mail.dave.lawrence at gmail.com>:

I am calling a python method from C using the attached code.

The Site.py file is:

import os

def find_site():
    path = os.path.abspath(".")
    return path

Cross compiled to Windows from Linux using mxe.cc and python 2.7.17
On 32-bit this runs as expected:

module = 028BC710
result = 0283D6B0
Found Site at \\wsl$\Ubuntu\home\dl
result = 0283D6B0 decref
module = 028BC710 decref

Site = \\wsl$\Ubuntu\home\dl
but crashes on 64-bit, failing to DECREF result:

module = 0000000002750408
result = 0000000000E62EF0
Found Site at \\wsl$\Ubuntu\home\dl
result = 0000000000E62EF0 decref

In both cases the libpython was made using the .dll copied from the target Windows machine and pexports and dlltool to create the .a

 if the return value of the python is return "C:/Test/Path" it works. if you add test2 = test and return test2 it fails. if you say test2 = "".join(c for c in path) and return test2 it fails. if you set path2 = "C:/Test/Path and return test2 it works

using Py_REFCNT [in the C code] shows a value of 2 for a return "c:/test" but a value of 1 a return test

----------
components: Library (Lib), Windows
files: py.cc
messages: 358033
nosy: Dave Lawrence, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: possible problem with 64-bit mingw DECREF
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file48767/py.cc

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

From report at bugs.python.org  Sun Dec  8 16:37:19 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 08 Dec 2019 21:37:19 +0000
Subject: [issue38997] test__xxsubinterpreters test_atexit test_capi
 test_threading are leaking references
In-Reply-To: <1575819312.04.0.64733813465.issue38997@roundup.psfhosted.org>
Message-ID: <1575841039.66.0.298617404002.issue38997@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for the fix, Victor!

----------

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

From report at bugs.python.org  Sun Dec  8 16:42:42 2019
From: report at bugs.python.org (AVicennA)
Date: Sun, 08 Dec 2019 21:42:42 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1575841362.41.0.872498136534.issue38993@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

Hello, I use decorators in my Python project. I tested project with cProfile(profiling). Then,
I decide did test with some decorator code fragments. Some results were surprising:

import functools
import cProfile

def decor(func):
    @functools.wraps(func)
    def wraps(*args, **kwargs):
        return func(*args, **kwargs)
    return wraps

@decor
def count(g_val):
    if g_val < 1:
        print("End")
    else:
        count(g_val - 1)
 
cProfile.run('count(102)')

OS names: Windows, Linux  -  x64
Python versions: 3.6.8, 3.4.3  -  x64

# cProfile using into the .py file
python dec_profile.py

End
         210 function calls (6 primitive calls) in 0.000 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 <string>:1(<module>)
    103/1    0.000    0.000    0.000    0.000 timeer.py:10(count)
    103/1    0.000    0.000    0.000    0.000 timeer.py:5(wraps)
        1    0.000    0.000    0.000    0.000 {built-in method builtins.exec}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.print}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

# Instead of 102 used ---> 82, 22, 33, 72 and etc. also gave me strange results like in 102. 
This behaviour can be changing sometimes, but usually give an incorrect results.

import functools
import cProfile

def decor(func):
    @functools.wraps(func)
    def wraps(*args, **kwargs):
        return func(*args, **kwargs)
    return wraps

@decor
def count(g_val):
    if g_val < 1:
        print("End")
    else:
        count(g_val - 1)
 
count(102)

# cProfile using via command line
python -m cProfile dec_profile.py

End
         539 function calls (334 primitive calls) in 0.002 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:103(release)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:143(__init__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:147(__enter__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:151(__exit__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:157(_get_module_lock)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:176(cb)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:211(_call_with_frames_removed)
       26    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:222(_verbose_message)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:307(__init__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:311(__enter__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:318(__exit__)
        4    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:321(<genexpr>)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:35(_new_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:369(__init__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:403(cached)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:416(parent)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:424(has_location)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:504(_init_module_attrs)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:564(module_from_spec)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:58(__init__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:651(_load_unlocked)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:707(find_spec)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:78(acquire)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:780(find_spec)
        3    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:843(__enter__)
        3    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:847(__exit__)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap>:870(_find_spec)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap>:936(_find_and_load_unlocked)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap>:966(_find_and_load)
        6    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:1080(_path_importer_cache)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap_external>:1117(_get_spec)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap_external>:1149(find_spec)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:1228(_get_spec)
        5    0.000    0.000    0.001    0.000 <frozen importlib._bootstrap_external>:1233(find_spec)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:263(cache_from_source)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:361(_get_cached)
        5    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:37(_relax_case)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:393(_check_name_wrapper)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:430(_validate_bytecode_header)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:485(_compile_bytecode)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:52(_r_long)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:524(spec_from_file_location)
       25    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:57(_path_join)
       25    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:59(<listcomp>)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:63(_path_split)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:669(create_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:672(exec_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:743(get_code)
        7    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:75(_path_stat)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:800(__init__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:825(get_filename)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:830(get_data)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:840(path_stats)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:85(_path_is_mode_type)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:94(_path_isfile)
        1    0.000    0.000    0.000    0.000 cProfile.py:27(Profile)
        1    0.000    0.000    0.000    0.000 cProfile.py:5(<module>)
        1    0.000    0.000    0.000    0.000 functools.py:44(update_wrapper)
        1    0.000    0.000    0.000    0.000 functools.py:74(wraps)
        1    0.000    0.000    0.002    0.002 timeer.py:1(<module>)
    103/1    0.000    0.000    0.000    0.000 timeer.py:10(count)
        1    0.000    0.000    0.000    0.000 timeer.py:4(decor)
    103/1    0.000    0.000    0.000    0.000 timeer.py:5(wraps)
        1    0.000    0.000    0.000    0.000 {built-in method _imp._fix_co_filename}
        5    0.000    0.000    0.000    0.000 {built-in method _imp.acquire_lock}
        1    0.000    0.000    0.000    0.000 {built-in method _imp.is_builtin}
        1    0.000    0.000    0.000    0.000 {built-in method _imp.is_frozen}
        5    0.000    0.000    0.000    0.000 {built-in method _imp.release_lock}
        2    0.000    0.000    0.000    0.000 {built-in method _thread.allocate_lock}
        2    0.000    0.000    0.000    0.000 {built-in method _thread.get_ident}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.__build_class__}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.any}
      2/1    0.000    0.000    0.002    0.002 {built-in method builtins.exec}
       13    0.000    0.000    0.000    0.000 {built-in method builtins.getattr}
        7    0.000    0.000    0.000    0.000 {built-in method builtins.hasattr}
        7    0.000    0.000    0.000    0.000 {built-in method builtins.isinstance}
        4    0.000    0.000    0.000    0.000 {built-in method builtins.len}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.print}
        5    0.000    0.000    0.000    0.000 {built-in method builtins.setattr}
        2    0.000    0.000    0.000    0.000 {built-in method from_bytes}
        1    0.000    0.000    0.000    0.000 {built-in method marshal.loads}
        3    0.000    0.000    0.000    0.000 {built-in method nt.fspath}
        2    0.000    0.000    0.000    0.000 {built-in method nt.getcwd}
        7    0.000    0.000    0.000    0.000 {built-in method nt.stat}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
        1    0.000    0.000    0.000    0.000 {method 'endswith' of 'str' objects}
        2    0.000    0.000    0.000    0.000 {method 'get' of 'dict' objects}
       27    0.000    0.000    0.000    0.000 {method 'join' of 'str' objects}
        1    0.000    0.000    0.000    0.000 {method 'read' of '_io.FileIO' objects}
        9    0.000    0.000    0.000    0.000 {method 'rpartition' of 'str' objects}
        2    0.000    0.000    0.000    0.000 {method 'rsplit' of 'str' objects}
       52    0.000    0.000    0.000    0.000 {method 'rstrip' of 'str' objects}
        1    0.000    0.000    0.000    0.000 {method 'update' of 'dict' objects}


Here also interesting results in computation with some factorial estimations:

import math
import cProfile

def fact(n):
    return sum(1 / math.factorial(n) for n in range(18))

print(cProfile.run('fact(200)'))

# cProfile into the .py file
python fact.py

42 function calls in 0.000 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 <string>:1(<module>)
        1    0.000    0.000    0.000    0.000 timeer.py:5(fact)
       19    0.000    0.000    0.000    0.000 timeer.py:6(<genexpr>)
        1    0.000    0.000    0.000    0.000 {built-in method builtins.exec}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.sum}
       18    0.000    0.000    0.000    0.000 {built-in method math.factorial}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

import math
import cProfile

def fact(n):
    print(sum(1 / math.factorial(n) for n in range(18)))

fact(200)

# cProfile using via command line
python -m cProfile fact.py

2.7182818284590455
         417 function calls (416 primitive calls) in 0.001 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:103(release)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:143(__init__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:147(__enter__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:151(__exit__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:157(_get_module_lock)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:176(cb)
        3    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:211(_call_with_frames_removed)
       27    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:222(_verbose_message)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:232(_requires_builtin_wrapper)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:307(__init__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:311(__enter__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:318(__exit__)
        8    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:321(<genexpr>)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:35(_new_module)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:369(__init__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:403(cached)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:416(parent)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:424(has_location)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:433(spec_from_loader)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:504(_init_module_attrs)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:564(module_from_spec)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:58(__init__)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:651(_load_unlocked)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:707(find_spec)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:728(create_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:736(exec_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:753(is_package)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:78(acquire)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:780(find_spec)
        4    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:843(__enter__)
        4    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap>:847(__exit__)
        2    0.000    0.000    0.001    0.000 <frozen importlib._bootstrap>:870(_find_spec)
        2    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap>:936(_find_and_load_unlocked)
        2    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap>:966(_find_and_load)
        6    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:1080(_path_importer_cache)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap_external>:1117(_get_spec)
        1    0.000    0.000    0.001    0.001 <frozen importlib._bootstrap_external>:1149(find_spec)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:1228(_get_spec)
        5    0.000    0.000    0.001    0.000 <frozen importlib._bootstrap_external>:1233(find_spec)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:263(cache_from_source)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:361(_get_cached)
        5    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:37(_relax_case)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:393(_check_name_wrapper)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:430(_validate_bytecode_header)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:485(_compile_bytecode)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:52(_r_long)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:524(spec_from_file_location)
       25    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:57(_path_join)
       25    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:59(<listcomp>)
        2    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:63(_path_split)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:669(create_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:672(exec_module)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:743(get_code)
        7    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:75(_path_stat)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:800(__init__)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:825(get_filename)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:830(get_data)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:840(path_stats)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:85(_path_is_mode_type)
        1    0.000    0.000    0.000    0.000 <frozen importlib._bootstrap_external>:94(_path_isfile)
        1    0.000    0.000    0.000    0.000 cProfile.py:27(Profile)
        1    0.000    0.000    0.000    0.000 cProfile.py:5(<module>)
        1    0.000    0.000    0.001    0.001 timeer.py:1(<module>)
        1    0.000    0.000    0.000    0.000 timeer.py:4(fact)
       19    0.000    0.000    0.000    0.000 timeer.py:5(<genexpr>)
        1    0.000    0.000    0.000    0.000 {built-in method _imp._fix_co_filename}
        8    0.000    0.000    0.000    0.000 {built-in method _imp.acquire_lock}
        1    0.000    0.000    0.000    0.000 {built-in method _imp.create_builtin}
        1    0.000    0.000    0.000    0.000 {built-in method _imp.exec_builtin}
        2    0.000    0.000    0.000    0.000 {built-in method _imp.is_builtin}
        1    0.000    0.000    0.000    0.000 {built-in method _imp.is_frozen}
        8    0.000    0.000    0.000    0.000 {built-in method _imp.release_lock}
        4    0.000    0.000    0.000    0.000 {built-in method _thread.allocate_lock}
        4    0.000    0.000    0.000    0.000 {built-in method _thread.get_ident}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.__build_class__}
        2    0.000    0.000    0.000    0.000 {built-in method builtins.any}
      2/1    0.000    0.000    0.001    0.001 {built-in method builtins.exec}
       10    0.000    0.000    0.000    0.000 {built-in method builtins.getattr}
       11    0.000    0.000    0.000    0.000 {built-in method builtins.hasattr}
        7    0.000    0.000    0.000    0.000 {built-in method builtins.isinstance}
        4    0.000    0.000    0.000    0.000 {built-in method builtins.len}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.print}
        1    0.000    0.000    0.000    0.000 {built-in method builtins.sum}
        2    0.000    0.000    0.000    0.000 {built-in method from_bytes}
        1    0.000    0.000    0.000    0.000 {built-in method marshal.loads}
       18    0.000    0.000    0.000    0.000 {built-in method math.factorial}
        3    0.000    0.000    0.000    0.000 {built-in method nt.fspath}
        2    0.000    0.000    0.000    0.000 {built-in method nt.getcwd}
        7    0.000    0.000    0.000    0.000 {built-in method nt.stat}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
        1    0.000    0.000    0.000    0.000 {method 'endswith' of 'str' objects}
        4    0.000    0.000    0.000    0.000 {method 'get' of 'dict' objects}
       27    0.000    0.000    0.000    0.000 {method 'join' of 'str' objects}
        1    0.000    0.000    0.000    0.000 {method 'read' of '_io.FileIO' objects}
       11    0.000    0.000    0.000    0.000 {method 'rpartition' of 'str' objects}
        2    0.000    0.000    0.000    0.000 {method 'rsplit' of 'str' objects}
       52    0.000    0.000    0.000    0.000 {method 'rstrip' of 'str' objects}

In cProfile documentation isn't talking about command line behaviour difference.

----------

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

From report at bugs.python.org  Sun Dec  8 16:47:05 2019
From: report at bugs.python.org (da-dada)
Date: Sun, 08 Dec 2019 21:47:05 +0000
Subject: [issue38998] dict.setdefault (setdefault of dictionary)
In-Reply-To: <1575830842.98.0.261556946938.issue38998@roundup.psfhosted.org>
Message-ID: <1575841625.12.0.864811549742.issue38998@roundup.psfhosted.org>


da-dada <georg.klingenberg at travedsl.de> added the comment:

I have no problem of making my programme run properly (asking first if in dict etc), but I just read the docu of dict.setdefault

setdefault(key[, default]) 
If key is in the dictionary, return its value. If not, insert key with a value of default and return default. default defaults to None.

and it clearly reads if the key is.. return its value, with a full stop;
so either the docu is wrong (but proposes exactly the needed shortcut) or python is as it is: come in & find out

----------

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

From report at bugs.python.org  Sun Dec  8 17:39:03 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 08 Dec 2019 22:39:03 +0000
Subject: [issue38998] dict.setdefault (setdefault of dictionary)
In-Reply-To: <1575841625.12.0.864811549742.issue38998@roundup.psfhosted.org>
Message-ID: <CA+jiYFBcxe5yiSJWVYW7fA_GyHFBQzQwof7OSC=SQWrge7juCw@mail.gmail.com>


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

The documentation is correct, in Python argument are computed before the
call to a function, not when they are used. You can try other functions
than dict.setdefault() and see that the behaviour is always the same.

Le dim. 8 d?c. 2019 ? 22:47, da-dada <report at bugs.python.org> a ?crit :

>
> da-dada <georg.klingenberg at travedsl.de> added the comment:
>
> I have no problem of making my programme run properly (asking first if in
> dict etc), but I just read the docu of dict.setdefault
>
> setdefault(key[, default])
> If key is in the dictionary, return its value. If not, insert key with a
> value of default and return default. default defaults to None.
>
> and it clearly reads if the key is.. return its value, with a full stop;
> so either the docu is wrong (but proposes exactly the needed shortcut) or
> python is as it is: come in & find out
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38998>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Dec  8 17:49:10 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Dec 2019 22:49:10 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1575845350.65.0.108536865516.issue38594@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Good suggestions. Thanks for taking the time to articulate in such a friendly way the shortcomings you encountered. I'm happy to help.

In [this ticket](https://gitlab.com/python-devs/importlib_metadata/issues/105), I've mirrored this ticket in the backport project, where I can iterate much faster.

I'll provide brief answers to some of your questions/concerns here and then work out the wording for the documentation (and code changes) necessary to communicate that effectively.

> The reference to `load_metadata()` is the only occurrence of the string `load_metadata` in the CPython and importlib_metadata code bases. I therefore believe the documentation in both CPython and the importlib_metadata standalone package are wrong because they are referring to a method that is never implemented nor called.

That's right. The documentation is wrong. It should say to implement a `Distribution` subclass (especially its abstract methods). Nothing more should be necessary.

> I see that certain APIs return Path-like objects (which I will need to implement)

Are you sure about that? The only code I see in the `Distribution` class that references a `Path` object is `.at()`, a static method that we decided to add to the `Distribution` class even though it would be more appropriate in the `PathDistribution` class in order to make that method readily available to projects that wished to construct the Path-based distribution objects from a file system (or zipfile) path. I'm pretty sure everything else in the Distribution class relies on the two abstract methods. If you disregard `at` (and I recommend you do) and focus on implementing the abstract methods, I think things will work. Let me know if you find otherwise.

> why the Context is optional and how Context could be used?

The interface is intentionally vague in order not to be too prescriptive, because as you point out, name or path may not be relevant in some contexts. It's meant to narrow the scope of any search.

So if a path is present, that means the query is looking in a specific 'sys.path' entry. And if the name is present, that means it's looking for a distribution having a specific name. But basically, you can solicit any properties you like. You could expect a `size='max(100)'` parameter and only return distributions smaller than 100 (for whatever interpretation of `size` you wish to implement. Your DistributionFinder should do its best to honor whatever context might be relevant to the Distributions you provide.

Does PyOxidizer interact with `sys.path` at all? If not, it can disregard `Context.path`.

----------

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

From report at bugs.python.org  Sun Dec  8 17:55:26 2019
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Dec 2019 22:55:26 +0000
Subject: [issue38901] Add a CLI flag to venv to use the pwd basename as the
 prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1575845726.06.0.490506872976.issue38901@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

If it were `.` would we then always check if the prompt was a folder and then use the folder's name in that case? Or would it only apply to `.`?

As for `__curdir__`, it could work, but I don't know how easy would that be to remember or explain to new users compared to `.`?

My vote is to support `.` and make the rule that if you specify a folder it will use the basename automatically.

----------

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

From report at bugs.python.org  Sun Dec  8 17:59:37 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2019 22:59:37 +0000
Subject: [issue38987] 3.8.0 on GNU/Linux fails to find shared library
In-Reply-To: <1575652752.94.0.770020872085.issue38987@roundup.psfhosted.org>
Message-ID: <1575845977.04.0.0620212715635.issue38987@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Did you update the ld.so cache with ldconfig?

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Sun Dec  8 18:06:16 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 08 Dec 2019 23:06:16 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1575846376.77.0.65487372228.issue38594@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Please have a look at https://gitlab.com/python-devs/importlib_metadata/merge_requests/104/diffs, which attempts to clarify the documentation to indicate how one would implement a custom finder. If you have a prototype implementation, I'd be happy to have a look.

The use-case you present is exactly the type of use-case this project wishes to enable, so I'm grateful that you're working on it and I'd like to do what I can to support the effort.

----------

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

From report at bugs.python.org  Sun Dec  8 18:40:05 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 Dec 2019 23:40:05 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1575848405.03.0.270866201122.issue38993@roundup.psfhosted.org>


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

@AVicennA Can you clarify exactly which part of the output you find surprising, and why, and what result you expected instead? It's a little hard to tell which details in your message we're supposed to be looking at.

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

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

From report at bugs.python.org  Sun Dec  8 19:45:34 2019
From: report at bugs.python.org (da-dada)
Date: Mon, 09 Dec 2019 00:45:34 +0000
Subject: [issue38998] dict.setdefault (setdefault of dictionary)
In-Reply-To: <1575830842.98.0.261556946938.issue38998@roundup.psfhosted.org>
Message-ID: <1575852334.14.0.94512504443.issue38998@roundup.psfhosted.org>


da-dada <georg.klingenberg at travedsl.de> added the comment:

my use case is different (I do a loop), but what I expected from the docs (just for fun!)

class Ddefault:

    def __init__(self):
        vars(self).setdefault('default', self.set_default() if not 'default' in vars(self) else self.default)
        vars(self).setdefault('default', self.set_default() if not 'default' in vars(self) else self.default)
        print(vars(self))

    def set_default(self):
        print(vars(self))
        return 'default'

if __name__ == "__main__":
    Ddefault()

may be the coding diverted from the docs after the fixing of issue 13521 and no one dares correcting..
anyway, I will probably keep my old coding (performance, if there is any)

----------

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

From report at bugs.python.org  Sun Dec  8 19:53:18 2019
From: report at bugs.python.org (Phillip Schanely)
Date: Mon, 09 Dec 2019 00:53:18 +0000
Subject: [issue16397] UserString doesn't combine nicely with strings
In-Reply-To: <1351966393.52.0.468233404693.issue16397@psf.upfronthosting.co.za>
Message-ID: <1575852798.34.0.154263011352.issue16397@roundup.psfhosted.org>


Change by Phillip Schanely <pschanely at gmail.com>:


----------
nosy: +pschanely

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

From report at bugs.python.org  Sun Dec  8 20:35:44 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Mon, 09 Dec 2019 01:35:44 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575855344.63.0.686355689828.issue38698@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:


New changeset 68157da8b42b26408af5d157d2dba4fcf29c6320 by Abhilash Raj in branch 'master':
bpo-38698: Add a new InvalidMessageID token to email header parser. (GH-17503)
https://github.com/python/cpython/commit/68157da8b42b26408af5d157d2dba4fcf29c6320


----------

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

From report at bugs.python.org  Sun Dec  8 20:35:51 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 01:35:51 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575855351.05.0.0664075644395.issue38698@roundup.psfhosted.org>


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


----------
pull_requests: +16991
pull_request: https://github.com/python/cpython/pull/17514

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

From report at bugs.python.org  Sun Dec  8 20:37:38 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Mon, 09 Dec 2019 01:37:38 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1575855458.16.0.7539688966.issue38708@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:


New changeset 3ae4ea1931361dd2743e464790e739d9285501bf by Abhilash Raj in branch 'master':
bpo-38708: email: Fix a potential IndexError when parsing Message-ID (GH-17504)
https://github.com/python/cpython/commit/3ae4ea1931361dd2743e464790e739d9285501bf


----------

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

From report at bugs.python.org  Sun Dec  8 20:37:47 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 01:37:47 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1575855467.33.0.917425754661.issue38708@roundup.psfhosted.org>


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


----------
pull_requests: +16992
pull_request: https://github.com/python/cpython/pull/17515

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

From report at bugs.python.org  Sun Dec  8 21:11:37 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 02:11:37 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575857497.65.0.5632408352.issue38698@roundup.psfhosted.org>


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


New changeset f66f4a09d0b6817fe6a86a567fd506aa223f1563 by Miss Islington (bot) in branch '3.8':
bpo-38698: Add a new InvalidMessageID token to email header parser. (GH-17503)
https://github.com/python/cpython/commit/f66f4a09d0b6817fe6a86a567fd506aa223f1563


----------

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

From report at bugs.python.org  Sun Dec  8 21:12:53 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 02:12:53 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1575857573.43.0.619088860299.issue38708@roundup.psfhosted.org>


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


New changeset 2abd3a8f580e6c7b1ce88b2ae9f9a783f4aea5d3 by Miss Islington (bot) in branch '3.8':
bpo-38708: email: Fix a potential IndexError when parsing Message-ID (GH-17504)
https://github.com/python/cpython/commit/2abd3a8f580e6c7b1ce88b2ae9f9a783f4aea5d3


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

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

From report at bugs.python.org  Sun Dec  8 21:35:20 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Mon, 09 Dec 2019 02:35:20 +0000
Subject: [issue38708] parse_message_id in email module is very buggy / crashy
In-Reply-To: <1572994084.54.0.352117032645.issue38708@roundup.psfhosted.org>
Message-ID: <1575858920.22.0.635169575232.issue38708@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Closing this as fixed.

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

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

From report at bugs.python.org  Sun Dec  8 21:36:06 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Mon, 09 Dec 2019 02:36:06 +0000
Subject: [issue38698] While parsing email message id: UnboundLocalError
In-Reply-To: <1572959008.39.0.0407638047652.issue38698@roundup.psfhosted.org>
Message-ID: <1575858966.92.0.435952139923.issue38698@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Closing this as fixed.

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

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

From report at bugs.python.org  Sun Dec  8 22:08:06 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 09 Dec 2019 03:08:06 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1575860886.59.0.0873050492647.issue38576@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
priority: normal -> high

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

From report at bugs.python.org  Sun Dec  8 22:10:03 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 09 Dec 2019 03:10:03 +0000
Subject: [issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header
 Injection (follow-up of CVE-2016-5699)
In-Reply-To: <1495638091.75.0.96439752743.issue30458@psf.upfronthosting.co.za>
Message-ID: <1575861003.59.0.4402048551.issue30458@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

i believe new work will be done via the new issue.  marking this closed.  if there is something not covered by issue38576 that remains, please open a new issue for it.  new discussion on this long issue is easy to get lost in.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30458>
_______________________________________

From report at bugs.python.org  Sun Dec  8 22:17:20 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 09 Dec 2019 03:17:20 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1575861440.89.0.0679562645293.issue13501@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.9 -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/issue13501>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:36:39 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 04:36:39 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575866199.76.0.880604939069.issue38673@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 109fc2792a490ee5cd8a423e17d415fbdedec5c8 by Miss Islington (bot) (Batuhan Ta?kaya) in branch 'master':
bpo-38673: dont switch to ps2 if the line starts with comment or whitespace (GH-17421)
https://github.com/python/cpython/commit/109fc2792a490ee5cd8a423e17d415fbdedec5c8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:37:39 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2019 04:37:39 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575866259.86.0.142606827642.issue38673@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I'd like to backport this to 3.8.1 at least. Are people interested in getting it backported to earlier versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:38:16 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 04:38:16 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575866296.13.0.100990770586.issue38673@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16993
pull_request: https://github.com/python/cpython/pull/17516

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:56:25 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 04:56:25 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575867385.71.0.277246987871.issue38673@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 184a3812b81e2f7d4bc6453bf7ceabe8ac590202 by Miss Islington (bot) in branch '3.8':
bpo-38673: dont switch to ps2 if the line starts with comment or whitespace (GH-17421)
https://github.com/python/cpython/commit/184a3812b81e2f7d4bc6453bf7ceabe8ac590202


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:07:06 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2019 05:07:06 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575868026.64.0.954084361939.issue38673@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

So 3.8.1 got backported by Miss Islington. Do we want this in earlier releases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:34:29 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2019 06:34:29 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575873269.24.0.322925702756.issue38673@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would prefer that.  I think treating '\n' and ' \n' differently is a bit of a bug.  And the fix pretty well matches code/codeop behavior.  I have so far not imagined how it could break code.    But you could let Ned Deily decide, before the next rc, if you want.

I am neutral on 2.7.

----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:47:28 2019
From: report at bugs.python.org (AVicennA)
Date: Mon, 09 Dec 2019 06:47:28 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1575874048.83.0.944879385564.issue38993@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

In short, here are different behaviours in increasing steps of values, which are (based on my researching) giving incorrect results in relation to each other.

Given example:

import functools
import cProfile

def decor(func):
    @functools.wraps(func)
    def wraps(*args, **kwargs):
        return func(*args, **kwargs)
    return wraps

@decor
def count(g_val):
    if g_val < 1:
        print("End")
    else:
        count(g_val - 1)
		
cProfile.run('count(VALUE)')
		

Below I wrote results by given values...

1) VALUE = 50

End                                                                                                                                                                                
         106 function calls (6 primitive calls) in 0.000 seconds                                                                                                                   
                                                                                                                                                                                   
   Ordered by: standard name                                                                                                                                                       
                                                                                                                                                                                   
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)                                                                                                            
        1    0.000    0.000    0.000    0.000 <string>:1(<module>)                                                                                                                 
     51/1    0.000    0.000    0.000    0.000 main.py:10(count)                                                                                                                    
     51/1    0.000    0.000    0.000    0.000 main.py:5(wraps)                                                                                                                     
        1    0.000    0.000    0.000    0.000 {built-in method exec}                                                                                                               
        1    0.000    0.000    0.000    0.000 {built-in method print}                                                                                                              
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}

		
2) VALUE = 45	
End                                                                                                                                                                                
         96 function calls (6 primitive calls) in 0.062 seconds                                                                                                                    
                                                                                                                                                                                   
   Ordered by: standard name                                                                                                                                                       
                                                                                                                                                                                   
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)                                                                                                            
        1    0.000    0.000    0.062    0.062 <string>:1(<module>)                                                                                                                 
     46/1    0.000    0.000    0.061    0.061 main.py:10(count)                                                                                                                    
     46/1    0.000    0.000    0.062    0.062 main.py:5(wraps)                                                                                                                     
        1    0.000    0.000    0.062    0.062 {built-in method exec}                                                                                                               
        1    0.061    0.061    0.061    0.061 {built-in method print}                                                                                                              
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
	
	
3) VALUE = 26		
End                                                                                                                                                                                
         58 function calls (6 primitive calls) in 0.003 seconds                                                                                                                    
                                                                                                                                                                                   
   Ordered by: standard name                                                                                                                                                       
                                                                                                                                                                                   
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)                                                                                                            
        1    0.000    0.000    0.002    0.002 <string>:1(<module>)                                                                                                                 
     27/1    0.000    0.000    0.002    0.002 main.py:10(count)                                                                                                                    
     27/1    0.000    0.000    0.002    0.002 main.py:5(wraps)                                                                                                                     
        1    0.000    0.000    0.003    0.003 {built-in method exec}                                                                                                               
        1    0.002    0.002    0.002    0.002 {built-in method print}                                                                                                              
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}
		
As you see above samples are giving surprise results.. 50 - gave 0 sec., but how 26 - gave 0.003 sec or 45 - gave 0.062 sec. Instead of these results I expected increased seconds by linearly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:59:16 2019
From: report at bugs.python.org (Chris Withers)
Date: Mon, 09 Dec 2019 06:59:16 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1575874756.63.0.412517239007.issue38669@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 4594565b56e9c99d2d3fb7549041bbca5ecba8e2 by Chris Withers (Miss Islington (bot)) in branch '3.8':
bpo-38669: patch.object now raises a helpful error (GH17510)
https://github.com/python/cpython/commit/4594565b56e9c99d2d3fb7549041bbca5ecba8e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:59:26 2019
From: report at bugs.python.org (Chris Withers)
Date: Mon, 09 Dec 2019 06:59:26 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1575874766.9.0.384169686046.issue38669@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 41973c99fdfdc78315e819661e279bdcc2f058b1 by Chris Withers (Miss Islington (bot)) in branch '3.7':
bpo-38669: patch.object now raises a helpful error (GH17511)
https://github.com/python/cpython/commit/41973c99fdfdc78315e819661e279bdcc2f058b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:00:24 2019
From: report at bugs.python.org (Chris Withers)
Date: Mon, 09 Dec 2019 07:00:24 +0000
Subject: [issue38669] patch.object should raise another error when first
 argument is a str
In-Reply-To: <1572748239.52.0.218774930946.issue38669@roundup.psfhosted.org>
Message-ID: <1575874824.3.0.795292986028.issue38669@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38669>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:32:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2019 07:32:54 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575876774.47.0.446740161048.issue38981@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not sure about the new name. "re" is an abbreviation, so if include it in the exception name it should be "RE". I am not sure what name is better: RECompileError, REParseError, RESyntaxError, REError, CompileError, ParseError, SyntaxError or Error.

json raises JSONDecodeError, ElementTree raises ParseError, other xml modules raise ExpatError, csv raises Error, configparser raises subclasses of Error.

Many modules (at least 18: aifc, binhex, concurrent.futures, configparser, copy, cvs, ftplib, locale, mailbox, shutil, sqlite, sunau, test.support, uu, wave, webbrowser, xdrlib, xmlrpc.client) have an exception named just Error for module-specific errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38981>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:18:22 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Dec 2019 08:18:22 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575879502.79.0.164383341032.issue38999@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

See PEP 486 (https://www.youtube.com/watch?v=Lmq13nrEFaM&list=PLuE3ABw6vYeR0gcPT6uj25ZZhmSP9vRB2&index=28&t=0s). This is intended behaviour, as it is assumed that explicitly specifying a Python version means that the user had a specific Python interpreter in mind.

There are also technical issues - if the shebang says #!/usr/bin/python2, and a virtual environment is active, how do we know if it's a Python 2 or 3 environment (without launching the interpreter, which is a significant extra cost for the launcher)? It would definitely be wrong to launch a Python 3 interpreter in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:19:10 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Dec 2019 08:19:10 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575879550.24.0.227181156178.issue38999@roundup.psfhosted.org>


Change by Paul Moore <p.f.moore at gmail.com>:


----------
Removed message: https://bugs.python.org/msg358060

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:19:50 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Dec 2019 08:19:50 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575879590.47.0.201202973181.issue38999@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

See PEP 486 (https://www.python.org/dev/peps/pep-0486/). This is intended behaviour, as it is assumed that explicitly specifying a Python version means that the user had a specific Python interpreter in mind.

There are also technical issues - if the shebang says #!/usr/bin/python2, and a virtual environment is active, how do we know if it's a Python 2 or 3 environment (without launching the interpreter, which is a significant extra cost for the launcher)? It would definitely be wrong to launch a Python 3 interpreter in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Mon Dec  9 04:40:56 2019
From: report at bugs.python.org (=?utf-8?q?Jakub_Piotr_C=C5=82apa?=)
Date: Mon, 09 Dec 2019 09:40:56 +0000
Subject: [issue31625] stop using ranlib
In-Reply-To: <1506665732.66.0.213398074469.issue31625@psf.upfronthosting.co.za>
Message-ID: <1575884456.93.0.526172200903.issue31625@roundup.psfhosted.org>


Change by Jakub Piotr C?apa <jpc at loee.pl>:


----------
pull_requests: +16994
pull_request: https://github.com/python/cpython/pull/15387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31625>
_______________________________________

From report at bugs.python.org  Mon Dec  9 04:43:10 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Dec 2019 09:43:10 +0000
Subject: [issue37916] distutils: allow overriding of the RANLIB command on
 macOS (darwin)
In-Reply-To: <1566473837.96.0.294748627211.issue37916@roundup.psfhosted.org>
Message-ID: <1575884590.61.0.928787788344.issue37916@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thank you for the PR. I did a quick look at it and added some comments to the PR including wondering whether the root cause of the problematic behavior is elsewhere in Distutils.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:04:23 2019
From: report at bugs.python.org (Tim Gates)
Date: Mon, 09 Dec 2019 10:04:23 +0000
Subject: [issue39002] Small typo in Lib/test/test_statistics.py: tranlation ->
 translation
Message-ID: <1575885863.07.0.931006878505.issue39002@roundup.psfhosted.org>


New submission from Tim Gates <tim.gates at iress.com>:

There is a small typo in Lib/test/test_statistics.py.
Should read translation rather than tranlation.

----------
assignee: docs at python
components: Documentation
messages: 358063
nosy: docs at python, timgates42
priority: normal
pull_requests: 16995
severity: normal
status: open
title: Small typo in Lib/test/test_statistics.py: tranlation -> translation
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39002>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:14:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 10:14:07 +0000
Subject: [issue24554] GC should happen when a subinterpreter is destroyed
In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za>
Message-ID: <1575886447.69.0.212488592016.issue24554@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue is partially fixed in the master branch. Extract of the finalize_interp_clear() function, called by Py_EndInterpreter():

    /* Clear interpreter state and all thread states */
    PyInterpreterState_Clear(tstate->interp);

    /* Trigger a GC collection on subinterpreters*/
    if (!is_main_interp) {
        _PyGC_CollectNoFail();
    }

gc.collect() is now called.

It's only "partially" fixed because I would prefer to trigger a GC collection before or during PyInterpreterState_Clear(). IMHO trigger it after PyInterpreterState_Clear() creates a risk of crash in finalizers written in C which don't handle well before called very late during Python finalization. After PyInterpreterState_Clear(), Python is basically unusable. All modules are cleared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24554>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:27:17 2019
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 09 Dec 2019 10:27:17 +0000
Subject: [issue38091] Import deadlock detection causes deadlock
In-Reply-To: <1568122000.74.0.240735069302.issue38091@roundup.psfhosted.org>
Message-ID: <1575887237.5.0.986940814534.issue38091@roundup.psfhosted.org>


Change by Armin Rigo <arigo at users.sourceforge.net>:


----------
keywords: +patch
pull_requests: +16996
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17518

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38091>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:34:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 10:34:53 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575887693.3.0.450276080371.issue38547@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +16997
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17519

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:36:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 10:36:19 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575887779.25.0.0873465193972.issue38547@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I think fixing the underlying pty issue should certainly be the goal (...)

I wrote PR 17519 which fix the bug. We just have to ignore SIGHUP signal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:57:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 10:57:18 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575889038.19.0.849986522673.issue38547@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a1838ec2592e5082c75c77888f2a7a3eb21133e5 by Victor Stinner in branch 'master':
bpo-38547: Fix test_pty if the process is the session leader (GH-17519)
https://github.com/python/cpython/commit/a1838ec2592e5082c75c77888f2a7a3eb21133e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:57:30 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 10:57:30 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575889050.45.0.514349812177.issue38547@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16998
pull_request: https://github.com/python/cpython/pull/17520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:57:36 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 10:57:36 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575889056.95.0.805188543889.issue38547@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +16999
pull_request: https://github.com/python/cpython/pull/17521

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 06:00:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 11:00:12 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575889212.68.0.366125937114.issue38547@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, I merged my fix to master. The backport to 3.7 and 3.8 will follow quickly. I close the issue.

Sorry for the inconvenience ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 06:13:13 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 11:13:13 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575889993.55.0.461268805368.issue38673@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17000
pull_request: https://github.com/python/cpython/pull/17522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 06:15:10 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 11:15:10 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575890110.95.0.810737207358.issue38547@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b9f4b49c6e525afd6fce02cfc14be52e98a18f67 by Miss Islington (bot) in branch '3.7':
bpo-38547: Fix test_pty if the process is the session leader (GH-17519)
https://github.com/python/cpython/commit/b9f4b49c6e525afd6fce02cfc14be52e98a18f67


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 06:15:26 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 09 Dec 2019 11:15:26 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575890126.59.0.351499523588.issue38992@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Yes PR GH-17513 does fix the problem.
Thanks Mark.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38992>
_______________________________________

From report at bugs.python.org  Mon Dec  9 06:15:27 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 11:15:27 +0000
Subject: [issue38547] test_pty fails when using setsid()
In-Reply-To: <1571657919.98.0.824899649018.issue38547@roundup.psfhosted.org>
Message-ID: <1575890127.36.0.76237118996.issue38547@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d08fd298dc8d5631f6c504d01ee4f9cfb47db79d by Miss Islington (bot) in branch '3.8':
bpo-38547: Fix test_pty if the process is the session leader (GH-17519)
https://github.com/python/cpython/commit/d08fd298dc8d5631f6c504d01ee4f9cfb47db79d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38547>
_______________________________________

From report at bugs.python.org  Mon Dec  9 06:38:41 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Dec 2019 11:38:41 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575891521.97.0.988401709544.issue38673@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 188d5ae6f047342f3d6860646ccf1a523ef8b0ed by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-38673: dont switch to ps2 if the line starts with comment or whitespace (GH-17421) (GH-17522)
https://github.com/python/cpython/commit/188d5ae6f047342f3d6860646ccf1a523ef8b0ed


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:09:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:09:37 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575896977.61.0.526826534671.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0131aba5ae20d704b972ecd2ef0fc6c9e370a1b3 by Victor Stinner in branch 'master':
bpo-38916: array.array: remove fromstring() and tostring() (GH-17487)
https://github.com/python/cpython/commit/0131aba5ae20d704b972ecd2ef0fc6c9e370a1b3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:15:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:15:22 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575897322.44.0.332588967413.issue38916@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17001
pull_request: https://github.com/python/cpython/pull/17523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:16:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:16:14 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575897374.28.0.994425327767.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Brett Cannon: "If it was documented as deprecated and raising a deprecation warning then 3.2 is definitely far enough back to warrant removing it."

I understood that Brett is in favor of removing it.

Raymond Hettinger: "The tostring() method should be handled in the same way."

Done.

Raymond Hettinger: "Remediation is easy because from_bytes() is a alias"

For code supporting Python 2 and Python 3, it may be annoying, but Python 3.9 will only be released after Python 2 support will end. So I consider that it's an acceptable annoyance. Users can put "if six.PY3" in their code or don't support Python 3.9.


Raymond Hettinger: "Still, all removals cause disruption from at least some users"

I'm perfectly aware of that. But I consider that it's worth it. I chose to push my change early in the 3.9 development cycle, to get users feedback earlier. So we can still revert the change if they are too many complains.


Raymond Hettinger: "The other deprecation in the array module says, "Deprecated since version 3.3, will be removed in version 4.0".  Perhaps this one should have had the same qualifier."

I proposed PR 17523 to document that tostring() and fromstring() deprecated aliases will be removed in Python 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:20:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:20:45 +0000
Subject: [issue39003] test_unparse leaked [35, 5,
 6] references: when pass when run again
Message-ID: <1575897645.46.0.79915802392.issue39003@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Sometimes, test_unparse leak references, sometimes it pass.

$ ./python -m test -R 3:3 test_unparse
(...)
test_unparse leaked [35, 5, 6] references, sum=46
(...)
Tests result: FAILURE

$ ./python -m test -R 3:3 test_unparse
(...)
Tests result: SUCCESS

----------
components: Tests
messages: 358074
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_unparse leaked [35, 5, 6] references: when pass when run again
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:21:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:21:22 +0000
Subject: [issue39003] test_unparse leaked [35, 5, 6] references: fail randomly,
 pass when run again
In-Reply-To: <1575897645.46.0.79915802392.issue39003@roundup.psfhosted.org>
Message-ID: <1575897682.55.0.884237510344.issue39003@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_unparse leaked [35, 5, 6] references: when pass when run again -> test_unparse leaked [35, 5, 6] references: fail randomly, pass when run again

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:24:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:24:37 +0000
Subject: [issue39004] test_largefile: test_it() failed on
Message-ID: <1575897877.42.0.877682602403.issue39004@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

0:22:15 load avg: 15.82 [288/420/3] test_largefile failed (11 min 19 sec) -- running: test_capi (2 min 40 sec), test_compileall (3 min 42 sec), test_shelve (14 min 46 sec), test_sax (10 min 4 sec), test_dbm (3 min 36 sec), test_multiprocessing_spawn (13 min 21 sec), test_posix (3 min 39 sec), test_mailbox (12 min 46 sec), test_asyncio (9 min 23 sec)
beginning 6 repetitions
123456
.Warning -- threading._dangling was modified by test_largefile
  Before: {<weakref at 0x7f1cf0e08fb0; to '_MainThread' at 0x7f1cf19395a0>}
  After:  {<weakref at 0x7f1cf0526470; to '_MainThread' at 0x7f1cf19395a0>, <weakref at 0x7f1cf0526170; to 'Thread' at 0x7f1cf057a3c0>} 
test test_largefile failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.refleak/build/Lib/test/test_largefile.py", line 211, in test_it
    self.assertEqual(os.path.getsize(TESTFN2), size)
AssertionError: 2496925696 != 2500000001

----------
messages: 358075
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_largefile: test_it() failed on

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39004>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:25:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:25:53 +0000
Subject: [issue39004] test_largefile: TestSocketSendfile.test_it() failed on
 AMD64 Fedora Stable Refleaks 3.x
In-Reply-To: <1575897877.42.0.877682602403.issue39004@roundup.psfhosted.org>
Message-ID: <1575897953.3.0.42170597677.issue39004@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 Fedora Stable Refleaks 3.x:
https://buildbot.python.org/all/#/builders/126/builds/14

----------
components: +Tests
nosy: +giampaolo.rodola, pablogsal
title: test_largefile: test_it() failed on -> test_largefile: TestSocketSendfile.test_it() failed on AMD64 Fedora Stable Refleaks 3.x
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39004>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:28:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:28:39 +0000
Subject: [issue39005] test_faulthandler: test_dump_traceback_later_file()
 fails randomly on AMD64 RHEL8 Refleaks 3.x
Message-ID: <1575898119.77.0.459055301338.issue39005@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 RHEL8 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/206/builds/13

The system load was quite high: 12.64.

0:23:25 load avg: 12.64 [283/420/1] test_faulthandler failed (1 min 7 sec) -- running: test_bz2 (8 min 20 sec), test_dbm (12 min 51 sec), test_asyncio (14 min 46 sec), test_mmap (9 min 3 sec), test_zipfile (13 min 9 sec), test_mailbox (8 min 49 sec), test_largefile (8 min 15 sec), test_shelve (19 min 51 sec)
beginning 6 repetitions
123456
.test test_faulthandler failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_faulthandler.py", line 610, in test_dump_traceback_later_file
    self.check_dump_traceback_later(filename=filename)
  File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_faulthandler.py", line 594, in check_dump_traceback_later
    self.assertRegex(trace, regex)
AssertionError: Regex didn't match: '^Timeout \\(0:00:00.500000\\)!\\nThread 0x[0-9a-f]+ \\(most recent call first\\):\\n  File "<string>", line 17 in func\n  File "<string>", line 26 in <module>$' not found in 'Timeout (0:00:00.500000)!\nThread 0x00007f69484b2740 (most recent call first):\n  File "<string>", line 18 in func\n  File "<string>", line 26 in <module>'

The test passed when re-run in verbose mode. So it may be related to the high system load while tests were run in parallel.

----------
components: Tests
messages: 358077
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_faulthandler: test_dump_traceback_later_file() fails randomly on AMD64 RHEL8 Refleaks 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39005>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:28:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2019 13:28:44 +0000
Subject: [issue39003] test_unparse leaked [35, 5, 6] references: fail randomly,
 pass when run again
In-Reply-To: <1575897645.46.0.79915802392.issue39003@roundup.psfhosted.org>
Message-ID: <1575898124.7.0.837392568025.issue39003@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is not this test select random files in non-verbose mode?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:33:11 2019
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Mon, 09 Dec 2019 13:33:11 +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: <1575898391.3.0.974158758003.issue10915@roundup.psfhosted.org>


Change by Paulo Henrique Silva <ph.silva at gmail.com>:


----------
nosy: +phsilva

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:33:26 2019
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Mon, 09 Dec 2019 13:33:26 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1575898406.28.0.457342112803.issue15751@roundup.psfhosted.org>


Change by Paulo Henrique Silva <ph.silva at gmail.com>:


----------
nosy: +phsilva

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:33:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:33:26 +0000
Subject: [issue39006] test_ssl: sendfile tests fail on AMD64 Debian root 3.7
Message-ID: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Pablo wrote on the buildbot-status mailing list:
"It seems that this worker has some bad upgrade to SSL as all branches fail at the same time:"

AMD64 Debian root 3.7:
https://buildbot.python.org/all/#builders/3/builds/8

======================================================================
ERROR: test_sock_sendfile_exception (test.test_asyncio.test_unix_events.SelectorEventLoopUnixSockSendfileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 613, in test_sock_sendfile_exception
    sock, proto = self.prepare()
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 491, in prepare
    self.run_loop(self.loop.sock_connect(sock, (support.HOST, port)))
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 481, in run_loop
    return self.loop.run_until_complete(coro)
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/asyncio/selector_events.py", line 460, in sock_connect
    if isinstance(sock, ssl.SSLSocket):
AttributeError: 'NoneType' object has no attribute 'SSLSocket'
======================================================================
ERROR: test_sock_sendfile_iobuffer (test.test_asyncio.test_unix_events.SelectorEventLoopUnixSockSendfileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 524, in test_sock_sendfile_iobuffer
    sock, proto = self.prepare()
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 491, in prepare
    self.run_loop(self.loop.sock_connect(sock, (support.HOST, port)))
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 481, in run_loop
    return self.loop.run_until_complete(coro)
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/asyncio/selector_events.py", line 460, in sock_connect
    if isinstance(sock, ssl.SSLSocket):
AttributeError: 'NoneType' object has no attribute 'SSLSocket'
======================================================================
ERROR: test_sock_sendfile_not_a_file (test.test_asyncio.test_unix_events.SelectorEventLoopUnixSockSendfileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 515, in test_sock_sendfile_not_a_file
    sock, proto = self.prepare()
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 491, in prepare
    self.run_loop(self.loop.sock_connect(sock, (support.HOST, port)))
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/test/test_asyncio/test_unix_events.py", line 481, in run_loop
    return self.loop.run_until_complete(coro)
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/asyncio/base_events.py", line 579, in run_until_complete
    return future.result()
  File "/root/buildarea/3.7.angelico-debian-amd64/build/Lib/asyncio/selector_events.py", line 460, in sock_connect
    if isinstance(sock, ssl.SSLSocket):
AttributeError: 'NoneType' object has no attribute 'SSLSocket'

----------
assignee: christian.heimes
components: SSL, Tests
messages: 358079
nosy: christian.heimes, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_ssl: sendfile tests fail on AMD64 Debian root 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:34:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:34:30 +0000
Subject: [issue39006] test_ssl: sendfile tests fail on AMD64 Debian root 3.7
 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575898470.22.0.134972659658.issue39006@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

"""
Python build finished successfully!
The necessary bits to build these optional modules were not found:
_ssl                  _tkinter              _uuid              
"""

The _ssl module was not built on this worker, so why test_ssl was not skipped?

----------
title: test_ssl: sendfile tests fail on AMD64 Debian root 3.7 -> test_ssl: sendfile tests fail on AMD64 Debian root 3.7 when _ssl is missing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:35:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:35:02 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575898502.7.0.575261352727.issue39006@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components:  -SSL
nosy:  -christian.heimes
title: test_ssl: sendfile tests fail on AMD64 Debian root 3.7 when _ssl is missing -> test_asyncio: sendfile tests fail on AMD64 Debian root 3.7 when _ssl is missing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:36:10 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 13:36:10 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575898570.17.0.454128915034.issue39006@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I don't see test_ssl.py in the logs. test_unix_events.py is failing because it is missing a check for _ssl.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:41:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:41:57 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575898917.35.0.12633169327.issue39006@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17002
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17524

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:43:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:43:14 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575898994.21.0.525425684353.issue39006@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same issue on AMD64 Debian root 3.8:
https://buildbot.python.org/all/#builders/162/builds/14

And AMD64 Debian root 3.x:
https://buildbot.python.org/all/#builders/225/builds/28

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:45:35 2019
From: report at bugs.python.org (Kevin Buchs)
Date: Mon, 09 Dec 2019 13:45:35 +0000
Subject: [issue38987] 3.8.0 on GNU/Linux fails to find shared library
In-Reply-To: <1575845977.04.0.0620212715635.issue38987@roundup.psfhosted.org>
Message-ID: <CAKT9s6CSv3vPa6+wVEEgWa6CrgXfE9C2tGzz7-qTjcZ9vGcjgg@mail.gmail.com>


Kevin Buchs <kevin.buchs at gmail.com> added the comment:

No, I didn?t. But I had made no changes, so it should not have needed
changing.

On Sun, Dec 8, 2019 at 4:59 PM Christian Heimes <report at bugs.python.org>
wrote:

>
> Christian Heimes <lists at cheimes.de> added the comment:
>
> Did you update the ld.so cache with ldconfig?
>
> ----------
> nosy: +christian.heimes
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38987>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38987>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:46:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:46:37 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575899197.15.0.940275006368.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0381ea79ac2da03179c8512c581cac588b69cff9 by Victor Stinner in branch '3.8':
bpo-38916: Document array.array deprecation (GH-17523)
https://github.com/python/cpython/commit/0381ea79ac2da03179c8512c581cac588b69cff9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:47:02 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 13:47:02 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575899222.42.0.31962771194.issue38916@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17003
pull_request: https://github.com/python/cpython/pull/17525

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:47:40 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 09 Dec 2019 13:47:40 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575899260.5.0.960200608812.issue39006@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry, my fault.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:51:04 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 13:51:04 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575899464.05.0.179861966779.issue37404@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +17004
pull_request: https://github.com/python/cpython/pull/17526

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37404>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:52:06 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 13:52:06 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1575899526.37.0.165385452798.issue37404@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The patch broke Python builds without ssl support and caused a minor performance regression in hot paths. I changed the code to only perform the check in debug mode.

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37404>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:52:11 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 13:52:11 +0000
Subject: [issue38916] Remove array.fromstring
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575899531.5.0.860183410955.issue38916@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 21e11383cc59146184da0d69a3f19f004215f9a7 by Miss Islington (bot) in branch '3.7':
bpo-38916: Document array.array deprecation (GH-17523)
https://github.com/python/cpython/commit/21e11383cc59146184da0d69a3f19f004215f9a7


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:53:13 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 13:53:13 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575899593.2.0.169956724511.issue39006@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The problem was introduced by https://bugs.python.org/issue37404. I created https://github.com/python/cpython/pull/17526 to fix the problem and address a minor performance regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:58:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 13:58:48 +0000
Subject: [issue38916] Remove array.fromstring() and array.tostring() aliases, 
 deprecated since Python 3.2
In-Reply-To: <1574777328.39.0.275521337595.issue38916@roundup.psfhosted.org>
Message-ID: <1575899928.56.0.125913752827.issue38916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The aliases were deprecated since Python 3.2. It's now time to use the newer names.

array.array.fromstring() implictly converted Unicode to UTF-8:

$ python3
Python 3.7.5 (default, Oct 17 2019, 12:16:48) 
>>> import array
>>> a=array.array('B')
>>> a.fromstring('?uro')
>>> a
array('B', [226, 130, 172, 117, 114, 111])
>>> list('?uro'.encode('utf8'))
[226, 130, 172, 117, 114, 111]

The removal is now documented in 3.7 and 3.8.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Remove array.fromstring -> Remove array.fromstring() and array.tostring() aliases, deprecated since Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38916>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:02:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 14:02:08 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575900128.27.0.573096806643.issue39006@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 82b4950b5e92bec343a436b3f9c116400b66e1b9 by Victor Stinner in branch 'master':
bpo-39006: Fix asyncio when the ssl module is missing (GH-17524)
https://github.com/python/cpython/commit/82b4950b5e92bec343a436b3f9c116400b66e1b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:02:15 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:02:15 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575900135.72.0.867394120366.issue39006@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17005
pull_request: https://github.com/python/cpython/pull/17527

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:02:22 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:02:22 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575900142.4.0.517087854708.issue39006@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17006
pull_request: https://github.com/python/cpython/pull/17528

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:04:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 14:04:23 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575900263.77.0.821721902752.issue39006@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote a fix which was approved by Andrew Svetlov. Andrew prefers my PR than Christian's PR 17526, so I merged my PR instead. See PR 17526 discussion for the rationale.

I merged your PR to master, 3.7 and 3.8 backport will automatically follow. I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:11:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 14:11:36 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1575900696.83.0.450110121818.issue38699@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> https://github.com/python-trio/trio/blob/master/trio/_highlevel_open_tcp_listeners.py

Extract:

# A large backlog can also use a bit more kernel memory, but this seems fairly
# negligible these days.

That's the main question here. Python is used on various platforms for various use cases.

Extract of the current C code:

    /* We try to choose a default backlog high enough to avoid connection drops
     * for common workloads, yet not too high to limit resource usage. */
    int backlog = Py_MIN(SOMAXCONN, 128);

Maybe the status quo is just fine and this issue should be closed. It's trivial to override the default. This issue is stricted to the *default* value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:12:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 14:12:31 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1575900751.59.0.795022925275.issue38699@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

gunicorn, tornado, uwsgi, trio are specialized use cases which expect high concurrency.

Maybe a tradeoff may be to document the default and suggest different values depending on the use cases, and/or to point to documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:16:10 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:16:10 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1575900970.14.0.377994290118.issue20443@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Anything new here? 3.9.0a2 is due next week.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:16:57 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 09 Dec 2019 14:16:57 +0000
Subject: [issue38949] incorrect prefix,
 exec_prefix in distutils.command.install
In-Reply-To: <1575208886.3.0.139345727722.issue38949@roundup.psfhosted.org>
Message-ID: <1575901017.12.0.733757553724.issue38949@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

get_config_vars() defined in distutils.sysconfig sets 'prefix' and 'exec_prefix' using sys.prefix (resp. sys.exec_prefix) on non nt platforms so there is no problem. Closing the issue as not a bug.

----------
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38949>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:18:28 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:18:28 +0000
Subject: [issue38913] Py_BuildValue("(s#O)",
 ...) segfaults if entered with exception raised
In-Reply-To: <1574749641.72.0.139840395561.issue38913@roundup.psfhosted.org>
Message-ID: <1575901108.69.0.995336915635.issue38913@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: this is going to miss Python 3.8.1 as I'm releasing 3.8.1rc1 right now.  Please address this before 3.8.2 (due in February).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:18:37 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:18:37 +0000
Subject: [issue38856] wait_closed() can raise ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1575901117.23.0.04512927054.issue38856@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: this is going to miss Python 3.8.1 as I'm releasing 3.8.1rc1 right now.  Please address this before 3.8.2 (due in February).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:19:33 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:19:33 +0000
Subject: [issue30064] BaseSelectorEventLoop.sock_{recv,
 sendall}() don't remove their callbacks when canceled
In-Reply-To: <1492073709.93.0.33740565749.issue30064@psf.upfronthosting.co.za>
Message-ID: <1575901173.59.0.703635081628.issue30064@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: this is going to miss Python 3.8.1 as I'm releasing 3.8.1rc1 right now.  Please address this before 3.8.2 (due in February).

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30064>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:19:52 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:19:52 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575901192.42.0.336522592217.issue39006@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b22183f2738e0e6c23f8c5fb5b232768c184ec96 by Miss Islington (bot) in branch '3.8':
bpo-39006: Fix asyncio when the ssl module is missing (GH-17524)
https://github.com/python/cpython/commit/b22183f2738e0e6c23f8c5fb5b232768c184ec96


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:20:31 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:20:31 +0000
Subject: [issue39006] test_asyncio: sendfile tests fail on AMD64 Debian root
 3.7 when _ssl is missing
In-Reply-To: <1575898406.57.0.107596401277.issue39006@roundup.psfhosted.org>
Message-ID: <1575901231.15.0.168198853988.issue39006@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a0078d9a3335a5e99afe97590fdcb8e2f526ed7b by Miss Islington (bot) in branch '3.7':
bpo-39006: Fix asyncio when the ssl module is missing (GH-17524)
https://github.com/python/cpython/commit/a0078d9a3335a5e99afe97590fdcb8e2f526ed7b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39006>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:21:14 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:21:14 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575901274.42.0.416770428405.issue37228@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset ab513a38c98695f271e448fe2cb7c5e39eeaaaaf by ?ukasz Langa (Kyle Stanley) in branch 'master':
bpo-37228: Fix loop.create_datagram_endpoint()'s usage of SO_REUSEADDR (#17311)
https://github.com/python/cpython/commit/ab513a38c98695f271e448fe2cb7c5e39eeaaaaf


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:21:23 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:21:23 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575901283.57.0.335346587298.issue37228@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17007
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17529

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:26:48 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:26:48 +0000
Subject: [issue38410] Possible fatal errors due to
 _PyEval_SetAsyncGen{Finalizer, Firstiter}()
In-Reply-To: <1570543574.99.0.942798410146.issue38410@roundup.psfhosted.org>
Message-ID: <1575901608.37.0.106460680734.issue38410@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Note: this is going to miss Python 3.8.1 as I'm releasing 3.8.1rc1 right now.  Please address this before 3.8.2 (due in February).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38410>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:36:38 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2019 14:36:38 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575902198.27.0.474165210885.issue38992@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:


New changeset bba873e633f0f1e88ea12fb935cbd58faa77f976 by Mark Dickinson in branch 'master':
bpo-38992: avoid fsum test failure from constant-folding (GH-17513)
https://github.com/python/cpython/commit/bba873e633f0f1e88ea12fb935cbd58faa77f976


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38992>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:36:46 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:36:46 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575902206.93.0.62322831083.issue38992@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17008
pull_request: https://github.com/python/cpython/pull/17530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38992>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:39:58 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:39:58 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575902398.39.0.272485550723.issue37228@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 79c29742a8ba96fc933efe34e55e90537b3eb780 by ?ukasz Langa (Miss Islington (bot)) in branch '3.8':
bpo-37228: Fix loop.create_datagram_endpoint()'s usage of SO_REUSEADDR (GH-17311) (#17529)
https://github.com/python/cpython/commit/79c29742a8ba96fc933efe34e55e90537b3eb780


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:44:41 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:44:41 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575902681.58.0.160648792156.issue37228@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Kyle, I'm releasing 3.8.1rc1 now. Please add the What's New entry before next Monday (3.8.1).

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:54:27 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 14:54:27 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575903267.67.0.651543666313.issue34776@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset d219cc4180e7589807ebbef7421879f095e72a98 by ?ukasz Langa (Yury Selivanov) in branch 'master':
bpo-34776: Fix dataclasses to support __future__ "annotations" mode (#9518)
https://github.com/python/cpython/commit/d219cc4180e7589807ebbef7421879f095e72a98


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:54:43 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2019 14:54:43 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575903283.03.0.138297658708.issue38673@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Ned agreed, it's merged into 3.7, so let's close.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:54:52 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:54:52 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575903292.75.0.45527708136.issue34776@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17009
pull_request: https://github.com/python/cpython/pull/17531

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:54:58 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2019 14:54:58 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1572797735.67.0.327959954505.issue38673@roundup.psfhosted.org>
Message-ID: <1575903298.95.0.691694727639.issue38673@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:55:00 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 14:55:00 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575903300.04.0.992822558619.issue34776@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17010
pull_request: https://github.com/python/cpython/pull/17532

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:59:33 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 09 Dec 2019 14:59:33 +0000
Subject: [issue30064] BaseSelectorEventLoop.sock_{recv,
 sendall}() don't remove their callbacks when canceled
In-Reply-To: <1492073709.93.0.33740565749.issue30064@psf.upfronthosting.co.za>
Message-ID: <1575903573.88.0.57337572676.issue30064@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

As I wrote, I don't think that we should fix the code but the failed uvloop test is slightly weird instead.

Maybe I'm wrong, I need to communicate with Yuri anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30064>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:01:32 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 09 Dec 2019 15:01:32 +0000
Subject: [issue38856] wait_closed() can raise ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1575903692.53.0.413365979237.issue38856@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry, I've missed this issue.
I'll address it in a while.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:01:41 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 09 Dec 2019 15:01:41 +0000
Subject: [issue38856] wait_closed() can raise ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1575903701.57.0.884414092542.issue38856@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee:  -> asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:12:47 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2019 15:12:47 +0000
Subject: [issue38673] REPL shows continuation prompt (...) when comment or
 space entered
In-Reply-To: <1575903298.97.0.0511486000074.issue38673@roundup.psfhosted.org>
Message-ID: <CAP7+vJJqySxOEx+D2Ho0Q=rQg09QFM3b5dnBqdxk8oERsoNxPA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

(And I'm giving up on 3.6 and 2.7 as these are close to their end of life.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38673>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:31:39 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 09 Dec 2019 15:31:39 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>
Message-ID: <1575905499.68.0.710321200506.issue34793@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +17011
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17533

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34793>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:51:59 2019
From: report at bugs.python.org (Wator Sead)
Date: Mon, 09 Dec 2019 15:51:59 +0000
Subject: [issue37535] Client SSLSocket with select.select() always returns
 readable with OpenSSL 1.1.1
In-Reply-To: <1562731064.9.0.934832826159.issue37535@roundup.psfhosted.org>
Message-ID: <1575906719.4.0.0606102436683.issue37535@roundup.psfhosted.org>


Wator Sead <seahoh at gmail.com> added the comment:

All new releases which include an OpenSSL version above 1.1.1 has the same issue. Can anybody fix it? Thanks a lot!

----------
nosy: +seahoh
versions: +Python 3.5, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37535>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:53:17 2019
From: report at bugs.python.org (hai shi)
Date: Mon, 09 Dec 2019 15:53:17 +0000
Subject: [issue38956] argparse.BooleanOptionalAction should not add the
 default value to the help string by default
In-Reply-To: <1575327804.72.0.272027136625.issue38956@roundup.psfhosted.org>
Message-ID: <1575906797.61.0.608176902318.issue38956@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38956>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:07:55 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 16:07:55 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575907675.09.0.269111244059.issue34776@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 0d57db27f2c563b6433a220b646b50bdeff8a1f2 by ?ukasz Langa (Miss Islington (bot)) in branch '3.8':
bpo-34776: Fix dataclasses to support __future__ "annotations" mode (GH-9518) (#17531)
https://github.com/python/cpython/commit/0d57db27f2c563b6433a220b646b50bdeff8a1f2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:07:58 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 16:07:58 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575907678.44.0.264815447191.issue34776@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 66d7a5d58a88bce312bc4668f2cc54c9488c5bd8 by ?ukasz Langa (Miss Islington (bot)) in branch '3.7':
bpo-34776: Fix dataclasses to support __future__ "annotations" mode (GH-9518) (#17532)
https://github.com/python/cpython/commit/66d7a5d58a88bce312bc4668f2cc54c9488c5bd8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:08:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:08:09 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1575907689.91.0.533336721037.issue20443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17012
pull_request: https://github.com/python/cpython/pull/17534

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:12:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:12:21 +0000
Subject: [issue32312] Create Py_AtExitRegister C API
In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za>
Message-ID: <1575907941.8.0.759197308538.issue32312@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32312>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:12:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:12:37 +0000
Subject: [issue38829] Make the function flush_io accessible in the C-API
In-Reply-To: <1573991525.07.0.835950836621.issue38829@roundup.psfhosted.org>
Message-ID: <1575907957.39.0.109655388016.issue38829@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API -IO

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38829>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:12:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:12:46 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1575907966.02.0.107212049745.issue36346@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:13:02 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1575907982.25.0.0355325644471.issue18697@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:13:10 +0000
Subject: [issue37465] Incorrect documentation for `s#` arguments in C API
 argument parsing
In-Reply-To: <1561969220.64.0.698927964651.issue37465@roundup.psfhosted.org>
Message-ID: <1575907990.08.0.408308538356.issue37465@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37465>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:13:33 +0000
Subject: [issue35827] C API dictionary views type checkers are not documented
In-Reply-To: <1548417904.67.0.718119168094.issue35827@roundup.psfhosted.org>
Message-ID: <1575908013.01.0.848676500293.issue35827@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35827>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:13:39 +0000
Subject: [issue34272] Reorganize C API tests
In-Reply-To: <1532868961.04.0.56676864532.issue34272@psf.upfronthosting.co.za>
Message-ID: <1575908019.04.0.922030477516.issue34272@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34272>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:13:43 +0000
Subject: [issue30155] Add ability to get/set tzinfo on datetime instances in C
 API
In-Reply-To: <1493047646.24.0.156322797242.issue30155@psf.upfronthosting.co.za>
Message-ID: <1575908023.13.0.211997282627.issue30155@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:13:46 +0000
Subject: [issue33592] Document contextvars C API
In-Reply-To: <1526923723.99.0.682650639539.issue33592@psf.upfronthosting.co.za>
Message-ID: <1575908026.81.0.179154353566.issue33592@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33592>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:15:45 2019
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 09 Dec 2019 16:15:45 +0000
Subject: [issue30155] Add ability to get/set tzinfo on datetime instances in C
 API
In-Reply-To: <1493047646.24.0.156322797242.issue30155@psf.upfronthosting.co.za>
Message-ID: <1575908145.41.0.0276055515298.issue30155@roundup.psfhosted.org>


Change by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +Add timezone support to datetime C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:16:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:16:44 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1575908204.33.0.229474728441.issue20443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Anything new here? 3.9.0a2 is due next week.

I had it in my TODO list but I lost the bpo number. Thanks for the reminder :-) I wrote PR 17534 that I plan to merge as soon as the CI tests pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:26:07 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 16:26:07 +0000
Subject: [issue37535] Client SSLSocket with select.select() always returns
 readable with OpenSSL 1.1.1
In-Reply-To: <1562731064.9.0.934832826159.issue37535@roundup.psfhosted.org>
Message-ID: <1575908767.75.0.184499569809.issue37535@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The problem is caused by the way how TLS 1.3 works. Select considers a TLS 1.3 socket as readable after the handshake, because there is still data on the line. The server is sending session tickets (usually two) after the handshake has been performed. If you set "context.num_tickets = 0" in server.py or "context.maximum_version = ssl.TLSVersion.TLSv1_2" in either server.py or client.py, your script works. Ticket #37120 has more information on that.

Session tickets are low-level TLS protocol elements. Methods like SSLSocket.pending() and SSLSocket.recv() only act on high-level application protocol data. That's why pending() returns 0 and recv() is blocking. There is no application data available.

You have to take another approach and follow the guidelines in 
https://docs.python.org/3/library/ssl.html#notes-on-non-blocking-sockets . You also have to set the SSLSocket into non-blocking mode and handle SSLWantWriteError or SSLWantReadError.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37535>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:34:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 16:34:06 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1575909246.19.0.157953486247.issue20443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b by Victor Stinner in branch 'master':
bpo-20443: No longer make sys.argv[0] absolute for script (GH-17534)
https://github.com/python/cpython/commit/a1a99b4bb7cbe2dbc55a1d92c3c509b4466d3c3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:41:55 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 09 Dec 2019 16:41:55 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1575909715.43.0.0548716626787.issue34776@roundup.psfhosted.org>


Change by ?ukasz Langa <lukasz at langa.pl>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34776>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:45:07 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 16:45:07 +0000
Subject: [issue38987] 3.8.0 on GNU/Linux fails to find shared library
In-Reply-To: <1575652752.94.0.770020872085.issue38987@roundup.psfhosted.org>
Message-ID: <1575909907.15.0.161270617944.issue38987@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

On Ubuntu and other Linux distros you must run ldconfig any time you install or change a shared library. Otherwise the dynamic linker won't be able to locate the shared library. 

I'm able to confirm that python3.8 does not work prior to calling, but works after calling ldconfig.

# ./configure --enable-shared
# make
# make install
# python3.8
python3.8: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory
# ldconfig
# python3.8
Python 3.8.0 (default, Dec  9 2019, 16:36:58) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38987>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:55:37 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2019 16:55:37 +0000
Subject: [issue38987] 3.8.0 on GNU/Linux fails to find shared library
In-Reply-To: <1575652752.94.0.770020872085.issue38987@roundup.psfhosted.org>
Message-ID: <1575910537.56.0.531651512564.issue38987@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

ld.so and ldd don't use /etc/ld.so.conf to locate libraries. They use /etc/ld.so.cache, which is created by ldconfig from /etc/ld.so.conf. The cache is typically the first file opened by a dynamically linked binary.

# ls -la /usr/local/lib/libpython3.*
lrwxrwxrwx. 1 root root       19 Dec  9 16:49 /usr/local/lib/libpython3.8.so -> libpython3.8.so.1.0
-rwxr-xr-x. 1 root root 17356488 Dec  9 16:49 /usr/local/lib/libpython3.8.so.1.0
-rwxr-xr-x. 1 root root     7448 Dec  9 16:49 /usr/local/lib/libpython3.so
# ldd /usr/local/bin/python3.8
        linux-vdso.so.1 (0x00007fff499d9000)
        libpython3.8.so.1.0 => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd1cd2f9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd1cd8ec000)
# ldconfig
# ldd /usr/local/bin/python3.8
        linux-vdso.so.1 (0x00007ffe19d9a000)
        libpython3.8.so.1.0 => /usr/local/lib/libpython3.8.so.1.0 (0x00007ff7f46f7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff7f4306000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff7f40e7000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff7f3ee3000)
        libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff7f3ce0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff7f3942000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff7f4ea4000)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38987>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:59:31 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2019 16:59:31 +0000
Subject: [issue36982] Add support for extended color functions in ncurses 6.1
In-Reply-To: <1558406631.2.0.0939623901621.issue36982@roundup.psfhosted.org>
Message-ID: <1575910771.12.0.874337812137.issue36982@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +17013
pull_request: https://github.com/python/cpython/pull/17536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36982>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:27:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 09 Dec 2019 17:27:24 +0000
Subject: [issue39003] test_unparse leaked [35, 5, 6] references: fail randomly,
 pass when run again
In-Reply-To: <1575897645.46.0.79915802392.issue39003@roundup.psfhosted.org>
Message-ID: <1575912444.88.0.927934639415.issue39003@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17014
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17537

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:27:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 17:27:29 +0000
Subject: [issue39007] Add audit hooks to winreg module
Message-ID: <1575912449.96.0.963204741941.issue39007@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The winreg module should have hooks added.

----------
assignee: steve.dower
components: Windows
messages: 358119
nosy: christian.heimes, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Add audit hooks to winreg module
type: security
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39007>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:32:40 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2019 17:32:40 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575912760.91.0.955607890826.issue38992@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:


New changeset 3c5feaffde1944052830c896ae39c54e76a2e063 by Mark Dickinson (Miss Islington (bot)) in branch '3.8':
bpo-38992: avoid fsum test failure from constant-folding (GH-17513) (GH-17530)
https://github.com/python/cpython/commit/3c5feaffde1944052830c896ae39c54e76a2e063


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38992>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:42:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 09 Dec 2019 17:42:23 +0000
Subject: [issue39002] Small typo in Lib/test/test_statistics.py: tranlation ->
 translation
In-Reply-To: <1575885863.07.0.931006878505.issue39002@roundup.psfhosted.org>
Message-ID: <1575913343.77.0.751996350967.issue39002@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c18b805ac6a2d22176240ca93982fa1fb6559ec7 by Raymond Hettinger (Tim Gates) in branch 'master':
bpo-39002: Fix simple typo: tranlation -> translation (GH-17517)
https://github.com/python/cpython/commit/c18b805ac6a2d22176240ca93982fa1fb6559ec7


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39002>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:42:37 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 17:42:37 +0000
Subject: [issue39002] Small typo in Lib/test/test_statistics.py: tranlation ->
 translation
In-Reply-To: <1575885863.07.0.931006878505.issue39002@roundup.psfhosted.org>
Message-ID: <1575913357.25.0.478603416915.issue39002@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +17015
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17538

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39002>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:57:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 09 Dec 2019 17:57:57 +0000
Subject: [issue39003] test_unparse leaked [35, 5, 6] references: fail randomly,
 pass when run again
In-Reply-To: <1575897645.46.0.79915802392.issue39003@roundup.psfhosted.org>
Message-ID: <1575914277.47.0.829137234678.issue39003@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset ac229116a34a679511c20bfeca167cc6a9df9807 by Pablo Galindo in branch 'master':
bpo-39003: Make sure all test are the same when using -R in test_unparse (GH-17537)
https://github.com/python/cpython/commit/ac229116a34a679511c20bfeca167cc6a9df9807


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:58:10 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 09 Dec 2019 17:58:10 +0000
Subject: [issue39003] test_unparse leaked [35, 5, 6] references: fail randomly,
 pass when run again
In-Reply-To: <1575897645.46.0.79915802392.issue39003@roundup.psfhosted.org>
Message-ID: <1575914290.23.0.631141832862.issue39003@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/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:22:49 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2019 18:22:49 +0000
Subject: [issue38992] testFsum failure caused by constant folding of a float
 expression
In-Reply-To: <1575718328.32.0.686761855241.issue38992@roundup.psfhosted.org>
Message-ID: <1575915769.23.0.739609679343.issue38992@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in master and 3.8. Not sure this is worth backporting to 3.7.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38992>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:33:10 2019
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 09 Dec 2019 18:33:10 +0000
Subject: [issue38981] better name for re.error Exception class.
In-Reply-To: <1575564967.92.0.182367459899.issue38981@roundup.psfhosted.org>
Message-ID: <1575916390.23.0.231078286947.issue38981@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

> RECompileError, REParseError, RESyntaxError, REError, CompileError, ParseError, SyntaxError or Error, 

> Many modules [...] have an exception named just Error

RECompileError, REParseError, RESyntaxError, REError, CompileError, ParseError are all fine with me. 

SyntaxError would be super confusing IMHO.
Remember the StackTrace does not get the fully qualified name, so it would be hard to distinguish from a SyntaxError with the Python Syntax.

aifc, binhex, sunau, uu, xdrlib might be removed with PEP 594, And I find  `Error` not informative enough. It suffers from the same issues as above, as stack traces do not have the full qualified name. 

I would also add that being able to search and find all occurrences of a given exceptions is useful, and that Error is too generic.

Let me know your choice and I can rename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38981>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:34:13 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 18:34:13 +0000
Subject: [issue39008] PySys_Audit should require PY_SSIZE_T_CLEAN
Message-ID: <1575916453.13.0.923153204552.issue39008@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Currently, calls to PySys_Audit() that use "#" format strings will raise a deprecation warning because Python/sysmodule.c is not PY_SSIZE_T_CLEAN

Since PySys_Audit is a new API, we should just define it as always requiring Py_ssize_t.

(Discovered while implementing issue39007).

----------
assignee: steve.dower
messages: 358125
nosy: steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: PySys_Audit should require PY_SSIZE_T_CLEAN
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39008>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:39:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 18:39:57 +0000
Subject: [issue39008] PySys_Audit should require PY_SSIZE_T_CLEAN
In-Reply-To: <1575916453.13.0.923153204552.issue39008@roundup.psfhosted.org>
Message-ID: <1575916797.76.0.1831511319.issue39008@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +17016
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17540

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39008>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:41:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 18:41:59 +0000
Subject: [issue39007] Add audit hooks to winreg module
In-Reply-To: <1575912449.96.0.963204741941.issue39007@roundup.psfhosted.org>
Message-ID: <1575916919.23.0.800169967509.issue39007@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +17017
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17541

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39007>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:50:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Dec 2019 18:50:54 +0000
Subject: [issue38990] Import genericpath fails with python -S
In-Reply-To: <1575668539.27.0.598357359198.issue38990@roundup.psfhosted.org>
Message-ID: <1575917454.49.0.315971253688.issue38990@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks for the report, Brittany, but I'm closing as "won't fix" as the only way to make this happen is to import genericpath directly which one shouldn't do (it's undocumented on purpose); always get a hold of this module via 'os'.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38990>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:55:38 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Dec 2019 18:55:38 +0000
Subject: [issue25160] Stop using deprecated imp module;
 imp should now emit a real DeprecationWarning
In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za>
Message-ID: <1575917738.92.0.433034674332.issue25160@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> Any reason to keep imp there?

Nope, not anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25160>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:57:38 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 09 Dec 2019 18:57:38 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1575917858.07.0.227695677048.issue20443@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I am not sure that if co_filename can break backwards compability or not (because until CodeType.replace; it was usual to break code object construction, people who are using code objects may take this too) but yes PR 17534 was necessary. 

My initial patch (PR 13527) proposed a future directive to do this (and poorly implemented the concept) which can be helpful (yet it needs a PEP).

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:01:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 19:01:12 +0000
Subject: [issue38989] pip install selects 32 bit wheels for 64 bit python if
 vcvarsall.bat amd64_x86 in environment
In-Reply-To: <1575658185.88.0.621824601443.issue38989@roundup.psfhosted.org>
Message-ID: <1575918072.47.0.521588067829.issue38989@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> maybe you have some relevant context

Nothing you haven't figured out yourself. As you say, they're both private functions, and as we investigated adding a "get_target_platform" function, it turned out that nearly all users were expecting the target platform, so rather than updating everything we added one for the less-common case.

get_host_platform was not defined before, so I'd say use it if it's there and use get_platform if it's not.

I doubt we're going to add any new public/supported APIs to distutils ever again, to be honest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38989>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:05:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 19:05:46 +0000
Subject: [issue39008] PySys_Audit should require PY_SSIZE_T_CLEAN
In-Reply-To: <1575916453.13.0.923153204552.issue39008@roundup.psfhosted.org>
Message-ID: <1575918346.27.0.311065253991.issue39008@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset b8cbe74c3498c617f0e73fd0cdc5c07f2c532092 by Steve Dower in branch 'master':
bpo-39008: Require Py_ssize_t for PySys_Audit formats rather than raise a deprecation warning (GH-17540)
https://github.com/python/cpython/commit/b8cbe74c3498c617f0e73fd0cdc5c07f2c532092


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39008>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:05:51 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 19:05:51 +0000
Subject: [issue39008] PySys_Audit should require PY_SSIZE_T_CLEAN
In-Reply-To: <1575916453.13.0.923153204552.issue39008@roundup.psfhosted.org>
Message-ID: <1575918351.6.0.812112441343.issue39008@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17018
pull_request: https://github.com/python/cpython/pull/17542

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39008>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:10:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 19:10:57 +0000
Subject: [issue39008] PySys_Audit should require PY_SSIZE_T_CLEAN
In-Reply-To: <1575916453.13.0.923153204552.issue39008@roundup.psfhosted.org>
Message-ID: <1575918657.65.0.0907838075906.issue39008@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39008>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:17:40 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 09 Dec 2019 19:17:40 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1575919060.54.0.18663800112.issue37193@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:18:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 19:18:16 +0000
Subject: [issue39007] Add audit hooks to winreg module
In-Reply-To: <1575912449.96.0.963204741941.issue39007@roundup.psfhosted.org>
Message-ID: <1575919096.48.0.602219317358.issue39007@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset ee17e3735634c5fe15a43f897707de8011618627 by Steve Dower in branch 'master':
bpo-39007: Add auditing events to functions in winreg (GH-17541)
https://github.com/python/cpython/commit/ee17e3735634c5fe15a43f897707de8011618627


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39007>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:18:25 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 19:18:25 +0000
Subject: [issue39007] Add audit hooks to winreg module
In-Reply-To: <1575912449.96.0.963204741941.issue39007@roundup.psfhosted.org>
Message-ID: <1575919105.32.0.227437427968.issue39007@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17019
pull_request: https://github.com/python/cpython/pull/17543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39007>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:19:34 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Dec 2019 19:19:34 +0000
Subject: [issue39007] Add audit hooks to winreg module
In-Reply-To: <1575912449.96.0.963204741941.issue39007@roundup.psfhosted.org>
Message-ID: <1575919174.67.0.503178236496.issue39007@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/issue39007>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:22:37 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 19:22:37 +0000
Subject: [issue39008] PySys_Audit should require PY_SSIZE_T_CLEAN
In-Reply-To: <1575916453.13.0.923153204552.issue39008@roundup.psfhosted.org>
Message-ID: <1575919356.99.0.879645493015.issue39008@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c93d68bbb986ee0879f5627223e0bd2bb91f63dd by Miss Islington (bot) in branch '3.8':
bpo-39008: Require Py_ssize_t for PySys_Audit formats rather than raise a deprecation warning (GH-17540)
https://github.com/python/cpython/commit/c93d68bbb986ee0879f5627223e0bd2bb91f63dd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39008>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:26:01 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 09 Dec 2019 19:26:01 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1575919561.81.0.0438149143946.issue37193@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This issue was also [reported in prometheus client](https://salsa.debian.org/debian/python-prometheus-client/commit/5aa256d8aab3b81604b855dc03f260342fc391fb) where the workaround was to use daemon threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:27:25 2019
From: report at bugs.python.org (Tim Gates)
Date: Mon, 09 Dec 2019 19:27:25 +0000
Subject: [issue39009] Small typo in Lib/test/test__locale.py: thousauds ->
 thousands
Message-ID: <1575919645.59.0.654742872958.issue39009@roundup.psfhosted.org>


New submission from Tim Gates <tim.gates at iress.com>:

In "Lib/test/test__locale.py" the text should read thousands rather than thousauds.

----------
messages: 358134
nosy: timgates42
priority: normal
severity: normal
status: open
title: Small typo in Lib/test/test__locale.py: thousauds -> thousands

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39009>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:34:07 2019
From: report at bugs.python.org (Tim Gates)
Date: Mon, 09 Dec 2019 19:34:07 +0000
Subject: [issue39009] Small typo in Lib/test/test__locale.py: thousauds ->
 thousands
In-Reply-To: <1575919645.59.0.654742872958.issue39009@roundup.psfhosted.org>
Message-ID: <1575920047.35.0.8222635972.issue39009@roundup.psfhosted.org>


Change by Tim Gates <tim.gates at iress.com>:


----------
keywords: +patch
pull_requests: +17020
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17544

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39009>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:36:29 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 19:36:29 +0000
Subject: [issue39007] Add audit hooks to winreg module
In-Reply-To: <1575912449.96.0.963204741941.issue39007@roundup.psfhosted.org>
Message-ID: <1575920189.82.0.39273993821.issue39007@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0ac9aaeb9727aa60bef918b619116a729d3ea56d by Miss Islington (bot) in branch '3.8':
bpo-39007: Add auditing events to functions in winreg (GH-17541)
https://github.com/python/cpython/commit/0ac9aaeb9727aa60bef918b619116a729d3ea56d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39007>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:41:23 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 09 Dec 2019 19:41:23 +0000
Subject: [issue39009] Small typo in Lib/test/test__locale.py: thousauds ->
 thousands
In-Reply-To: <1575919645.59.0.654742872958.issue39009@roundup.psfhosted.org>
Message-ID: <1575920483.78.0.660628839699.issue39009@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
assignee:  -> pablogsal
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39009>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:48:04 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2019 19:48:04 +0000
Subject: [issue38990] Import genericpath fails with python -S
In-Reply-To: <1575668539.27.0.598357359198.issue38990@roundup.psfhosted.org>
Message-ID: <1575920884.08.0.656782541712.issue38990@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue31802. I skipped genericpath because I did not expect that somebody can import it directly (unlike to posixpath, ntpath and macpath). genericpath is an internal module, it is not even documented.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38990>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:48:55 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2019 19:48:55 +0000
Subject: [issue38990] Import genericpath fails with python -S
In-Reply-To: <1575668539.27.0.598357359198.issue38990@roundup.psfhosted.org>
Message-ID: <1575920935.0.0.942369727122.issue38990@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38990>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:11:43 2019
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Mon, 09 Dec 2019 20:11:43 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1575922303.86.0.895932963324.issue38630@roundup.psfhosted.org>


????? ???????? <dpb at corrigendum.ru> added the comment:

> What you do is split 'wait' into two parts: first it waits for me process to become reapable without actually reaping it. On Linux you can do this with waitid+WNOWAIT. On kqueue platforms you can do it with kqueue.

> Then, you take a lock, and use it to atomically call waitpid/waitid to reap the process + update self.returncode to record that you've done so.

> In send_signal, we use the same lock to atomically check whether the process has been reaped, and then send the signal if it hasn't.

It's a good idea, but it would break the scenario where two threads call wait() concurrently. It would create this race condition:

1. Thread A reaps the process.
2. Thread B thinks the process is still running, so it calls waitid+WNOHANG on a stale PID, with unpredictable results.
3. Thread A sets self.returncode.

What is needed here is a reader-writer lock. subprocess.wait would work like this (pseudocode):

with lock taken for reading:
    os.waitid(..., WNOHANG)
with lock taken for writing:
    os.waitid(...)
    self.returncode = ...

Whereas subprocess.send_signal would work like this:

with lock taken for reading:
    os.kill(...)

Unfortunately, it doesn't seem like Python has reader-writer locks in the library...

----------
nosy: +SpecLad

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:20:57 2019
From: report at bugs.python.org (Sergey Fedoseev)
Date: Mon, 09 Dec 2019 20:20:57 +0000
Subject: [issue27961] remove support for platforms without "long long"
In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za>
Message-ID: <1575922857.45.0.502204566828.issue27961@roundup.psfhosted.org>


Change by Sergey Fedoseev <fedoseev.sergey at gmail.com>:


----------
pull_requests: +17021
pull_request: https://github.com/python/cpython/pull/17539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27961>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:22:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 20:22:24 +0000
Subject: [issue27961] remove support for platforms without "long long"
In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za>
Message-ID: <1575922944.15.0.837345051574.issue27961@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a2ff283d519be11f50220885ddc4d029eb8cb0a0 by Victor Stinner (Sergey Fedoseev) in branch 'master':
bpo-27961: Replace PY_ULLONG_MAX with ULLONG_MAX (GH-17539)
https://github.com/python/cpython/commit/a2ff283d519be11f50220885ddc4d029eb8cb0a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27961>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:27:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 20:27:31 +0000
Subject: [issue39003] test_unparse leaked [35, 5, 6] references: fail randomly,
 pass when run again
In-Reply-To: <1575914290.26.0.526382801444.issue39003@roundup.psfhosted.org>
Message-ID: <CABqyc3zfCHO+9zOpdoJfcpw2FQWL+WZiXbYCEr6sMr2896gTBg@mail.gmail.com>


STINNER Victor <vstinner at python.org> added the comment:

Thanks for the quick fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39003>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:47:38 2019
From: report at bugs.python.org (Jonathan Slenders)
Date: Mon, 09 Dec 2019 20:47:38 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
Message-ID: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>


New submission from Jonathan Slenders <jonathan.slenders at gmail.com>:

We have a snippet of code that runs perfectly fine using the `SelectorEventLoop`, but crashes *sometimes* using the `ProactorEventLoop`.

The traceback is the following. The exception cannot be caught within the asyncio application itself (e.g., it is not attached to any Future or propagated in a coroutine). It probably propagates in `run_until_complete()`.

  File "C:\Python38\lib\asyncio\proactor_events.py", line 768, in _loop_self_reading
    f.result()  # may raise
  File "C:\Python38\lib\asyncio\windows_events.py", line 808, in _poll
    value = callback(transferred, key, ov)
  File "C:\Python38\lib\asyncio\windows_events.py", line 457, in finish_recv
    raise ConnectionResetError(*exc.args)

I can see that in `IocpProactor._poll`, `OSError` is caught and attached to the future, but not `ConnectionResetError`. I would expect that `ConnectionResetError` too will be attached to the future.

In order to reproduce, run the following snippet on Python 3.8:

from prompt_toolkit import prompt  # pip install prompt_toolkit
while 1:
    prompt('>')

Hold down the enter key, and it'll trigger quickly.

See also: https://github.com/prompt-toolkit/python-prompt-toolkit/issues/1023

----------
components: asyncio
messages: 358140
nosy: Jonathan Slenders, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: ProactorEventLoop raises unhandled ConnectionResetError
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:57:39 2019
From: report at bugs.python.org (Jonathan Slenders)
Date: Mon, 09 Dec 2019 20:57:39 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1575925059.28.0.623769035231.issue39010@roundup.psfhosted.org>


Jonathan Slenders <jonathan.slenders at gmail.com> added the comment:

Suppressing `ConnectionResetError` in `BaseProactorEventLoop._loop_self_reading`, like we do with `CancelledError` seems to fix it.

Although I'm not sure what it causing the error, and whether we need to handle it somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:18:18 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 09 Dec 2019 21:18:18 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1575926298.63.0.236571067399.issue38630@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

>  Thread B thinks the process is still running, so it calls waitid+WNOHANG on a stale PID, with unpredictable results.

I'm pretty sure you mean WNOWAIT, right? The actual reaping step (which might use WNOHANG) is already protected by a lock, but there's a danger that a process might try to perform the blocking-until-exit step (which uses WNOWAIT) on a stale pid.


Good catch!

I think this can be fixed by using a second lock around all of .wait(). But this is a bit tricky because we also need to account for concurrent .poll() calls. So something like:

def wait(self):
    # Don't take the big lock unless the process is actually still running
    # This isn't just an optimization; it's critical for poll() correctness
    if self.poll() is not None:
        return self.returncode

    with self._blocking_wait_lock:
        with self._returncode_lock:
            revalidate pid licenses

        block_until_child_exits()

        with self._returncode_lock:
            reap the child and mark it as reaped

def poll(self):
    # if someone is already blocked waiting for the child, then it definitely
    # hasn't exited yet, so we don't need to call waitpid ourselves.
    # This isn't just an optimization; it's critical for correctness.
    if not self._blocking_wait_lock.acquire(blocking=False):
        return None
    try:
        with self._returncode_lock:
            do the actual poll + returncode updating
    finally:
        self._blocking_wait_lock.release()

Notes:

If there's already a wait() running, and someone calls poll(), then we have to make sure the poll() can't reap the process out from under the wait(). To fix that, poll skips trying in case wait is already running.

But, this could introduce its own race condition: if a process has exited but we haven't noticed yet, and then someone calls wait() and poll() simultaneously, then the wait() might take the lock, then poll() notices the lock is taken, and concludes that the process can't have exited yet. If course wait() will immediately reap the process and drop the lock, but by this point poll() has already returned the wrong information.

The problem is that poll() needs to be able to treat "the blocking wait lock is taken" as implying "the process hasn't exited yet". So to make that implication true, we add a check at the top of wait().

Of course if a process exits while wait() is running, and someone calls poll() in that brief interval between it exiting and wait() noticing, then poll() could again fail to report it exiting. But I think this is fine: it's ok if poll() is a fraction of a second out of date; that race condition is inherent in its API. The problem would be if the fails to notice a process that exited a while ago and is just sitting around waiting to be reaped.

... Ugh but there is still one more race condition here. I think this fixes all the cases involving send_signal, wait, and poll interactions with each other, BUT we broke the case of two threads calling poll() at the same time. One thread will take the blocking_wait_lock, then the other will take this as evidence that someone is blocked in wait() and exit early, which isn't appropriate.

I think we can patch up this last race condition by adding yet one more lock: a simple

with self._poll_lock:

around the whole body of poll(), so that only one thread can call it at a time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:28:39 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 09 Dec 2019 21:28:39 +0000
Subject: [issue38699] socket: change listen() default backlog from 128 to 4096?
In-Reply-To: <1572965147.18.0.658730209941.issue38699@roundup.psfhosted.org>
Message-ID: <1575926919.57.0.219196462401.issue38699@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

Yeah, I don't think it matters that much. There are lots of random gotchas that you have to watch out for using the socket module.

To be clear: I do still think that using a large value by default, and clamping user input values at 65535, would be improvements. I just don't think they're important enough to spend energy arguing about it :-).

The reason I'm not worried about large backlogs wasting kernel memory is that servers all call accept as fast as they can. This means any incoming connection flood will end up taking memory regardless of the size of the kernel-side buffer. And I'm pretty sure the kernel buffer ia a linked list, so setting it to a large value doesn't cost anything if you're not using it.

Anyway asyncio at least should probably update its default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:34:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2019 21:34:59 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1575927299.65.0.341927118131.issue39010@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

ConnectionResetError means that the pipe socket is closed. Was the event loop closed? Can you provide a reproducer? Can you try to get debug logs to see what's going on?
https://docs.python.org/dev/library/asyncio-dev.html#debug-mode

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:41:44 2019
From: report at bugs.python.org (Baptiste Mispelon)
Date: Mon, 09 Dec 2019 21:41:44 +0000
Subject: [issue38975] Add direct anchors to regex syntax documentation
In-Reply-To: <1575493951.25.0.258282311971.issue38975@roundup.psfhosted.org>
Message-ID: <1575927704.7.0.59738595148.issue38975@roundup.psfhosted.org>


Baptiste Mispelon <bmispelon at gmail.com> added the comment:

I've tried using subsection (level 3) for each syntax element and I'm not sure it's a big improvement.

Pros:
  * Visible ? anchors which make it easier to copy/paste a reference link


Cons:
  * <h3> headings have a slightly different style (bigger font, no background color)
  * All the added titles show up in the table of content (might not be a problem)
  * Lots of re-indenting is needed which makes the diff quite noisy (even without reflowing the paragraphs)

I'm not sure what's the best way to share this alternative. A new PR? An extra commit on the existing PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38975>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:46:45 2019
From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=)
Date: Mon, 09 Dec 2019 21:46:45 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1575928005.31.0.0102439322645.issue38630@roundup.psfhosted.org>


????? ???????? <dpb at corrigendum.ru> added the comment:

> I'm pretty sure you mean WNOWAIT, right?

Right.

> revalidate pid licenses

What does this mean?

> I think we can patch up this last race condition by adding yet one more lock

Wouldn't it be sufficient to add

if self.returncode is not None:
    return self.returncode

at the top of poll()?

(And in fact, you don't even need to add it, since an equivalent of this check is already there.)

I think this makes calling poll() from wait() unnecessary too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:04:42 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 09 Dec 2019 22:04:42 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1575929082.29.0.239567961278.issue38630@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

>             revalidate pid licenses

It means autocorrect mangled the text... I don't remember what word that's supposed to be, but basically I meant "revalidate the pid hasn't been reaped"

> Wouldn't it be sufficient to add
> 
> if self.returncode is not None:
>     return self.returncode
> 
> at the top of poll()?

No, the race condition is:

1. Process exits
[some time passes]
2. Thread 1 and Thread 2 both call poll() simultaneously
3. Thread 1 and Thread 2 both see that the process hasn't been reaped
4. Thread 1 attempts to take the blocking_wait_lock, to make sure no-one is blocked in wait(). It succeeds.
5. Thread 2 attempts to take the blocking_wait_lock, and it fails (because Thread 1 already has it). Thread 2's poll() returns saying that the process hasn't exited yet (which is wrong!)
6. Thread 1 calls waitpid(..., WNOHANG) and reaps the process, then releases the lock.

So adding a check at the top (= step 3) doesn't help. The problem is in steps 4/5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:16:04 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 09 Dec 2019 22:16:04 +0000
Subject: [issue39009] Small typo in Lib/test/test__locale.py: thousauds ->
 thousands
In-Reply-To: <1575919645.59.0.654742872958.issue39009@roundup.psfhosted.org>
Message-ID: <1575929764.88.0.163678968168.issue39009@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 2ad7651c00c9b58b2b8b9e3687c82c203ece576c by Pablo Galindo (Tim Gates) in branch 'master':
bpo-39009: Fix typo in test__locale (GH-17544)
https://github.com/python/cpython/commit/2ad7651c00c9b58b2b8b9e3687c82c203ece576c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39009>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:16:23 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 09 Dec 2019 22:16:23 +0000
Subject: [issue39009] Small typo in Lib/test/test__locale.py: thousauds ->
 thousands
In-Reply-To: <1575919645.59.0.654742872958.issue39009@roundup.psfhosted.org>
Message-ID: <1575929783.9.0.94073314092.issue39009@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/issue39009>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:22:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2019 23:22:20 +0000
Subject: [issue38944] Idle autocomplete window doesn't close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575933740.62.0.139190933737.issue38944@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 232689b40d8fcbbac27c8705607ff482ea5b46f8 by Terry Jan Reedy (JohnnyNajera) in branch 'master':
bpo-38944: Escape key now closes IDLE completion windows. (GH-17419)
https://github.com/python/cpython/commit/232689b40d8fcbbac27c8705607ff482ea5b46f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:22:29 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 23:22:29 +0000
Subject: [issue38944] Idle autocomplete window doesn't close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575933749.4.0.686709600041.issue38944@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17022
pull_request: https://github.com/python/cpython/pull/17546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:22:36 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 23:22:36 +0000
Subject: [issue38944] Idle autocomplete window doesn't close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575933756.07.0.904280561587.issue38944@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17023
pull_request: https://github.com/python/cpython/pull/17547

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:22:50 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2019 23:22:50 +0000
Subject: [issue27609] IDLE completions: format, factor, and fix
In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za>
Message-ID: <1575933770.77.0.574969177748.issue27609@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

38943 Autocomplete box sometimes does not show on Ubuntu.
38944 Excape key should close completion box.

----------
dependencies: +Idle autocomplete window doesn't close on Escape key, Idle autocomplete window doesn't show up

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27609>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:32:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2019 23:32:35 +0000
Subject: [issue38944] Idle completion windows should close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575934355.67.0.71451007388.issue38944@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With this done, we can think about whether the behavior of <Return> should be changed (on a new issue).  I need to first document what it does do in all the different situations.

----------
stage: patch review -> backport needed
title: Idle autocomplete window doesn't close on Escape key -> Idle completion windows should close on Escape key
type:  -> behavior
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:38:37 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 23:38:37 +0000
Subject: [issue38944] Idle completion windows should close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575934717.12.0.442949979374.issue38944@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b2c7bf231aadc0dd985e02549b1a8b93334047a by Miss Islington (bot) in branch '3.8':
bpo-38944: Escape key now closes IDLE completion windows. (GH-17419)
https://github.com/python/cpython/commit/2b2c7bf231aadc0dd985e02549b1a8b93334047a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:40:16 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 09 Dec 2019 23:40:16 +0000
Subject: [issue38944] Idle completion windows should close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575934816.25.0.235673113548.issue38944@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4e0e452dd06a0f3565d94075188d1fd1f60d4d65 by Miss Islington (bot) in branch '3.7':
bpo-38944: Escape key now closes IDLE completion windows. (GH-17419)
https://github.com/python/cpython/commit/4e0e452dd06a0f3565d94075188d1fd1f60d4d65


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:40:50 2019
From: report at bugs.python.org (mefistotelis)
Date: Mon, 09 Dec 2019 23:40:50 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
Message-ID: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>


New submission from mefistotelis <mefistotelis at gmail.com>:

TLDR:
If I place "\r" in an Element attribute, it is handled and idiomized to "&#10;" in the XML file. But wait - \r is not really code 10, right?

Real description:

If I create ElementTree and read it just after creation, I'm getting what I put there - "\r". But if I save and re-load, it transforms into "\n". The character is incorrectly converted before being idiomized, and saved XML file has invalid value stored.

Quick repro:

# python3 -i
Python 3.8.0 (default, Oct 25 2019, 06:23:40)  [GCC 9.2.0 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> elem = ET.Element('TEST')
>>> elem.set("Attt", "a\x0db")
>>> tree = ET.ElementTree(elem)
>>> with open("_test1.xml", "wb") as xml_fh:
...     tree.write(xml_fh, encoding='utf-8', xml_declaration=True)
...
>>> tree.getroot().get("Attt")
'a\rb'
>>> tree = ET.parse("_test1.xml")
>>> tree.getroot().get("Attt")
'a\nb'
>>>

Related issue: https://bugs.python.org/issue5752
(keeping this one separate as it seem to be a simple bug, easy to fix outside of the discussion there)

If there's a good workaround - please let me know.

Tested on Windows, v3.8 and v3.6

----------
components: XML
messages: 358154
nosy: mefistotelis
priority: normal
severity: normal
status: open
title: ElementTree attributes replace "\r" with "\n"
type: behavior
versions: Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:45:48 2019
From: report at bugs.python.org (Alexandros Karypidis)
Date: Mon, 09 Dec 2019 23:45:48 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575935148.15.0.37337170388.issue38999@roundup.psfhosted.org>


Alexandros Karypidis <karypid at gmail.com> added the comment:

I think this situation is not ideal and the limitation seems artificial.

If I understand correctly, there are two parameters that govern the behaviour of the python launcher:

1) Is the shebang using /usr/bin/env or not?
2) IS the shebang specifying a version qualifier or not?

There are 4 combinations available:

a) env with version qualifier
b) env without version qualifier
c) non-env with version qualifier
d) non-env without version qualifier

Of the above, the python launcher supports (b) and (d).

For case (c) the launcher is configurable with py.ini

For case (a) it was decided to treat it as case (b) and search for "python.exe" in the path. To quote:

In the case of (1) I read:

"The launcher also looks for the specific shebang line #!/usr/bin/env python. On Unix, the env program searches for a command on $PATH and runs the command so located. Similarly, with this shebang line, the launcher will look for a copy of python.exe on the user's current %PATH% and will run that copy.

As activating a virtualenv means that it is added to PATH, no special handling is needed to run scripts with the active virtualenv - they just need to use the #!/usr/bin/env python shebang line, exactly as on Unix. (If there is no activated virtualenv, and no python.exe on PATH, the launcher will look for a default Python exactly as if the shebang line had said #!python)."

Why does the launcher search for "python.exe" specifically when using a version qualifier with env? This is very different to what happens on UNIX and causes the issues I reported. I see no reason why using #!/usr/bin/evn pythonX where X is a major version should not check the PATH for that specific version (e.g. #!/usr/bin/evn python3 should check for python3.exe in the PATH) and only fall back to plain "python.exe" if no match is found. This would be much closer to UNIX behaviour and allow for "common" shebangs across Windows/Linux/Darwin etc.

I would also note that if I create a python2 virtual environment and use a #!/usr/bin/env python3 shebang, a search on the path for python.exe would yield the version 2 executable from the virtual environment folder. So the argument about there being a technical issue is anyway true (the same wrong thing can happen in the current implementation).

Do you have any suggestion on how to work around this limitation using the current implementation of python launcher? Is there any way to use #!/usr/bin/env python3 across both Windows and non-Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:50:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2019 23:50:49 +0000
Subject: [issue38944] Idle completion windows should close on Escape key
In-Reply-To: <1575114149.62.0.468764206111.issue38944@roundup.psfhosted.org>
Message-ID: <1575935449.17.0.407775384601.issue38944@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: backport needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38944>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:30:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Dec 2019 00:30:08 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575937808.42.0.831447454299.issue38943@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset bbc4162bafe018f07bab0b624b37974cc33daad9 by Terry Jan Reedy (JohnnyNajera) in branch 'master':
bpo-38943: Fix IDLE autocomplete window not always appearing (GH-17416)
https://github.com/python/cpython/commit/bbc4162bafe018f07bab0b624b37974cc33daad9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:30:14 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 10 Dec 2019 00:30:14 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575937814.53.0.287847557655.issue38943@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17024
pull_request: https://github.com/python/cpython/pull/17548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:30:21 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 10 Dec 2019 00:30:21 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575937821.78.0.938695617918.issue38943@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17025
pull_request: https://github.com/python/cpython/pull/17549

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:46:21 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 10 Dec 2019 00:46:21 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575938781.5.0.683859493248.issue38943@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1b0e88dde146eb290735f4b486d4a67074132100 by Miss Islington (bot) in branch '3.7':
bpo-38943: Fix IDLE autocomplete window not always appearing (GH-17416)
https://github.com/python/cpython/commit/1b0e88dde146eb290735f4b486d4a67074132100


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:48:23 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 10 Dec 2019 00:48:23 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575938903.96.0.705646570222.issue38943@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 34d5d5e096ee804e94199bf242469cdf9bbc3316 by Miss Islington (bot) in branch '3.8':
bpo-38943: Fix IDLE autocomplete window not always appearing (GH-17416)
https://github.com/python/cpython/commit/34d5d5e096ee804e94199bf242469cdf9bbc3316


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:49:12 2019
From: report at bugs.python.org (Wator Sead)
Date: Tue, 10 Dec 2019 00:49:12 +0000
Subject: [issue37535] Client SSLSocket with select.select() always returns
 readable with OpenSSL 1.1.1
In-Reply-To: <1562731064.9.0.934832826159.issue37535@roundup.psfhosted.org>
Message-ID: <1575938952.01.0.316254010314.issue37535@roundup.psfhosted.org>


Wator Sead <seahoh at gmail.com> added the comment:

Thanks for explanation, I understand what the reason is. But why do_handshake() not clear of useless data buffer after it is completed? I think that must be easy to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37535>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:16:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Dec 2019 01:16:20 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575940580.09.0.139887196628.issue38943@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/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:17:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Dec 2019 01:17:49 +0000
Subject: [issue38943] Idle autocomplete window doesn't show up
In-Reply-To: <1575062086.38.0.158761016689.issue38943@roundup.psfhosted.org>
Message-ID: <1575940669.14.0.592665263743.issue38943@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38943>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:35:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Dec 2019 01:35:31 +0000
Subject: [issue39002] Small typo in Lib/test/test_statistics.py: tranlation ->
 translation
In-Reply-To: <1575885863.07.0.931006878505.issue39002@roundup.psfhosted.org>
Message-ID: <1575941731.85.0.252652805471.issue39002@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 859767d58ea8e34313f00fc102a810efff285941 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-39002: Fix simple typo: tranlation -> translation (GH-17517) (GH-17538)
https://github.com/python/cpython/commit/859767d58ea8e34313f00fc102a810efff285941


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39002>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:37:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Dec 2019 01:37:03 +0000
Subject: [issue39002] Small typo in Lib/test/test_statistics.py: tranlation ->
 translation
In-Reply-To: <1575885863.07.0.931006878505.issue39002@roundup.psfhosted.org>
Message-ID: <1575941823.96.0.548164539992.issue39002@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for noticing this.

Please do fill-out the CLA.

I've gone ahead and applied the patch because a typo doesn't need a CLA (correct spelling isn't copyrightable), but you'll need it for future contributing.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39002>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:40:25 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Dec 2019 01:40:25 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1575942025.91.0.238778675754.issue39011@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:04:19 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 10 Dec 2019 05:04:19 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1575954259.62.0.147563246243.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Thanks for taking care of merging to 3.x (master) and 3.8, ?ukasz!

> Kyle, I'm releasing 3.8.1rc1 now. Please add the What's New entry before next Monday (3.8.1).

No problem, I'll definitely have time to do that before 3.8.1 final, likely in the next few days. I'll add you as a reviewer the to PR. After adding the What's New to 3.x and 3.8, I'll work on the manual backport PRs to 3.7, 3,6, and 3.5 via cherry-pick. This was suggested by Ned in the comments of GH-17311, for having a separate versionchanged for each of those branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:13:50 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Dec 2019 05:13:50 +0000
Subject: [issue39012] nuget package published at 3.8.1-c1 instead of rc1
Message-ID: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Should be rc1

----------
assignee: steve.dower
components: Windows
messages: 358163
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: nuget package published at 3.8.1-c1 instead of rc1
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:48:47 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 05:48:47 +0000
Subject: [issue37465] Incorrect documentation for `s#` arguments in C API
 argument parsing
In-Reply-To: <1561969220.64.0.698927964651.issue37465@roundup.psfhosted.org>
Message-ID: <1575956927.59.0.00139757488892.issue37465@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37465>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:34:39 2019
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 10 Dec 2019 07:34:39 +0000
Subject: [issue37535] Client SSLSocket with select.select() always returns
 readable with OpenSSL 1.1.1
In-Reply-To: <1562731064.9.0.934832826159.issue37535@roundup.psfhosted.org>
Message-ID: <1575963279.44.0.787039490206.issue37535@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

do_handshake() performs just the handshake. TLS protocol can send or receive additional protocol data after the handshake, e.g. alerts, rekeying or renegotiation. The example just happened to not trigger these in TLS 1.2. TLS makes non-blocking IO more complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37535>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:43:40 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:43:40 +0000
Subject: [issue38852] test_recursion_limit in test_threading crashes with
 SIGSEGV on android
In-Reply-To: <1574193737.03.0.937540674169.issue38852@roundup.psfhosted.org>
Message-ID: <1575963820.31.0.897124153308.issue38852@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38852>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:45:42 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:45:42 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
In-Reply-To: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>
Message-ID: <1575963942.22.0.607670117254.issue38840@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Not interested anymore in android stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:46:29 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:46:29 +0000
Subject: [issue38848] compileall fails when the platform lacks a functional
 sem_open()
In-Reply-To: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>
Message-ID: <1575963989.36.0.502333117072.issue38848@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Not interested anymore in android stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:47:10 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:47:10 +0000
Subject: [issue38851] UDPLITE tests fail on android
In-Reply-To: <1574192449.59.0.396437190264.issue38851@roundup.psfhosted.org>
Message-ID: <1575964030.27.0.895101272952.issue38851@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Not interested anymore in android stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38851>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:47:27 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:47:27 +0000
Subject: [issue38850] test_largefile fails on android
In-Reply-To: <1574179571.39.0.141498155807.issue38850@roundup.psfhosted.org>
Message-ID: <1575964047.18.0.254555010764.issue38850@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Not interested anymore in android stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38850>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:47:52 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:47:52 +0000
Subject: [issue38849] test_timestamp_naive fails on android
In-Reply-To: <1574179215.81.0.231075264826.issue38849@roundup.psfhosted.org>
Message-ID: <1575964072.19.0.0655248562693.issue38849@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Not interested anymore in android stuff.

----------
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38849>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:48:36 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:48:36 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1575964116.5.0.399773659323.issue25172@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Not interested anymore in android stuff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:50:10 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:50:10 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
In-Reply-To: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>
Message-ID: <1575964210.08.0.308359838622.issue36414@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:51:18 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:51:18 +0000
Subject: [issue36758] configured libdir not correctly passed to Python
 executable
In-Reply-To: <1556622948.14.0.900799269401.issue36758@roundup.psfhosted.org>
Message-ID: <1575964278.69.0.75144739767.issue36758@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36758>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:52:25 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:52:25 +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: <1575964345.57.0.953572148129.issue35813@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:52:54 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:52:54 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
In-Reply-To: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>
Message-ID: <1575964374.3.0.939185639195.issue38840@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:53:59 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:53:59 +0000
Subject: [issue38848] compileall fails when the platform lacks a functional
 sem_open()
In-Reply-To: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>
Message-ID: <1575964439.52.0.944494740615.issue38848@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:54:21 2019
From: report at bugs.python.org (Gabe Appleton)
Date: Tue, 10 Dec 2019 07:54:21 +0000
Subject: [issue38851] UDPLITE tests fail on android
In-Reply-To: <1575964030.27.0.895101272952.issue38851@roundup.psfhosted.org>
Message-ID: <796682ED-DE0F-4C19-AA2B-60D13C397FDA@gabeappleton.me>


Gabe Appleton <gabe at gabeappleton.me> added the comment:

Also, isn't this just a permissions error? I wouldn't think that would indicate a failure of the feature, but instead one of the testing environment.

On December 10, 2019 7:47:10 AM UTC, Xavier de Gaye <report at bugs.python.org> wrote:
>
>Xavier de Gaye <xdegaye at gmail.com> added the comment:
>
>Not interested anymore in android stuff.
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><https://bugs.python.org/issue38851>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38851>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:54:29 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:54:29 +0000
Subject: [issue38851] UDPLITE tests fail on android
In-Reply-To: <1574192449.59.0.396437190264.issue38851@roundup.psfhosted.org>
Message-ID: <1575964469.58.0.98334301037.issue38851@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38851>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:55:10 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:55:10 +0000
Subject: [issue38850] test_largefile fails on android
In-Reply-To: <1574179571.39.0.141498155807.issue38850@roundup.psfhosted.org>
Message-ID: <1575964510.08.0.276793230271.issue38850@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38850>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:55:45 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:55:45 +0000
Subject: [issue38849] test_timestamp_naive fails on android
In-Reply-To: <1574179215.81.0.231075264826.issue38849@roundup.psfhosted.org>
Message-ID: <1575964545.76.0.389212704775.issue38849@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38849>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:56:18 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 07:56:18 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1575964578.49.0.319479782086.issue25172@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:01:23 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:01:23 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1575964883.72.0.0300597375353.issue28833@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28833>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:03:17 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:03:17 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1575964997.74.0.323166169302.issue28190@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:03:47 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:03:47 +0000
Subject: [issue36361] generate correct pyconfig.h when cross-compiling
In-Reply-To: <1552987896.08.0.0930536102698.issue36361@roundup.psfhosted.org>
Message-ID: <1575965027.88.0.742106910892.issue36361@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36361>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:04:07 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:04:07 +0000
Subject: [issue36351] the ipv6type variable in configure.ac may be set
 incorrectly when cross-compiling
In-Reply-To: <1552925433.25.0.962523188847.issue36351@roundup.psfhosted.org>
Message-ID: <1575965047.09.0.470616498645.issue36351@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36351>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:05:10 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:05:10 +0000
Subject: [issue36214] AC_RUN_IFELSE macros not used as arguments of
 AC_CACHE_VAL et al
In-Reply-To: <1551888207.23.0.560311387445.issue36214@roundup.psfhosted.org>
Message-ID: <1575965110.44.0.936762952617.issue36214@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36214>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:05:39 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:05:39 +0000
Subject: [issue36125] Cannot cross-compile to more featureful but same tune
In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org>
Message-ID: <1575965139.52.0.81355533882.issue36125@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36125>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:06:04 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:06:04 +0000
Subject: [issue27640] add the '--disable-test-suite' option to configure
In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za>
Message-ID: <1575965164.05.0.411914662556.issue27640@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:06:27 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:06:27 +0000
Subject: [issue36145] android arm cross compilation fails, config issue
In-Reply-To: <1551354685.49.0.372861646836.issue36145@roundup.psfhosted.org>
Message-ID: <1575965187.61.0.305613587058.issue36145@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36145>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:06:49 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:06:49 +0000
Subject: [issue36141] configure: error: could not find pthreads on your system
 during cross compilation
In-Reply-To: <1551297073.48.0.367193754314.issue36141@roundup.psfhosted.org>
Message-ID: <1575965209.32.0.370263797321.issue36141@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36141>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:07:15 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:07:15 +0000
Subject: [issue35997] ImportError: dlopen failed: cannot locate symbol
 "PyBool_Type"
In-Reply-To: <1550176592.88.0.291433310272.issue35997@roundup.psfhosted.org>
Message-ID: <1575965235.94.0.805759854389.issue35997@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35997>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:07:33 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:07:33 +0000
Subject: [issue35953] crosscompilation fails with clang on android
In-Reply-To: <1549800196.49.0.252123188802.issue35953@roundup.psfhosted.org>
Message-ID: <1575965253.18.0.371560292334.issue35953@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35953>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:08:09 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:08:09 +0000
Subject: [issue31046] ensurepip does not honour the value of $(prefix)
In-Reply-To: <1501087168.72.0.253170854096.issue31046@psf.upfronthosting.co.za>
Message-ID: <1575965289.84.0.422667563045.issue31046@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31046>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:08:26 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:08:26 +0000
Subject: [issue26852] add the '--enable-sourceless-distribution' option to
 configure
In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za>
Message-ID: <1575965306.31.0.637039784188.issue26852@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26852>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:09:02 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:09:02 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1575965342.49.0.0744277813067.issue13886@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:09:38 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:09:38 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1575965378.62.0.678070941707.issue26855@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:10:02 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:10:02 +0000
Subject: [issue32203] [ctypes] test_struct_by_value fails on android-24-arm64
In-Reply-To: <1512235574.32.0.213398074469.issue32203@psf.upfronthosting.co.za>
Message-ID: <1575965402.48.0.378077069882.issue32203@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32203>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:10:28 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:10:28 +0000
Subject: [issue32202] [ctypes] all long double tests fail on android-24-x86_64
In-Reply-To: <1512234593.69.0.213398074469.issue32202@psf.upfronthosting.co.za>
Message-ID: <1575965428.46.0.178799507966.issue32202@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32202>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:11:17 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:11:17 +0000
Subject: [issue32461] the first build after a change to Makefile.pre.in uses
 the old Makefile
In-Reply-To: <1514706812.13.0.467229070634.issue32461@psf.upfronthosting.co.za>
Message-ID: <1575965477.48.0.744408114252.issue32461@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32461>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:12:27 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:12:27 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1575965547.25.0.61252111937.issue20211@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:12:47 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:12:47 +0000
Subject: [issue29267] Cannot override some flags in CFLAGS from the
 command-line
In-Reply-To: <1484333637.07.0.801577004436.issue29267@psf.upfronthosting.co.za>
Message-ID: <1575965567.63.0.298680297839.issue29267@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29267>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:13:06 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:13:06 +0000
Subject: [issue28542] document cross compilation
In-Reply-To: <1477563460.46.0.569265292251.issue28542@psf.upfronthosting.co.za>
Message-ID: <1575965586.4.0.650072280824.issue28542@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28542>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:13:29 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:13:29 +0000
Subject: [issue28207] Use pkg-config to find dependencies
In-Reply-To: <1474313690.75.0.976333515942.issue28207@psf.upfronthosting.co.za>
Message-ID: <1575965609.75.0.170778296774.issue28207@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28207>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:14:17 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:14:17 +0000
Subject: [issue28125] identify cross builds by a more generic environment
 setting.
In-Reply-To: <1473764033.74.0.830597862284.issue28125@psf.upfronthosting.co.za>
Message-ID: <1575965657.02.0.775623047998.issue28125@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28125>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:15:02 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:15:02 +0000
Subject: [issue22724] byte-compile fails for cross-builds
In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za>
Message-ID: <1575965702.38.0.562391967945.issue22724@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22724>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:15:26 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:15:26 +0000
Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and
 DESTSHARED
In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>
Message-ID: <1575965726.69.0.552465726849.issue26971@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26971>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:16:01 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 08:16:01 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
 when trying to run sourceless tests
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1575965761.5.0.222356605019.issue26859@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26859>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:27:48 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2019 08:27:48 +0000
Subject: [issue39004] test_largefile: TestSocketSendfile.test_it() failed on
 AMD64 Fedora Stable Refleaks 3.x
In-Reply-To: <1575897877.42.0.877682602403.issue39004@roundup.psfhosted.org>
Message-ID: <1575966468.51.0.132009991223.issue39004@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
keywords: +patch
pull_requests: +17026
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39004>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:29:47 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2019 08:29:47 +0000
Subject: [issue39004] test_largefile: TestSocketSendfile.test_it() failed on
 AMD64 Fedora Stable Refleaks 3.x
In-Reply-To: <1575897877.42.0.877682602403.issue39004@roundup.psfhosted.org>
Message-ID: <1575966587.66.0.750774071564.issue39004@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I suspect it's a timing problem (client disconnects, threaded server fails to detect that in time). Let's see what happens by incrementing the timeout when waiting for the thread to be join()ed (PR-17552).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39004>
_______________________________________

From report at bugs.python.org  Tue Dec 10 03:53:47 2019
From: report at bugs.python.org (Wator Sead)
Date: Tue, 10 Dec 2019 08:53:47 +0000
Subject: [issue37535] Client SSLSocket with select.select() always returns
 readable with OpenSSL 1.1.1
In-Reply-To: <1562731064.9.0.934832826159.issue37535@roundup.psfhosted.org>
Message-ID: <1575968027.45.0.765387500833.issue37535@roundup.psfhosted.org>


Wator Sead <seahoh at gmail.com> added the comment:

So, that means there are some additional optional operations after do_handshake(), the data is needed. Thanks for explanation!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37535>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:31:23 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2019 09:31:23 +0000
Subject: [issue39004] test_largefile: TestSocketSendfile.test_it() failed on
 AMD64 Fedora Stable Refleaks 3.x
In-Reply-To: <1575897877.42.0.877682602403.issue39004@roundup.psfhosted.org>
Message-ID: <1575970283.98.0.650389461708.issue39004@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:


New changeset 82374979ec7e01e23385dca1d02b2aa3de16fea5 by Giampaolo Rodola in branch 'master':
bpo-39004: increment large sendfile() test timeout (GH-17552)
https://github.com/python/cpython/commit/82374979ec7e01e23385dca1d02b2aa3de16fea5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39004>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:48:48 2019
From: report at bugs.python.org (Artem Tepanov)
Date: Tue, 10 Dec 2019 09:48:48 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
Message-ID: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>


New submission from Artem Tepanov <a.tepanov at gmail.com>:

Why I can't execute this code:

while False:
    if False:
        break
print('WTF?')
When I use repl.it or PyCharm on my work (Python 3.7) all works fine, yes I know this code looks silly, but it is a legal expression.

About CPython Interpreter:
C:\WINDOWS\system32>python
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

----------
messages: 358175
nosy: Artem Tepanov
priority: normal
severity: normal
status: open
title: SyntaxError: 'break' outside loop for legal Expression
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:56:01 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 10 Dec 2019 09:56:01 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575971761.0.0.384481662801.issue39013@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I don't know, why *can't* you execute that code? It works fine for me. Although I'm not using the exact same version of 3.8 that you are using.

Could you copy and paste (not a screen shot or photo!) the text of your interactive session, including the error that you get, please?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 05:40:23 2019
From: report at bugs.python.org (Artem Tepanov)
Date: Tue, 10 Dec 2019 10:40:23 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575974423.6.0.0660062743772.issue39013@roundup.psfhosted.org>


Artem Tepanov <a.tepanov at gmail.com> added the comment:

Using cmd:
C:\Users\ATepanov>python -V
Python 3.8.0

C:\Users\ATepanov>python C:\Users\ATepanov\Desktop\Outside_The_Loop.py
  File "C:\Users\ATepanov\Desktop\Outside_The_Loop.py", line 3
    break
    ^
SyntaxError: 'break' outside loop


In Interactive:
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> while False:
...     break
...
  File "<stdin>", line 2
SyntaxError: 'break' outside loop
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 05:44:15 2019
From: report at bugs.python.org (Artem Tepanov)
Date: Tue, 10 Dec 2019 10:44:15 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575974655.37.0.58681371747.issue39013@roundup.psfhosted.org>


Artem Tepanov <a.tepanov at gmail.com> added the comment:

Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> while False:
...     if False:
...         break
...
  File "<stdin>", line 3
SyntaxError: 'break' outside loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 05:49:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 10 Dec 2019 10:49:47 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575974987.01.0.676306434464.issue39013@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be same as issue38640 . Can you please try 3.8.1RC1 to see if it's fixed?

https://www.python.org/downloads/release/python-381rc1/

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 05:57:50 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 10:57:50 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575975470.91.0.0370403065255.issue39013@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> while False: break => SyntaxError: 'break' outside loop

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 06:07:07 2019
From: report at bugs.python.org (Artem Tepanov)
Date: Tue, 10 Dec 2019 11:07:07 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575976027.81.0.310919440147.issue39013@roundup.psfhosted.org>


Artem Tepanov <a.tepanov at gmail.com> added the comment:

Thx, after upgrade to:
Python 3.8.1rc1 (tags/v3.8.1rc1:b00a2b5, Dec 10 2019, 01:13:53) [MSC v.1916 64 bit (AMD64)] on win32
All works fine,
...but Could you "pushing the person" which responsible for Web-Site please?, because I got Interpreter from there: https://www.python.org/downloads/release/python-380/

Without any Warnings or Recommendation for using 3.8.1rc1

Is it normal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 06:14:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 11:14:09 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1575976449.24.0.859723432891.issue39011@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See https://www.w3.org/TR/REC-xml/#sec-line-ends.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Tue Dec 10 06:21:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 11:21:51 +0000
Subject: [issue35827] C API dictionary views type checkers are not documented
In-Reply-To: <1548417904.67.0.718119168094.issue35827@roundup.psfhosted.org>
Message-ID: <1575976911.88.0.393828680143.issue35827@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

They were added in a22e8bdfd92cd4f1bc3d60e91df6410c4efde6a0. Additional types like PyDictRevIterKey_Type were added later. I am not sure that all these types should be exposed in the public C API.

----------
nosy: +christian.heimes, serhiy.storchaka
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35827>
_______________________________________

From report at bugs.python.org  Tue Dec 10 06:59:46 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 11:59:46 +0000
Subject: [issue30386] Add a build infrastructure for Android
In-Reply-To: <1495029473.85.0.224153889861.issue30386@psf.upfronthosting.co.za>
Message-ID: <1575979186.3.0.301903862304.issue30386@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> works for me
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30386>
_______________________________________

From report at bugs.python.org  Tue Dec 10 07:01:16 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 Dec 2019 12:01:16 +0000
Subject: [issue31114] 'make install' fails when the configure 'prefix' is '/'
 and DESTDIR is used
In-Reply-To: <1501782040.16.0.9530512469.issue31114@psf.upfronthosting.co.za>
Message-ID: <1575979276.26.0.729773196169.issue31114@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy:  -xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31114>
_______________________________________

From report at bugs.python.org  Tue Dec 10 07:07:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 10 Dec 2019 12:07:15 +0000
Subject: [issue39013] SyntaxError: 'break' outside loop for legal Expression
In-Reply-To: <1575971328.9.0.440165492985.issue39013@roundup.psfhosted.org>
Message-ID: <1575979635.56.0.0463706033966.issue39013@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the confirmation. The issue was found after 3.8.0 release. The fix is in 3.8.1RC1 and will be made as 3.8.1 in couple of weeks. Normally regressions are not listed at downloads page but are tagged as regression in the tracker like the one linked. You can wait for sometime to use 3.8.1 which should fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39013>
_______________________________________

From report at bugs.python.org  Tue Dec 10 07:29:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 12:29:56 +0000
Subject: [issue39004] test_largefile: TestSocketSendfile.test_it() failed on
 AMD64 Fedora Stable Refleaks 3.x
In-Reply-To: <1575897877.42.0.877682602403.issue39004@roundup.psfhosted.org>
Message-ID: <1575980996.5.0.909458102173.issue39004@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Let's say that it's enough to hide the race condition :-) I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39004>
_______________________________________

From report at bugs.python.org  Tue Dec 10 07:37:50 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2019 12:37:50 +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: <1575981470.95.0.185395434208.issue24925@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +17027
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17553

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Dec 10 07:42:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 12:42:57 +0000
Subject: [issue39014] test_concurrent_futures: test_crash() timed out on AMD64
 Fedora Rawhide Refleaks 3.x
Message-ID: <1575981777.91.0.383152425566.issue39014@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 Fedora Rawhide Refleaks 3.x:
https://buildbot.python.org/all/#/builders/82/builds/12

0:15:30 load avg: 12.25 [308/420/1] test_concurrent_futures failed (15 min 26 sec) -- running: test_largefile (11 min 22 sec), test_io (2 min 9 sec), test_mailbox (12 min 37 sec), test_faulthandler (53.4 sec), test_shelve (13 min 39 sec)
beginning 6 repetitions
123456
....
Traceback:
 Thread 0x00007fae68fb6700 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 303 in wait
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/queues.py", line 227 in _feed
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 882 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 902 in _bootstrap

Thread 0x00007fae637fe700 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/selectors.py", line 415 in select
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/connection.py", line 930 in wait
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py", line 362 in _queue_management_worker
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 882 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 902 in _bootstrap

Current thread 0x00007fae77c14740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 946 in _fail_on_deadlock
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1007 in test_crash
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 616 in _callTestMethod
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 659 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 719 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/testresult.py", line 162 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2079 in _run_suite
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2201 in run_unittest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/refleak.py", line 87 in dash_R
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 232 in _runtest_inner2
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest_mp.py", line 80 in run_tests_worker
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 654 in _main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/regrtest.py", line 43 in _main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/regrtest.py", line 47 in <module>
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 86 in _run_code
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 193 in _run_module_as_main

test test_concurrent_futures failed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1003, in test_crash
    res.result(timeout=self.TIMEOUT)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/_base.py", line 441, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1007, in test_crash
    self._fail_on_deadlock(executor)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 955, in _fail_on_deadlock
    self.fail(f"Executor deadlock:\n\n{tb}")
AssertionError: Executor deadlock:

Thread 0x00007fae68fb6700 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 303 in wait
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/queues.py", line 227 in _feed
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 882 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 902 in _bootstrap

Thread 0x00007fae637fe700 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/selectors.py", line 415 in select
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/connection.py", line 930 in wait
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py", line 362 in _queue_management_worker
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 882 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 902 in _bootstrap

Current thread 0x00007fae77c14740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 946 in _fail_on_deadlock
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1007 in test_crash
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 616 in _callTestMethod
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 659 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 719 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/testresult.py", line 162 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2079 in _run_suite
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2201 in run_unittest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/refleak.py", line 87 in dash_R
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 232 in _runtest_inner2
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest_mp.py", line 80 in run_tests_worker
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 654 in _main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/regrtest.py", line 43 in _main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/regrtest.py", line 47 in <module>
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 86 in _run_code
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 193 in _run_module_as_main

(...)

======================================================================
FAIL: test_crash (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) [crash at task unpickle]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1003, in test_crash
    res.result(timeout=self.TIMEOUT)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/_base.py", line 441, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1007, in test_crash
    self._fail_on_deadlock(executor)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 955, in _fail_on_deadlock
    self.fail(f"Executor deadlock:\n\n{tb}")
AssertionError: Executor deadlock:

Thread 0x00007f38c9484700 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 303 in wait
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/queues.py", line 227 in _feed
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 882 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 902 in _bootstrap

Thread 0x00007f38cac87700 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/selectors.py", line 415 in select
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/connection.py", line 930 in wait
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py", line 362 in _queue_management_worker
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 882 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 944 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 902 in _bootstrap

Current thread 0x00007f38d9b9a740 (most recent call first):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 946 in _fail_on_deadlock
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1007 in test_crash
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 616 in _callTestMethod
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 659 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 719 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2079 in _run_suite
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2201 in run_unittest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/refleak.py", line 87 in dash_R
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 232 in _runtest_inner2
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 691 in _main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 86 in _run_code
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 193 in _run_module_as_main


----------------------------------------------------------------------

Ran 168 tests in 172.838s

FAILED (failures=1, skipped=3)
1 test failed again:
    test_concurrent_futures

----------
components: Tests
messages: 358185
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures: test_crash() timed out on AMD64 Fedora Rawhide Refleaks 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39014>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:23:27 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 10 Dec 2019 13:23:27 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1575984207.84.0.247756776035.issue38999@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I don't think the "/usr/bin/env" case needs to limit qualified names like "python3[.x]" to registered installations. This is a choice made to simplify the implementation. If it finds a generic "python.exe" executable in PATH, for 3.5+ it is possible to query version information directly from it. Older versions lack this metadata, but it's also possible to inspect the PE import table (i.e. IMAGE_DIRECTORY_ENTRY_IMPORT) for a dependency on "python2x.dll" or "python3x.dll".

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:28:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 13:28:24 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1575984504.27.0.917546449168.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17028
pull_request: https://github.com/python/cpython/pull/17554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:37:06 2019
From: report at bugs.python.org (Julien Danjou)
Date: Tue, 10 Dec 2019 13:37:06 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985026.94.0.481669321044.issue1021318@roundup.psfhosted.org>


Julien Danjou <julien at danjou.info> added the comment:

This is actually true and it's quite easy to produce a bug that triggers a segmentation fault when iterating over a large list of threads create dynamically.

That makes PyThreadState_Next barely usable for any program that has a few threads. The head mutex needs to be locked to be able to iterate safely over the list of thread.

----------
nosy: +jd
title: PyThreadState_Next not thread safe? -> PyThreadState_Next not thread safe
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:38:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 13:38:20 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985100.39.0.830935966907.issue1021318@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This is actually true and it's quite easy to produce a bug that triggers a segmentation fault when iterating over a large list of threads create dynamically.

This issue is closed. Would you be able to write a reproducer script? If yes, maybe open a new issue, or I can reopen this one.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:42:39 2019
From: report at bugs.python.org (Julien Danjou)
Date: Tue, 10 Dec 2019 13:42:39 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985359.04.0.237308157491.issue1021318@roundup.psfhosted.org>


Julien Danjou <julien at danjou.info> added the comment:

It'd be great if you could reopen it. I'm interested in fixing it properly.

It's impossible to "solve" in Python 2 since the head mutex is not accessible (it's static in pystate.c) but this is doable with Python 3 (yay).

We'd simply need to provide a new API to lock/unlock the interpreter's mutex.

How hard to you need the script to reproduce? I can try to spend some time to extract some of my code to have one if that's really needed (I'm using Cython to generate some of the C code).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:44:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 13:44:37 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985477.22.0.163769781947.issue1021318@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopened the issue and changed the version to 3.9.

----------
resolution: out of date -> 
status: closed -> open
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/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:44:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 13:44:49 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985489.1.0.839266642456.issue1021318@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +eric.snow, pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:46:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 13:46:53 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985613.41.0.991943761585.issue1021318@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> We'd simply need to provide a new API to lock/unlock the interpreter's mutex.

Are you talking about this lock?

#define HEAD_LOCK(runtime) \
    PyThread_acquire_lock((runtime)->interpreters.mutex, WAIT_LOCK)
#define HEAD_UNLOCK(runtime) \
    PyThread_release_lock((runtime)->interpreters.mutex)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:50:04 2019
From: report at bugs.python.org (Julien Danjou)
Date: Tue, 10 Dec 2019 13:50:04 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1575985804.76.0.606980865508.issue1021318@roundup.psfhosted.org>


Julien Danjou <julien at danjou.info> added the comment:

Yes, that's the one ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:10:12 2019
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 10 Dec 2019 14:10: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: <1575987012.55.0.821711148187.issue24925@roundup.psfhosted.org>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

I tried to make a pull request, but it fails on the format of news file name.
At least the tests all pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:57:12 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 10 Dec 2019 14:57:12 +0000
Subject: [issue25160] Stop using deprecated imp module;
 imp should now emit a real DeprecationWarning
In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za>
Message-ID: <1575989832.38.0.814252715473.issue25160@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Make sure the standard library doesn't emit those warnings itself.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25160>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:03:06 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 10 Dec 2019 15:03:06 +0000
Subject: [issue39015] DeprecationWarnings of implicitly truncations by __int__
 appearing in the standard library
Message-ID: <1575990186.74.0.753297592604.issue39015@roundup.psfhosted.org>


New submission from ?ukasz Langa <lukasz at langa.pl>:

The original issue was bpo-36048. Some call sites were not updated and now 3.8.0 and 3.8.1rc1 are emitting a lot of warnings like:

    <frozen importlib._bootstrap>:219: DeprecationWarning: an integer is required (got type float).  Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.

Adding authors of GH-11952 as nosy.

----------
components: Library (Lib)
keywords: 3.8regression
messages: 358195
nosy: lukasz.langa, serhiy.storchaka, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: DeprecationWarnings of implicitly truncations by __int__ appearing in the standard library
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39015>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:04:06 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 10 Dec 2019 15:04:06 +0000
Subject: [issue25160] Stop using deprecated imp module;
 imp should now emit a real DeprecationWarning
In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za>
Message-ID: <1575990246.5.0.365325306962.issue25160@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

I meant to comment on a different issue, the trigger is stuff like https://bugs.python.org/issue39015 (new deprecationwarnings being generated without cleaning up the standard library first).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25160>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:25:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 10 Dec 2019 15:25:39 +0000
Subject: [issue28249] doctest.DocTestFinder reports incorrect line numbers
 with exclude_empty=False
In-Reply-To: <1474558340.5.0.316638267735.issue28249@psf.upfronthosting.co.za>
Message-ID: <1575991539.11.0.259350606433.issue28249@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/issue28249>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:29:14 2019
From: report at bugs.python.org (PCManticore)
Date: Tue, 10 Dec 2019 15:29:14 +0000
Subject: [issue38947] dataclass defaults behave inconsistently for
 init=True/init=False when default is a descriptor
In-Reply-To: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>
Message-ID: <1575991754.53.0.17400732438.issue38947@roundup.psfhosted.org>


Change by PCManticore <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38947>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:30:59 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 15:30:59 +0000
Subject: [issue39015] DeprecationWarnings of implicitly truncations by __int__
 appearing in the standard library
In-Reply-To: <1575990186.74.0.753297592604.issue39015@roundup.psfhosted.org>
Message-ID: <1575991859.24.0.671094493368.issue39015@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

How did you get warnings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39015>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:31:45 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 10 Dec 2019 15:31:45 +0000
Subject: [issue39015] DeprecationWarnings of implicitly truncations by __int__
 appearing in the standard library
In-Reply-To: <1575990186.74.0.753297592604.issue39015@roundup.psfhosted.org>
Message-ID: <1575991905.9.0.00840114997497.issue39015@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/issue39015>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:37:03 2019
From: report at bugs.python.org (Christian Tismer)
Date: Tue, 10 Dec 2019 15:37:03 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
Message-ID: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>


New submission from Christian Tismer <tismer at stackless.com>:

By the new Py_TPFLAGS_METHOD_DESCRIPTOR flag, a new code path is
activated, and when extension types like PySide create a new
class, we observe negative refcounts.

The reason is that the code in typeobject.c fkt. type_mro_modified
calls lookup_maybe_method which returns a _borrowed_ reference.
This happens in the "if (custom) {" branch.

Removing all Py_XDECREF calls from the function fixes that.

----------
components: Extension Modules
messages: 358198
nosy: Christian.Tismer
priority: critical
severity: normal
status: open
title: Negative Refcount in Python 3.8
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:38:18 2019
From: report at bugs.python.org (Christian Tismer)
Date: Tue, 10 Dec 2019 15:38:18 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1575992298.67.0.794308745322.issue39016@roundup.psfhosted.org>


Change by Christian Tismer <tismer at stackless.com>:


----------
keywords: +patch
pull_requests: +17029
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17555

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:18:23 2019
From: report at bugs.python.org (Jonathan Slenders)
Date: Tue, 10 Dec 2019 16:18:23 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1575994703.62.0.321808538373.issue39010@roundup.psfhosted.org>


Jonathan Slenders <jonathan.slenders at gmail.com> added the comment:

Thanks Victor for the reply.

It looks like it's the self-socket in the BaseProactorEventLoop that gets closed. It's exactly this FD for which the exception is raised.

We don't close the event loop anywhere. I also don't see `_close_self_pipe` being called anywhere.

Debug logs don't provide any help. I'm looking into a reproducer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:19:56 2019
From: report at bugs.python.org (jvoisin)
Date: Tue, 10 Dec 2019 16:19:56 +0000
Subject: [issue39017] Infinite loop in the tarfile module
Message-ID: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

While playing with fuzzing and Python, I stumbled upon an infinite loop in Python's tarfile module: just open the attached file with `tarfile.open('timeout-a52710a313fdb35fb428c3399277cb640fe2f686')`, and Python will be endlessly stuck in the `_proc_pax` function in tarfile.py, likely due to a missing check of `length` being strictly superior to zero.

----------
files: timeout-a52710a313fdb35fb428c3399277cb640fe2f686
messages: 358200
nosy: ethan.furman, jvoisin
priority: normal
severity: normal
status: open
title: Infinite loop in the tarfile module
type: security
versions: Python 3.7
Added file: https://bugs.python.org/file48768/timeout-a52710a313fdb35fb428c3399277cb640fe2f686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:21:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 10 Dec 2019 16:21:43 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1575994903.3.0.126535234078.issue39016@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>From the PR:

Christian, can you open the PR against master instead? We will backport the change to 3.8 after is merged.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:24:42 2019
From: report at bugs.python.org (Matej Cepl)
Date: Tue, 10 Dec 2019 16:24:42 +0000
Subject: [issue38576] CVE-2019-18348: CRLF injection via the host part of the
 url passed to urlopen()
In-Reply-To: <1571903478.88.0.753943817426.issue38576@roundup.psfhosted.org>
Message-ID: <1575995082.87.0.101416632465.issue38576@roundup.psfhosted.org>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:47:08 2019
From: report at bugs.python.org (jvoisin)
Date: Tue, 10 Dec 2019 16:47:08 +0000
Subject: [issue39018] IndexError exception on corrupted zip file
Message-ID: <1575996427.98.0.820358175016.issue39018@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file raises an `IndexError: tuple index out of range` exception when trying to open it with `zipfile.Zipfile('crash-23b7d72644702df94bfcfaab4c25b01ff31c0b38')`, with the following stacktrace:

```
$ cat test_zip.py
import zipfile
import sys

with zipfile.ZipFile(sys.argv[1]) as f:
  pass
$ python3 ./test_zip.py ./crash-23b7d72644702df94bfcfaab4c25b01ff31c0b38
Traceback (most recent call last):
  File "./test_zip.py", line 4, in <module>
    with zipfile.ZipFile(sys.argv[1]) as f:
  File "/usr/lib/python3.7/zipfile.py", line 1225, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.7/zipfile.py", line 1348, in _RealGetContents
    x._decodeExtra()
  File "/usr/lib/python3.7/zipfile.py", line 480, in _decodeExtra
    self.file_size = counts[idx]
IndexError: tuple index out of range
$

```

The zipfile documentation doesn't mention that IndexError is a possible exception for this method.

----------
components: Library (Lib)
files: crash-23b7d72644702df94bfcfaab4c25b01ff31c0b38
messages: 358202
nosy: jvoisin
priority: normal
severity: normal
status: open
title: IndexError exception on corrupted zip file
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48769/crash-23b7d72644702df94bfcfaab4c25b01ff31c0b38

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39018>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:54:54 2019
From: report at bugs.python.org (Christian Tismer)
Date: Tue, 10 Dec 2019 16:54:54 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575994903.3.0.126535234078.issue39016@roundup.psfhosted.org>
Message-ID: <eb8814ee-088b-a8b1-5bc4-05b3d393dbf7@stackless.com>


Christian Tismer <tismer at stackless.com> added the comment:

No, this appears to be impossible.

The function "type_mro_modified" exists as well, but there is no
"if (custom) {" branch at all!

On 10.12.19 17:21, Pablo Galindo Salgado wrote:
> 
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
> 
>>From the PR:
> 
> Christian, can you open the PR against master instead? We will backport the change to 3.8 after is merged.
> 
> ----------
> nosy: +pablogsal
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39016>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:55:53 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 10 Dec 2019 16:55:53 +0000
Subject: [issue39018] IndexError exception on corrupted zip file
In-Reply-To: <1575996427.98.0.820358175016.issue39018@roundup.psfhosted.org>
Message-ID: <1575996953.38.0.390898067112.issue39018@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

master produces the below error while 3.8.0 produces IndexError. I guess it's fixed by one of the reports.

./python ../backups/bpo39018.py ../crash-23b7d72644702df94bfcfaab4c25b01ff31c0b38
Traceback (most recent call last):
  File "/home/xtreak/stuff/python/cpython/../backups/bpo39018.py", line 4, in <module>
    with zipfile.ZipFile(sys.argv[1]) as f:
  File "/home/xtreak/stuff/python/cpython/Lib/zipfile.py", line 1256, in __init__
    self._RealGetContents()
  File "/home/xtreak/stuff/python/cpython/Lib/zipfile.py", line 1379, in _RealGetContents
    x._decodeExtra()
  File "/home/xtreak/stuff/python/cpython/Lib/zipfile.py", line 483, in _decodeExtra
    raise BadZipFile(f"Corrupt zip64 extra field. "
zipfile.BadZipFile: Corrupt zip64 extra field. File size not found.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39018>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:57:16 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 10 Dec 2019 16:57:16 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1575997036.45.0.749879142222.issue39016@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> No, this appears to be impossible.

Oh, I see. Apologies then for the misunderstunding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:58:53 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 10 Dec 2019 16:58:53 +0000
Subject: [issue39018] IndexError exception on corrupted zip file
In-Reply-To: <1575996427.98.0.820358175016.issue39018@roundup.psfhosted.org>
Message-ID: <1575997133.7.0.44940317915.issue39018@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Bisecting gives me the commit as da6ce58dd5ac109485af45878fca6bfd265b43e9 where exception message is improved with issue36993

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39018>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:07:32 2019
From: report at bugs.python.org (Christian Tismer)
Date: Tue, 10 Dec 2019 17:07:32 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575997036.45.0.749879142222.issue39016@roundup.psfhosted.org>
Message-ID: <cfcc6418-9c86-2785-d3a6-6c5ccff57fcd@stackless.com>


Christian Tismer <tismer at stackless.com> added the comment:

On 10.12.19 17:57, Pablo Galindo Salgado wrote:
> 
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
> 
>> No, this appears to be impossible.
> 
> Oh, I see. Apologies then for the misunderstunding.

Well, but I think that is weird, too!
Why should that custom clause be in 3.8 but not in master?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:19:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 17:19:43 +0000
Subject: [issue39018] IndexError exception on corrupted zip file
In-Reply-To: <1575996427.98.0.820358175016.issue39018@roundup.psfhosted.org>
Message-ID: <1575998383.94.0.569558664161.issue39018@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39018>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:20:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 17:20:30 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1575998430.01.0.116349623356.issue39017@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +lars.gustaebel, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:49:24 2019
From: report at bugs.python.org (Jonathan Slenders)
Date: Tue, 10 Dec 2019 17:49:24 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1576000164.77.0.0299901287377.issue39010@roundup.psfhosted.org>


Jonathan Slenders <jonathan.slenders at gmail.com> added the comment:

It looks like the following code will reproduce the issue:

```
import asyncio
import threading

loop = asyncio.get_event_loop()

while True:
    def test():
        loop.call_soon_threadsafe(loop.stop)

    threading.Thread(target=test).start()
    loop.run_forever()

```

Leave it running on Windows, in Python 3.8 for a few seconds, then it starts spawning `ConnectionResetError`s.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:55:54 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 10 Dec 2019 17:55:54 +0000
Subject: [issue39019] Missing class getitems in standard library classes
Message-ID: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

After working on issue 38994 and issue 38978, I decided to write a simple AST analyzer to find class getitem syntax usage in typeshed. It discovered a few classes (I am not sure if there are more). As @brett.cannon suggested in PR 17498 I'll prepare individual pull requests.  

typeshed/stdlib/3/subprocess.pyi:868  => Popen
typeshed/stdlib/3/subprocess.pyi:82   => CompletedProcess
typeshed/stdlib/3/tempfile.pyi:98     => SpooledTemporaryFile
typeshed/stdlib/3/os/__init__.pyi:463 => DirEntry
typeshed/stdlib/3/http/cookies.pyi:5  => Morsel

----------
messages: 358209
nosy: BTaskaya, brett.cannon
priority: normal
severity: normal
status: open
title: Missing class getitems in standard library classes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:00:10 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 10 Dec 2019 18:00:10 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1576000810.82.0.535147366105.issue39019@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
components: +Library (Lib)
nosy: +levkivskyi
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:06:57 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 10 Dec 2019 18:06:57 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1576001217.62.0.609614718935.issue39019@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17030
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17558

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:12:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 18:12:20 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576001540.82.0.620728908737.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17031
pull_request: https://github.com/python/cpython/pull/17559

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:12:28 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 10 Dec 2019 18:12:28 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1576001548.1.0.00209561525142.issue39019@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17032
pull_request: https://github.com/python/cpython/pull/17560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:24:25 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 10 Dec 2019 18:24:25 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1576002265.35.0.667547460663.issue39019@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17033
pull_request: https://github.com/python/cpython/pull/17561

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:28:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 18:28:23 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576002503.55.0.696667150961.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17034
pull_request: https://github.com/python/cpython/pull/17562

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:28:53 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 10 Dec 2019 18:28:53 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1576002533.69.0.861904439524.issue39019@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17035
pull_request: https://github.com/python/cpython/pull/17563

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:41:14 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 Dec 2019 18:41:14 +0000
Subject: [issue39020] [AIX] module _ctypes fails to build since ESCDELAY has
 been added
Message-ID: <1576003274.61.0.235026296751.issue39020@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Did not notice this earlier - as the buildbot does not report it: issue38312 introduced a regression with regard to AIX.

Not sure how to classify component (as Build, C API, or Library, so left blank)

Failed to build these modules:
_curses                                                        

commit b32cb97bce472dad337c6b2f071883f6234e21d8
Author: Anthony Sottile <asottile at umich.edu>
Date:   Thu Oct 31 02:13:48 2019 -0700

    bpo-38312: Add curses.{get,set}_escdelay and curses.{get,set}_tabsize. (GH-16938)

Background: ncurses is not part of AIX; curses. ncurses packages provided by other parties are not stable enough for, among other things, allow the buildbot to pass.

Prior to this commit AIX passed all tests related to _curses.

----------
messages: 358210
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: [AIX] module _ctypes fails to build since ESCDELAY has been added
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39020>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:44:53 2019
From: report at bugs.python.org (Sergii Tkachenko)
Date: Tue, 10 Dec 2019 18:44:53 +0000
Subject: [issue33762] temp file isn't IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576003493.21.0.977628177233.issue33762@roundup.psfhosted.org>


Sergii Tkachenko <hi at sergii.org> added the comment:

Confirming this to be a thing on Python 3.7.5 / OS X 10.15.1.

In [31]: f = tempfile.NamedTemporaryFile()
In [32]: isinstance(f, io.IOBase)
Out[32]: False

----------
nosy: +sergiitk
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:50:12 2019
From: report at bugs.python.org (Sergii Tkachenko)
Date: Tue, 10 Dec 2019 18:50:12 +0000
Subject: [issue33762] temp file isn't IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576003812.05.0.630282873456.issue33762@roundup.psfhosted.org>


Sergii Tkachenko <hi at sergii.org> added the comment:

Affected as well:
Python 3.8.0 (default, Nov  3 2019, 10:55:54)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin

----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:01:30 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 Dec 2019 19:01:30 +0000
Subject: [issue39020] [AIX] module _ctypes fails to build since ESCDELAY has
 been added
In-Reply-To: <1576003274.61.0.235026296751.issue39020@roundup.psfhosted.org>
Message-ID: <1576004490.03.0.426300707156.issue39020@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39020>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:06:26 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 Dec 2019 19:06:26 +0000
Subject: [issue39020] [AIX] module _ctypes fails to build since ESCDELAY has
 been added
In-Reply-To: <1576003274.61.0.235026296751.issue39020@roundup.psfhosted.org>
Message-ID: <1576004786.96.0.754834958348.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I am thinking along two lines:

a) tell setup.py to not build _curses, just as _curses_panel

b) figure out how to use configure tests, to establish that ESCDELAY is not available AND then tell _cursesmodule.* that these routines are not available (and add that to the new docs for these routines).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39020>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:08:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 19:08:00 +0000
Subject: [issue33762] temp file isn't IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576004880.12.0.640381303756.issue33762@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Even if make TemporaryFile a subclass of IOBase (I am not sure we should do this) you could only use this in Python 3.9 and newer. I think it is better to fix this issue on the aiohttp side. aiohttp already registers payload types for a bunch of file-like types. You can also register it yourself:

aiohttp.payload.PAYLOAD_REGISTRY.register(aiohttp.payload.IOBasePayload, tempfile.TemporaryFile)

Seems IOBasePayload needs only read() and close() methods.

----------
nosy: +asvetlov, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:29:13 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2019 19:29:13 +0000
Subject: [issue39020] [AIX] module _curses fails to build since ESCDELAY has
 been added
In-Reply-To: <1576003274.61.0.235026296751.issue39020@roundup.psfhosted.org>
Message-ID: <1576006153.17.0.819034622906.issue39020@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +Build
title: [AIX] module _ctypes fails to build since ESCDELAY has been added -> [AIX] module _curses fails to build since ESCDELAY has been added

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39020>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:33:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 19:33:12 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576006392.54.0.966260092632.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 07871b256c76ca561554d1f82b430fc64a5c7ee0 by Victor Stinner in branch 'master':
bpo-38614: Use test.support.LOOPBACK_TIMEOUT constant (GH-17554)
https://github.com/python/cpython/commit/07871b256c76ca561554d1f82b430fc64a5c7ee0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:37:50 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Dec 2019 19:37:50 +0000
Subject: [issue33762] temp file isn't IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576006670.17.0.881806814178.issue33762@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:40:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 19:40:39 +0000
Subject: [issue39020] [AIX] module _curses fails to build since ESCDELAY has
 been added
In-Reply-To: <1576003274.61.0.235026296751.issue39020@roundup.psfhosted.org>
Message-ID: <1576006839.85.0.697868256307.issue39020@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I prefer option (b). We can also just use

#if !defined(_AIX) || defined(NCURSES_VERSION)

Interesting, a comment in curses.h:

 * Notes:
 *	a. ESCDELAY was an undocumented feature under AIX curses.
 *	   It gives the ESC expire time in milliseconds.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39020>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:41:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 19:41:30 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576006890.33.0.116981211085.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bbc8b7965bb9f46763c96878326966f4231c7d39 by Victor Stinner in branch 'master':
bpo-38614: Use default join_thread() timeout in tests (GH-17559)
https://github.com/python/cpython/commit/bbc8b7965bb9f46763c96878326966f4231c7d39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:44:22 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 10 Dec 2019 19:44:22 +0000
Subject: [issue33762] temp file isn't IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576007062.3.0.372825914121.issue33762@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Agree, aiohttp can be fixed easily.

If somebody wants to make a pull request -- you are welcome!
https://github.com/aio-libs/aiohttp/issues/4432

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:04:34 2019
From: report at bugs.python.org (mefistotelis)
Date: Tue, 10 Dec 2019 20:04:34 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1576008274.56.0.262303621307.issue39011@roundup.psfhosted.org>


mefistotelis <mefistotelis at gmail.com> added the comment:

Disclaimer: I'm not at all an expert in XML specs.

The linked spec chapter, "End-of-Line Handling", says all line endings should behave like they were converted to "\n" _before_ parsing.

This means:

1. This part of spec does not apply to the behavior described in the issue , because line endings are converted before the file is saved. The spec describes loading process, not saving.

2. Before parsing, the line endings within attributes are replaced by idioms - so they are no longer line endings in the meaning assigned by the spec. The chapter starts with clear indication that it only applies to line endings which are used to give structure to physical file. The affected line endings are narrowed by stating: "files [...], for editing convenience, are organized into lines.". Since line endings in attributes are idiomized, they don't take part of organizing file into lines.


Then again, I'm not an expert. From the various specs I worked with, I know that the affected industry always comes out with unified interpretation of specs. If it was widely accepted to apply this chapter to values of attributes, I'd understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:05:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2019 20:05:51 +0000
Subject: [issue33762] temp file isn't IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576008351.36.0.935000037611.issue33762@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Actually things are more complex. TemporaryFile is not a class, it is a function, so it does not make sense to use it with isinstance(). And if add support for TemporaryFile, NamedTemporaryFile and SpooledTemporaryFile should be supported too.

It may be easier to use a virtual subclassing: register IOBasePayload with a class which has an __instancecheck__() method which checks the existence of attributes "read" and "close".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:12:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 20:12:30 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576008750.4.0.112501363412.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c98b0199a984430312833ef403d265be314f7244 by Victor Stinner in branch 'master':
bpo-38614: Use test.support.LONG_TIMEOUT constant (GH-17562)
https://github.com/python/cpython/commit/c98b0199a984430312833ef403d265be314f7244


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:17:23 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Dec 2019 20:17:23 +0000
Subject: [issue39012] nuget package published as 3.8.1-c1 instead of rc1
In-Reply-To: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>
Message-ID: <1576009043.21.0.356945775215.issue39012@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
title: nuget package published at 3.8.1-c1 instead of rc1 -> nuget package published as 3.8.1-c1 instead of rc1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:18:54 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Dec 2019 20:18:54 +0000
Subject: [issue39012] nuget package published as 3.8.1-c1 instead of rc1
In-Reply-To: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>
Message-ID: <1576009134.73.0.137534560036.issue39012@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +17036
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17564

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:33:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 20:33:35 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576010015.86.0.979916415884.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17037
pull_request: https://github.com/python/cpython/pull/17565

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:34:05 2019
From: report at bugs.python.org (Dave Lawrence)
Date: Tue, 10 Dec 2019 20:34:05 +0000
Subject: [issue39001] possible problem with 64-bit mingw DECREF
In-Reply-To: <1575839278.99.0.426657382539.issue39001@roundup.psfhosted.org>
Message-ID: <1576010045.3.0.394825329698.issue39001@roundup.psfhosted.org>


Dave Lawrence <mail.dave.lawrence at gmail.com> added the comment:

further investigation seems to point to this being something to do with mingw and the dll. I have tried compiling the same test example on 64-bit linux and in the Ubuntu WSL on windows and it works. Tests also show that the refcount of '1' is correct and not the problem.
the PyObject pointers of 0000000002750408 are suspicious though and on sight look like 32-bit addresses -- is there some odd 32/64 bit mismatch happening somewhere even though the lib clearly links and loads the dll?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39001>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:42:15 2019
From: report at bugs.python.org (Rebecca Morgan)
Date: Tue, 10 Dec 2019 20:42:15 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1576010535.53.0.583366958378.issue38860@roundup.psfhosted.org>


Rebecca Morgan <beccamorgan92 at gmail.com> added the comment:

Hi there, I?m a newcomer would like to take a look at this. Planning to investigate over the next few days.

----------
nosy: +beccamorgan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:06:26 2019
From: report at bugs.python.org (Fabio Pugliese Ornellas)
Date: Tue, 10 Dec 2019 21:06:26 +0000
Subject: [issue38225] iscoroutinefunction broken with cython - allow tagging
 of functions as async?
In-Reply-To: <1568918319.91.0.348855638851.issue38225@roundup.psfhosted.org>
Message-ID: <1576011986.71.0.373901838291.issue38225@roundup.psfhosted.org>


Fabio Pugliese Ornellas <fabio.ornellas at gmail.com> added the comment:

It is worth noting that test frameworks can greatly benefit from iscoroutinefunction to work.

I'm the main author of TestSlide, which provides more strict mocking for Python. I recently added async support, so we can detect bugs such as configuring a sync mock for something that is async (https://testslide.readthedocs.io/en/2.0.2/strict_mock/index.html#coroutine-functions-async-def). It works just fine, as long as iscoroutinefunction works, which is not the case for async Cython (a big chunk of TestSlide's use cases).

+1 an Andrew's func.__awaitable__ idea: interpreter can provide that for `async def` and one can also do that for anything that implements __call__ to communicate that the callable is async.

----------
nosy: +fornellas

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38225>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:09:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 21:09:30 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576012170.29.0.728853729682.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1d0f9b316a290f0e1f330fdbceb027deb96ce109 by Victor Stinner in branch 'master':
bpo-38614: Use test.support.INTERNET_TIMEOUT constant (GH-17565)
https://github.com/python/cpython/commit/1d0f9b316a290f0e1f330fdbceb027deb96ce109


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:13:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 21:13:54 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576012434.38.0.657489487806.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17038
pull_request: https://github.com/python/cpython/pull/17566

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:18:18 2019
From: report at bugs.python.org (Jonathan Slenders)
Date: Tue, 10 Dec 2019 21:18:18 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1576012698.92.0.266086468077.issue39010@roundup.psfhosted.org>


Jonathan Slenders <jonathan.slenders at gmail.com> added the comment:

Even simpler, the following code will crash after so many iterations:


```
import asyncio
loop = asyncio.get_event_loop()

while True:
    loop.call_soon_threadsafe(loop.stop)
    loop.run_forever()
```

Adding a little sleep of 0.01s after `run_forever()` prevents the issue.

So, to me it looks like the cancellation of the `_OverlappedFuture` that wraps around the `_recv()` call from the self-pipe did not complete before we start `_recv()` again in the next `run_forever()` call. No idea if that makes sense...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:28:55 2019
From: report at bugs.python.org (Giovanni Lombardo)
Date: Tue, 10 Dec 2019 21:28:55 +0000
Subject: [issue31485] Tkinter widget.unbind(sequence,
 funcid) unbind all bindings
In-Reply-To: <1505483834.38.0.808110743528.issue31485@psf.upfronthosting.co.za>
Message-ID: <1576013335.43.0.0277744155565.issue31485@roundup.psfhosted.org>


Giovanni Lombardo <g.lombardo at protonmail.com> added the comment:

http://docs.python.org/devguide/triaging.html#assigned-to

----------
nosy: +glombardo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31485>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:37:50 2019
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Dec 2019 21:37:50 +0000
Subject: [issue39017] Infinite loop in the tarfile module
In-Reply-To: <1575994796.67.0.46582695163.issue39017@roundup.psfhosted.org>
Message-ID: <1576013870.51.0.740981399226.issue39017@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39017>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:46:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2019 21:46:08 +0000
Subject: [issue39001] possible problem with 64-bit mingw DECREF
In-Reply-To: <1575839278.99.0.426657382539.issue39001@roundup.psfhosted.org>
Message-ID: <1576014368.78.0.518976527121.issue39001@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39001>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:13:15 2019
From: report at bugs.python.org (Christian Tismer)
Date: Tue, 10 Dec 2019 22:13:15 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575997036.45.0.749879142222.issue39016@roundup.psfhosted.org>
Message-ID: <85332bb6-1116-3415-e154-415d428e6ebd@stackless.com>


Christian Tismer <tismer at stackless.com> added the comment:

On 10.12.19 17:57, Pablo Galindo Salgado wrote:
> 
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
> 
>> No, this appears to be impossible.
> 
> Oh, I see. Apologies then for the misunderstunding.

No problem! You could as well have been right.
I tried to move the patch to master and realized only then
that there was nothing similar. Interesting btw., I should
investigate when this divergence was introduced.

Best -- Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:47:09 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 Dec 2019 22:47:09 +0000
Subject: [issue39020] [AIX] module _curses fails to build since ESCDELAY has
 been added
In-Reply-To: <1576003274.61.0.235026296751.issue39020@roundup.psfhosted.org>
Message-ID: <1576018029.05.0.169011214669.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

quote: Interesting, a comment in curses.h:

 * Notes:
 *	a. ESCDELAY was an undocumented feature under AIX curses.
 *	   It gives the ESC expire time in milliseconds.

iirc - that is a symbolic link to ncurses.h from ncurses-devel RPM package, not something from AIX itself.

On my test partitions - where I do not install RPMs, I do not have that comment. Likewise, I did see that comment on the gccfarm POWER8 provided by IBM (which has ncurses-devel installed, or I would have never known :) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39020>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:50:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Dec 2019 22:50:55 +0000
Subject: [issue33762] Make tempfiles subclass IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576018255.67.0.983684701828.issue33762@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

TemporaryFile() returns an instance of _TemporaryFileWrapper.  isinstance(TemporaryFile(), io.IOBase) is a sensible thing to do and would be True if _TemporaryFileWrapper subclassed the appropriate io base file.

The base class for IDLE's stdxxx pseudofiles does this and hence, for instance,

>>> sys.stdout
<idlelib.run.StdOutputFile object at 0x0000023BEB515F70>
>>> isinstance(sys.stdout, io.IOBase)
True

I believe that tempfile long predates io, added in 2.6.  Since the IO base classes are not 'abstract base classes' in the sense of subclassing abc.ABCMeta, the tempfile classes cannot just be registered as implementing them.  And tempfile has never been re-written to be based on io, by subclassing io base classes.

Doing so would fix this issue.  It *might* result in simpler tempfile code (but I would not be sure until it is done).  It would also address (but not automatically fix) #26175. I think SpooledTemporaryFile would likely be the hardest.  Martin and Serhiy are correct that a change would be an enhancement, not a bugfix.

----------
stage:  -> test needed
title: temp file isn't IOBase -> Make tempfiles subclass IOBase
type: behavior -> enhancement
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:19:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Dec 2019 23:19:20 +0000
Subject: [issue39012] nuget package published as 3.8.1-c1 instead of rc1
In-Reply-To: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>
Message-ID: <1576019960.83.0.139672158875.issue39012@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d0802d07d2c864b95480a9b24c7cc050e19189d5 by Steve Dower in branch 'master':
bpo-39012: Fix RC version suffix for nuget release files (GH-17564)
https://github.com/python/cpython/commit/d0802d07d2c864b95480a9b24c7cc050e19189d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:19:29 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 10 Dec 2019 23:19:29 +0000
Subject: [issue39012] nuget package published as 3.8.1-c1 instead of rc1
In-Reply-To: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>
Message-ID: <1576019969.66.0.549959357817.issue39012@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17039
pull_request: https://github.com/python/cpython/pull/17567

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:20:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Dec 2019 23:20:16 +0000
Subject: [issue39012] nuget package published as 3.8.1-c1 instead of rc1
In-Reply-To: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>
Message-ID: <1576020016.8.0.0406202806731.issue39012@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/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:22:54 2019
From: report at bugs.python.org (Matt)
Date: Tue, 10 Dec 2019 23:22:54 +0000
Subject: [issue39021] multiprocessing is_alive() between children processes
Message-ID: <1576020174.84.0.795117240122.issue39021@roundup.psfhosted.org>


New submission from Matt <matthewtimms at live.com.au>:

I'm trying to evaluate process' state between two "sibling" processes (processes created by the same parent process); using the .is_alive() and exitcode to evaluate whether a process has been init'd, started, finished successfully or unsuccessfully. 
The reference to one process is passed to the other and I'd like to call .is_alive(). This raises the following assertion error:

Process C-2:
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/home/timms/.PyCharm2019.2/config/scratches/is_alive_method.py", line 59, in run
    print("brother - ",self.brother.state)
  File "/home/timms/.PyCharm2019.2/config/scratches/is_alive_method.py", line 16, in state
    if self.is_alive():
  File "/usr/lib/python3.7/multiprocessing/process.py", line 151, in is_alive
    assert self._parent_pid == os.getpid(), 'can only test a child process'
AssertionError: can only test a child process

It's obvious that the assertion fails given the family structure of the processes. Overwriting the is_alive() method in my own process class appears to produce my desired output behaviour - with assertion and discarding self removed (see attachment).

Is there something fundamental to how process' operate that I should be weary of? I understand that is_alive also joins itself if possible; is that the sole reason for the assertion? Could a method that mirrors is_alive() without the assertion and discard method work with the desired intention I've described above?

----------
files: is_alive_method.py
messages: 358232
nosy: matttimms
priority: normal
severity: normal
status: open
title: multiprocessing is_alive() between children processes
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48770/is_alive_method.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39021>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:24:23 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 Dec 2019 23:24:23 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.2
Message-ID: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Calling for another refresh of importlib.metadata from the third-party package. History at https://importlib-metadata.readthedocs.io/en/latest/changelog%20(links).html.

----------
messages: 358233
nosy: jaraco
priority: normal
severity: normal
status: open
title: Synchronize importlib.metadata with importlib_metadata 1.2
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:28:29 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 Dec 2019 23:28:29 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1576020509.32.0.15569375078.issue38594@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've merged the recommended changes into importlib_metadata 1.3 and I'm including those changes in issue39022.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38594>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:28:35 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 Dec 2019 23:28:35 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.3
In-Reply-To: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>
Message-ID: <1576020515.02.0.986659113657.issue39022@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
title: Synchronize importlib.metadata with importlib_metadata 1.2 -> Synchronize importlib.metadata with importlib_metadata 1.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:33:01 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 Dec 2019 23:33:01 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.3
In-Reply-To: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>
Message-ID: <1576020781.66.0.573402293586.issue39022@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +17040
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17568

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:33:02 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 10 Dec 2019 23:33:02 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1576020782.0.0.510771905905.issue38594@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +17041
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17568

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38594>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:40:10 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 10 Dec 2019 23:40:10 +0000
Subject: [issue39012] nuget package published as 3.8.1-c1 instead of rc1
In-Reply-To: <1575954830.8.0.575755006659.issue39012@roundup.psfhosted.org>
Message-ID: <1576021210.36.0.394169007903.issue39012@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 00e2fe4f214eadd5714751968e158c78a8a3f04b by Miss Islington (bot) in branch '3.8':
bpo-39012: Fix RC version suffix for nuget release files (GH-17564)
https://github.com/python/cpython/commit/00e2fe4f214eadd5714751968e158c78a8a3f04b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39012>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:25:38 2019
From: report at bugs.python.org (Michael Thompson)
Date: Wed, 11 Dec 2019 00:25:38 +0000
Subject: [issue39023] random.seed with string and version 1 not deterministic
 in 3.5.2
Message-ID: <1576023938.27.0.564451634943.issue39023@roundup.psfhosted.org>


New submission from Michael Thompson <mfthom at gmail.com>:

Version 3.5.2, the "rand string seed" is not deterministic in code sample below across multiple invocations of the program.  Python 3.6.8 works fine.

#!/usr/bin/env python3
import random
lis = '94'
random.seed(lis, version=1)
w = random.random() * 100
print('rand string seed: %d' % w)
lis = 94
random.seed(lis, version=1)
w = random.random() * 100
print('rand int seed: %d' % w)


Running in a Docker container: uname -a:
Linux formatstring-igrader 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

----------
messages: 358236
nosy: mfthomps
priority: normal
severity: normal
status: open
title: random.seed with string and version 1 not deterministic in 3.5.2
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39023>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:05:19 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 11 Dec 2019 01:05:19 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1576026319.14.0.57811322148.issue38594@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset b7a0109cd2bafaa21a4d50aad307e901c68f9156 by Jason R. Coombs in branch 'master':
bpo-39022, bpo-38594: Sync with importlib_metadata 1.3 (GH-17568)
https://github.com/python/cpython/commit/b7a0109cd2bafaa21a4d50aad307e901c68f9156


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38594>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:05:25 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 11 Dec 2019 01:05:25 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.3
In-Reply-To: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>
Message-ID: <1576026325.48.0.844825332531.issue39022@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17042
pull_request: https://github.com/python/cpython/pull/17569

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:05:25 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 11 Dec 2019 01:05:25 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1576026325.67.0.469557933415.issue38594@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17043
pull_request: https://github.com/python/cpython/pull/17569

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38594>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:05:19 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 11 Dec 2019 01:05:19 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.3
In-Reply-To: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>
Message-ID: <1576026319.26.0.168024175415.issue39022@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset b7a0109cd2bafaa21a4d50aad307e901c68f9156 by Jason R. Coombs in branch 'master':
bpo-39022, bpo-38594: Sync with importlib_metadata 1.3 (GH-17568)
https://github.com/python/cpython/commit/b7a0109cd2bafaa21a4d50aad307e901c68f9156


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:10:39 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Dec 2019 01:10:39 +0000
Subject: [issue39023] random.seed with string and version 1 not deterministic
 in 3.5.2
In-Reply-To: <1576023938.27.0.564451634943.issue39023@roundup.psfhosted.org>
Message-ID: <1576026639.45.0.0942454446519.issue39023@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this was already fixed in 3.5, but the fix would have gone in later than the 3.5.2 release: see issue #27706. 3.5.3 and later should have the fix.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39023>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:28:36 2019
From: report at bugs.python.org (Michael Thompson)
Date: Wed, 11 Dec 2019 01:28:36 +0000
Subject: [issue39023] random.seed with string and version 1 not deterministic
 in 3.5.2
In-Reply-To: <1576026639.45.0.0942454446519.issue39023@roundup.psfhosted.org>
Message-ID: <CAO0BwYCVHEOBhBg2vt3n5DV236F_stv47-fMhXkbZwTgQXgSfQ@mail.gmail.com>


Michael Thompson <mfthom at gmail.com> added the comment:

Thanks.  I found 3.6 works for me.
--Mike

On Tue, Dec 10, 2019 at 5:10 PM Mark Dickinson <report at bugs.python.org>
wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> I think this was already fixed in 3.5, but the fix would have gone in
> later than the 3.5.2 release: see issue #27706. 3.5.3 and later should have
> the fix.
>
> ----------
> nosy: +mark.dickinson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39023>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39023>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:41:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Dec 2019 01:41:51 +0000
Subject: [issue39023] random.seed with string and version 1 not deterministic
 in 3.5.2
In-Reply-To: <1576023938.27.0.564451634943.issue39023@roundup.psfhosted.org>
Message-ID: <1576028511.95.0.987548862194.issue39023@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39023>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:47:13 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 11 Dec 2019 01:47:13 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.3
In-Reply-To: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>
Message-ID: <1576028833.48.0.738566519851.issue39022@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset b738237d6792acba85b1f6e6c8993a812c7fd815 by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':
bpo-39022, bpo-38594: Sync with importlib_metadata 1.3 (GH-17568) (GH-17569)
https://github.com/python/cpython/commit/b738237d6792acba85b1f6e6c8993a812c7fd815


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:47:13 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 11 Dec 2019 01:47:13 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1576028833.35.0.689524799302.issue38594@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset b738237d6792acba85b1f6e6c8993a812c7fd815 by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':
bpo-39022, bpo-38594: Sync with importlib_metadata 1.3 (GH-17568) (GH-17569)
https://github.com/python/cpython/commit/b738237d6792acba85b1f6e6c8993a812c7fd815


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38594>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:45:21 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 11 Dec 2019 02:45:21 +0000
Subject: [issue39022] Synchronize importlib.metadata with importlib_metadata
 1.3
In-Reply-To: <1576020263.92.0.109449278441.issue39022@roundup.psfhosted.org>
Message-ID: <1576032321.54.0.443499355285.issue39022@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39022>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:45:25 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 11 Dec 2019 02:45:25 +0000
Subject: [issue38594] importlib.metadata documentation deficiencies
In-Reply-To: <1572060294.8.0.317725248433.issue38594@roundup.psfhosted.org>
Message-ID: <1576032325.87.0.186844680642.issue38594@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm hoping those documentation edits address the deficiencies, but if not, we can take another stab at it. Feel free to re-open as needed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38594>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:29:08 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2019 04:29:08 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576038548.16.0.921665992691.issue37228@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +17044
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17570

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:49:30 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2019 04:49:30 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576039770.75.0.19315780317.issue37228@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 95157c6a281ccfc7a92a17dfb8d7b5338cad5cb7 by Ned Deily in branch '3.7':
bpo-37228: Fix loop.create_datagram_endpoint()'s usage of SO_REUSEADDR (GH-17311) (GH-17570)
https://github.com/python/cpython/commit/95157c6a281ccfc7a92a17dfb8d7b5338cad5cb7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:54:08 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2019 04:54:08 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576040048.72.0.171831493821.issue37228@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The backport to 3.7 seems straightforward so I did it to unblock 3.7.6rc1.  The backport to 3.6 is a bit more complicated and 3.6.10rc1 can wait a bit longer so I'll leave that for Kyle along with the various What's New entries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:39:09 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 11 Dec 2019 05:39:09 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576042748.99.0.702940363058.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> The backport to 3.7 seems straightforward so I did it to unblock 3.7.6rc1.  The backport to 3.6 is a bit more complicated and 3.6.10rc1 can wait a bit longer so I'll leave that for Kyle along with the various What's New entries.

Thanks, Ned. I'll prioritize working on the What's New entries for 3.7 and 3.8 (likely in the same PR to master) before working on the backports to 3.6 and 3.5, since the release for 3.7.1 and 3.7.6 are coming up soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:42:39 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 11 Dec 2019 05:42:39 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576042959.92.0.375341946009.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> since the release for 3.7.1 and 3.7.6 are coming up soon.

Clarification: should be "since the release for 3.8.1 and 3.7.6 are coming up soon", that was a typo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:44:19 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2019 05:44:19 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576043059.2.0.891161069034.issue37228@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Actually, 3.6.10rc1 is currently blocked by this so if you do have time to work on it first, that would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:47:26 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 11 Dec 2019 05:47:26 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576043246.56.0.63954018287.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Oh okay, I'll work on the 3.6 backport first then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:21:40 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 11 Dec 2019 06:21:40 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576045300.59.0.135049828326.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17045
pull_request: https://github.com/python/cpython/pull/17571

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:33:06 2019
From: report at bugs.python.org (John94)
Date: Wed, 11 Dec 2019 06:33:06 +0000
Subject: [issue39024] Compiling relative paths test fails (install via pyenv)
Message-ID: <1576045986.0.0.10589382757.issue39024@roundup.psfhosted.org>


New submission from John94 <krballard94 at gmail.com>:

Installed the below versions using pyenv on macOS 10.15.2, once installed I ran tests on all versions and they all failed on the "test_py_compile" test.

2.7.17 - https://pastebin.com/iFCA7FZb
3.6.9  - https://pastebin.com/UYfUqK9p
3.7.5  - https://pastebin.com/dzKeYVZD
3.8.0  - https://pastebin.com/sT7DT1WQ

----------
components: Tests
files: 2_7_17.txt
messages: 358250
nosy: John94
priority: normal
severity: normal
status: open
title: Compiling relative paths test fails (install via pyenv)
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48771/2_7_17.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39024>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:33:30 2019
From: report at bugs.python.org (John94)
Date: Wed, 11 Dec 2019 06:33:30 +0000
Subject: [issue39024] Compiling relative paths test fails (install via pyenv)
In-Reply-To: <1576045986.0.0.10589382757.issue39024@roundup.psfhosted.org>
Message-ID: <1576046010.06.0.489616995608.issue39024@roundup.psfhosted.org>


Change by John94 <krballard94 at gmail.com>:


Removed file: https://bugs.python.org/file48771/2_7_17.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39024>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:36:54 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2019 06:36:54 +0000
Subject: [issue39024] Compiling relative paths test fails (install via pyenv)
In-Reply-To: <1576045986.0.0.10589382757.issue39024@roundup.psfhosted.org>
Message-ID: <1576046214.87.0.769094917886.issue39024@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report.  This problem is being tracked in Issue38295.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_relative_path of test_py_compile fails on macOS 10.15 Catalina

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39024>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:54:14 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2019 06:54:14 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576047254.35.0.0362156344233.issue37228@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset b23c0840ce07e03f2705fb08d94f8f03e5c5d5b8 by Ned Deily (Kyle Stanley) in branch '3.6':
[3.6] bpo-37228: Fix loop.create_datagram_endpoint()'s usage of SO_REUSEADDR (GH-17311). (GH-17571)
https://github.com/python/cpython/commit/b23c0840ce07e03f2705fb08d94f8f03e5c5d5b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 02:03:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2019 07:03:01 +0000
Subject: [issue33762] Make tempfiles subclass IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576047781.95.0.675069806104.issue33762@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have doubts that making _TemporaryFileWrapper a subclass of IOBase can make it simpler. It can make it more complex. _TemporaryFileWrapper is a proxy class with the __getattr__ method which not just return attributes of the underlying file, but wraps methods so they have references to the _TemporaryFileWrapper instance. If subclass IOBase you will need to write implementations of all methods of IOBase and its subclasses. You could also to reproduce the hierarhy of io classes to support binary and text, buffered and unbuffered files.

IDLE's pseudofiles are simpler because they represent only text files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Wed Dec 11 02:08:32 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 11 Dec 2019 07:08:32 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576048112.42.0.995114486471.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Now that the backports for 3.6-3.8 are merged, I'll work on the What's New entries next. Waiting on feedback from Larry Hastings regarding the potential 3.5 backport, I'll add him to the nosy list.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Wed Dec 11 04:13:16 2019
From: report at bugs.python.org (Ben Brown)
Date: Wed, 11 Dec 2019 09:13:16 +0000
Subject: [issue37226] Asyncio Fatal Error on SSL Transport - IndexError Deque
 Index Out Of Range
In-Reply-To: <1560242699.55.0.804750809475.issue37226@roundup.psfhosted.org>
Message-ID: <1576055596.25.0.999813711229.issue37226@roundup.psfhosted.org>


Change by Ben Brown <ben.brown at envisionvirginracing.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37226>
_______________________________________

From report at bugs.python.org  Wed Dec 11 05:30:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 10:30:22 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576060222.06.0.94468467938.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0d63bacefd2e5b937ec6b0ec3053777c09941b4a by Victor Stinner in branch 'master':
bpo-38614: Use test.support.SHORT_TIMEOUT constant (GH-17566)
https://github.com/python/cpython/commit/0d63bacefd2e5b937ec6b0ec3053777c09941b4a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Wed Dec 11 05:44:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 10:44:10 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576061050.07.0.293875817718.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17046
pull_request: https://github.com/python/cpython/pull/17572

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Wed Dec 11 06:30:56 2019
From: report at bugs.python.org (Bluebird)
Date: Wed, 11 Dec 2019 11:30:56 +0000
Subject: [issue39025] Windows Python Launcher does not update PATH to Scripts
 directory
Message-ID: <1576063856.43.0.431001018192.issue39025@roundup.psfhosted.org>


New submission from Bluebird <phil at freehackers.org>:

The py Python launcher is a great improvement over a few years ago when managing multiple Python installation was tedious.

However, it does not solve one annoying problem: the Scripts directory. If you install tools like mypy, pyqt-tools or pyinstaller, to be able to use them, you need to have the Scripts directory in your PATH variable. And if you have multiple Python installations, you are back to square 1 where you have to explicitely modify your PATH according to the version of Python where the tools have been installed.

To give a practical example, at work, I have Python 3.1 because some of our software are distributed as .pyc for this version of Python, Python 3.5 for the same reason and Python 3.7 for all the developments which do not incur the previous dependencies.

The default environement with Python and Python\Scripts added to the path is Python 3.5 . However, for all PyQt developments, I use Python 3.7 . I launch my program with py -3.7 myfancygui.py  but when I want to access some of the pyqt tools like pyuic5, I need to explicitely add Python3.7\Scripts to my PATH.

The technical solution is not clear to me, but it would be nice to duplicate the benefits of the py launcher to the Scripts directory.

Some random propositions:

1. Create a pyscript launcher, which would work like py but would take as command-line the name of the script to run:

    pyscript -3.7 pyuic5

2. Let py execute a command-line with proper environment for that specific version of python:

   > py -env-3.7
   Environment adjusted for Python 3.7
   > pyuic5 ... works fine
   > exit
   Back to default environement

There are probably other stratagic ways to reach the same result.

----------
components: Windows
messages: 358256
nosy: bluebird, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Python Launcher does not update PATH to Scripts directory
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39025>
_______________________________________

From report at bugs.python.org  Wed Dec 11 06:37:01 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 11 Dec 2019 11:37:01 +0000
Subject: [issue28866] Type cache is not correctly invalidated on a class
 defining mro()
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1576064221.35.0.0313681193764.issue28866@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

A refcount problem possibly caused by the fix: https://bugs.python.org/issue39016

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28866>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:31:19 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 11 Dec 2019 12:31:19 +0000
Subject: [issue28866] Type cache is not correctly invalidated on a class
 defining mro()
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1576067479.27.0.421416192872.issue28866@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +17047
pull_request: https://github.com/python/cpython/pull/17573

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28866>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:36:42 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 11 Dec 2019 12:36:42 +0000
Subject: [issue28866] Type cache is not correctly invalidated on a class
 defining mro()
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1576067802.47.0.0490355695495.issue28866@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Steve, I would like to add your reproducer (weird.py) to CPython's test suite, to make sure this doesn't happen again.

Would you be willing to sign the contributor agreement, so we can use your code in Python?

The instructions are here: https://www.python.org/psf/contrib/contrib-form/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28866>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:47:45 2019
From: report at bugs.python.org (Paul Moore)
Date: Wed, 11 Dec 2019 12:47:45 +0000
Subject: [issue39025] Windows Python Launcher does not update PATH to Scripts
 directory
In-Reply-To: <1576063856.43.0.431001018192.issue39025@roundup.psfhosted.org>
Message-ID: <1576068465.41.0.305153488003.issue39025@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Most items in the Scripts directory can be run using the `-m` flag to Python, so you can use something like `py -m pip` to run pip without needing the Scripts directory in PATH.

If an individual project like PyQt doesn't support -m, it's relatively easy for them to add, so it might be worth suggesting to them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39025>
_______________________________________

From report at bugs.python.org  Wed Dec 11 08:13:40 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 11 Dec 2019 13:13:40 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1576070020.44.0.986082107003.issue39016@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

lookup_maybe_method should not return a borrowed reference. It increfs its return value.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 08:46:21 2019
From: report at bugs.python.org (Julien Danjou)
Date: Wed, 11 Dec 2019 13:46:21 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1576071981.49.0.682756689449.issue1021318@roundup.psfhosted.org>


Julien Danjou <julien at danjou.info> added the comment:

Victor, do you have an idea of how you would like this mutex to be exposed?

I see it only recently changed in Python 3.7 to be part of a structure, though this structure is not public AFAIU.

Is adding 2 new lock/unlock C functions good enough?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:02:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 14:02:09 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1576072929.85.0.213365547585.issue1021318@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm not sure of what is the best approach. Currently, bpo-10915 is blocking different projects: "Make the PyGILState API compatible with multiple interpreters". We may have to fix this API first, and clarify the scope of the different locks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:02:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 14:02: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: <1576072948.84.0.328592549732.issue10915@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-1021318: "PyThreadState_Next not thread safe".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:06:22 2019
From: report at bugs.python.org (Bluebird)
Date: Wed, 11 Dec 2019 14:06:22 +0000
Subject: [issue39025] Windows Python Launcher does not update PATH to Scripts
 directory
In-Reply-To: <1576063856.43.0.431001018192.issue39025@roundup.psfhosted.org>
Message-ID: <1576073182.55.0.671324499813.issue39025@roundup.psfhosted.org>


Bluebird <phil at freehackers.org> added the comment:

Thanks for the quick feedback.

I agree that it makes sense for python modules to support -m. However, PyQt comes with many executables originally written in C++ for Qt (designer, assistant). It feels a bit strange to add a module with that name, just for the purpose of creating a -m target so that you can run it without Scripts in path.

Moreover, some of these C++ exectuables depends on DLL which are only in the Scripts directory and it might not work. I do not think that your proposal addresses the full problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39025>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:58:40 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Wed, 11 Dec 2019 14:58:40 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1576076320.7.0.219867091241.issue38860@roundup.psfhosted.org>


Change by Lewis Gaul <lewis.gaul at gmail.com>:


----------
nosy: +LewisGaul, aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:25:09 2019
From: report at bugs.python.org (Rebecca Morgan)
Date: Wed, 11 Dec 2019 15:25:09 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1576077909.98.0.817022992423.issue38860@roundup.psfhosted.org>


Rebecca Morgan <beccamorgan92 at gmail.com> added the comment:

Looking at the test case 'test_from_buffer_copy' here:
https://github.com/python/cpython/blob/master/Lib/ctypes/test/test_frombuffer.py

This suggests the failure to call init in this instance is expected behavior (similarly for from_buffer), unlike e.g. the classmethod fromkeys() with a dictionary subclass which behaves as expected.

Are there any required changes here, perhaps if not code then documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:34:04 2019
From: report at bugs.python.org (Gaige Paulsen)
Date: Wed, 11 Dec 2019 15:34:04 +0000
Subject: [issue39026] pystate.h contains non-relative of initconfig.h include
 causing macOS Framework include failure
Message-ID: <1576078444.86.0.577960577024.issue39026@roundup.psfhosted.org>


New submission from Gaige Paulsen <gaige at cluetrust.com>:

The cpython/pystate.h includes cpython/initconfig.h using the relative path "cpython/initconfig.h", which probably works fine if your include path explicitly contains the top of the python directory, however when developing with a framework in macOS, the framework's root path cannot be referred to relatively.

Since cpython/pystate.h and cpython/initconfig.h live in the same directory, any C compiler should include them correctly, regardless of include path if the cpython/pystate.h includes "initconfig.h" instead of "cpython/initconfig.h", since I believe the very first path is always relative to the file including the next file.  In this case, cpython is the parent of pystate.h and thus including initconfig.h directly should work fine.

Previous 3.x versions worked fine, but the cpython directory wasn't in Headers for macOS.

Although I wasn't able to exhaustively test this on all platforms and with all compilers, changing the include in cpython/pystate.h to "initconfig.h" solved the compilation/include problem.

----------
components: C API, macOS
messages: 358266
nosy: gaige, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39026>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:36:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 15:36:46 +0000
Subject: [issue39026] pystate.h contains non-relative of initconfig.h include
 causing macOS Framework include failure
In-Reply-To: <1576078444.86.0.577960577024.issue39026@roundup.psfhosted.org>
Message-ID: <1576078606.47.0.872513253345.issue39026@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39026>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:42:00 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 11 Dec 2019 15:42:00 +0000
Subject: [issue39026] pystate.h contains non-relative of initconfig.h include
 causing macOS Framework include failure
In-Reply-To: <1576078444.86.0.577960577024.issue39026@roundup.psfhosted.org>
Message-ID: <1576078920.36.0.165309297615.issue39026@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

In what way does it not work when using a framework build? Is this when you add the python framework to an (Xcode) project and include the main python header using "#include <Python/Python.h>"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39026>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:48:54 2019
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 11 Dec 2019 15:48:54 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1576070020.44.0.986082107003.issue39016@roundup.psfhosted.org>
Message-ID: <6785bd53-0ac7-3b97-3f2e-43f745d55062@stackless.com>


Christian Tismer <tismer at stackless.com> added the comment:

On 11.12.19 14:13, Petr Viktorin wrote:
> 
> Petr Viktorin <encukou at gmail.com> added the comment:
> 
> lookup_maybe_method should not return a borrowed reference. It increfs its return value.

At second sight, this seems to be true. No idea why I
was so convinced. Need to sleep and look again..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:57:00 2019
From: report at bugs.python.org (Gaige Paulsen)
Date: Wed, 11 Dec 2019 15:57:00 +0000
Subject: [issue39026] pystate.h contains non-relative of initconfig.h include
 causing macOS Framework include failure
In-Reply-To: <1576078444.86.0.577960577024.issue39026@roundup.psfhosted.org>
Message-ID: <1576079820.41.0.118189273463.issue39026@roundup.psfhosted.org>


Gaige Paulsen <gaige at cluetrust.com> added the comment:

I should have been more specific. Sorry about that.

Yes, when including <Python/Python.h> in Xcode, incorporating the framework. In particular, I'm embedding 3.8 in an application (previously used the system Framework, which was 2.7, which worked but Apple has warned that it may disappear....).  

The Xcode error is:

In file included from /Users/gaige/MyApp/Code/PythonImporter.m:10:
In file included from ../python-framework/Python.framework/Headers/Python.h:121:
In file included from ../python-framework/Python.framework/Headers/genobject.h:11:
In file included from ../python-framework/Python.framework/Headers/pystate.h:129:
../python-framework/Python.framework/Headers/cpython/pystate.h:10:10: fatal error: 'cpython/initconfig.h' file not found
#include "cpython/initconfig.h"
         ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.

python-framework is in the framework search path.

Let me know if there's something further I can clarify.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39026>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:18:10 2019
From: report at bugs.python.org (Eshan Singhal)
Date: Wed, 11 Dec 2019 16:18:10 +0000
Subject: [issue1438480] shutil.move raises OSError when copystat fails
Message-ID: <1576081090.32.0.931532502037.issue1438480@roundup.psfhosted.org>


Eshan Singhal <eshansinghal21 at gmail.com> added the comment:

Amending shutil.copy and shutil.copy2 to expose a method of ignoring the permission errors rather than changing the current behaviour would not fix the original issue without further changes in consumers of these functions to pass through the new parameter (i.e. shutil.move in this scenario).

This may be undesirable as copy_function is an optional parameter to shutil.move and so there would have to be a specialcase guard/check to see if the copy_function is shutil.copy or shutil.copy2 when passing in a new ignore_permission_errors parameter.

I propose a new issue to track adding functionality to optionally ignore permission issues for shutil.copy/shutil.copy2, and this issue can remain open.

----------
nosy: +eshan-singhal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1438480>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:37:27 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 11 Dec 2019 16:37:27 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1576082247.46.0.920541602686.issue39016@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The goal now should be to find a reasonably small reproducer.

I'm trying to compile PySide to see what it does, but it's a big project and I'm a bit lost.
Christian, you said in an e-mail that you have a workaround -- unsetting the Py_TPFLAGS_METHOD_DESCRIPTOR. Could you point me to the commit with that workaround, so I could try exploring the code in context?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:43:01 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 11 Dec 2019 16:43:01 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
Message-ID: <1576082581.75.0.897173308766.issue1021318@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:44:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Dec 2019 16:44:31 +0000
Subject: [issue39025] Windows Python Launcher does not update PATH to Scripts
 directory
In-Reply-To: <1576063856.43.0.431001018192.issue39025@roundup.psfhosted.org>
Message-ID: <1576082671.35.0.719327436094.issue39025@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Moreover, some of these C++ exectuables depends on DLL which are only in the Scripts directory and it might not work.

In this case, perhaps these tools should be in a separate directory? A simple .py script could be added to Scripts that works with "-m" and launches the executable.

> I do not think that your proposal addresses the full problem.

You'll have to excuse us. We've had a lot of experience in this area with this problem, and so we'll be very quick to rule out imaginary proposals like the one you posted that we know are technically infeasible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39025>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:49:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Dec 2019 16:49:08 +0000
Subject: [issue39025] Windows Python Launcher does not update PATH to Scripts
 directory
In-Reply-To: <1576063856.43.0.431001018192.issue39025@roundup.psfhosted.org>
Message-ID: <1576082947.99.0.644322944586.issue39025@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Create a pyscript launcher, which would work like py but would take as command-line the name of the script to run ...

This is spelled "py [-x.y] -m [script]", but it's up to the libraries to support it. We can't force them to do it.

> Let py execute a command-line with proper environment for that specific version of python

"Proper environment" is a matter of opinion, as evidenced by hundreds of issues that arise every time people try to get clever here.

And %PATH% on Windows is a system setting that has an impact on every application that launches, and also has different behaviour on different version of the OS (because it's a system setting, so the system can change how it uses that setting over time).

Perhaps what you want is a virtual environment? Then your activate command is spelled "activate" and your exit command is spelled "deactivate". These have some of the issues I hinted at, as well as many of their own, but at least they already exist and are in widespread use, so most libraries are going to avoid relying on things that don't work. Inventing a new approach here would create and entirely new set of things that don't work, and it'll take the ecosystem years to catch up (and many won't even care to try until there's critical mass usage of the new approach, which won't happen until the ecosystem catches up, etc. etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39025>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:55:39 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Wed, 11 Dec 2019 16:55:39 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1576083339.56.0.737366588082.issue36225@roundup.psfhosted.org>


Change by Lewis Gaul <lewis.gaul at gmail.com>:


----------
pull_requests: +17048
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Wed Dec 11 12:00:43 2019
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 11 Dec 2019 17:00:43 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1576082247.46.0.920541602686.issue39016@roundup.psfhosted.org>
Message-ID: <8869705d-b263-33b6-0447-eae22c415ce5@stackless.com>


Christian Tismer <tismer at stackless.com> added the comment:

On 11.12.19 17:37, Petr Viktorin wrote:
> 
> Petr Viktorin <encukou at gmail.com> added the comment:
> 
> The goal now should be to find a reasonably small reproducer.
> 
> I'm trying to compile PySide to see what it does, but it's a big project and I'm a bit lost.
> Christian, you said in an e-mail that you have a workaround -- unsetting the Py_TPFLAGS_METHOD_DESCRIPTOR. Could you point me to the commit with that workaround, so I could try exploring the code in context?

Yes, it went into gerrit here:

https://codereview.qt-project.org/c/pyside/pyside-setup/+/282705

The problem is that during PySide type creation the PyType_Ready
function looks into the mro() method, which uses this new
flag. When I temporary remove that, everything works.

Cheers -- Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 12:05:49 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 11 Dec 2019 17:05:49 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1576083949.72.0.254237932001.issue39016@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thanks!

(note: unfortunately I'll probably not have time for CPython until next week, but further investigation is on my list.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 12:44:04 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Dec 2019 17:44:04 +0000
Subject: [issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled
In-Reply-To: <1474611707.66.0.467568151114.issue28254@psf.upfronthosting.co.za>
Message-ID: <1576086244.06.0.800945105097.issue28254@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/issue28254>
_______________________________________

From report at bugs.python.org  Wed Dec 11 13:31:59 2019
From: report at bugs.python.org (Justin Capella)
Date: Wed, 11 Dec 2019 18:31:59 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1576089119.95.0.741054231039.issue38860@roundup.psfhosted.org>


Justin Capella <justincapella at gmail.com> added the comment:

It might make sense that CSimpleData types do not call init, which makes sense for _fields_ but it doesn't make sense to offer subclassing (of Structure) and not use the subclass, instead creating a type of the same name.

That test case is bugged, missing an underscore... The git blame wasn't "available" for that particular test but I would argue that it's testing for undocumented behavior :p

I wanted to be able to do assertions/initialization, I'm sure other people have expected from_buffer(_copy) et al would act as a class method, returning an instance of the subclass.

More generally, I think that GenericPyCData_new should not "tp_alloc"... What's _new about that?

My guess is there was at some level desire to "optimize" ctypes. If that does turn out to be the case I'd hope for a "unsimple" CData and ask that Structure be an instance of that.

Either way docs reflecting the behavior to Structure would be nice, I just hope it includes "prior to version" :p thanks for taking a look

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Wed Dec 11 13:49:12 2019
From: report at bugs.python.org (Alexandros Karypidis)
Date: Wed, 11 Dec 2019 18:49:12 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1576090152.21.0.771099655459.issue38999@roundup.psfhosted.org>


Alexandros Karypidis <karypid at gmail.com> added the comment:

My suggestion to gradually fall back from most specific to least specific version, was an attempt to reconcile the input from various viewpoints.

I think that ideally the behaviour should be as close to UNIX as possible. This means that it should just search the path for that binary (which is the whole point of using /usr/bin/env) and use it (even if it is the wrong version).

While I understand that one can do more (verify the version in whatever executable is located, etc) there is a lot in favor of consistency across platforms (versus even better behavior).

So my vote if the community decides to address this would be to just "search the path for <whatever>.exe when encountering #!/usr/bin/env <whatever>" and then launch it and hope for the best.

This makes it simple for users to intervene via the PATH (which is the whole point of /usr/bin/env) and launch whatever they want. 

Currently, creatign a venv on windows only places "python.exe" in the Scripts folder (another difference to Linux). I would argue this is "correct" though because I think this was a decision of DISTROS (to use python for version 2 and python3 for version 3, while undertransition). Most distros still do that to this day and it will likely stick around. One day there will be only "python" and it will mean "version 3" but until then, it's better for the py launcher to do the same as on Linux and say "could not find python3 in the path" where the user can intervene (e.g. copy python.exe as python3.exe) and "fix" it manually.

Of course, doing "smarter" things on Windows is always an option but I would say that at least the "minimal" should be done to support consistency. (As I said, I would also suggest that no more than this minimal be done, but not in order to keep implementation simple, but to keep it consistent with other platforms).

Then again, that's merely one point of view from someone who is a user and does not even contribute to the project...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Wed Dec 11 15:46:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Dec 2019 20:46:17 +0000
Subject: [issue33762] Make tempfiles subclass IOBase
In-Reply-To: <1528059185.23.0.592728768989.issue33762@psf.upfronthosting.co.za>
Message-ID: <1576097177.5.0.74961546911.issue33762@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Looking at the tempfile code more, I agree with Serhiy that changing it should be rejected.  Python is a duck-typed language (essentially what Martin said). People should not be over-zealous in using instance checks.
 
The doc specifically says that TemporaryFile returns a *file-like object*
https://docs.python.org/3/glossary.html#term-file-like-object
which only require implementing the interface.

----------
resolution:  -> rejected
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33762>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:17:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 21:17:28 +0000
Subject: [issue38614] test_asyncio: test_communicate() failed on AMD64 FreeBSD
 Shared 3.8
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576099048.18.0.692123661169.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7772b1af5ebc9d72d0cfc8332aea6b2143eafa27 by Victor Stinner in branch 'master':
bpo-38614: Use support timeout constants (GH-17572)
https://github.com/python/cpython/commit/7772b1af5ebc9d72d0cfc8332aea6b2143eafa27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:22:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 21:22:46 +0000
Subject: [issue38614] Add timeout constants to test.support
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576099366.08.0.343216265553.issue38614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_asyncio: test_communicate() failed on AMD64 FreeBSD Shared 3.8 -> Add timeout constants to test.support

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:26:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Dec 2019 21:26:41 +0000
Subject: [issue38614] Add timeout constants to test.support
In-Reply-To: <1572265095.84.0.80833057987.issue38614@roundup.psfhosted.org>
Message-ID: <1576099601.42.0.67937086065.issue38614@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm not sure about backporting the new timeout constants of test.support to Python 3.7 and 3.8. Backporting all changes may help to make tests more stable in 3.7 and 3.7 branches. It should also help to backport test changes from master to 3.7 and 3.8. But it's somehow a new feature and so I suggest to not backport yet.

I may backport later if they are too many conflicts or if tests fail too often because of too short timeouts.

I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38614>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:04:07 2019
From: report at bugs.python.org (janust)
Date: Wed, 11 Dec 2019 22:04:07 +0000
Subject: [issue39027] run_coroutine_threadsafe uses wrong TimeoutError
Message-ID: <1576101847.74.0.586846433042.issue39027@roundup.psfhosted.org>


New submission from janust <ysangkok at gmail.com>:

https://docs.python.org/3.8/library/asyncio-task.html#asyncio.run_coroutine_threadsafe has a code example that catches a asyncio.TimeoutError from run_coroutine_threadsafe. In Python 3.7, this exception was equal to concurrent.futures.TimeoutError, but since https://github.com/python/cpython/commit/431b540bf79f0982559b1b0e420b1b085f667bb7 that is not the case anymore.

----------
assignee: docs at python
components: Documentation
messages: 358281
nosy: docs at python, janust
priority: normal
severity: normal
status: open
title: run_coroutine_threadsafe uses wrong TimeoutError
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39027>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:11:43 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Dec 2019 22:11:43 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1576102303.78.0.244035096725.issue38999@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> This makes it simple for users to intervene via the PATH (which is the whole point of /usr/bin/env) and launch whatever they want.

That's one point of view, but the other is that the whole point of the shebang line is for users to be able to run the script without having to use a terminal at all. And once you're there, you no longer have a customisable PATH to work with.

"Simple for users to intervene via the PATH" is not true on Windows. Modifying PATH globally can break applications or (some) system components, and modifying it temporarily requires becoming a terminal user, which is not the majority.

Personally, I think supporting the shebang line in py.exe is a misfeature and would prefer we'd never done it (though it predates my involvement). But if someone wants to implement support for detecting a venv and matching it to the shebang, I won't actively block it going in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:30:47 2019
From: report at bugs.python.org (Dave Lawrence)
Date: Wed, 11 Dec 2019 22:30:47 +0000
Subject: [issue39001] possible problem with 64-bit mingw DECREF
In-Reply-To: <1575839278.99.0.426657382539.issue39001@roundup.psfhosted.org>
Message-ID: <1576103447.56.0.700017763875.issue39001@roundup.psfhosted.org>


Dave Lawrence <mail.dave.lawrence at gmail.com> added the comment:

by redefinining the Py_DECREF macro in my application:

#define  Py_DECREF(op) do { if (--op->ob_refcnt == 0) fprintf(stderr, "DECREF %s %d %p %d %s %p\n", __FILE__, __LINE__, op, Py_SIZE(op), Py_TYPE(op)->tp_name,Py_TYPE(op)->tp_dealloc );  fflush(stderr); } while(0)

this outputs lines like this:

DECREF vardef_file.cc 1601 0000000009F3C728 0 generator 0000000000000000

which appears to be showing the tp_dealloc is a null pointer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39001>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:44:24 2019
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 11 Dec 2019 22:44:24 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1576104264.26.0.358921773797.issue39016@roundup.psfhosted.org>


Christian Tismer <tismer at stackless.com> added the comment:

Sorry, I believe I was wrong and lookup_maybe_method does not return a borrowed reference. _PyType_Lookup does and I was confused.
Closing that for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:45:03 2019
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 11 Dec 2019 22:45:03 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1576104303.56.0.744199706341.issue39016@roundup.psfhosted.org>


Change by Christian Tismer <tismer at stackless.com>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:46:06 2019
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 11 Dec 2019 22:46:06 +0000
Subject: [issue39016] Negative Refcount in Python 3.8
In-Reply-To: <1575992223.28.0.659364408655.issue39016@roundup.psfhosted.org>
Message-ID: <1576104366.04.0.768081100649.issue39016@roundup.psfhosted.org>


Change by Christian Tismer <tismer at stackless.com>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39016>
_______________________________________

From report at bugs.python.org  Wed Dec 11 18:40:14 2019
From: report at bugs.python.org (Dave Lawrence)
Date: Wed, 11 Dec 2019 23:40:14 +0000
Subject: [issue39001] possible problem with 64-bit mingw DECREF
In-Reply-To: <1575839278.99.0.426657382539.issue39001@roundup.psfhosted.org>
Message-ID: <1576107614.75.0.237839027804.issue39001@roundup.psfhosted.org>


Dave Lawrence <mail.dave.lawrence at gmail.com> added the comment:

traced to be a duplicate of https://bugs.python.org/issue28267

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39001>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:24:38 2019
From: report at bugs.python.org (Joy)
Date: Thu, 12 Dec 2019 03:24:38 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
In-Reply-To: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>
Message-ID: <1576121078.27.0.809623907301.issue38921@roundup.psfhosted.org>


Joy <joy.bushnell at gmail.com> added the comment:

Yes, still working on a script for this bug.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38921>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:04:55 2019
From: report at bugs.python.org (Sebastian Berg)
Date: Thu, 12 Dec 2019 04:04:55 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
Message-ID: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>


New submission from Sebastian Berg <sebastian at sipsolutions.net>:

The keyword argument extraction/finding function seems to have a performance bug/enhancement (unless I am missing something here). It reads:


```
    for (i=0; i < nkwargs; i++) {
        PyObject *kwname = PyTuple_GET_ITEM(kwnames, i);

        /* ptr==ptr should match in most cases since keyword keys
           should be interned strings */
        if (kwname == key) {
            return kwstack[i];
        }
        assert(PyUnicode_Check(kwname));
        if (_PyUnicode_EQ(kwname, key)) {
            return kwstack[i];
        }
    }
```

However, it should be split into two separate for loops, using the `PyUnicode_EQ` check only if it failed for _all_ other arguments.

I will open a PR for this (it seemed like a bpo number is wanted for almost everything.

----------
components: C API
messages: 358287
nosy: seberg
priority: normal
severity: normal
status: open
title: ENH: Fix performance issue in keyword extraction
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:05:12 2019
From: report at bugs.python.org (Sebastian Berg)
Date: Thu, 12 Dec 2019 04:05:12 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576123512.67.0.551192529045.issue39028@roundup.psfhosted.org>


Change by Sebastian Berg <sebastian at sipsolutions.net>:


----------
keywords: +patch
pull_requests: +17049
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:23:32 2019
From: report at bugs.python.org (Ashley Whetter)
Date: Thu, 12 Dec 2019 05:23:32 +0000
Subject: [issue37701] shutil.copyfile raises SpecialFileError for symlink to
 fifo
In-Reply-To: <1564375011.26.0.591034083368.issue37701@roundup.psfhosted.org>
Message-ID: <1576128212.47.0.150898250906.issue37701@roundup.psfhosted.org>


Change by Ashley Whetter <ashley at awhetter.co.uk>:


----------
keywords: +patch
pull_requests: +17050
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/16575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37701>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:54:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 12 Dec 2019 05:54:03 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576130043.66.0.558695242698.issue37228@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The fix seems to generate few DeprecationWarning while running test suite with -Wall.

?  cpython git:(master) git checkout ab513a38c98695f271e448fe2cb7c5e39eeaaaaf~1 Lib/asyncio
Updated 1 path from 4fb4056fbc
?  cpython git:(master) ? ./python.exe -Wall -m test test_asyncio -m test_create_datagram_endpoint_nosoreuseport -m test_create_datagram_endpoint_ip_addr
0:00:00 load avg: 3.12 Run tests sequentially
0:00:00 load avg: 3.12 [1/1] test_asyncio

== Tests result: SUCCESS ==

1 test OK.

Total duration: 133 ms
Tests result: SUCCESS

?  cpython git:(master) ? git checkout ab513a38c98695f271e448fe2cb7c5e39eeaaaaf Lib/asyncio
Updated 1 path from 63d1437ba5
?  cpython git:(master) ./python.exe -Wall -m test test_asyncio -m test_create_datagram_endpoint_nosoreuseport -m test_create_datagram_endpoint_ip_addr
0:00:00 load avg: 3.03 Run tests sequentially
0:00:00 load avg: 3.03 [1/1] test_asyncio
/Users/kasingar/stuff/python/cpython/Lib/asyncio/events.py:81: DeprecationWarning: The *reuse_address* parameter has been deprecated as of 3.5.10 and is scheduled for removal in 3.11.
  self._context.run(self._callback, *self._args)
/Users/kasingar/stuff/python/cpython/Lib/asyncio/events.py:81: DeprecationWarning: The *reuse_address* parameter has been deprecated as of 3.5.10 and is scheduled for removal in 3.11.
  self._context.run(self._callback, *self._args)

== Tests result: SUCCESS ==

1 test OK.

Total duration: 135 ms
Tests result: SUCCESS

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:08:03 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 12 Dec 2019 06:08:03 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576130883.69.0.486291974256.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> The fix seems to generate few DeprecationWarning while running test suite with -Wall.

Thanks Karthikeyan, I'm guessing that I missed an assertWarns() or left an outdated test somewhere that explicitly sets `reuse_address=False` (since `reuse_address=True` would raise a ValueError instead of a DeprecationWarning). I'll do some investigation and fix the issue as soon as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:10:40 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 12 Dec 2019 06:10:40 +0000
Subject: [issue36054] On Linux,
 os.count() should read cgroup cpu.shares and cpu.cfs (CPU count
 inside docker container)
In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org>
Message-ID: <1576131040.05.0.661846720971.issue36054@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:17:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2019 06:17:43 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576131463.82.0.364169549804.issue39028@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Could you please provide benchmarks which demonstrate the performance issue?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:32:52 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 12 Dec 2019 06:32:52 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576132372.43.0.535967758614.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> or left an outdated test somewhere that explicitly sets `reuse_address=False`

Looks like this was the issue, I left a `reuse_address=False` in both test_create_datagram_endpoint_nosoreuseport and test_create_datagram_endpoint_ip_addr. I fixed it locally on the latest commit to master:

[aeros:~/repos/cpython]$ ./python -Wall -m test test_asyncio -m test_create_datagram_endpoint_nosoreuseport -m test_create_datagram_endpoint_ip_addr 
0:00:00 load avg: 0.29 Run tests sequentially
0:00:00 load avg: 0.29 [1/1] test_asyncio

== Tests result: SUCCESS ==

1 test OK.

Total duration: 130 ms
Tests result: SUCCESS

I also used git grep to ensure `reuse_address=False` didn't exist at any other locations, other than the intentional one to test the DeprecationWarning.

But while doing that, I did notice that `reuse_address=` is present in several other locations through Lib/asyncio, which will likely add some confusing deprecation warnings to anyone running their asyncio programs with -Wall. The way we did the deprecation was using an _unset sentinel, so even `reuse_address=None` will cause a DeprecationWarning (since the parameter will be removed entirely in 3.11).

I'll fix them accordingly and open a new PR (as well as the backports).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:34:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 12 Dec 2019 06:34:23 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576132463.38.0.787157469177.issue37228@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

One more resource warning about unclosed resource being garbage collected. As per the other tests I think transport and protocol need to be closed as per below patch but someone can verify if it's the right approach.

./python.exe -X tracemalloc -Wall -m test test_asyncio -m test_create_datagram_endpoint_reuse_address_warning
0:00:00 load avg: 2.45 Run tests sequentially
0:00:00 load avg: 2.45 [1/1] test_asyncio
/Users/kasingar/stuff/python/cpython/Lib/test/support/__init__.py:1722: ResourceWarning: unclosed <socket.socket fd=6, family=AddressFamily.AF_INET, type=SocketKind.SOCK_DGRAM, proto=17, laddr=('127.0.0.1', 62353)>
  gc.collect()
Object allocated at (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/asyncio/base_events.py", lineno 1331
    sock = socket.socket(
/Users/kasingar/stuff/python/cpython/Lib/asyncio/selector_events.py:694: ResourceWarning: unclosed transport <_SelectorDatagramTransport fd=6>
  _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
Object allocated at (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/asyncio/selector_events.py", lineno 84
    return _SelectorDatagramTransport(self, sock, protocol,

== Tests result: SUCCESS ==

1 test OK.

Total duration: 373 ms
Tests result: SUCCESS

diff --git Lib/test/test_asyncio/test_base_events.py Lib/test/test_asyncio/test_base_events.py
index 6c0f00dc93..338f35c8dd 100644
--- Lib/test/test_asyncio/test_base_events.py
+++ Lib/test/test_asyncio/test_base_events.py
@@ -1814,7 +1814,9 @@ class BaseEventLoopWithSelectorTests(test_utils.TestCase):
             reuse_address=False)

         with self.assertWarns(DeprecationWarning):
-            self.loop.run_until_complete(coro)
+            transport, protocol = self.loop.run_until_complete(coro)
+            transport.close()
+            self.loop.run_until_complete(protocol.done)

     @patch_socket
     def test_create_datagram_endpoint_nosoreuseport(self, m_socket):

After patch there are no resource warnings for the test.

./python.exe -X tracemalloc -Wall -m test test_asyncio -m test_create_datagram_endpoint_reuse_address_warning
0:00:00 load avg: 2.09 Run tests sequentially
0:00:00 load avg: 2.09 [1/1] test_asyncio

== Tests result: SUCCESS ==

1 test OK.

Total duration: 349 ms
Tests result: SUCCESS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:38:05 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 12 Dec 2019 06:38:05 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576132685.63.0.916485472351.issue37228@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/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 01:44:33 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 12 Dec 2019 06:44:33 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576133073.31.0.530007505722.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I'll fix them accordingly and open a new PR (as well as the backports).

Nevermind. Upon further inspection, the other occurrences of `reuse_address=` were for create_server(), not create_datagram_endpoint(). The PR will only include the removal of the two occurrences of `reuse_address=False` in Lib/test/test_asyncio/test_base_events.py. Fortunately, this _should_ mean that the `needs backport to x` labels and automated backports from miss-islington will work correctly, since the changes are rather minimal. 

Thanks again for pointing it out Karthikeyan, as well as mentioning the specific tests the DeprecationWarnings were coming from. That made it a lot easier to figure out the source of the warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 02:09:15 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 12 Dec 2019 07:09:15 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576134555.2.0.79190158301.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> One more resource warning about unclosed resource being garbage collected. As per the other tests I think transport and protocol need to be closed as per below patch but someone can verify if it's the right approach.

Ah, good catch. It's not needed when the ValueError occurs because it prevents the transport and protocol from being created in the first place, but I forgot that it would still be needed for the DeprecationWarning test. In addition to your changes, I'll also add a self.assertEqual('CLOSED', protocol.state). This is done in most of the other tests and it doesn't hurt to make sure the protocol properly closed.

I'll add your fix to the PR and add you to the "Co-authored-by" for that commit, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 02:35:41 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 12 Dec 2019 07:35:41 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576136141.74.0.216515940928.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17051
pull_request: https://github.com/python/cpython/pull/17577

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 02:59:47 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 12 Dec 2019 07:59:47 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576137587.26.0.631778933233.issue39028@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Thu Dec 12 03:59:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 12 Dec 2019 08:59:34 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
Message-ID: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I can reproduce frequently the failure of test_clean on my Mac machine. It checks for removal of foo_path. It's removed by Maildir.clean that removes files based on the access time as below. The test also does similar thing with os.utime(foo_path, (time.time() - 129600 - 2, foo_stat.st_mtime)) but I guess the file is not really deleted in some cases.

https://github.com/python/cpython/blob/7772b1af5ebc9d72d0cfc8332aea6b2143eafa27/Lib/mailbox.py#L482

def clean(self):
    """Delete old files in "tmp"."""
    now = time.time()
    for entry in os.listdir(os.path.join(self._path, 'tmp')):
        path = os.path.join(self._path, 'tmp', entry)
        if now - os.path.getatime(path) > 129600:   # 60 * 60 * 36
            os.remove(path)

$ ./python.exe -Wall -m test -R 3:3 -j 4 test_mailbox -m test_clean
0:00:00 load avg: 2.12 Run tests in parallel using 4 child processes
0:00:00 load avg: 2.12 [1/1/1] test_mailbox failed
beginning 6 repetitions
123456
.....test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/test/test_mailbox.py", line 737, in test_clean
    self.assertFalse(os.path.exists(foo_path))
AssertionError: True is not false

== Tests result: FAILURE ==

1 test failed:
    test_mailbox

Total duration: 951 ms
Tests result: FAILURE

----------
components: Tests
messages: 358295
nosy: barry, maxking, r.david.murray, xtreak
priority: normal
severity: normal
status: open
title: TestMaildir.test_clean fails randomly under parallel tests
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Dec 12 04:18:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2019 09:18:19 +0000
Subject: [issue39015] DeprecationWarnings of implicitly truncations by __int__
 appearing in the standard library
In-Reply-To: <1575990186.74.0.753297592604.issue39015@roundup.psfhosted.org>
Message-ID: <1576142299.96.0.968832840838.issue39015@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/issue39015>
_______________________________________

From report at bugs.python.org  Thu Dec 12 04:41:20 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 12 Dec 2019 09:41:20 +0000
Subject: [issue39027] run_coroutine_threadsafe uses wrong TimeoutError
In-Reply-To: <1576101847.74.0.586846433042.issue39027@roundup.psfhosted.org>
Message-ID: <1576143680.44.0.98191602083.issue39027@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Thanks for letting us know, janust. I confirmed that `asyncio.TimeoutError` no longer works for the code example in 3.8 and that replacing it with `concurrent.futures.TimeoutError` works correctly.

Before moving forward with a PR to the docs, I think we should wait for feedback from Yury to check if this behavior is intentional for `run_coroutine_threadsafe()`, I'll add him to the nosy list.

To me, this seems more like a side effect of `asyncio.TimeoutError` being changed to BaseException rather than an intended consequence. The main purpose of that change was to ensure that TimeoutError wasn't unintentionally suppressed by generic try-except blocks. IMO, it seems rather counter-intuitive to have to specify `concurrent.futures.TimeoutError` when using a timeout for the future returned by `run_coroutine_threadsafe()`. I'm not certain that it can be avoided though, other than by changing it to return an instance of asyncio.Future instead of concurrent.futures.Future.

----------
nosy: +aeros, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39027>
_______________________________________

From report at bugs.python.org  Thu Dec 12 05:05:03 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 12 Dec 2019 10:05:03 +0000
Subject: [issue39027] run_coroutine_threadsafe uses wrong TimeoutError
In-Reply-To: <1576101847.74.0.586846433042.issue39027@roundup.psfhosted.org>
Message-ID: <1576145103.37.0.664837904422.issue39027@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

futures._chain_future() should convert exceptions.
Seems _convert_future_exc() does this work already but maybe it fails somehow.
We need to investigate more.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39027>
_______________________________________

From report at bugs.python.org  Thu Dec 12 05:19:54 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 12 Dec 2019 10:19:54 +0000
Subject: [issue6699] IDLE: Warn user about overwriting a file that has a newer
 version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1576145994.55.0.874356748602.issue6699@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17052
pull_request: https://github.com/python/cpython/pull/17578

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6699>
_______________________________________

From report at bugs.python.org  Thu Dec 12 05:21:06 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 12 Dec 2019 10:21:06 +0000
Subject: [issue6699] IDLE: Warn user about overwriting a file that has a newer
 version on filesystem
In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za>
Message-ID: <1576146066.67.0.589833833993.issue6699@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a pull request for this issue.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6699>
_______________________________________

From report at bugs.python.org  Thu Dec 12 05:30:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2019 10:30:30 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1576146630.63.0.253141604592.issue39029@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Should not parallel tests be ran in different directories?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Dec 12 06:15:24 2019
From: report at bugs.python.org (dankreso)
Date: Thu, 12 Dec 2019 11:15:24 +0000
Subject: [issue39030] Ctypes unions with bitfield members that do not share
 memory
Message-ID: <1576149324.34.0.405331329456.issue39030@roundup.psfhosted.org>


New submission from dankreso <dankreso at gmail.com>:

I've found what looks like a corner case bug. Specifically, the behaviour that looks suspicious is when a ctypes union has bit field members, where the members have bit widths that are smaller than the size types:

class BitFieldUnion(Union):
    _fields_ = [("a", c_uint32, 16), ("b", c_uint32, 16)]

buff = bytearray(4)

bitfield_union = BitFieldUnion.from_buffer(buff)
bitfield_union.a = 1
bitfield_union.b = 2

print("a is {}".format(bitfield_union.a)) # Prints "a is 1"
print("b is {}".format(bitfield_union.b)) # Prints "b is 2"
print("Buffer: {}".format(buff)) # Prints "Buffer: b'\x01\x00\x00\x00'".

(Example of this script can be found at https://rextester.com/XJFGAK37131. I've also tried it on my system which is Ubuntu 16.04.2 LTS with Python 3.6.)

Here I would expect both 'a' and 'b' to be set to 2, and for the buffer to look like '\x02\x00\x00\x00'. Here's the equivalent code in C which behaves as expected: https://rextester.com/HWDUMB56821.

If at least one of the bitwidths in the above example are changed from 16 to 32, however, then 'a', 'b', and the buffer look as expected.

I've also attached some further examples of weird behaviour with unions with bitfield members - online version can be found at https://rextester.com/VZRB77320.

----------
components: ctypes
files: bitfield_union.py
messages: 358300
nosy: dankreso
priority: normal
severity: normal
status: open
title: Ctypes unions with bitfield members that do not share memory
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48772/bitfield_union.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39030>
_______________________________________

From report at bugs.python.org  Thu Dec 12 07:09:50 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 12:09:50 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576152590.11.0.118604141526.issue39028@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Thu Dec 12 08:47:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 Dec 2019 13:47:35 +0000
Subject: [issue19038] Fix sort order in Misc/ACKS.
In-Reply-To: <1379365334.74.0.639757614971.issue19038@psf.upfronthosting.co.za>
Message-ID: <1576158455.59.0.255842640197.issue19038@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Even though I was not nosy on this 6 year old issue, I just got the following email requesting that the attachments be removed.  I am not doing so because they seem to be needed to make sense of the issue.  But anyone else who wants to do so may.  I removed the OP from the nosy list to avoid prompting more responses.

"Please remove two attachments (ACKS and ACKS.diff) in a bug [1] I
reported in September 2013 (Georg Brandl closed this bug)."

----------
nosy: +terry.reedy -taewong.seo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19038>
_______________________________________

From report at bugs.python.org  Thu Dec 12 08:49:44 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 12 Dec 2019 13:49:44 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576158584.24.0.510231036331.issue37228@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17053
pull_request: https://github.com/python/cpython/pull/17579

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 08:49:50 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 12 Dec 2019 13:49:50 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576158590.31.0.274097551475.issue37228@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17054
pull_request: https://github.com/python/cpython/pull/17580

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 08:49:56 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 12 Dec 2019 13:49:56 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576158596.47.0.441120105905.issue37228@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17055
pull_request: https://github.com/python/cpython/pull/17581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Thu Dec 12 10:24:35 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 12 Dec 2019 15:24:35 +0000
Subject: [issue38449] regression - mimetypes guess_type is confused by ;
 in the filename
In-Reply-To: <1570802800.7.0.378651276775.issue38449@roundup.psfhosted.org>
Message-ID: <1576164275.45.0.752760100332.issue38449@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@ned.deily @maxking
I close this issue since all PRs were merged.
Thanks, everyone for actions for this issue :)

Have a warm and happy holiday and a hopeful new year.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38449>
_______________________________________

From report at bugs.python.org  Thu Dec 12 10:41:56 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Thu, 12 Dec 2019 15:41:56 +0000
Subject: [issue39030] Ctypes unions with bitfield members that do not share
 memory
In-Reply-To: <1576149324.34.0.405331329456.issue39030@roundup.psfhosted.org>
Message-ID: <1576165316.45.0.256634177674.issue39030@roundup.psfhosted.org>


Change by Lewis Gaul <lewis.gaul at gmail.com>:


----------
nosy: +LewisGaul, belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39030>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:06:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2019 16:06:06 +0000
Subject: [issue28267] [MinGW] Crash at start when compiled by MinGW for 64-bit
 Windows using PC/pyconfig.h
In-Reply-To: <1474796748.74.0.791284991149.issue28267@psf.upfronthosting.co.za>
Message-ID: <1576166766.46.0.126254413711.issue28267@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28267>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:11:03 2019
From: report at bugs.python.org (Sebastian Berg)
Date: Thu, 12 Dec 2019 16:11:03 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576167063.07.0.345284845535.issue39028@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

Fair enough, we had code that does it the other way, so it seemed "too obvious" since the current check seems mainly useful with few kwargs. However, a single kwarg is super common in python, while many seem super rare (in any argument clinic function)

Which is why I had even trouble finding a function where it could make a difference, since it needs many kwargs.

With changes:

sebastian at seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", signed=True)'
1000000 loops, best of 5: 205 nsec per loop
sebastian at seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", signed=True)'
1000000 loops, best of 5: 207 nsec per loop

On master:

sebastian at seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", signed=True)'
1000000 loops, best of 5: 221 nsec per loop
sebastian at seberg-x1 ~/python-dev/bin
 % ./python3 -m timeit -s 'i = 4' 'i.to_bytes(length=5, byteorder="big", signed=True)'
1000000 loops, best of 5: 218 nsec per loop

Which, at close to 5% is barely noticeable, I suppose with more kwargs it could start to make a difference. With less than 3, it just does not matter I guess. Also, I am currently not sure how likely non-interned strings could actually happen. But I am not sure it matters to optimize for them (unless PyArg_From* functions use them).

In any case, sorry if this was noise, happy to fix things up or just drop it if many kwargs are considered non-existing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Thu Dec 12 13:09:32 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Thu, 12 Dec 2019 18:09:32 +0000
Subject: [issue32730] Allow py launcher to launch other registered Pythons
In-Reply-To: <1517414233.69.0.467229070634.issue32730@psf.upfronthosting.co.za>
Message-ID: <1576174172.48.0.391925811753.issue32730@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/issue32730>
_______________________________________

From report at bugs.python.org  Thu Dec 12 15:15:07 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 12 Dec 2019 20:15:07 +0000
Subject: [issue39031] Inconsistent lineno and col_offset info when parsing elif
Message-ID: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

While working on pegen, we came across an inconsistency on how line number and column offset info is stored for (el)if nodes. When parsing a very simple if-elif construct like

if a:
    pass
elif b:
    pass

the following parse tree gets generated:

Module(
    body=[
        If(
            test=Name(id="a", ctx=Load(), lineno=1, col_offset=3, end_lineno=1, end_col_offset=4),
            body=[Pass(lineno=2, col_offset=4, end_lineno=2, end_col_offset=8)],
            orelse=[
                If(
                    test=Name(
                        id="b", ctx=Load(), lineno=3, col_offset=5, end_lineno=3, end_col_offset=6
                    ),
                    body=[Pass(lineno=4, col_offset=4, end_lineno=4, end_col_offset=8)],
                    orelse=[],
                    lineno=3,
                    col_offset=5,
                    end_lineno=4,
                    end_col_offset=8,
                )
            ],
            lineno=1,
            col_offset=0,
            end_lineno=4,
            end_col_offset=8,
        )
    ],
    type_ignores=[],
)

There is the inconsistency that the column offset for the if statement is 0, thus the if statement starts with the keyword if, whereas the column offset for elif if 5, which means that the elif keyword is skipped.

As Guido suggests over at https://github.com/gvanrossum/pegen/issues/107#issuecomment-565135047 we could very easily change Python/ast.c so that the elif statement start with the elif keyword as well.

I have a PR ready!

----------
messages: 358304
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: Inconsistent lineno and col_offset info when parsing elif
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 15:16:24 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 12 Dec 2019 20:16:24 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576181784.06.0.946469435218.issue39031@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
title: Inconsistent lineno and col_offset info when parsing elif -> Inconsistency with lineno and col_offset info when parsing elif

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 15:21:36 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 12 Dec 2019 20:21:36 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576182096.09.0.197785402294.issue39031@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
keywords: +patch
pull_requests: +17056
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17582

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:14:02 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 21:14:02 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576185242.72.0.731665520156.issue39031@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:14:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 21:14:17 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576185257.97.0.172327406336.issue39031@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:14:46 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 21:14:46 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576185286.12.0.79281866815.issue39031@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:16:45 2019
From: report at bugs.python.org (Aaron Hall)
Date: Thu, 12 Dec 2019 21:16:45 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1576185405.71.0.338354888482.issue36144@roundup.psfhosted.org>


Aaron Hall <aaronchall at yahoo.com> added the comment:

Another obvious way to do it, but I'm +1 on it.

A small side point however - PEP 584 reads:

> To create a new dict containing the merged items of two (or more) dicts, one can currently write:

> {**d1, **d2}

> but this is neither obvious nor easily discoverable. It is only guaranteed to work if the keys are all strings. If the keys are not strings, it currently works in CPython, but it may not work with other implementations, or future versions of CPython[2].

...

> [2] Non-string keys: https://bugs.python.org/issue35105 and https://mail.python.org/pipermail/python-dev/2018-October/155435.html

The references cited does not back this assertion up. Perhaps the intent is to reference the "cool/weird hack" dict(d1, **d2) (see https://mail.python.org/pipermail/python-dev/2010-April/099485.html and https://mail.python.org/pipermail/python-dev/2010-April/099459.html), which allowed any hashable keys in Python 2 but only strings in Python 3.

If I see {**d1, **d2}, my expectations are that this is the new generalized unpacking and I currently expect any keys to be allowed, and the PEP should be updated to accurately reflect this to prevent future misunderstandings.

----------
nosy: +Aaron Hall

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:40:27 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 12 Dec 2019 21:40:27 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576186827.98.0.830117651215.issue39031@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 025a602af7ee284d8db6955c26016f3f27d35536 by Miss Islington (bot) (Lysandros Nikolaou) in branch 'master':
bpo-39031: Include elif keyword when producing lineno/col-offset info for if_stmt (GH-17582)
https://github.com/python/cpython/commit/025a602af7ee284d8db6955c26016f3f27d35536


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:40:37 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 12 Dec 2019 21:40:37 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576186837.44.0.915335694469.issue39031@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17057
pull_request: https://github.com/python/cpython/pull/17583

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:51:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 21:51:49 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576187509.43.0.0512105354869.issue39031@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17058
pull_request: https://github.com/python/cpython/pull/17584

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:53:23 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 12 Dec 2019 21:53:23 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576187603.86.0.781011996646.issue39031@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +17059
pull_request: https://github.com/python/cpython/pull/17585

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:11:47 2019
From: report at bugs.python.org (Chris)
Date: Thu, 12 Dec 2019 22:11:47 +0000
Subject: [issue39032] wait_for and Condition.wait still not playing nicely
Message-ID: <1576188707.28.0.976402286233.issue39032@roundup.psfhosted.org>


New submission from Chris <chrisriches42 at gmail.com>:

This is related to https://bugs.python.org/issue22970, https://bugs.python.org/issue33638, and https://bugs.python.org/issue32751. I've replicated the issue on Python 3.6.9, 3.7.4, and 3.8.0. Looking at the source, I'm fairly sure the bug is still in master right now.

The problem is yet another case of wait_for returning early, before the child has been fully cancelled and terminated. The issue arises if wait_for itself is cancelled. Take the following minimal example:

cond = asyncio.Condition()
async def coro():
    async with cond:
        await asyncio.wait_for(cond.wait(), timeout=999)

If coro is cancelled a few seconds after being run, wait_for will cancel the cond.wait(), then immediately re-raise the CancelledError inside coro, leading to "RuntimeError: Lock is not acquired."

Relevant source code plucked from the 3.8 branch is as follows:

try:
        # wait until the future completes or the timeout
        try:
            await waiter
        except exceptions.CancelledError:
            fut.remove_done_callback(cb)
            fut.cancel()
            raise

        if fut.done():
            return fut.result()
        else:
            fut.remove_done_callback(cb)
            # We must ensure that the task is not running
            # after wait_for() returns.
            # See https://bugs.python.org/issue32751
            await _cancel_and_wait(fut, loop=loop)
            raise exceptions.TimeoutError()
    finally:
        timeout_handle.cancel()

Note how if the timeout occurs, the method waits for the future to complete before raising. If CancelledError is thrown, it doesn't.

A simple fix seems to be replacing the "fut.cancel()" with "await _cancel_and_wait(fut, loop=loop)" so the behaviour is the same in both cases, however I'm only superficially familiar with the code, and am unsure if this would cause other problems.

----------
components: asyncio
messages: 358307
nosy: asvetlov, criches, yselivanov
priority: normal
severity: normal
status: open
title: wait_for and Condition.wait still not playing nicely
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39032>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:12:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 22:12:06 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576188726.86.0.63467362061.issue39031@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Hmmm, there is some problem with the CI and the 3.7 branch. Seems like Travis CI is giving some problems again.... I will investigate or maybe ask Brett to make the check not required again (we still have Azure Pipelines, testing the same thing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:12:41 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 12 Dec 2019 22:12:41 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576188761.87.0.981694328053.issue39031@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The same thing happens with 3.8.....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:20:17 2019
From: report at bugs.python.org (Mihail Georgiev)
Date: Thu, 12 Dec 2019 22:20:17 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
Message-ID: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>


New submission from Mihail Georgiev <misho88 at gmail.com>:

I think there's a "t" missing:

Lib/zipimport.py
609-
610-                try:
611:                    _boostrap_external._validate_hash_pyc(
612-                        data, source_hash, fullname, exc_details)
613-                except ImportError:
614-                    return None
615-    else:
616-        source_mtime, source_size = \
617-            _get_mtime_and_size_of_source(self, fullpath)
618-
619-        if source_mtime:

----------
components: Library (Lib)
messages: 358310
nosy: misho88
priority: normal
severity: normal
status: open
title: zipimport raises NameError: name '_boostrap_external' is not defined
type: crash
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:48:44 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 12 Dec 2019 22:48:44 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576190924.56.0.53656251225.issue39033@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Good catch!  Would you like to submit a pull request to fix it?  Ideally such a PR should also include a test to exercise this code.

----------
nosy: +twouters, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:19:35 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 12 Dec 2019 23:19:35 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1576192775.44.0.00929237557609.issue38999@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I think supporting the shebang line in py.exe is a misfeature and 
> would prefer we'd never done it (though it predates my involvement). 

Do you mean all shebangs, including those with a native file path?
Or do you mean just virtual shebangs, and in particular those that search PATH via "/usr/bin/env"? It's not without controversy even in Unix. For example, see [1] and the rebuttal to it in the comments.

In the case of this issue, "env" is used to run a script in an active virtual environment. This doesn't rely on the user or system PATH, assuming the command can be found in the active scripts directory.

As an alternative to modifying the launcher, pip (via distlib) could be updated to transform "#!/usr/bin/env pythonX[.Y]" shebangs into "#!/usr/bin/env python" when installing scripts in Windows. pip and distlib are third-party tools, however, so that suggestion is beyond the scope of this issue tracker.

[1] https://jmmv.dev/2016/09/env-considered-harmful.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:35:48 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 12 Dec 2019 23:35:48 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1576193748.32.0.110801913777.issue38999@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Do you mean all shebangs, including those with a native file path?

I like the idea as a whole, but ultimately end up disliking all the available options (in the context of py.exe, that is).

* Unix/virtual shebangs don't work reliably on Windows (as we can see :) )
* Native file path shebangs on Windows don't work on Unix

The scripts installed by pip &co. are their own executable wrappers, so the shebang shouldn't matter.

But, the python.org Windows installer associates .py files with py.exe, so it _does_ matter for double-click and PATHEXT scenarios.

Perhaps it is reasonable to redefine "/usr/bin/env python*" as "use %VIRTUALENV% python.exe if set" regardless of the specific version? I really don't want to add checks that require running Python - I'd rather bail out and recommend using "py" directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:47:54 2019
From: report at bugs.python.org (Jeong-Min Lee)
Date: Thu, 12 Dec 2019 23:47:54 +0000
Subject: [issue38947] dataclass defaults behave inconsistently for
 init=True/init=False when default is a descriptor
In-Reply-To: <1575158007.0.0.672423182846.issue38947@roundup.psfhosted.org>
Message-ID: <1576194474.03.0.329038874591.issue38947@roundup.psfhosted.org>


Change by Jeong-Min Lee <falsetru at gmail.com>:


----------
nosy: +falsetru

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38947>
_______________________________________

From report at bugs.python.org  Thu Dec 12 20:12:55 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 13 Dec 2019 01:12:55 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1576199575.76.0.966896047982.issue38815@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

I had to rebuild the openssl (1.1.x) port on the worker that had test_ssl failing in order to bring it back to green, so as not to hide new test failures.

If/when someone is able to produce a fix for the failing test, I am happy to revert the openssl build to its prior (failing config) state at any time to verify the test fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38815>
_______________________________________

From report at bugs.python.org  Thu Dec 12 20:47:59 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 01:47:59 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576201679.4.0.885059579483.issue39033@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/issue39033>
_______________________________________

From report at bugs.python.org  Thu Dec 12 21:42:05 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 13 Dec 2019 02:42:05 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1576204925.43.0.650607401262.issue32949@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Should this be closed now that PR6641 has been merged?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:00:51 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 13 Dec 2019 03:00:51 +0000
Subject: [issue32907] pathlib: test_resolve_common fails on Windows w/
 longusername
In-Reply-To: <1519292402.67.0.467229070634.issue32907@psf.upfronthosting.co.za>
Message-ID: <1576206051.75.0.820015614586.issue32907@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Release Windows Store app containing Python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32907>
_______________________________________

From report at bugs.python.org  Fri Dec 13 00:28:34 2019
From: report at bugs.python.org (Ma Lin)
Date: Fri, 13 Dec 2019 05:28:34 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576214914.89.0.0704339537452.issue39033@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Is it possible to scan stdlib to find similar bugs?

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:08:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 06:08:47 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576217327.97.0.990583292951.issue39033@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

A possible test case to trigger this code path based on testUncheckedHashBasedPyc would be as below. check_hash_based_pycs can be patched to be "always" so that the hash is validated using _bootstrap_external._validate_hash_pyc. The difference between "state = old" for pyc and "state = new" in py would ensure the hashes are different to raise ImportError expected and the test picks up state = new as the updated source code. Without fixing the typo trying to make hash validation would throw NameError.


@unittest.mock.patch('_imp.check_hash_based_pycs', 'always')
def test_checked_hash_based_change_pyc(self):
    source = b"state = 'old'"
    source_hash = importlib.util.source_hash(source)
    bytecode = importlib._bootstrap_external._code_to_hash_pyc(
        compile(source, "???", "exec"),
        source_hash,
        False,
    )
    files = {TESTMOD + ".py": (NOW, "state = 'new'"),
             TESTMOD + ".pyc": (NOW - 20, bytecode)}
    def check(mod):
        self.assertEqual(mod.state, 'new')
    self.doTest(None, files, TESTMOD, call=check)

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:15:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 06:15:18 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576217718.42.0.211372707613.issue39033@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Also since the fix involves modifying zipimport.py it would also require running "make regen-importlib && make -s" for changes to ensure the updated regen code is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:19:36 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 06:19:36 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576217976.25.0.853179198665.issue39033@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Ma Lin, Running pylint/flake8 could possibly detect it but needs to be manually checked. issue36948 was a similar report I filed in the past using flake8 regarding NameError.

pylint - Lib/zipimport.py:611:20: E0602: Undefined variable '_boostrap_external' (undefined-variable)
flake8 - Lib/zipimport.py:611:21: F821 undefined name '_boostrap_external'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:49:04 2019
From: report at bugs.python.org (Rustam Agakishiev)
Date: Fri, 13 Dec 2019 06:49:04 +0000
Subject: [issue39034] Documentation: Coroutines
Message-ID: <1576219743.99.0.330194096424.issue39034@roundup.psfhosted.org>


New submission from Rustam Agakishiev <agakishy at gmail.com>:

Here: https://docs.python.org/3/library/asyncio-task.html??
it says:"To actually run a coroutine, asyncio provides three main mechanisms:"

and a few pages down it gives you a fourth mechanism:
"awaitable asyncio.gather(*aws, loop=None, return_exceptions=False)
Run awaitable objects in the aws sequence concurrently."

And it really runs awaitables:
future = asyncio.gather(*awslist) # aws are run...
...                               # some other heavy tasks
result = async future             # collect results

Shouldn't it be added to docs?

----------
assignee: docs at python
components: Documentation
messages: 358320
nosy: agarus, docs at python
priority: normal
severity: normal
status: open
title: Documentation: Coroutines
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39034>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:51:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2019 06:51:39 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576219899.8.0.690383616138.issue39033@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Wince you has virtually written a patch, do you mind to create a PR Karthikeyan?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:52:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2019 06:52:43 +0000
Subject: [issue32949] Simplify "with"-related opcodes
In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za>
Message-ID: <1576219963.55.0.577160961158.issue32949@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sure.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32949>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:56:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 07:56:41 +0000
Subject: [issue39034] Documentation: Coroutines
In-Reply-To: <1576219743.99.0.330194096424.issue39034@roundup.psfhosted.org>
Message-ID: <1576223801.68.0.327795386903.issue39034@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +asyncio
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39034>
_______________________________________

From report at bugs.python.org  Fri Dec 13 04:05:59 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 09:05:59 +0000
Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict
In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za>
Message-ID: <1576227959.09.0.197730913223.issue21600@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This sounds like a good idea given the docs and the general agreement in the thread. I would like to target this for 3.9 . Differentiation between the normal patches and the ones from patch.dict is nice but given that docstring indicates LIFO for all active patches storing patch.dict items also in _patch.active_patches ensures we can do LIFO if there is a mixture of normal and dictionary patches started with start method. Adding other maintainers for thoughts.

diff --git Lib/unittest/mock.py Lib/unittest/mock.py
index cd5a2aeb60..96115e06ba 100644
--- Lib/unittest/mock.py
+++ Lib/unittest/mock.py
@@ -1853,8 +1853,21 @@ class _patch_dict(object):
         self._unpatch_dict()
         return False

-    start = __enter__
-    stop = __exit__
+    def start(self):
+        """Activate a patch, returning any created mock."""
+        result = self.__enter__()
+        _patch._active_patches.append(self)
+        return result
+
+    def stop(self):
+        """Stop an active patch."""
+        try:
+            _patch._active_patches.remove(self)
+        except ValueError:
+            # If the patch hasn't been started this will fail
+            pass
+
+        return self.__exit__()

----------
components: +Library (Lib) -Tests
nosy: +cjw296, lisroach, mariocj89, xtreak
versions: +Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21600>
_______________________________________

From report at bugs.python.org  Fri Dec 13 04:57:20 2019
From: report at bugs.python.org (Mario Corchero)
Date: Fri, 13 Dec 2019 09:57:20 +0000
Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict
In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za>
Message-ID: <1576231040.4.0.272741634521.issue21600@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Makes total sense, I think we should get this for 3.9.
Not sure I'll backport this, even if a bugfix it might cause unexpected changes (Though I'd be OK with it, given that calling stop twice causes no issue).

I'm happy to push a PR with the proposed change and some tests if you want @xtreak. This is quite a simple fix we can get through in a short time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21600>
_______________________________________

From report at bugs.python.org  Fri Dec 13 04:58:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 09:58:10 +0000
Subject: [issue32952] Add __qualname__ for attributes of Mock instances
In-Reply-To: <1519588331.93.0.467229070634.issue32952@psf.upfronthosting.co.za>
Message-ID: <1576231090.4.0.622625395872.issue32952@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/issue32952>
_______________________________________

From report at bugs.python.org  Fri Dec 13 05:28:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2019 10:28:51 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
Message-ID: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Example of failure of a backport from 3.8 to 3.7, PR 17577:
https://github.com/python/cpython/pull/17577

"""
$ python --version

Python 3.6.9

$ pip --version

pip 19.3.1 from /home/travis/virtualenv/python3.6.9/lib/python3.6/site-packages/pip (python 3.6)
before_install.1

0.00s$ set -e

$ pyenv global 3.7.1

pyenv: version `3.7.1' not installed
"""

Travis CI logs:
https://travis-ci.org/python/cpython/jobs/624160244

Thread on python-dev:
https://mail.python.org/archives/list/python-dev at python.org/thread/YCTLWAYIC44YTVGNN4EDLWKMER2LAPDA/

----------
components: Tests
messages: 358325
nosy: inada.naoki, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Travis CI fail on backports: pyvenv not installed
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Fri Dec 13 05:38:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2019 10:38:45 +0000
Subject: [issue32952] Add __qualname__ for attributes of Mock instances
In-Reply-To: <1519588331.93.0.467229070634.issue32952@psf.upfronthosting.co.za>
Message-ID: <1576233525.87.0.82051972354.issue32952@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +michael.foord
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32952>
_______________________________________

From report at bugs.python.org  Fri Dec 13 05:47:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 10:47:15 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576234035.68.0.490941594216.issue39033@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sure Serhiy, I will create one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 06:03:27 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 11:03:27 +0000
Subject: [issue32952] Add __qualname__ for attributes of Mock instances
In-Reply-To: <1519588331.93.0.467229070634.issue32952@psf.upfronthosting.co.za>
Message-ID: <1576235006.99.0.131656946084.issue32952@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

create_autospec already does recursive spec setting on the class and it has the attributes/methods mocked to retain attributes but doesn't copy the metadata of the original methods to the mock itself. I am not sure spec_set needs to do more stuff than simple attribute level checks making it more heavy to resemble autospeccing and there is an issue for that already. Currently we don't copy __qualname__ to the mock at [0]. 

The func metadata are copied to checksig and during __call__ checksig is used but it's not usable outside and I am not sure we need to do it. The fix to do _copy_func_details(func, mock) below that would copy the function attributes to the actual mock thus accessing the attributes for the mock making below example work.


from unittest.mock import MagicMock, create_autospec, patch

class SomeClass(object):

    def some_method(self):
        print("Hi!")

if __name__ == "__main__":
    ins = SomeClass()
    assert ins.some_method.__qualname__ == "SomeClass.some_method"

    with patch('__main__.SomeClass', autospec=True) as mocked:
        obj = SomeClass()
        assert obj.some_method.__qualname__ == "SomeClass.some_method"
        obj.some_method()
        obj.some_method.assert_called_once()


Copy metadata patch : 

diff --git Lib/unittest/mock.py Lib/unittest/mock.py
index cd5a2aeb60..ea1c6c84ac 100644
--- Lib/unittest/mock.py
+++ Lib/unittest/mock.py
@@ -117,6 +117,7 @@ def _check_signature(func, mock, skipfirst, instance=False):
     def checksig(self, /, *args, **kwargs):
         sig.bind(*args, **kwargs)
     _copy_func_details(func, checksig)
+    _copy_func_details(func, mock)
     type(mock)._mock_check_sig = checksig
     type(mock).__signature__ = sig

@@ -127,6 +128,7 @@ def _copy_func_details(func, funcopy):
     for attribute in (
         '__name__', '__doc__', '__text_signature__',
         '__module__', '__defaults__', '__kwdefaults__',
+        '__qualname__'
     ):
         try:
             setattr(funcopy, attribute, getattr(func, attribute))

[0] https://github.com/python/cpython/blob/025a602af7ee284d8db6955c26016f3f27d35536/Lib/unittest/mock.py#L124
[1] https://github.com/python/cpython/blob/025a602af7ee284d8db6955c26016f3f27d35536/Lib/unittest/mock.py#L119

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32952>
_______________________________________

From report at bugs.python.org  Fri Dec 13 06:13:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 11:13:51 +0000
Subject: [issue27341] mock.patch decorating a generator returns a regular
 function.
In-Reply-To: <1466141708.88.0.0388300458163.issue27341@psf.upfronthosting.co.za>
Message-ID: <1576235631.15.0.661222255702.issue27341@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/issue27341>
_______________________________________

From report at bugs.python.org  Fri Dec 13 06:16:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 11:16:14 +0000
Subject: [issue27197] mock.patch interactions with "from" imports
In-Reply-To: <1464974465.34.0.0106266005771.issue27197@psf.upfronthosting.co.za>
Message-ID: <1576235774.14.0.965352481786.issue27197@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/issue27197>
_______________________________________

From report at bugs.python.org  Fri Dec 13 07:42:53 2019
From: report at bugs.python.org (Lovi)
Date: Fri, 13 Dec 2019 12:42:53 +0000
Subject: [issue39036] Add center_char attribute to str type
Message-ID: <1576240973.63.0.296149851981.issue39036@roundup.psfhosted.org>


New submission from Lovi <1668151593 at qq.com>:

I think Python3.9 needs to add the center_char attribute which means the center character of strings to string type, such as the center_char of '12345' is '1' and the center_char of 'abcd' is 'bc'.

----------
components: Windows
messages: 358328
nosy: lovi, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add center_char attribute to str type
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39036>
_______________________________________

From report at bugs.python.org  Fri Dec 13 07:50:19 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 13 Dec 2019 12:50:19 +0000
Subject: [issue39034] Documentation: Coroutines
In-Reply-To: <1576219743.99.0.330194096424.issue39034@roundup.psfhosted.org>
Message-ID: <1576241419.33.0.169640236078.issue39034@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I suggest thinking that gather() implicitly creates tasks for running coroutines.
The documentation is technically correct, enumeration of all potentially endless list of things that calls `create_task()` for wrapping passed coroutine is not very helpful, especially for the beginning document.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39034>
_______________________________________

From report at bugs.python.org  Fri Dec 13 08:24:48 2019
From: report at bugs.python.org (Sergei Lebedev)
Date: Fri, 13 Dec 2019 13:24:48 +0000
Subject: [issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled
In-Reply-To: <1474611707.66.0.467568151114.issue28254@psf.upfronthosting.co.za>
Message-ID: <1576243488.71.0.901845734232.issue28254@roundup.psfhosted.org>


Sergei Lebedev <sergei.a.lebedev at gmail.com> added the comment:

I know this patch has already been rejected, but I wanted to give another potential use-case for accessing GC status from C: JIT compilers.

Imagine a JIT compiler which uses alternative storage for instance attributes. In order to maintain correctness, it should "materialize" the stored attributes whenever __dict__ (or rather a pointer to __dict__) is accessed. In this context materialization means something like:

    __dict__ = {}
    for key, value in zip(keys, values):
        __dict__[key] = value

Now, what if a __dict__ is accessed during a GC collection (which is possible: collect->deduce_unreachable->subtract_refs->subtype_traverse via tp_traverse)? The JIT compiler should be able to detect such calls and avoid allocating anything:

    if collecting:
        return

    __dict__ = {}
    # ...

This is possible to implement in pure Python using gc.isenabled and gc.callbacks, but there is no existing API to do that in C.

Does this sounds convincing enough to motivate adding

int PyGC_IsEnabled(void)
int PyGC_IsCollecting(void)

to the C API?

----------
nosy: +sergei.lebedev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28254>
_______________________________________

From report at bugs.python.org  Fri Dec 13 08:29:00 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 13 Dec 2019 13:29:00 +0000
Subject: [issue39036] Add center_char attribute to str type
In-Reply-To: <1576240973.63.0.296149851981.issue39036@roundup.psfhosted.org>
Message-ID: <1576243740.88.0.085701949016.issue39036@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

What you mean by "center_char" is not clear to me.

How is "bc" a character? It looks like two characters to me.

How is "1" the center char of "12345"? It looks like the leftmost character to me.

Once you have explained what "center_char" does, could you explain how it will be useful?

----------
components: +Library (Lib) -Windows
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39036>
_______________________________________

From report at bugs.python.org  Fri Dec 13 08:30:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 13:30:04 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576243804.28.0.277945110264.issue39033@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +17060
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17588

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Fri Dec 13 09:03:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 13 Dec 2019 14:03:47 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576245827.1.0.418587167567.issue39031@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17061
pull_request: https://github.com/python/cpython/pull/17589

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Fri Dec 13 09:04:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 13 Dec 2019 14:04:18 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576245858.4.0.992594933293.issue39031@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 0ed45d0cbfc7579dfc5527c19aa6e4bb696db2e0 by Pablo Galindo in branch '3.7':
[3.7] bpo-39031: Include elif keyword when producing lineno/col-offset info for if_stmt (GH-17582) (#17584)
https://github.com/python/cpython/commit/0ed45d0cbfc7579dfc5527c19aa6e4bb696db2e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:19:37 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 13 Dec 2019 15:19:37 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
Message-ID: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

>>> class A: pass
    ... 
    >>> with A(): pass
    ... 
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: __enter__

I expected `AttributeError: __exit__`, since PEP 343 states (https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement):

> The details of the above translation are intended to prescribe the exact semantics. If either of the relevant methods are not found as expected, the interpreter will raise AttributeError, in the order that they are tried (__exit__, __enter__).

and the language documentation states (https://docs.python.org/3/reference/compound_stmts.html#the-with-statement):

> The execution of the with statement with one ?item? proceeds as follows:
> 1. The context expression (the expression given in the with_item) is evaluated to obtain a context manager.
> 2. The context manager?s __exit__() is loaded for later use.
> 3. The context manager?s __enter__() method is invoked.

----------
components: Interpreter Core
messages: 358333
nosy: gvanrossum, maggyero, ncoghlan
priority: normal
severity: normal
status: open
title: Wrong trial order of __exit__ and __enter__ in the with statement
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:29:04 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 13 Dec 2019 15:29:04 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576250944.67.0.11806809383.issue39037@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See issue 27100, which led to a deliberate change in behaviour to look up __enter__ before __exit__. It looks like the documentation (not the PEP text, which shouldn't be considered normative; just the reference manual) needs to be adjusted to match the new behaviour.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:41:25 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 13 Dec 2019 15:41:25 +0000
Subject: [issue27495] Pretty printing sorting for set and frozenset instances
In-Reply-To: <1468323029.69.0.352634397545.issue27495@psf.upfronthosting.co.za>
Message-ID: <1576251685.56.0.177469611524.issue27495@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +SilentGhost
type: enhancement -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27495>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:47:33 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 13 Dec 2019 15:47:33 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576252053.91.0.419241403475.issue39037@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

Thanks @mark.dickinson for the link. Can I open a documentation PR for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:57:25 2019
From: report at bugs.python.org (jvoisin)
Date: Fri, 13 Dec 2019 15:57:25 +0000
Subject: [issue39038] OverflowError in tarfile.open
Message-ID: <1576252645.43.0.77972989062.issue39038@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file produces the following stacktrace when opened via `tarfile.open`, on Python 3.7.5rc1:

```
$ cat test.py 
import sys
import tarfile

tarfile.open(sys.argv[1])
$ python3 test.py ./crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    tarfile.open(sys.argv[1])
  File "/usr/lib/python3.7/tarfile.py", line 1573, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1645, in gzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1621, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1484, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2289, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1097, in fromtarfile
    return obj._proc_member(tarfile)
  File "/usr/lib/python3.7/tarfile.py", line 1119, in _proc_member
    return self._proc_pax(tarfile)
  File "/usr/lib/python3.7/tarfile.py", line 1230, in _proc_pax
    match = regex.match(buf, pos)
OverflowError: Python int too large to convert to C ssize
```

----------
components: Library (Lib)
files: crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf
messages: 358336
nosy: jvoisin
priority: normal
severity: normal
status: open
title: OverflowError in tarfile.open
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48773/crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39038>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:00:48 2019
From: report at bugs.python.org (jvoisin)
Date: Fri, 13 Dec 2019 16:00:48 +0000
Subject: [issue39039] zlib.error with tarfile.open
Message-ID: <1576252848.69.0.760468308355.issue39039@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file produces the following stacktrace when opened via `tarfile.open`, on Python 3.7.5rc1:

```
$ cat test.py 
import sys
import tarfile

tarfile.open(sys.argv[1])
$ python3 test.py ./crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    tarfile.open(sys.argv[1])
  File "/usr/lib/python3.7/tarfile.py", line 1573, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1645, in gzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1621, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1484, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2289, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1094, in fromtarfile
    buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.7/gzip.py", line 276, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 471, in read
    uncompress = self._decompressor.decompress(buf, size)
zlib.error: Error -3 while decompressing data: invalid distances se
```

----------
components: Library (Lib)
files: crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82
messages: 358337
nosy: jvoisin
priority: normal
severity: normal
status: open
title: zlib.error with tarfile.open
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48774/crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39039>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:02:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 16:02:19 +0000
Subject: [issue39039] zlib.error with tarfile.open
In-Reply-To: <1576252848.69.0.760468308355.issue39039@roundup.psfhosted.org>
Message-ID: <1576252939.86.0.15941402356.issue39039@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39039>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:03:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 16:03:03 +0000
Subject: [issue39038] OverflowError in tarfile.open
In-Reply-To: <1576252645.43.0.77972989062.issue39038@roundup.psfhosted.org>
Message-ID: <1576252983.18.0.537440236346.issue39038@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39038>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:08:17 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 13 Dec 2019 16:08:17 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1576253297.43.0.197657371152.issue27100@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
nosy: +maggyero

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:22:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 13 Dec 2019 16:22:24 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576254144.34.0.334669215468.issue39031@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 3b18b17efcee6f968cf85c543254b3611311e9f4 by Pablo Galindo (Miss Islington (bot)) in branch '3.8':
bpo-39031: Include elif keyword when producing lineno/col-offset info for if_stmt (GH-17582) (GH-17589)
https://github.com/python/cpython/commit/3b18b17efcee6f968cf85c543254b3611311e9f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:33:19 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 13 Dec 2019 16:33:19 +0000
Subject: [issue39038] OverflowError in tarfile.open
In-Reply-To: <1576252645.43.0.77972989062.issue39038@roundup.psfhosted.org>
Message-ID: <1576254799.27.0.574620840878.issue39038@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

The file is not a valid tar file:

$ tar xf crash-83a6e7d4b810c6a0bd4fd9dfd6a0b36550034ccf

gzip: stdin: invalid compressed data--crc error

gzip: stdin: invalid compressed data--length error
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Child returned status 1
tar: Error is not recoverable: exiting now

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39038>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:34:20 2019
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 13 Dec 2019 16:34:20 +0000
Subject: [issue39039] zlib.error with tarfile.open
In-Reply-To: <1576252848.69.0.760468308355.issue39039@roundup.psfhosted.org>
Message-ID: <1576254860.93.0.174074609204.issue39039@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

This file is also an invalid tar file:

$ tar xf crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82 

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error is not recoverable: exiting now

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39039>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:38:47 2019
From: report at bugs.python.org (jvoisin)
Date: Fri, 13 Dec 2019 16:38:47 +0000
Subject: [issue39039] zlib.error with tarfile.open
In-Reply-To: <1576252848.69.0.760468308355.issue39039@roundup.psfhosted.org>
Message-ID: <1576255127.74.0.581770543014.issue39039@roundup.psfhosted.org>


jvoisin <jvoisin at google.com> added the comment:

Sure, but as a user, I would expect a better exception, like ValueError or ReadError, along with an error message, instead of an unexpected zlib exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39039>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:42:53 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 13 Dec 2019 16:42:53 +0000
Subject: [issue36746] Create test for fcntl.lockf()
In-Reply-To: <1556476378.45.0.872717637619.issue36746@roundup.psfhosted.org>
Message-ID: <1576255373.25.0.379752292293.issue36746@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@nanjekyejoannah

IMHO, tests were added through bpo-22367
I think that we can close this issue.
What do you think?

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36746>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:59:51 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 16:59:51 +0000
Subject: [issue39040] Wrong filename in when mime header was too long
Message-ID: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>


New submission from Manfred Kaiser <manfred.kaiser at logfile.at>:

I'm working on a mailfilter in python and used the method "get_filename" of the "EmailMessage" class.

In some cases a wrong filename was returned. The reason was, that the Content-Disposition Header had a line break and the following intention was interpreted as part of the filename.

After fixing this bug, I was able to get the right filename.

I had to change "linesep_splitter" in "email.policy" to match the intention.

Old Value:

linesep_splitter = re.compile(r'\n|\r')


New Value:

linesep_splitter = re.compile(r'\n\s+|\r\s+')

----------
components: email
messages: 358343
nosy: barry, mkaiser, r.david.murray
priority: normal
severity: normal
status: open
title: Wrong filename in when mime header was too long
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/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:04:32 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 17:04:32 +0000
Subject: [issue39040] Wrong filename in when mime header was too long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576256672.78.0.672827526029.issue39040@roundup.psfhosted.org>


Change by Manfred Kaiser <manfred.kaiser at logfile.at>:


----------
keywords: +patch
pull_requests: +17062
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17590

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:08:35 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 17:08:35 +0000
Subject: [issue39040] Wrong filename in mail when mime header was too long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576256915.19.0.318924185012.issue39040@roundup.psfhosted.org>


Change by Manfred Kaiser <manfred.kaiser at logfile.at>:


----------
title: Wrong filename in when mime header was too long -> Wrong filename in mail when mime header was too long

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:08:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2019 17:08:51 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576256931.66.0.802130847659.issue39037@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
keywords: +easy
nosy: +docs at python
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:08:59 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 17:08:59 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576256939.27.0.0017757167868.issue39040@roundup.psfhosted.org>


Change by Manfred Kaiser <manfred.kaiser at logfile.at>:


----------
title: Wrong filename in mail when mime header was too long -> Wrong attachement filename when mail mime header was too long

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:33:39 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 13 Dec 2019 17:33:39 +0000
Subject: [issue36746] Create test for fcntl.lockf()
In-Reply-To: <1556476378.45.0.872717637619.issue36746@roundup.psfhosted.org>
Message-ID: <1576258419.33.0.49311485484.issue36746@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@victor looks to be the author of the change the introduced the tests that can resolve this.

Victor, can we consider this closed. I have no problem closing the issue and the related PR.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36746>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:38:36 2019
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2019 17:38:36 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576258716.23.0.0976975075857.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report.  Can you provide an example that reproduces the problem?  

Per the RFC, lines may be broken before whitespace in certain places in certain headers, but that does not make the whitespace go away.  Only the crlf sequence is removed when unfolding the header, per the RFC, so your proposed fix is incorrect. I suspect your example header is invalid, and the question will then become is there some sort of Postel-style error recovery we can and want to do in the function that parses the content-disposition header.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:49:39 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2019 17:49:39 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576259379.46.0.286091596083.issue39037@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Gery please do open a documentation PR! :)

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:50:40 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 17:50:40 +0000
Subject: [issue1021318] PyThreadState_Next not thread safe
In-Reply-To: <1576072929.85.0.213365547585.issue1021318@roundup.psfhosted.org>
Message-ID: <CALFfu7AoZYmLrQorFKMoCv9Qb450S=n1Yr11RULb=osyrTkGag@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Wed, Dec 11, 2019 at 7:02 AM STINNER Victor <report at bugs.python.org> wrote:
> We may have to fix this API first, and clarify the scope of the different locks.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1021318>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:07:00 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2019 18:07:00 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1576260420.83.0.912024512401.issue36406@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 8289e27393395ee903bd096d42e07c112d7f15c6 by Brett Cannon (Xtreak) in branch 'master':
bpo-36406: Handle namespace packages in doctest (GH-12520)
https://github.com/python/cpython/commit/8289e27393395ee903bd096d42e07c112d7f15c6


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:07:15 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 13 Dec 2019 18:07:15 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1576260435.44.0.775631859528.issue36406@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17063
pull_request: https://github.com/python/cpython/pull/17591

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:07:24 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 13 Dec 2019 18:07:24 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1576260444.12.0.0125921040405.issue36406@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17064
pull_request: https://github.com/python/cpython/pull/17592

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:21:58 2019
From: report at bugs.python.org (Lewis Gaul)
Date: Fri, 13 Dec 2019 18:21:58 +0000
Subject: [issue37776] Test Py_Finalize() from a subinterpreter
In-Reply-To: <1565113410.42.0.547052767114.issue37776@roundup.psfhosted.org>
Message-ID: <1576261318.87.0.54339551183.issue37776@roundup.psfhosted.org>


Lewis Gaul <lewis.gaul at gmail.com> added the comment:

It seems that test_audit_subinterpreter() in _testembed.c was (unintentionally?) doing this already.

After fixing #36225 I found this testcase causes a segfault, but works fine when switching back to the main threadstate before calling Py_Finalize().

So it looks like adding a specific testcase for this is likely to weed out an actual issue here!

----------
nosy: +LewisGaul

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37776>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:29:20 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 18:29:20 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576261760.35.0.964823040726.issue39040@roundup.psfhosted.org>


Change by Manfred Kaiser <manfred.kaiser at logfile.at>:


Added file: https://bugs.python.org/file48775/testscript.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:34:12 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 18:34:12 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576262052.35.0.938992407933.issue39040@roundup.psfhosted.org>


Manfred Kaiser <manfred.kaiser at logfile.at> added the comment:

The original filename is "Schulbesuchsbest?ttigung.pdf", but when I use the method "get_filename" I got "Schulbesuchsbest?ttigung.        pdf"

I removed some headers from the mail for privacy reasons

----------
Added file: https://bugs.python.org/file48776/error.eml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:36:11 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 18:36:11 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576262171.55.0.647209469971.issue39040@roundup.psfhosted.org>


Manfred Kaiser <manfred.kaiser at logfile.at> added the comment:

The mail was sent from the GMail web interface

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:52:06 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Fri, 13 Dec 2019 18:52:06 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576263126.75.0.0857846253238.issue39040@roundup.psfhosted.org>


Change by Manfred Kaiser <manfred.kaiser at logfile.at>:


Added file: https://bugs.python.org/file48777/original_mail_from_gmail.eml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:28:50 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 13 Dec 2019 19:28:50 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1576265330.42.0.353401694368.issue13586@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17065
pull_request: https://github.com/python/cpython/pull/17593

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:44:51 2019
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2019 19:44:51 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576266291.14.0.80225077233.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

That header is *completely* non-RFC compliant.  If gmail generated that header there is something very wrong in google-land :(

The RFC compliant formatting for that header looks like this:

Content-Disposition: attachment;
 filename*=utf-8''Schulbesuchsbest%C3%A4ttigung.pdf

You will note that this is nothing like encoded word format.  Encoded words are not valid inside quoted strings, and quoted strings can't be used in mime header attributes if there are non-ascii characters involved.  Nor can encoded words.  

Now, all that said, there is an obvious rule that can be followed to understand what that header is trying to convey, and the current parser already implements most of it (you will find comments about it in the parser, as well as defects being registered).  So, a patch to _header_value_parser to fix the error recovery will be accepted.  I've looked at the code to remind myself, but not deeply enough to be *sure* where the changes need to be made.  There are two possibilities I see off the bat (and both may need fixing): get_bare_quoted_string and get_parameter.  Either one or both of those may be forgetting that whitespace between encoded words should be dropped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:55:46 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 13 Dec 2019 19:55:46 +0000
Subject: [issue13586] IDLE: Replace selected not working/consistent with find
In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za>
Message-ID: <1576266946.52.0.967211855313.issue13586@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I've created a pull request for this issue.  Please take a look.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13586>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:30:27 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 Dec 2019 20:30:27 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576269027.15.0.883171238313.issue39031@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:17:17 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 21:17:17 +0000
Subject: [issue38962] Reference leaks in subinterpreters
In-Reply-To: <1575402950.84.0.0958518006452.issue38962@roundup.psfhosted.org>
Message-ID: <1576271837.55.0.206068739748.issue38962@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for all the work on this!

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38962>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:27:21 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 21:27:21 +0000
Subject: [issue36854] GC operates out of global runtime state.
In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org>
Message-ID: <1576272441.01.0.953880342634.issue36854@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Wed, Dec 4, 2019 at 4:36 AM STINNER Victor <report at bugs.python.org> wrote:
> Each time I tried to fix a bug in the Python finalization, I introduced worse bugs :-D

:)

> We cannot fix all bugs at once, we have to work incrementally.

+1

> I like the idea of introducing workarounds specific to subinterpreters: leave the code path for the main interpreter unchanged. It helps to iterate on the code to slowly fix the code.

+1

> I prefer to not open an issue, since the Python finalization is broken is so many ways :-D Anyway, I'm hitting issues on the finalization each time I'm working on subinterpeter changes, so it's hard to forget about it :-)

Sounds good. :)

On Wed, Dec 4, 2019 at 4:39 AM STINNER Victor <report at bugs.python.org> wrote:
> I'm a believer that subinterpreters is one of the most realistic solution to make Python faster. I said it in my EuroPython keynote on CPython performance ;-)

Again, thanks for that!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36854>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:29:12 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 21:29:12 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1576272551.99.0.050731282847.issue38858@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for working on this.  It really does have far-reaching benefits, not just for the subinterpreter stuff I'm interested in. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:33:48 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 21:33:48 +0000
Subject: [issue37776] Test Py_Finalize() from a subinterpreter
In-Reply-To: <1576261318.87.0.54339551183.issue37776@roundup.psfhosted.org>
Message-ID: <CALFfu7DzbCnjLoMYx4eGPOtx+he0vPBQiO=oHhd2ODV6dKFAcg@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Fri, Dec 13, 2019 at 11:22 AM Lewis Gaul <report at bugs.python.org> wrote:
> So it looks like adding a specific testcase for this is likely to weed out an actual issue here!

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37776>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:39:20 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 21:39:20 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1575174189.52.0.427280357232.issue37224@roundup.psfhosted.org>
Message-ID: <CALFfu7DU_=Hdw76tSnzor=+OS60er+SYeWwJ1e0v=EGqW0_MjA@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley <report at bugs.python.org> wrote:
> Based on the above hint, I was able to make some progress on a potential solution. Thanks Eric.

That's great!

> Instead of only checking "frame->f_executing", I changed "_is_running()" to also check the
> "finalizing" field of PyInterpreterState. The "finalizing" field is set to 1 in "Py_EndInterpreter()",
> so this ensures that an interpreter in the process of being destroyed is considered "running",
> so that operations (such as running scripts, destroying the interpreter, etc) can't occur during
> finalization.

Ah, that makes sense.

> I had to add a private function to the C-API in order to access "interp->finalizing" from
> Modules/_xxsubinterpretersmodule.c due to the struct for PyInterpreterState being internal only.

Yep, it has to use the public C-API just like any other module.  The
function has a "_Py" prefix and be defined in Include/cpython, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:42:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 21:42:27 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1575174189.52.0.427280357232.issue37224@roundup.psfhosted.org>
Message-ID: <CALFfu7Ad4_stQO0woN+tbAH+s8uZvhg5RS-btAY4gH85Uwhb3w@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Sat, Nov 30, 2019 at 9:23 PM Kyle Stanley <report at bugs.python.org> wrote:
> I have a few ideas that I'd like to test out for fixing this failure, and if any of them produce positive results I'll report back.

Sounds good.

> Since the failures are still consistently occurring, I have not yer revised GH-16293. I'll do that when/if I come up with a more thorough solution.

We don't need everything to be fixed in a single PR.  Feel free to
create a PR just for the "finalizing" fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:46:59 2019
From: report at bugs.python.org (AVicennA)
Date: Fri, 13 Dec 2019 21:46:59 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1576273619.58.0.20621268931.issue38993@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

In official documentation: https://docs.python.org/3/library/profile.html was not noted about the difference behaviour of cProfile in command line and into the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:56:07 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 13 Dec 2019 21:56:07 +0000
Subject: [issue39041] Support GitHub Actions in CI
Message-ID: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Enable support for GitHub Actions CI to do PR build and test runs.

Once stable, we can deprecate Azure Pipelines PR builds.

The only regression right now is that test results are not collected in a nice view like AP has. But I think that view is not widely used, and searching the logs on GitHub is probably good enough.

----------
assignee: steve.dower
components: Build
messages: 358361
nosy: brett.cannon, steve.dower
priority: normal
pull_requests: 17066
severity: normal
stage: patch review
status: open
title: Support GitHub Actions in CI
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:21:22 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 22:21:22 +0000
Subject: [issue39042] Use the runtime's main thread ID in the threading module.
Message-ID: <1576275682.19.0.998306709118.issue39042@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

The threading module has a "main_thread()" function that returns a Thread instance for the "main" thread.  The main thread is the one running when the runtime is initialized and has a specific role in various parts of the runtime.  Currently the threading module instead uses the ID of the thread where the module is imported for the first time.  Usually this isn't a problem. (perhaps only in embedding cases?)

Since 3.8 we store the ID of the thread where the runtime was initialized (_PyRuntime.main_thread).  By using this in the threading module we can be consistent across the runtime about what the main thread is.

This is particularly significant because in 3.8 we also updated the signal module to use _PyRuntime.main_thread (instead of calling PyThread_get_thread_ident() when the module is loaded).  See issue38904.

We should also consider backporting this change to 3.8, to resolve the difference between the threading and signal modules.

----------
components: Library (Lib)
messages: 358362
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Use the runtime's main thread ID in the threading module.
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39042>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:25:14 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 22:25:14 +0000
Subject: [issue38904] "signal only works in main thread" in main thread
In-Reply-To: <1574575580.88.0.320595380442.issue38904@roundup.psfhosted.org>
Message-ID: <1576275914.67.0.946957959481.issue38904@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Before 3.8, the "signal" module checked against the thread in which the module was initially loaded, treating that thread as the "main" thread.  That same was true (and still is) for the "threading" module.  The problem for both modules is that the Python runtime may have actually been initialized in a different thread, which is the actual "main" thread.

Since Python 3.8 we store the ID of the thread where the runtime is initialized and use that in the check the "signal" module does.  However, the "threading" module still uses the ID of the thread where it is first imported.  So your check against "threading.main_thread()" must be in code that isn't running in the same thread where you ran Py_Initialize().  It probably used to work because you imported "signal" and "threading" for the first time in the same thread.

So what next?

First, I've created issue39042 to address the current different meanings of "main thread".  That should resolve the discrepancy between the signal and threading modules.

Second, what can we do to help embedders make sure they are running their code in the main thread (e.g. when setting signals)?  Is there any C-API we could add which would have helped you here?

----------
nosy: +eric.snow, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38904>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:31:46 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2019 22:31:46 +0000
Subject: [issue33608] 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: <1576276306.14.0.788455413698.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Sorry for the delay, Phil.  I'll try to take a look in the next couple of hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:30:11 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2019 23:30:11 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1576279811.25.0.0222763139791.issue36406@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset d3212036aa2510b9e133ba4bfaf1262d6bcbe7f0 by Brett Cannon (Miss Islington (bot)) in branch '3.7':
bpo-36406: Handle namespace packages in doctest (GH-12520) (GH-17592)
https://github.com/python/cpython/commit/d3212036aa2510b9e133ba4bfaf1262d6bcbe7f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:30:45 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2019 23:30:45 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1576279845.25.0.719041891681.issue36406@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset aa74a53ad61134911ac7904f24fd2630aeaa8ac8 by Brett Cannon (Miss Islington (bot)) in branch '3.8':
bpo-36406: Handle namespace packages in doctest (GH-12520) (GH-17591)
https://github.com/python/cpython/commit/aa74a53ad61134911ac7904f24fd2630aeaa8ac8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:38:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 13 Dec 2019 23:38:43 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1576280323.64.0.399973560236.issue36406@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:08:39 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Dec 2019 00:08:39 +0000
Subject: [issue33608] 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: <1576282119.71.0.963435421665.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm out of time and this deserves some careful discussion.  I'll get to it next Friday (or sooner if possible).  Sorry!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:45:47 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Dec 2019 00:45:47 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1576284347.49.0.936909781572.issue38993@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This doesn't seem like an appropriate use of the bug tracker.

Investigating and explaining cProfile results seems better suited for StackOverflow or some other forum.  Then if an actual known bug or potential optimization arises, the bug tracker can to used to follow-up on a specific request.  

Being "surprised" by timing/profling results usually isn't a bug and can sometimes be resolved by studying the source to how one's simplified mental model differs from the realities faced by a real-world implementation.

I recommend closing this but allowing it to be reopened if specific improvement can be proposed.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:57:10 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 14 Dec 2019 00:57: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: <1576285030.9.0.582537958777.issue23930@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23930>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:57:09 2019
From: report at bugs.python.org (AVicennA)
Date: Sat, 14 Dec 2019 00:57:09 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1576285029.22.0.143523750459.issue38993@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

@rhettinger, I did not write nowhere in my post that it's a pure bug. I use "behaviour" instead of it. And it getting me incorrect results everytime, that is why I should wrote it in here for resolving this problem. This is not about getting error message, that write to Stackoverflow. I think you were not checking this never.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:25:56 2019
From: report at bugs.python.org (Lovi)
Date: Sat, 14 Dec 2019 01:25:56 +0000
Subject: [issue39036] Add center_char attribute to str type
In-Reply-To: <1576240973.63.0.296149851981.issue39036@roundup.psfhosted.org>
Message-ID: <1576286756.58.0.745357394614.issue39036@roundup.psfhosted.org>


Lovi <1668151593 at qq.com> added the comment:

Sorry, I made a mistake.

The center char of '12345' is '3' and the center char of 'abcd' is '' because it doesn't have the most central character.

In my opinion, with center_char, when you need the center character of a string you can get it directly with str.center_char instead of tedious index and calculation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39036>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:35:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Dec 2019 01:35:29 +0000
Subject: [issue39036] Add center_char attribute to str type
In-Reply-To: <1576240973.63.0.296149851981.issue39036@roundup.psfhosted.org>
Message-ID: <1576287329.17.0.898092438094.issue39036@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for the suggestion, but this proposal isn't broadly useful enough to warrant adding a new method.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39036>
_______________________________________

From report at bugs.python.org  Fri Dec 13 21:02:33 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 14 Dec 2019 02:02:33 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576288953.56.0.374600668108.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17067
pull_request: https://github.com/python/cpython/pull/17595

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Fri Dec 13 21:04:57 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 14 Dec 2019 02:04:57 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576289097.86.0.210148038212.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Opened a PR that adds the whatsnew entries to master, 3.8, 3.7, and 3.6: GH-17595.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:08:01 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 14 Dec 2019 03:08:01 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1576292881.15.0.856522308314.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Yep, it has to use the public C-API just like any other module.  The
> function has a "_Py" prefix and be defined in Include/cpython, right?

Yeah, I named it "_PyInterpreterIsFinalizing" and it's within Include/cpython. Definitely open to suggestions on the name though, it's basically just a private getter for interp->finalizing.

> We don't need everything to be fixed in a single PR.  Feel free to
> create a PR just for the "finalizing" fix.

Oh, awesome! In that case, I'll do some more rigorous testing before opening the PR then; I'd like to be 99.99% certain that it at least resolves the following failure:

FAIL: test_still_running (test.test__xxsubinterpreters.DestroyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test__xxsubinterpreters.py", line 765, in test_still_running
    interpreters.destroy(interp)
AssertionError: RuntimeError not raised

Especially since it would be adding a new private C-API function, who's primary purpose is to address this specific failure.

This might be a bit of a time consuming process, but I should have time in the next week or so to work on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:40:21 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 14 Dec 2019 04:40:21 +0000
Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict
In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za>
Message-ID: <1576298421.18.0.0415108177931.issue21600@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Mario. I think the last patch attached to the issue is complete with tests and needs to be updated master. Feel free to raise a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21600>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:43:56 2019
From: report at bugs.python.org (Lovi)
Date: Sat, 14 Dec 2019 04:43:56 +0000
Subject: [issue39043] Add math.fib() generator
Message-ID: <1576298636.18.0.950547793455.issue39043@roundup.psfhosted.org>


New submission from Lovi <1668151593 at qq.com>:

I think it's appropriate to add the generator fib() to the math module. With fib(), some operations will be easier.

The generator is like this:

def fib(count=None):
    if count is not None and not isinstance(count, int):
        raise ValueError(f"Parameter count has an unexpected type: {count.__class__.__name__}.")
    a, b = 0, 1
    while True:
        a, b = b, a + b
        if count is not None:
            if not count:
                return
            count -= 1
        yield a

----------
components: Library (Lib)
messages: 358375
nosy: lovi
priority: normal
severity: normal
status: open
title: Add math.fib() generator
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39043>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:47:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 14 Dec 2019 04:47:41 +0000
Subject: [issue39043] Add math.fib() generator
In-Reply-To: <1576298636.18.0.950547793455.issue39043@roundup.psfhosted.org>
Message-ID: <1576298861.13.0.761391633111.issue39043@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39043>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:53:45 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 14 Dec 2019 04:53:45 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576299225.02.0.0981363886162.issue39031@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

There was a bug in my last PR, hopefully I will get a fix some time later today.

The bug is as follows: I only updated the asdl_seq_SET call for an elif without an else, if an else is included then the behavior is like before.

After my last PR it looks like this, parsing

2:if a:
3:    pass
4:elif b:
5:    pass

outputs the following AST:

Module(
    body=[
        If(
            test=Name(id="a", ctx=Load(), lineno=2, col_offset=3, end_lineno=2, end_col_offset=4),
            body=[Pass(lineno=3, col_offset=4, end_lineno=3, end_col_offset=8)],
            orelse=[
                If(
                    test=Name(
                        id="b", ctx=Load(), lineno=4, col_offset=5, end_lineno=4, end_col_offset=6
                    ),
                    body=[Pass(lineno=5, col_offset=4, end_lineno=5, end_col_offset=8)],
                    orelse=[],
                    lineno=4,
                    col_offset=0,
                    end_lineno=5,
                    end_col_offset=8,
                )
            ],
            lineno=2,
            col_offset=0,
            end_lineno=5,
            end_col_offset=8,
        )
    ],
    type_ignores=[],
)

On the other hand parsing

2:if a:
3:    pass
4:elif b:
5:    pass
6:else:
7:    pass

outputs

Module(
    body=[
        If(
            test=Name(
                id="a",
                ctx=Load(),
                lineno=2,
                col_offset=3,
                end_lineno=2,
                end_col_offset=4,
            ),
            body=[Pass(lineno=3, col_offset=4, end_lineno=3, end_col_offset=8)],
            orelse=[
                If(
                    test=Name(
                        id="b",
                        ctx=Load(),
                        lineno=4,
                        col_offset=5,
                        end_lineno=4,
                        end_col_offset=6,
                    ),
                    body=[Pass(lineno=5, col_offset=4, end_lineno=5, end_col_offset=8)],
                    orelse=[
                        Pass(lineno=7, col_offset=4, end_lineno=7, end_col_offset=8)
                    ],
                    lineno=4,
                    col_offset=5,
                    end_lineno=7,
                    end_col_offset=8,
                )
            ],
            lineno=2,
            col_offset=0,
            end_lineno=7,
            end_col_offset=8,
        )
    ],
    type_ignores=[],
)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Sat Dec 14 00:10:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Dec 2019 05:10:44 +0000
Subject: [issue39043] Add math.fib() generator
In-Reply-To: <1576298636.18.0.950547793455.issue39043@roundup.psfhosted.org>
Message-ID: <1576300244.46.0.860442989436.issue39043@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, this isn't sufficiently useful or needed to warrant inclusion in the standard library.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39043>
_______________________________________

From report at bugs.python.org  Sat Dec 14 00:22:45 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 14 Dec 2019 05:22:45 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576300965.41.0.517282447372.issue39031@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +17068
pull_request: https://github.com/python/cpython/pull/17596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Sat Dec 14 01:12:46 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Sat, 14 Dec 2019 06:12:46 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576303966.2.0.10892562501.issue39040@roundup.psfhosted.org>


Manfred Kaiser <manfred.kaiser at logfile.at> added the comment:

thanks for your response. I have found the RFC https://tools.ietf.org/html/rfc2184

Gmail creates wrong Headers, which are not rfc-compliant.
The problem is, that many people are using gmail and emails, which were sent from Gmail might be wrong.

How can we solve this problem? It is not a Python problem. We can create workarrounds. But in my opinion Google has to fix the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sat Dec 14 01:34:52 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 14 Dec 2019 06:34:52 +0000
Subject: [issue39044] Segfault on build for the master branch
Message-ID: <1576305292.12.0.476771129808.issue39044@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

I just pulled changes from upstream and when I build with:

./configure --with-pydebug && make -j

Am getting a Segmentation fault:

./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
 CC='gcc -pthread' LDSHARED='gcc -pthread -shared    ' OPT='-g -Og -Wall'       _TCLTK_INCLUDES='' _TCLTK_LIBS=''       ./python -E ./setup.py  build
Segmentation fault (core dumped)
make: *** [Makefile:614: sharedmods] Error 139

I hope someone else can replicate this on:

o LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 19.04
Release:        19.04
Codename:       disco

----------
components: Build
messages: 358379
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Segfault on build for the master branch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39044>
_______________________________________

From report at bugs.python.org  Sat Dec 14 01:38:49 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 14 Dec 2019 06:38:49 +0000
Subject: [issue39044] Segfault on build for the master branch
In-Reply-To: <1576305292.12.0.476771129808.issue39044@roundup.psfhosted.org>
Message-ID: <1576305529.72.0.294283802671.issue39044@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +pablogsal, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39044>
_______________________________________

From report at bugs.python.org  Sat Dec 14 01:46:20 2019
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 14 Dec 2019 06:46:20 +0000
Subject: [issue39044] Segfault on build for the master branch
In-Reply-To: <1576305292.12.0.476771129808.issue39044@roundup.psfhosted.org>
Message-ID: <1576305980.38.0.372812637263.issue39044@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

If you updated an unclean checkout, try running `make distclean` before configuring and building again; that often clears this kind of thing up.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39044>
_______________________________________

From report at bugs.python.org  Sat Dec 14 01:53:30 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 14 Dec 2019 06:53:30 +0000
Subject: [issue39044] Segfault on build for the master branch
In-Reply-To: <1576305292.12.0.476771129808.issue39044@roundup.psfhosted.org>
Message-ID: <1576306410.01.0.0133964009987.issue39044@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Actually my master had some segfaulting changes that I had moved to it in error. Thanks.

Closing this.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39044>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:01:03 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 14 Dec 2019 07:01:03 +0000
Subject: [issue39044] Segfault on build for the master branch
In-Reply-To: <1576305292.12.0.476771129808.issue39044@roundup.psfhosted.org>
Message-ID: <1576306863.51.0.0223490999016.issue39044@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Confirmed....forgeting to run makedistclean was the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39044>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:54:44 2019
From: report at bugs.python.org (Lovi)
Date: Sat, 14 Dec 2019 07:54:44 +0000
Subject: [issue39045] Segmentation of string
Message-ID: <1576310084.51.0.108674240792.issue39045@roundup.psfhosted.org>


New submission from Lovi <1668151593 at qq.com>:

I thought for a long time. I think it's necessary to add a segment method to str type or string module. This method is used to split a string into m parts and return all cases.

For example:

segment('1234', m=3) -> [('1', '2', '34'), ('1', '23', '4'), ('12', '3', '4')]
segment('12345', m=3) -> [('1', '2', '345'), ('1', '23', '45'), ('1', '234', '5'), ('12', '3', '45'), ('12', '34', '5'), ('123', '4', '5')]


I hope this proposal can be adopted.

----------
components: Library (Lib)
messages: 358383
nosy: lovi
priority: normal
severity: normal
status: open
title: Segmentation of string
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39045>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:58:48 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Sat, 14 Dec 2019 07:58:48 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576310328.06.0.434981273834.issue39040@roundup.psfhosted.org>


Manfred Kaiser <manfred.kaiser at logfile.at> added the comment:

RFC-2184 was obsoleted by RFC-2231 (https://www.rfc-editor.org/rfc/rfc2231.html)

There are also no quoted strings, like google uses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sat Dec 14 03:26:01 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 Dec 2019 08:26:01 +0000
Subject: [issue39045] Segmentation of string
In-Reply-To: <1576310084.51.0.108674240792.issue39045@roundup.psfhosted.org>
Message-ID: <1576311961.06.0.643130341382.issue39045@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

It is generally suggested to offer this sort of proposals for discussion on python-ideas mailing list [0] first. There, you can elaborate on why you think this is necessary, what sort of use cases this new method could have, etc. Once there is a broad agreement on behaviour and details of this new feature, if it's to be adopted at all, you can open an issue to track the implementation work.

Good luck. I'm closing the issue, as the proposal is not yet well formed, but you're welcome to re-open this bug after discussion on the mailing list.

[0] https://mail.python.org/mailman3/lists/python-ideas.python.org/

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39045>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:04:07 2019
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Sat, 14 Dec 2019 10:04:07 +0000
Subject: [issue39046] collections.abc.Reversible should not be a subclass of
 Hashable
Message-ID: <1576317847.63.0.718393349876.issue39046@roundup.psfhosted.org>


New submission from Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:

>>> from collections.abc import Hashable, Reversible
>>> assert issubclass(Reversible, Hashable)

However, this is trivially wrong - lists are Reversible but not Hashable, and there is no reason to thing that reversible objects should all be hashable.

The versions of these classes in the typing module have the same problem.

----------
components: Library (Lib)
messages: 358386
nosy: Zac Hatfield-Dodds
priority: normal
severity: normal
status: open
title: collections.abc.Reversible should not be a subclass of Hashable
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39046>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:31:22 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 14 Dec 2019 10:31:22 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576319482.91.0.663118605061.issue39031@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17069
pull_request: https://github.com/python/cpython/pull/17600

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:31:52 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 14 Dec 2019 10:31:52 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576319512.82.0.000869989628943.issue39031@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17070
pull_request: https://github.com/python/cpython/pull/17601

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:36:22 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 14 Dec 2019 10:36:22 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576319782.54.0.989666681336.issue39031@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:51:19 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 10:51:19 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576320679.82.0.370664564365.issue39035@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +17071
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17602

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:55:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 14 Dec 2019 10:55:43 +0000
Subject: [issue39031] Inconsistency with lineno and col_offset info when
 parsing elif
In-Reply-To: <1576181707.03.0.620704542473.issue39031@roundup.psfhosted.org>
Message-ID: <1576320943.52.0.546070736022.issue39031@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks, Lysandros for the quick fix!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39031>
_______________________________________

From report at bugs.python.org  Sat Dec 14 06:07:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 Dec 2019 11:07:16 +0000
Subject: [issue39044] Segfault on build for the master branch
In-Reply-To: <1576305292.12.0.476771129808.issue39044@roundup.psfhosted.org>
Message-ID: <1576321636.64.0.321097614799.issue39044@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Confirmed....forgeting to run makedistclean was the problem.

Yeah, it happens often to me.

If "make distclean" is not enough, I move untracked files outside the Python repository and run "git clean "-fdx" which removes *all* untracked files. Use "git clean -ndx" to see which files will be removed, to double check. Otherwise, you may loose sensitive files which are not tracked by Git.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39044>
_______________________________________

From report at bugs.python.org  Sat Dec 14 06:10:18 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 11:10:18 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576321818.24.0.153176385914.issue39035@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 94d2c8df1a7657015a2fcdb4c4d43392f91f8348 by Inada Naoki in branch 'master':
bpo-39035: travis: Don't use beta group (GH-17602)
https://github.com/python/cpython/commit/94d2c8df1a7657015a2fcdb4c4d43392f91f8348


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 07:02:49 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 Dec 2019 12:02:49 +0000
Subject: [issue39046] collections.abc.Reversible should not be a subclass of
 Hashable
In-Reply-To: <1576317847.63.0.718393349876.issue39046@roundup.psfhosted.org>
Message-ID: <1576324969.92.0.212400558446.issue39046@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +rhettinger, stutzbach
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39046>
_______________________________________

From report at bugs.python.org  Sat Dec 14 07:05:04 2019
From: report at bugs.python.org (Lovi)
Date: Sat, 14 Dec 2019 12:05:04 +0000
Subject: [issue39046] collections.abc.Reversible should not be a subclass of
 Hashable
In-Reply-To: <1576317847.63.0.718393349876.issue39046@roundup.psfhosted.org>
Message-ID: <1576325104.83.0.667542836989.issue39046@roundup.psfhosted.org>


Change by Lovi <1668151593 at qq.com>:


----------
nosy: +lovi
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39046>
_______________________________________

From report at bugs.python.org  Sat Dec 14 07:22:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 14 Dec 2019 12:22:03 +0000
Subject: [issue39046] collections.abc.Reversible should not be a subclass of
 Hashable
In-Reply-To: <1576317847.63.0.718393349876.issue39046@roundup.psfhosted.org>
Message-ID: <1576326123.87.0.808816753165.issue39046@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/issue39046>
_______________________________________

From report at bugs.python.org  Sat Dec 14 08:37:25 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 13:37:25 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576330645.74.0.705544516748.issue39035@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17072
pull_request: https://github.com/python/cpython/pull/17603

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 08:42:45 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 13:42:45 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576330965.07.0.380047861638.issue39035@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17073
pull_request: https://github.com/python/cpython/pull/17604

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 08:44:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 13:44:17 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576331057.16.0.769737466187.issue39035@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17074
pull_request: https://github.com/python/cpython/pull/17605

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:01:59 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 14:01:59 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576332119.42.0.4199905815.issue39035@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 5c5d8f63d7d235e557ad20e7d722b22772681759 by Inada Naoki in branch '3.8':
bpo-39035: travis: Don't use beta group (GH-17603)
https://github.com/python/cpython/commit/5c5d8f63d7d235e557ad20e7d722b22772681759


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:02:23 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 14:02:23 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576332143.94.0.279576833206.issue39035@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset be7489cb43e25b6d8bfa077589c18cc0a2367efd by Inada Naoki in branch '3.7':
bpo-39035: travis: Don't use beta group (GH-17604)
https://github.com/python/cpython/commit/be7489cb43e25b6d8bfa077589c18cc0a2367efd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:02:58 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 14 Dec 2019 14:02:58 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576332178.89.0.908897798125.issue39035@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset de4481339dec395d70e350aa2e22d7990d2b3635 by Inada Naoki in branch '2.7':
bpo-39035: travis: Don't use beta group (GH-17605)
https://github.com/python/cpython/commit/de4481339dec395d70e350aa2e22d7990d2b3635


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:42:34 2019
From: report at bugs.python.org (Mario Corchero)
Date: Sat, 14 Dec 2019 14:42:34 +0000
Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict
In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za>
Message-ID: <1576334554.28.0.74027086758.issue21600@roundup.psfhosted.org>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
pull_requests: +17075
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17606

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21600>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:53:17 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Sat, 14 Dec 2019 14:53:17 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576335197.35.0.539704154254.issue39040@roundup.psfhosted.org>


Manfred Kaiser <manfred.kaiser at logfile.at> added the comment:

as you mentioned, rfc-2047 forbidds encoded words in quoted strings.

Source: https://tools.ietf.org/html/rfc2047 - Chapter 5/3

I have tested a few web mail clients and they have the same issue. According to the RFCs, this is not allowed, but I think it is widely used.

Should we fix this problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:57:28 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 14 Dec 2019 14:57:28 +0000
Subject: [issue32888] Improve exception message in ast.literal_eval
In-Reply-To: <1519147581.54.0.467229070634.issue32888@psf.upfronthosting.co.za>
Message-ID: <1576335448.39.0.915510986964.issue32888@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17076
pull_request: https://github.com/python/cpython/pull/16620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32888>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:59:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 Dec 2019 14:59:42 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576335582.0.0.18290428612.issue39035@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

INADA-san: do you want to close this issue since you pushed changes, or do you prefer to wait to see if it's issue is fixed before closing it? (wait a few days and look at Travis CI jobs)

3.5 uses:

language: c
dist: trusty
sudo: false
group: beta

3.6 uses:

language: c
dist: trusty
sudo: false
group: beta

These branches still get pull requests for security fixes. Maybe it's worth it to also update these branches? Maybe even upgrade them to Ubuntu Xenial?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:28:49 2019
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2019 15:28:49 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576337329.72.0.249558361184.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, google should fix their bug.  However, the python email package tries very hard to interpret even RFC-non-compliant emails when there is a way to do so.  As I said, the package already tries to interpret headers such as google is generating, it's just that there is a bug in that interpretation: it is keeping the blank between then encoded words when it should not be.  That bug can be fixed, in get_raw_encoded_word and/or get_parameter, in email._header_value_parser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:31:14 2019
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2019 15:31:14 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576337474.83.0.767480084521.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

And you are right that this is a very common bug in email programs.  So common that I suspect the RFC folks will eventually have to accept it as a de-facto standard.  So we do need to support it in the python email library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:38:35 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 14 Dec 2019 15:38:35 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576337915.75.0.372547195357.issue39040@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +maxking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:48:11 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 14 Dec 2019 15:48:11 +0000
Subject: [issue39046] collections.abc.Reversible should not be a subclass of
 Hashable
In-Reply-To: <1576317847.63.0.718393349876.issue39046@roundup.psfhosted.org>
Message-ID: <1576338491.39.0.64195443217.issue39046@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I don't know that this is easily solved. By design, issubclass(X, Hashable) checks whether X defines a __hash__ method (or at least has a class attribute __hash__ that isn't None). And because everything ultimately derives from object, which *does* have a __hash__ method (that just hashes the object's address), everything appears hashable, *except* if it explicitly sets __hash__ = None.

You'll find that many classes defined in collections.abc are hashable (e.g. Iterable, Iterator, Sequence, Collection).

But not Set and Mapping. This is because those override __eq__, and there's some deep magic somewhere that sets __hash__ = None in the class dict if __eq__ is overridden.

You could try the following: add an explicit __hash__ = None to all the collection ABCs (in _collections_abc.py) that you think shouldn't define __hash__, and see if all the tests pass. 

However, even if they do, I suspect that this may break stuff. E.g. a class that inherits from Iterable but doesn't override __hash__ or __eq__ would suddenly no longer be usable as a dict key.

Since this is only a problem with abstract classes like Iterable or Reversible, maybe we should just ignore the problem?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39046>
_______________________________________

From report at bugs.python.org  Sat Dec 14 12:10:08 2019
From: report at bugs.python.org (Attila Jeges)
Date: Sat, 14 Dec 2019 17:10:08 +0000
Subject: [issue39047] TestTemporaryDirectory.test_flags fails on FreeBSD/ZFS
Message-ID: <1576343408.28.0.119673970593.issue39047@roundup.psfhosted.org>


New submission from Attila Jeges <attila.jeges at gmail.com>:

When I run test_tempfle.py on FreeBSD/ZFS I get the following error:

======================================================================
ERROR: test_flags (__main__.TestTemporaryDirectory)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/attilaj/cpython/Lib/test/test_tempfile.py", line 1498, in test_flags
    os.chflags(os.path.join(root, name), flags)
OSError: [Errno 45] Operation not supported: '/tmp/awxj9cgb/dir0/dir0/dir0/test1.txt'

----------------------------------------------------------------------
Ran 90 tests in 1.133s

FAILED (errors=1, skipped=1)

I think this is similar to Issue #15747.

----------
components: Tests
messages: 358398
nosy: attilajeges
priority: normal
severity: normal
status: open
title: TestTemporaryDirectory.test_flags fails on FreeBSD/ZFS
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39047>
_______________________________________

From report at bugs.python.org  Sat Dec 14 12:14:29 2019
From: report at bugs.python.org (Attila Jeges)
Date: Sat, 14 Dec 2019 17:14:29 +0000
Subject: [issue39047] TestTemporaryDirectory.test_flags fails on FreeBSD/ZFS
In-Reply-To: <1576343408.28.0.119673970593.issue39047@roundup.psfhosted.org>
Message-ID: <1576343669.22.0.285310574288.issue39047@roundup.psfhosted.org>


Change by Attila Jeges <attila.jeges at gmail.com>:


----------
keywords: +patch
pull_requests: +17077
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17607

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39047>
_______________________________________

From report at bugs.python.org  Sat Dec 14 13:07:01 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 18:07:01 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576346821.54.0.950796199912.issue39037@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch
pull_requests: +17078
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17608

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Sat Dec 14 13:08:36 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 18:08:36 +0000
Subject: [issue39037] Wrong trial order of __exit__ and __enter__ in the with
 statement
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576346916.01.0.919276196441.issue39037@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

Done @brett.cannon, would you like to review it? https://github.com/python/cpython/pull/17608

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Sat Dec 14 13:16:00 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 18:16:00 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576347360.54.0.325209665738.issue39037@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Wrong trial order of __exit__ and __enter__ in the with statement -> Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Sat Dec 14 13:22:37 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Dec 2019 18:22:37 +0000
Subject: [issue39045] Segmentation of string
In-Reply-To: <1576310084.51.0.108674240792.issue39045@roundup.psfhosted.org>
Message-ID: <1576347757.27.0.580402265329.issue39045@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For the record, this is an easy application of itertools.combinations:

>>> def segment(s, m):
...     for c in itertools.combinations(range(1, len(s)), m-1):
...         yield tuple(s[i:j] for i, j in zip((0,)+c, c+(len(s),)))
... 
>>> list(segment("12345", m=3))
[('1', '2', '345'), ('1', '23', '45'), ('1', '234', '5'), ('12', '3', '45'), ('12', '34', '5'), ('123', '4', '5')]

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39045>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:16:23 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 19:16:23 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576350983.41.0.969696482702.issue38295@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
nosy: +maggyero

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:47:38 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 19:47:38 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1576352858.93.0.936645655923.issue27100@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
pull_requests: +17079
pull_request: https://github.com/python/cpython/pull/17609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:52:06 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 14 Dec 2019 19:52:06 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576353126.1.0.68687677577.issue39035@roundup.psfhosted.org>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

I already diagnosed this in https://mail.python.org/archives/list/python-dev at python.org/message/3Z4FNPEFTFTYDX6RYOQ54UKOVLQAWUEU/:

* https://travis-ci.org/python/cpython/jobs/616384134 looks for `pythonX.Y` but doesn't account for the fact that it could be Pyenv's stub
* https://travis-ci.org/python/cpython/builds/616384157 is trying to use Python version(s) that are not guaranteed to be preinstalled in the VM for all `language:`s.

I could fix this but I need to know what the hard requirements are to pick an optimal configuration.

* Is the (preinstalled only for `language: c`) `clang 7.0.0` required? Would 3.4-4.0 (available from xenial distro) do?
* Is `xenial` required? Would `bionic` do? In bionic, clang 7 is available from distro.
* Which Python version needs to be preinstalled? Tools/ssl/multissltests.py says it's supposed to be compatible with 2.7 and 3.4-3.7. Options are, by decreasing "sum of flexibility+reliability":
  * use 3.5.1 or 2.7.12 from distro
  * hard require `language:python; python: 3.7` (then we cannot use custom `clang`)
  * use another pyenv-preinstalled version (there are also 3.6 and 2.7 that are supposed to be preinstalled but there might be none)

----------
nosy: +__Vano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:56:55 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 14 Dec 2019 19:56:55 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576353415.34.0.585978224582.issue39035@roundup.psfhosted.org>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

> New changeset 94d2c8df1a7657015a2fcdb4c4d43392f91f8348 by Inada Naoki in branch 'master':
bpo-39035: travis: Don't use beta group (GH-17602)

> INADA-san: do you want to close this issue since you pushed changes?

This may actually fix the problem.

`group: beta` is undocumented. It was required long ago once to try out a new feature but I've absolutely no idea what it does (and if it does anything) now. It's quite possible that it can give us some beta unsupported VM image.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:57:59 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 19:57:59 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1576353479.58.0.508418121748.issue27100@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
pull_requests:  -17079

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:58:37 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 19:58:37 +0000
Subject: [issue39048] Reorder the __aenter__ and __aexit__ checks for async
 with
Message-ID: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

Following https://bugs.python.org/issue27100 which did it for the with statement, what was left to do was to reorder the __aenter__ and __aexit__ method checks for the async with statement.

I have opened a PR for this here: https://github.com/python/cpython/pull/17609

----------
components: Interpreter Core
messages: 358403
nosy: brett.cannon, maggyero, rhettinger
priority: normal
pull_requests: 17080
severity: normal
status: open
title: Reorder the __aenter__ and __aexit__ checks for async with
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:58:53 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 19:58:53 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1576353533.58.0.243524937927.issue27100@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
pull_requests: +17081
pull_request: https://github.com/python/cpython/pull/17609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:00:34 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 20:00:34 +0000
Subject: [issue39048] bpo-39048: Reorder the __aenter__ and __aexit__ method
 checks for the async with statement
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1576353634.84.0.255772660847.issue39048@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Reorder the __aenter__ and __aexit__ checks for async with -> bpo-39048: Reorder the __aenter__ and __aexit__ method checks for the async with statement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:00:41 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 20:00:41 +0000
Subject: [issue39048] Reorder the __aenter__ and __aexit__ method checks for
 the async with statement
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1576353641.28.0.0975826711774.issue39048@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: bpo-39048: Reorder the __aenter__ and __aexit__ method checks for the async with statement -> Reorder the __aenter__ and __aexit__ method checks for the async with statement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:02:46 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 14 Dec 2019 20:02:46 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1576353766.19.0.456855767611.issue27100@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@ncoghlan

> Reviewing the discussion, I assume this was left open to cover reordering the __aenter__ and __aexit__ checks for async with, but that can just as easily be handled as a separate issue (which would also be clearer at the NEWS level).

Here it is: https://bugs.python.org/issue39048

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:06:03 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 14 Dec 2019 20:06:03 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576353963.71.0.181636955437.issue39035@roundup.psfhosted.org>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

While we are at it, shall we enable build config validation (https://docs.travis-ci.com/user/build-config-validation)?

It would produce warnings for outdated keys like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:27:23 2019
From: report at bugs.python.org (Andrey)
Date: Sat, 14 Dec 2019 20:27:23 +0000
Subject: [issue39049] Add "elif" to "for_stmt" and "while_stmt"
Message-ID: <1576355243.3.0.84895867469.issue39049@roundup.psfhosted.org>


New submission from Andrey <komissar.off.andrey at gmail.com>:

Add an ability to use "elif" in for statement and while statement besides "else"

Example
Now:
```python3
for i in range(j):
    ...
else:
    if i > 5:
        ...
    else:
        ...
```
Shall be:
```python3
for i in range(j):
    ...
elif i > 5:
    ...
else:
    ...
```

----------
components: Build
messages: 358406
nosy: moff4
priority: normal
severity: normal
status: open
title: Add "elif" to "for_stmt" and "while_stmt"
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39049>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:48:25 2019
From: report at bugs.python.org (Andrey)
Date: Sat, 14 Dec 2019 20:48:25 +0000
Subject: [issue39049] Add "elif" to "for_stmt" and "while_stmt"
In-Reply-To: <1576355243.3.0.84895867469.issue39049@roundup.psfhosted.org>
Message-ID: <1576356505.51.0.0908532007007.issue39049@roundup.psfhosted.org>


Change by Andrey <komissar.off.andrey at gmail.com>:


----------
keywords: +patch
pull_requests: +17082
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17610

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39049>
_______________________________________

From report at bugs.python.org  Sat Dec 14 16:03:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Dec 2019 21:03:31 +0000
Subject: [issue39049] Add "elif" to "for_stmt" and "while_stmt"
In-Reply-To: <1576355243.3.0.84895867469.issue39049@roundup.psfhosted.org>
Message-ID: <1576357411.69.0.416290782752.issue39049@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Changes to the language syntax usually require extensive discussion and a PEP.

To move forward, your next step would be to launch a discussion on the python-ideas newsgroup.  If the idea advances to an approved PEP, this tracker issue can be re-opened.

----------
components: +Interpreter Core -Build
nosy: +rhettinger
resolution:  -> later
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39049>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:01:41 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 14 Dec 2019 22:01:41 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
Message-ID: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

When I click the button, I see a traceback.

Exception in Tkinter callback
Traceback (most recent call last):
  File "/home/lubuntu2/cpython/Lib/tkinter/__init__.py", line 1885, in __call__
    return self.func(*args)
  File "/home/lubuntu2/cpython/Lib/idlelib/configdialog.py", line 212, in help
    view_text(self, title='Help for IDLE preferences',
TypeError: view_text() got an unexpected keyword argument 'text'


It appears that this bug was introduced in bpo-37628 / 3221a63c692.

----------
assignee: terry.reedy
components: IDLE
messages: 358408
nosy: ZackerySpytz, terry.reedy
priority: normal
severity: normal
status: open
title: The "Help" button in IDLE's config dialog does not work
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:06:54 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 14 Dec 2019 22:06:54 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
In-Reply-To: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>
Message-ID: <1576361214.54.0.0682752124069.issue39050@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17083
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17611

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Sat Dec 14 19:28:14 2019
From: report at bugs.python.org (William Dias)
Date: Sun, 15 Dec 2019 00:28:14 +0000
Subject: [issue26227] Windows: socket.gethostbyaddr(name) fails for non-ASCII
 hostname
In-Reply-To: <1453942730.98.0.111965775649.issue26227@psf.upfronthosting.co.za>
Message-ID: <1576369694.67.0.63696318781.issue26227@roundup.psfhosted.org>


William Dias <william.dias at gmail.com> added the comment:

Shouldn't this issue be solved for Python  3.7.5? Or do I have to manually apply the patch?

I have a windows 8.1 x64 PC whose hostname contains special characters. When creating a socket, the gethostbyaddr() method raises a UnicodeDecodeError: 'utf-8' codec can't decode byt 0xe1 in position 1.

Let me know if you need more information.

Thanks

----------
nosy: +williamdias
type:  -> crash
versions: +Python 3.7 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26227>
_______________________________________

From report at bugs.python.org  Sat Dec 14 20:50:50 2019
From: report at bugs.python.org (Philip Rowlands)
Date: Sun, 15 Dec 2019 01:50:50 +0000
Subject: [issue31140] Insufficient error message with incorrect formated
 string literal
In-Reply-To: <1502182558.08.0.700048111188.issue31140@psf.upfronthosting.co.za>
Message-ID: <1576374650.31.0.737182058219.issue31140@roundup.psfhosted.org>


Philip Rowlands <pythonbugs at dimebar.com> added the comment:

Status as of 3.9.0a1:

======
test.py above appears fixed, i.e. reasonable error message.

$ ./python test.py
  File "/home/bob/pybug/Python-3.9.0a1/test.py", line 2
    hello = f"{world)}"
            ^
SyntaxError: f-string: unmatched ')'


======
bpo-31140.py is not as bad a initially reported, but still gives the wrong line number.

$ ./python bpo-31140.py
  File "<fstring>", line 1
    (a>2s)
        ^
SyntaxError: invalid syntax


=======
And my own example which led me to this bug. The syntax error is on line 3, not line 1.

$ cat fruit.py
pass
pass
s = f"{My favourite fruit is {apple}}"

$ ./python -V
Python 3.9.0a1

$ ./python fruit.py
  File "<fstring>", line 1
    (My favourite fruit is {apple})
        ^
SyntaxError: invalid syntax

----------
nosy: +philiprowlands
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31140>
_______________________________________

From report at bugs.python.org  Sat Dec 14 21:13:14 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 02:13:14 +0000
Subject: [issue39051] Python not working on Windows 10
Message-ID: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>


New submission from Rafael Dominiquini <rafaeldominiquini at gmail.com>:

I have Python installed on my computer for a while now and everything worked fine. But today, I can't run it anymore:


    Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
    Python runtime state: core initialized
    ModuleNotFoundError: No module named 'encodings'

    Current thread 0x00007e84 (most recent call first):
    <no Python frame>


I have already tried to download the installer and use the "Repair" option, but even though the installation indicates that everything is fine, the error continue...

Attached is the complete terminal output:

https://pastebin.com/fcFZkUSV
https://pastebin.com/Nx9J4fPu

SO: Windows 10
Python Version: 3.8.0 (64 bits)

Thanks.

----------
components: Windows
messages: 358411
nosy: paul.moore, rafaeldominiquini, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python not working on Windows 10
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 02:19:59 2019
From: report at bugs.python.org (chengyang)
Date: Sun, 15 Dec 2019 07:19:59 +0000
Subject: [issue39052] import error when in python -m pdb debug mode
Message-ID: <1576394399.54.0.25584896953.issue39052@roundup.psfhosted.org>


New submission from chengyang <qingyongyang at sina.com>:

D:\data\mypython\photosort ???

2019/09/08  15:51    <DIR>          .
2019/09/08  15:51    <DIR>          ..
2019/09/08  15:51                88 myfilesort.py
2019/09/08  15:38               220 myhome.py
2019/12/15  10:44               275 mymain_menu.py
2019/08/22  21:24                39 myphotosort.py
2019/09/08  15:51    <DIR>          siproject
2019/09/08  17:16    <DIR>          __pycache__
               4 ???            622 ??
               4 ??? 253,973,061,632 ????

D:\data\mypython\photosort>python -m pdb myhome.py
> d:\data\mypython\photosort\myhome.py(1)<module>()
-> import os
(Pdb) s
> d:\data\mypython\photosort\myhome.py(2)<module>()
-> import re
(Pdb) s
> d:\data\mypython\photosort\myhome.py(3)<module>()
-> import sys
(Pdb) s
> d:\data\mypython\photosort\myhome.py(4)<module>()
-> sys.path.append('d:\data\mypath\photosort')
(Pdb) s
> d:\data\mypython\photosort\myhome.py(5)<module>()
-> import myfilesort
(Pdb) s
--Call--
> <frozen importlib._bootstrap>(978)_find_and_load()
(Pdb)

----------
components: Windows
files: myfilesort.py
messages: 358412
nosy: chengyang, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: import error when in python -m pdb debug mode
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48778/myfilesort.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39052>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:50:47 2019
From: report at bugs.python.org (YoSTEALTH)
Date: Sun, 15 Dec 2019 08:50:47 +0000
Subject: [issue39053] Hide manually raised exception formatting
Message-ID: <1576399847.23.0.606573681326.issue39053@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

class Some_Class:

    def error(self):
        if not getattr(self, 'boo', None):
            raise Exception(f'`class {self.__class__.__name__}:` raised some error!')


something = Some_Class()
something.error()


# This is how Error looks
# -----------------------
Traceback (most recent call last):
  File "/test.py", line 9, in <module>
    something.error()
  File "/test.py", line 5, in error
    raise Exception(f'`class {self.__class__.__name__}:` raised some error!')
Exception: `class Some_Class:` raised some error!


# This is how Error should look
# -----------------------------
Traceback (most recent call last):
  File "/test.py", line 9, in <module>
    something.error()
  File "/test.py", line 5, in error
    raise Exception(...)
Exception: `class Some_Class:` raised some error!


When a developer manually raises an error they want the user/developer debugging the error to see the final, nicely formatted error message itself "Exception: `class Some_Class:` raised some error!" not the ugly formating of the error message itself "raise Exception(f'`class {self.__class__.__name__}:` raised some error!')" which can also lead to confusion, thus it should be hidden as "raise Exception(...)"

It could also be said that "raise Exception(...)" shouldn't even be shown but what raises this error condition "if not getattr(self, 'boo', None):" but this seems more work so i am keeping it simple by saying lets just hide the ugly formatting part.

----------
components: Interpreter Core
messages: 358413
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: Hide manually raised exception formatting
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39053>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:58:50 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 15 Dec 2019 08:58:50 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576400330.45.0.358261371333.issue39051@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

The most common cause of this error is the PYTHONPATH and PYTHONHOME environment variables.

You can see what environment variables are set by the "set" command.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 04:16:39 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 15 Dec 2019 09:16:39 +0000
Subject: [issue39053] Hide manually raised exception formatting
In-Reply-To: <1576399847.23.0.606573681326.issue39053@roundup.psfhosted.org>
Message-ID: <1576401399.86.0.142867585663.issue39053@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

This sounds like it needs at least some discussion on python-ideas. For example, just reading your description I can't imagine what is supposed to happen when an error occurs when producing argument to the exception.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39053>
_______________________________________

From report at bugs.python.org  Sun Dec 15 06:12:47 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 15 Dec 2019 11:12:47 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1576408367.46.0.383025084276.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17084
pull_request: https://github.com/python/cpython/pull/17612

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Sun Dec 15 06:27:27 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 15 Dec 2019 11:27:27 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576409247.01.0.099355858434.issue39037@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@gvanrossum

By the way, is there any particular reason why the ``try`` statement implementation equivalent to the ``with`` statement given in PEP 343 puts the finally clause in an outer ``try`` statement instead of in the inner ``try`` statement? (cf. https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement)

In other words, couldn't we simplify this:

```
mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
exc = True
try:
    try:
        VAR = value  # Only if "as VAR" is present
        BLOCK
    except:
        # The exceptional case is handled here
        exc = False
        if not exit(mgr, *sys.exc_info()):
            raise
        # The exception is swallowed if exit() returns true
finally:
    # The normal and non-local-goto cases are handled here
    if exc:
        exit(mgr, None, None, None)
```

into that?

```
mgr = (EXPR)
exit = type(mgr).__exit__  # Not calling it yet
value = type(mgr).__enter__(mgr)
exc = True
try:
    VAR = value  # Only if "as VAR" is present
    BLOCK
except:
    # The exceptional case is handled here
    exc = False
    if not exit(mgr, *sys.exc_info()):
        raise
    # The exception is swallowed if exit() returns true
finally:
    # The normal and non-local-goto cases are handled here
    if exc:
        exit(mgr, None, None, None)
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Sun Dec 15 06:36:37 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 11:36:37 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576409797.0.0.584114536282.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

* PYTHONHOME = (not set)
* PYTHONPATH = 'C:\Developing\Python;C:\Developing\Python\Scripts;C:\Developing\Python\Lib;C:\Developing\Python\Lib\site-packages;C:\Developing\Python\DLLs;'

-- I try to set the variable 'PYTHONHOME=C:\Developing\Python', but the same error appear!

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:07:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 15 Dec 2019 12:07:24 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576411644.72.0.0171487302631.issue39051@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Where did you install the portion?

What is in the C:\Developing\Python and C:\Developing\Python\Lib?

What happen when you unset both environment variables?

Do you use any antivirus software?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:23:33 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2019 12:23:33 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576412613.12.0.862152173434.issue39037@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It's a matter of historical timing: PEP 343 was written before try/except/finally was allowed, when try/finally and try/except were still distinct statements.

However, PEP 341 was *also* accepted and implemented for Python 2.5, allowing for the modern try/except/finally form: https://docs.python.org/dev/whatsnew/2.5.html#pep-341-unified-try-except-finally

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:25:28 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 15 Dec 2019 12:25:28 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1576412728.24.0.784244895144.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17085
pull_request: https://github.com/python/cpython/pull/17613

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:30:37 2019
From: report at bugs.python.org (Lovi)
Date: Sun, 15 Dec 2019 12:30:37 +0000
Subject: [issue39054] Add an parameter to list.remove()
Message-ID: <1576413037.77.0.199193038416.issue39054@roundup.psfhosted.org>


New submission from Lovi <1668151593 at qq.com>:

I think the list can add a parameter to remove():

remove(value, appear_time=1, /)

The parameter appear_time indicates the number of times the value appears in the list.


I want this effect:

>>> list1 = [1, 2, 3, 2, 1, 2, 1]
>>> list1.remove(2, 2)
>>> list1
[1, 2, 3, 1, 2, 1]
>>> list1.remove(1, 3)
>>> list1
[1, 2, 3, 1, 2]

----------
messages: 358420
nosy: lovi
priority: normal
severity: normal
status: open
title: Add an parameter to list.remove()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39054>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:35:30 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2019 12:35:30 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1576413330.85.0.729003422309.issue36375@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Leaving the relationship between pickle and __name__ alone wasn't an oversight, as folks already rely on that to gracefully transition from single-file modules to multi-file packages without breaking pickle compatibility in either direction. The trick is to do a "from ._submodule import *" in the package's __init__.py (exposing all the names), and then a "__name__ = __package__" in the submodule itself.

Thus the second snippet above, as a way to port code that was specifically relying on the double import to provide pickle compatibility without risking introducing other unintended incompatibility problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:37:34 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 15 Dec 2019 12:37:34 +0000
Subject: [issue39054] Add an parameter to list.remove()
In-Reply-To: <1576413037.77.0.199193038416.issue39054@roundup.psfhosted.org>
Message-ID: <1576413454.24.0.465533491577.issue39054@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Again, please start proposal discussion at python-ideas. Also, it is not sufficient just to post there, you need to engage with the people asking question to justify whatever new feature you're advocating.

----------
components: +Interpreter Core
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39054>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:46:28 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2019 12:46:28 +0000
Subject: [issue37292] _xxsubinterpreters: Can't unpickle objects defined in
 __main__
In-Reply-To: <1560603991.54.0.788079404137.issue37292@roundup.psfhosted.org>
Message-ID: <1576413988.08.0.758808735482.issue37292@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There's a reason multiprocessing in spawn mode jumps through the hoops that it does: it's the only way to get __main__ pickling to work when you're not forking the entire process.

You also don't want to naively re-run __main__ in the subprocess for the same reason multiprocessing doesn't: doing so would also re-run the script parts, not just the class and function definition parts.

So while I don't think it should be implicit the way it is for multiprocessing spawn mode, I do think it would make sense to offer a way to explicitly opt-in to re-running __main__ in a child interpreter as "__si_main__", aliasing the subinterpreter's __main__ module to that, and also aliasing "__si_main__" to "__main__" in the parent interpreter.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37292>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:49:32 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 15 Dec 2019 12:49:32 +0000
Subject: [issue38720] Logging failure with timestamp messages
In-Reply-To: <1573053027.67.0.846988059067.issue38720@roundup.psfhosted.org>
Message-ID: <1576414172.08.0.0186733499189.issue38720@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I'm going to close this pending additional information from the OP.  @xtobes, please reopen if you are able to provide a minimally reproducing example.  Thank you!

----------
nosy: +cheryl.sabella
resolution:  -> works for me
stage:  -> test needed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38720>
_______________________________________

From report at bugs.python.org  Sun Dec 15 07:51:40 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 12:51:40 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576414300.55.0.432368794052.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

"C:\Developing\Python" is where I installed Python, selecting it in the installer. This directory is where the binary 'python.exe' is located!
"C:\Developing\Python\Lib" have the folders:

idlelib
site-packages
test
tkinter
turtledemo

When I unset both variables, the same error occurs:

-----
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'python'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = 'C:\\Developing\\Python\\python.exe'
  sys.base_prefix = ''
  sys.base_exec_prefix = ''
  sys.executable = 'C:\\Developing\\Python\\python.exe'
  sys.prefix = ''
  sys.exec_prefix = ''
  sys.path = [
    'C:\\Developing\\Python\\python38.zip',
    'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\',
    'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\lib-tk',
    'C:\\Developing\\Python\\python-3.8.0.amd64\\DLLs\\',
    'C:\\Developing\\Python',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000060e8 (most recent call first):
<no Python frame>
-----

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:01:54 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 13:01:54 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576414913.9.0.0210055838603.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

There are other Python installations on my computer, embedded in other application installations (GIMP, etc ...), and these seem to be working normally. But they are all older versions of Python...
I haven't tried reinstalling again since I didn't want to have to reinstall all packages I currently have installed using 'pip'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:01:53 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 13:01:53 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576414913.9.0.0210055838603.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

There are other Python installations on my computer, embedded in other application installations (GIMP, etc ...), and these seem to be working normally. But they are all older versions of Python...
I haven't tried reinstalling again since I didn't want to have to reinstall all packages I currently have installed using 'pip'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:01:54 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 15 Dec 2019 13:01:54 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576414914.06.0.77573757076.issue39051@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Many files and directories in the "C:\Developing\Python\Lib" are disappeared.
I don't know why.  But since you tried clean install, I suppose your antivirus killed Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:02:01 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 15 Dec 2019 13:02:01 +0000
Subject: [issue34000] Document when compile returns a code object v. AST
In-Reply-To: <1530287332.99.0.56676864532.issue34000@psf.upfronthosting.co.za>
Message-ID: <1576414921.89.0.513259160075.issue34000@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thank you for the bug report and thank you @BTaskaya for finding the other issue.  I'm closing this as a duplicate of #27119.

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> `compile` doesn't compile into an AST object as specified

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34000>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:05:00 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 13:05:00 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576415100.83.0.894406323734.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

I don't tried clean install! I tried to use the option "Repair" from the installer.
Later I will try to completely uninstall and install from scratch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:06:19 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 13:06:19 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576415179.85.0.657319697028.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

In this folder ("C: \ Developing \ Python \ Lib") there are only the folders I have listed. No other files...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:26:33 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 15 Dec 2019 13:26:33 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576416393.59.0.0946873072198.issue39051@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> * PYTHONPATH = 'C:\Developing\Python;C:\Developing\Python\Scripts;
> C:\Developing\Python\Lib;C:\Developing\Python\Lib\site-packages;
> C:\Developing\Python\DLLs;'

FYI, none of this should set here. For a standard configuration, the installation directory should never be in the PYTHONPATH environment variable -- including the standard library (Lib & DLLs), site-packages, and Scripts.

> I haven't tried reinstalling again since I didn't want to have to 
> reinstall all packages I currently have installed using 'pip'

The existing site-packages and Scripts directories should remain if you reinstall to "C:\Developing\Python". Either way, you don't really have a choice. The installation is broken.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:34:33 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 15 Dec 2019 13:34:33 +0000
Subject: [issue36589] Incorrect error handling in curses.update_lines_cols()
In-Reply-To: <1554923035.79.0.592038232821.issue36589@roundup.psfhosted.org>
Message-ID: <1576416873.22.0.172293731237.issue36589@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/issue36589>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:35:54 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 15 Dec 2019 13:35:54 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1576416954.56.0.152090714946.issue39037@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

Thanks @ncoghlan, it perfectly answered my question on Stack Overflow: https://stackoverflow.com/questions/59322585/what-is-the-exact-try-statement-equivalent-of-the-with-statement-in-python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:40:17 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 15 Dec 2019 13:40:17 +0000
Subject: [issue34215] streams.py:IncompleteReadError is message is unclear
 when expected is None
In-Reply-To: <1532465024.45.0.56676864532.issue34215@psf.upfronthosting.co.za>
Message-ID: <1576417217.08.0.581456411333.issue34215@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +asvetlov, yselivanov
stage:  -> patch review
versions: +Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34215>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:40:54 2019
From: report at bugs.python.org (Paul Moore)
Date: Sun, 15 Dec 2019 13:40:54 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576417254.54.0.629616900855.issue39051@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

> sys.path = [
>    'C:\\Developing\\Python\\python38.zip',
>    'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\',
>    'C:\\Developing\\Python\\python-3.8.0.amd64\\Lib\\lib-tk',
>    'C:\\Developing\\Python\\python-3.8.0.amd64\\DLLs\\',
>    'C:\\Developing\\Python',

The subdirectory python-3.8.0.amd64 in the various paths above should not be present, and would not be in a normal clean Python installation. It appears that somehow your installation has been corrupted.

I would recommend a clean install. if that doesn't work, it's likely that some environment variables or registry paths in your system are set incorrectly (or at least, in ways the standard installation is not expecting).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:41:56 2019
From: report at bugs.python.org (Paul Moore)
Date: Sun, 15 Dec 2019 13:41:56 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576417316.06.0.413474719651.issue39051@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Can you also confirm that the installation of Python was done with the standard Python installer from the python.org website, and is not another distribution (such as Anaconda)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 09:18:00 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2019 14:18:00 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1576419480.05.0.485010194497.issue38021@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 39afa2d3147e4b05a1161cc90dbf09b95072c2bb by Nick Coghlan (Michael Felt) in branch 'master':
bpo-38021: Modify AIX platform_tag so it covers PEP 425 needs (GH-17303)
https://github.com/python/cpython/commit/39afa2d3147e4b05a1161cc90dbf09b95072c2bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Sun Dec 15 09:26:57 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2019 14:26:57 +0000
Subject: [issue38021] Modify AIX platform_tag so it provides PEP425 needs
In-Reply-To: <1567537368.97.0.869605154196.issue38021@roundup.psfhosted.org>
Message-ID: <1576420017.65.0.875534986937.issue38021@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for your patience Michael!

I made some cosmetic changes to the error handling logic that you may want to include in the PyPA patches. (I'd intended to make it so that a malformed build date resulted in the "Unknown" "9898" build date being used, rather than triggering a ValueError on import of the AIX support module, but my except clause was too narrow. A PR to widen it to trap ValueError as well would definitely be acceptable).

For detection of tag variants, counting hyphens has the benefit of being able to distinguish more variants than just two, but checking the final field would indeed work for distinguishing the current two formats.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38021>
_______________________________________

From report at bugs.python.org  Sun Dec 15 10:35:56 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 15 Dec 2019 15:35:56 +0000
Subject: [issue36595] IDLE: Add search to textview.ViewWindow
In-Reply-To: <1554941521.08.0.779423976753.issue36595@roundup.psfhosted.org>
Message-ID: <1576424156.65.0.77201830408.issue36595@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17086
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/17614

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36595>
_______________________________________

From report at bugs.python.org  Sun Dec 15 10:36:59 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 15 Dec 2019 15:36:59 +0000
Subject: [issue36595] IDLE: Add search to textview.ViewWindow
In-Reply-To: <1554941521.08.0.779423976753.issue36595@roundup.psfhosted.org>
Message-ID: <1576424219.85.0.641471224223.issue36595@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I have created a pull request for this issue.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36595>
_______________________________________

From report at bugs.python.org  Sun Dec 15 12:21:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2019 17:21:28 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
Message-ID: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

If validate=True is passed to base64.b64decode(), it should raise a binascii.Error if the input contains any character not from the acceptable alphabet.

But it does not raise if the input ends with a single \n. It raises if the input ends with a multiple \n or with any other whitespace character. Only a single \n is accepted.

This is an implementation artifact. A regular exception ending with $ is used to validate an input. But $ matches not only end of string. It matches also an empty string before the trailing \n.

Similar errors are also occurred in other sites. I'll open separate issues for different cases.

----------
components: Library (Lib)
messages: 358438
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: base64.b64decode() with validate=True does not raise for a trailing \n
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39055>
_______________________________________

From report at bugs.python.org  Sun Dec 15 12:26:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2019 17:26:51 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1576430811.4.0.264368028971.issue39055@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17087
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17616

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39055>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:43:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2019 18:43:33 +0000
Subject: [issue39056] Issues with handling the -W option
Message-ID: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are some issues with handling the -W option:

1. A traceback is printed for some invalid category names.

$ ./python -Wignore::0
'import warnings' failed; traceback:
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 542, in <module>
    _processoptions(sys.warnoptions)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 208, in _processoptions
    _setoption(arg)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 224, in _setoption
    category = _getcategory(category)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 271, in _getcategory
    if not issubclass(cat, Warning):
TypeError: issubclass() arg 1 must be a class

$ ./python -Wignore::0a 
'import warnings' failed; traceback:
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 542, in <module>
    _processoptions(sys.warnoptions)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 208, in _processoptions
    _setoption(arg)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 224, in _setoption
    category = _getcategory(category)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 256, in _getcategory
    cat = eval(category)
  File "<string>", line 1
    0a
     ^
SyntaxError: unexpected EOF while parsing

$ ./python -Wignore::=
'import warnings' failed; traceback:
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 542, in <module>
    _processoptions(sys.warnoptions)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 208, in _processoptions
    _setoption(arg)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 224, in _setoption
    category = _getcategory(category)
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 264, in _getcategory
    m = __import__(module, None, None, [klass])
ValueError: Empty module name

In normal case Python just complains:

$ ./python -Wignore::unknown
Invalid -W option ignored: unknown warning category: 'unknown'

2. For non-ascii warning names Python complains about a module and strips the last character:

$ ./python -Wignore::W?rning
Invalid -W option ignored: invalid module name: 'W?rnin'

3. The re module is always imported is the -W option is used, even if this is not needed.

----------
components: Library (Lib)
messages: 358439
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Issues with handling the -W option
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39056>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:46:53 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 15 Dec 2019 18:46:53 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576435613.17.0.298859440779.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

I'm in favor of a `math.total_ordering` function, but IMHO sorting functions should emit a warning if they contains an unorderable objects.

This can be done easily: I suppose the sorting function checks if the objects of the iterable are minor that another object. And soon or later, this check will be done for all objects in the iterable.

What I propose is simply to add a flag `all_orderables`, true by default.

After the current object a is checked against the object b, if `all_orderables` is true, another check will be performed: `a >= b`?

If this return false, `all_orderables` will be set to false.

At the end of sorting, if `all_orderables` is false, a warning will be emitted.

This way, no old code will break, but developers will be informed of the problem. Because "Errors should never pass silently" :)

----------
nosy: +Marco Sulla

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:52:34 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 15 Dec 2019 18:52:34 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576435954.85.0.679102752378.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Excuse me, a little errata:

> After the current object a is checked against the object b, if `all_orderables` is true [...]

must be change to

> After the current object a is checked against the object b, ***if the check returns false and*** if `all_orderables` is true [...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:07:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2019 19:07:06 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1576436826.9.0.346084846944.issue39056@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17088
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17618

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39056>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:43:12 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Dec 2019 19:43:12 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576438992.86.0.222040565438.issue36095@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> IMHO sorting functions should emit a warning if they contains an unorderable objects

How do you define "unorderable", and how do you propose to detect "unorderable objects" efficiently in practice within the sorting algorithm?

What you propose isn't practical in full generality. The case in which `sorted` can't give a well-defined result is the case where the collection of elements being sorted, under the given ordering, is not a total preorder. Being a total preorder is a property of the whole collection being sorted, not of individual objects: it's not necessarily true that if the collection is not totally preordered then there's any one item you can point to as being "unorderable".

Checking for a total preorder is much more expensive than simply sorting (at best it would be a quadratic time post-sort check), so that's not a reasonable check to make.

So by checking for unorderable objects, whatever those are, you're only solving a small part of the overall problem, at the expense of extra computation. You're also likely breaking the existing guarantees (depending on how you do this checking) that `sort` and `sorted` only rely on `<` comparisons; that would be a backwards compatibility break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:44:35 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Dec 2019 19:44:35 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576439075.98.0.534789634025.issue36095@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tim, Raymond: I propose that we close this issue as "won't fix". The suggestion to add `math.total_ordering` could be broken out into a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:45:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2019 19:45:57 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
Message-ID: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There are several issues with urllib.request.proxy_bypass_environment:

1. Leading dots are ignored in the proxy list, but not in the checked hostname. So ".localhost" does not matches ".localhost" in the proxy list.

2. A single trailing \n in the checked hostname is ignored, so "localhost\n" passes the check if the proxy list contains "localhost". But "localhost\n\n" and "localhost " do not pass. This is an artifact of using $ in the regular expression.

----------
components: Library (Lib)
messages: 358444
nosy: orsenthil, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Issues with urllib.request.proxy_bypass_environment
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39057>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:49:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2019 19:49:37 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1576439377.12.0.124058277235.issue39057@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17089
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17619

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39057>
_______________________________________

From report at bugs.python.org  Sun Dec 15 15:20:51 2019
From: report at bugs.python.org (Tim Peters)
Date: Sun, 15 Dec 2019 20:20:51 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576441251.56.0.820517922298.issue36095@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Closing as Mark suggested, but as "not a bug" rather than "won't fix".  That floats aren't totally ordered is a consequence of IEEE 754 semantics, not Python's whim.  As Mark said, if people want a total_ordering function for floats, that should be opened as a different issue - we're not going to change the default float comparison logic.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 15:56:43 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 20:56:43 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576443403.75.0.0944098168955.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

1) I tried to clear the value of the variable 'PYTHONPATH', and the error keeps happening!
2) In my installation directory, I don't have the file 'C:\Developing\Python\python38.zip', neither the directory 'C:\Developing\Python\python-3.8.0.amd64\'. I don't know why this message appears!
3) I use the installer from python.org (https://www.python.org/downloads/release/python-380/), but I got the 64-bit installer!

I will try to do a clear install later.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:36:44 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 15 Dec 2019 21:36:44 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576445804.77.0.308598630616.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Excuse me, but have you, Dickinson and Peters, read how I propose to check if the object is orderable or not? 

I explained it in a very detailed way, and this does not change the float comparison. And does not need to check first if the iterable it totally preordered.

Can you please read my post?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:46:37 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 21:46:37 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576446397.42.0.719454881257.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

I reinstall python here from scratch and now is working. But I need to delete the remaining files after the uninstall. When I tried to uninstall and reinstall holding the existing directories (\Lib\site-packages), the installer fail to copy the missing files to the installation directory.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:50:07 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 21:50:07 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576446607.83.0.241541100166.issue39051@roundup.psfhosted.org>


Change by Rafael Dominiquini <rafaeldominiquini at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:51:49 2019
From: report at bugs.python.org (Rafael Dominiquini)
Date: Sun, 15 Dec 2019 21:51:49 +0000
Subject: [issue39051] Python not working on Windows 10
In-Reply-To: <1576375994.78.0.555277558727.issue39051@roundup.psfhosted.org>
Message-ID: <1576446709.35.0.0626327732704.issue39051@roundup.psfhosted.org>


Rafael Dominiquini <rafaeldominiquini at gmail.com> added the comment:

I probably unintentionally deleted some necessary files here on my machine. I closed the issue and marked 'not a bug'.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39051>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:55:04 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 15 Dec 2019 21:55:04 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576446904.95.0.651206131285.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Anyway, Java by default puts NaNs at the end of the iterable:

https://onlinegdb.com/SJjuiXE0S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:56:37 2019
From: report at bugs.python.org (Tim Peters)
Date: Sun, 15 Dec 2019 21:56:37 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576446997.51.0.987631619812.issue36095@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Marco, your

> I suppose the sorting function checks if the objects of
> the iterable are minor that another object

was incoherent to me.  No idea what "are minor that another object" could possibly mean.

As Mark explained, the mathematical meaning of "orderable" is more expensive to check than it is to do sorting.

Mark also explained that list.sort() guarantees to use only "<" (__lt__) comparisons.  Because your message was incoherent to me (see above), I don't know what purpose would be served by checking ">=" too, but if there _is_ a coherent purpose, list.sort() cannot use ">=" regardless.

Reply to Mark's message instead of this one?  You haven't addressed any of the points he raised, and they're all deal-breakers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:00:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Dec 2019 22:00:42 +0000
Subject: [issue38629] float is missing __ceil__() and __floor__(),
 required by numbers.Real
In-Reply-To: <1572344297.94.0.916739375163.issue38629@roundup.psfhosted.org>
Message-ID: <1576447242.1.0.975528624776.issue38629@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset cb8b946ac10386e6cab1376945f64f683b5b16d3 by Victor Stinner (Batuhan Ta?kaya) in branch 'master':
bpo-38629: implement __floor__ and __ceil__ for float type (GH-16985)
https://github.com/python/cpython/commit/cb8b946ac10386e6cab1376945f64f683b5b16d3


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38629>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:01:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Dec 2019 22:01:27 +0000
Subject: [issue38629] float is missing __ceil__() and __floor__(),
 required by numbers.Real
In-Reply-To: <1572344297.94.0.916739375163.issue38629@roundup.psfhosted.org>
Message-ID: <1576447287.79.0.392451472817.issue38629@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Batuhan Ta?kaya for the implementation, and thanks Ran Benita for the feature request :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38629>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:02:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Dec 2019 22:02:50 +0000
Subject: [issue38316] docs: Code object's "co_stacksize" field is described
 with mistake
In-Reply-To: <1569789294.48.0.284805020981.issue38316@roundup.psfhosted.org>
Message-ID: <1576447370.96.0.15126323045.issue38316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d587272fe3b0fcad2f23a490e76f9f82ca7d64ef by Victor Stinner (Batuhan Ta?kaya) in branch 'master':
 bpo-38316: Fix co_stacksize documentation (GH-16983)
https://github.com/python/cpython/commit/d587272fe3b0fcad2f23a490e76f9f82ca7d64ef


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38316>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:16:04 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Dec 2019 22:16:04 +0000
Subject: [issue39058] argparse should preserve argument ordering in Namespace
Message-ID: <1576448164.39.0.171350779582.issue39058@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently, Namespace() objects sort the attributes in the __repr__.  This is annoying because argument order matters and because everywhere else in the module we preserve order (i.e. users see help in the order that arguments are added).

Note, the docs do not promise that Namespace is displayed with a sort.  This is likely just an artifact of older dictionaries having arbitrary or randomised ordering.


>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> _ = parser.add_argument('source')
>>> _ = parser.add_argument('destination')

# Order matters to the user inputing the arguments 
# (source must go first and destination must go last
>>> args = parser.parse_args(['input.txt', 'output.txt'])

# Order is preserved internally
>>> vars(args)
{'source': 'input.txt', 'destination': 'output.txt'}

# Despite this, the Namespace() repr alphabetizes the output
>>> args
Namespace(destination='output.txt', source='input.txt')

# Order is preserved in help()
>>> parser.parse_args(['-h'])       
usage: [-h] source destination

positional arguments:
  source
  destination

optional arguments:
  -h, --help   show this help message and exit

----------
components: Library (Lib)
messages: 358455
nosy: rhettinger
priority: normal
severity: normal
status: open
title: argparse should preserve argument ordering in Namespace
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39058>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:19:59 2019
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 15 Dec 2019 22:19:59 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576448399.33.0.588870477753.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> No idea what "are minor that another object" could possibly mean.

Oh my god... a < b?

> I don't know what purpose would be served by checking ">=" too

Well, it's very simple. Since the sorting algorithm checks if a < b, if this check fails, I propose to check also a >= b. If this is false too, the iterable contains an unorderable object. From this point, the check will never done again, an unorderable object is sufficient to raise the warning.

The check a >= b is *not* for ordering the iterable, is only for checking if the elements are orderable or not, and raise the warning.

Furthermore, I suppose that if someone is sure that its iterable is unorderable-free and want a fine-grained boost to speed, a flag can added. If true, sorting will not use the algorithm with the check, but the old algorithm.

> You haven't addressed any of the points he (Dickinson) raised

Dickinson said you have to check for total preorder. If you have understood my idea, this is not needed at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:37:42 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 Dec 2019 22:37:42 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1576449462.79.0.187504385332.issue37193@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Another workaround might be to set the new "block_on_close" flag (Issue 33540) to False on the server subclass or instance.

Victor: Replying to <https://bugs.python.org/issue37193#msg345817> "What do I think of also using a weakref?", I assume you mean maintaining "_threads" as a WeakSet rather than a list object. That seems a nice way to solve the problem, but it seems redundant to me if other code such as Maru's proposal was also added to clean up the list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:05:17 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 15 Dec 2019 23:05:17 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576451117.83.0.57499192497.issue39040@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

I tried to take a look at the code to see where the fix needs to be and I probably need some help.

I looked at the parse tree for the header and it looks something like this:

ContentDisposition([Token([ValueTerminal('attachment')]), ValueTerminal(';'), MimeParameters([Parameter([Attribute([CFWSList([WhiteSpaceTerminal(' ')]), ValueTerminal('filename')]), ValueTerminal('='), Value([QuotedString([BareQuotedString([EncodedWord([ValueTerminal('Schulbesuchsbest?ttigung.')]), WhiteSpaceTerminal('    '), EncodedWord([ValueTerminal('pdf')])])])])])])])


The offending piece of code, which seems to be working as designed is get_bare_quoted_string() in email/_header_value_parser.py. 

    while value and value[0] != '"':
        if value[0] in WSP:
            token, value = get_fws(value)
        elif value[:2] == '=?':
            try:
                token, value = get_encoded_word(value)
                bare_quoted_string.defects.append(errors.InvalidHeaderDefect(
                    "encoded word inside quoted string"))
            except errors.HeaderParseError:
                token, value = get_qcontent(value)
        else:
            token, value = get_qcontent(value)
        bare_quoted_string.append(token)

It just loops and parses the values. We cannot ignore the FWS until we know that the atom before and after the FWS are encoded words. I can't seem to find a clean way to look-ahead (which can perhaps be used in get_parameters()) or look-back (which can be used after parsing the entire bare_quoted_string?) in the parse tree to delete the offending whitespace. 

Any example of such kind of parse-tree manipulation in the code base would be awesome!

----------
versions: +Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:34:18 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2019 23:34:18 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576452858.54.0.11997283376.issue39033@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 79f02fee1a542c440fd906fd54154c73fc0f8235 by Nick Coghlan (Xtreak) in branch 'master':
bpo-39033: Fix NameError in zipimport during hash validation (GH-17588)
https://github.com/python/cpython/commit/79f02fee1a542c440fd906fd54154c73fc0f8235


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Sun Dec 15 20:33:18 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Dec 2019 01:33:18 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576459998.08.0.173206342197.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The example you want to look at is get_unstructured.  That shows both lookback and modification of the parse tree to handle the whitespace between encoded words.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:20:00 2019
From: report at bugs.python.org (Yoong Hor Meng)
Date: Mon, 16 Dec 2019 02:20:00 +0000
Subject: [issue23041] csv needs more quoting rules
In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za>
Message-ID: <1576462800.75.0.926241585556.issue23041@roundup.psfhosted.org>


Yoong Hor Meng <yoonghm at gmail.com> added the comment:

There is a real requirement for csv to handle an empty field vs a empty string """".  csv.QUOTE_NOTNULL could be useful.

----------
nosy: +yoonghm
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23041>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:23:08 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 16 Dec 2019 02:23:08 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576462988.01.0.305726413692.issue36095@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Ah, so you're proposing a hack that would catch some, but not all, cases where a total ordering doesn't exist.  Why?  The issue tracker isn't a suitable place to discuss it regardless, so if you want to pursue it I'd suggest taking it to python-ideas.  If you do, some points to think about in advance:

- As above, it only catches some cases.  For example, given list [a, b], where a < b and b < a, no total ordering exists but the hack won't detect anything amiss.

- As has been said twice already, list.sort() promises to use only "<".  This isn't disposable.  User-written classes _rely_ on it, which was the point:  for instances to participate in sorting, the class only needs to define __lt__ (and, although it's not currently documented, they can also participate in the `bisect` and `heapq` module facilities, which also restrict themselves to "<" compares).

- Assuming "a < b" is false about half the time, the hack would require sorting to do about 50% more comparisons.  That's a huge expense.  All in all, I've spent at least a year of my life minimizing the number of compares Python's sort needs to do, and that would more than wipe out all the progress I've made since 1991 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:51:30 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Mon, 16 Dec 2019 02:51:30 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576464690.84.0.860543773374.issue39040@roundup.psfhosted.org>


Change by Abhilash Raj <raj.abhilash1 at gmail.com>:


----------
pull_requests: +17090
pull_request: https://github.com/python/cpython/pull/17620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:53:25 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Mon, 16 Dec 2019 02:53:25 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576464805.04.0.299010537819.issue39040@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Thanks for the pointer, David! I created a PR for the fix, would you be able to review it please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Sun Dec 15 22:23:11 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Dec 2019 03:23:11 +0000
Subject: [issue39058] argparse should preserve argument ordering in Namespace
In-Reply-To: <1576448164.39.0.171350779582.issue39058@roundup.psfhosted.org>
Message-ID: <1576466591.94.0.12347270454.issue39058@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +17091
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17621

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39058>
_______________________________________

From report at bugs.python.org  Mon Dec 16 00:17:23 2019
From: report at bugs.python.org (Marco Sulla)
Date: Mon, 16 Dec 2019 05:17:23 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576473443.12.0.635199233863.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Excuse me, I had an epiphany.

NaN returns False for every comparison.

So in teory any element of the iterable should result minor that NaN.

So NaN should treated as the highest element, and should be at the end of the sorted result!

Indeed this is the behavior in Java. NaNs are in the end of the sorted iterator.

On the contrary, Python sorting does not move the NaN from its position.

Why?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Mon Dec 16 00:26:46 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 16 Dec 2019 05:26:46 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1576474006.51.0.759408860272.issue36095@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Sorry, but I'm not replying here any more:  the issue tracker is not for asking questions or brainstorming ideas.  Take this to python-ideas, please.  If a concrete proposal that gains traction results, _then_ the issue tracker may be an appropriate place (but a new issue - this issue is closed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Mon Dec 16 00:31:24 2019
From: report at bugs.python.org (Richard Warfield)
Date: Mon, 16 Dec 2019 05:31:24 +0000
Subject: [issue38904] "signal only works in main thread" in main thread
In-Reply-To: <1576275914.67.0.946957959481.issue38904@roundup.psfhosted.org>
Message-ID: <CAJLv-k_Y3_7Jd7yoXYY8nZsyW2CoPO5V0g_8GhzAJ+ELw8yi7g@mail.gmail.com>


Richard Warfield <warfield at gmail.com> added the comment:

Thanks for looking into this.  Changing the behavior of the
"threading" module to be consistent with the runtime and "signal" module
would be sufficient, at least for my particular case.  If the "if
threading.current_thread() is threading.main_thread()" guard worked as
expected it would be clear how to resolve the problem.

On Sat, Dec 14, 2019 at 6:25 AM Eric Snow <report at bugs.python.org> wrote:

>
> Eric Snow <ericsnowcurrently at gmail.com> added the comment:
>
> Before 3.8, the "signal" module checked against the thread in which the
> module was initially loaded, treating that thread as the "main" thread.
> That same was true (and still is) for the "threading" module.  The problem
> for both modules is that the Python runtime may have actually been
> initialized in a different thread, which is the actual "main" thread.
>
> Since Python 3.8 we store the ID of the thread where the runtime is
> initialized and use that in the check the "signal" module does.  However,
> the "threading" module still uses the ID of the thread where it is first
> imported.  So your check against "threading.main_thread()" must be in code
> that isn't running in the same thread where you ran Py_Initialize().  It
> probably used to work because you imported "signal" and "threading" for the
> first time in the same thread.
>
> So what next?
>
> First, I've created issue39042 to address the current different meanings
> of "main thread".  That should resolve the discrepancy between the signal
> and threading modules.
>
> Second, what can we do to help embedders make sure they are running their
> code in the main thread (e.g. when setting signals)?  Is there any C-API we
> could add which would have helped you here?
>
> ----------
> nosy: +eric.snow, vstinner
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38904>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38904>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:13:16 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 16 Dec 2019 07:13:16 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576480396.73.0.649821574467.issue39035@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17092
pull_request: https://github.com/python/cpython/pull/17622

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:31:11 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 16 Dec 2019 07:31:11 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576481471.77.0.852581894938.issue39035@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17093
pull_request: https://github.com/python/cpython/pull/17623

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Mon Dec 16 03:50:51 2019
From: report at bugs.python.org (AVicennA)
Date: Mon, 16 Dec 2019 08:50:51 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
Message-ID: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>


New submission from AVicennA <tural.jalilov.92 at gmail.com>:

This is about rounding process and getting incorrect results. In documentation written
that, "This is not a bug: it?s a result of the fact that most decimal fractions can?t be 
represented exactly as a float". - https://docs.python.org/3/library/functions.html?highlight=round#round
It is also related with hardware. I wrote some code parts that shows it and used decimal value
as in documentation sample:

''' 2.675(4) - (4) or (3) or (2) etc. I have given range 2, and the result is influenced not 
    just by one number after those 2 ranges, but also the another number consistently. '''

>>> round(2.675, 2)
2.67
>>>
>>> round(5.765, 2)
5.76
>>>
>>> round(2.6754, 2)
2.68
>>>
>>> round(5.7652, 2)
5.77

''' "format" is also not working properly. Gives incorrect results. '''

>>> format(2.675, ".2f")  
'2.67'
>>>
>>> format(2.678, ".2f")
'2.68'
>>>
>>> '{:0.2f}'.format(2.675)
'2.67'
>>>
>>> '{:0.2f}'.format(2.678)
'2.68'

''' Because, when the decimal string is converted to a binary floating-point number, it's 
    again replaced with a binary approximation:

    Whose exact value is 5.765 --> 5.76499999999999968025576890795491635799407958984375
                                                 &&
                         2.675 --> 2.67499999999999982236431605997495353221893310546875

    It means that, the 76(5) --> 5 replaced in a memory as 4.(999999999999)
                                                 &&
                       67(5) --> 5 replaced in a memory as 4.(999999999999) '''

>>> from decimal import Decimal
>>> Decimal(2.675)
Decimal('2.67499999999999982236431605997495353221893310546875')
>>>
>>> Decimal(5.765)
Decimal('5.76499999999999968025576890795491635799407958984375')

''' Used float point precision(FPU) with math lib to apply a certain correct form. 
    I propose to use some tricks. But again incorrect result in third sample: '''

>>> import math
>>> math.ceil(2.675 * 100) / 100
2.68
>>>
>>> print("%.2f" % (math.ceil(2.675 * 100) / 100))
2.68
>>> math.ceil(2.673 * 100) / 100
2.68

''' The most correct form is using by round: '''

>>> round(2.675 * 100) / 100
2.68
>>>
>>> round(2.673 * 100) / 100
2.67
>>> round(2.674 * 100) / 100
2.67
>>> round(2.676 * 100) / 100
2.68

''' In this case, whatever the range the full right result is a return.
    Mostly can be using in fraction side correctness. '''

>>> def my_round(val, n):
...     return round(val * 10 ** n) / 10 ** n
...
>>> my_round(2.675, 2)
2.68
>>>
>>> my_round(2.676, 2)
2.68
>>>
>>> my_round(2.674, 2)
2.67
>>>
>>> my_round(2.673, 2)
2.67
>>>
>>> my_round(2.674, 3)
2.674
>>>
>>> my_round(55.37678, 3)
55.377
>>>
>>> my_round(55.37678, 2)
55.38
>>>
>>> my_round(55.37478, 2)
55.37
>>>
>>> my_round(224.562563, 2)
224.56
>>>
>>> my_round(224.562563, 3)
224.563
>>>
>>> my_round(224.562563, 4)
224.5626
>>>
>>> my_round(224.562563, 5)
224.56256
>>>
>>> my_round(224.562563, 7)
224.562563
>>>
>>> my_round(224.562563, 11)
224.562563

''' my_round - function tested on Windows and Linux platforms(x64). This can be added in Python
    next releases to solve this problem which related with the IEEE 754 and PEP 754 problems. '''

----------
assignee: docs at python
components: Documentation, FreeBSD, IDLE, Interpreter Core, Library (Lib), Tests, Windows, macOS
messages: 358467
nosy: AVicennA, docs at python, koobs, ned.deily, paul.moore, ronaldoussoren, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Getting incorrect results in rounding procedures
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 04:51:58 2019
From: report at bugs.python.org (Amit Itzkovitch)
Date: Mon, 16 Dec 2019 09:51:58 +0000
Subject: [issue39060] asyncio.Task.print_stack doesn't print the full stack
Message-ID: <1576489918.95.0.196774987509.issue39060@roundup.psfhosted.org>


New submission from Amit Itzkovitch <amit7itz at gmail.com>:

Hi!
I think I found some issue in the "print_stack()" function of asyncio.Task.
When I try to print the stack of some task, I only see the first few lines of the stack. 
Attached an example file, that contains a recursive function that after 10 calls prints the stack of the task. 
You can see that the stack that it prints only shows the first call of the recursive function, although you would expect to see it 10 times.

Tested on python3.7 and 3.8 on both MacOS and CentOS, the result is the same. 

Your help will be appreciated very much! :)

----------
components: asyncio
files: example.py
messages: 358468
nosy: amit7itz, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Task.print_stack doesn't print the full stack
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48779/example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39060>
_______________________________________

From report at bugs.python.org  Mon Dec 16 05:01:35 2019
From: report at bugs.python.org (Maxime Istasse)
Date: Mon, 16 Dec 2019 10:01:35 +0000
Subject: [issue39061] Garbage Collection optimizations cause "memory leak"
Message-ID: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>


New submission from Maxime Istasse <istassem at gmail.com>:

When working on a self-referencing object in the young generation and the middle-generation collection kicks in, that object is directly moved to the old generation. (if I understood this well: https://github.com/python/cpython/blob/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113/Modules/gcmodule.c#L1192)
Then, it won't be freed until the old generation is collected, which happens to be much later. (because of this: https://github.com/python/cpython/blob/d68b592dd67cb87c4fa862a8d3b3fd0a7d05e113/Modules/gcmodule.c#L1388)

It happens to cause huge memory leaks if the self-referencing objects occupies a lot of RAM, which should be expected.

This is of course the kind of problem that I expect with garbage collection with bad parameters.

However, I also expected that playing with threshold0 could have been sufficient to solve it. However, the fact that we move the object to old generation every time the middle collection pops in forces the problem to happen once in a while, and in the end reaching very high memory consumption.

I think the best and simplest solution would be to move the objects one generation at a time. This would avoid the heavy but short-lived objects to make it to the old generation.

----------
components: Interpreter Core
files: late_gc.py
messages: 358469
nosy: mistasse
priority: normal
severity: normal
status: open
title: Garbage Collection optimizations cause "memory leak"
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file48780/late_gc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________

From report at bugs.python.org  Mon Dec 16 05:02:04 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 16 Dec 2019 10:02:04 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576490523.98.0.649730765595.issue39059@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You've spent a lot of time demonstrating behaviour, but have not given us any reason why you think the results given are wrong.

As far as I can tell, every single example you show is correct. You have even quoted one of the relevant sections from the docs. "This is not a bug..."

You've flagged this is a documentation bug, an IDLE bug, an interpreter core bug, a library bug, etc. It isn't all of those things! I don't know what you actually want: do you want to improve the documentation? Something else?

By the way, your function "my_round" is buggy. This is wrong:

my_round(2.675, 2)
2.68

The binary float 2.675 is exactly equal to 3011782250804019/1125899906842624, or in decimal, exactly 

2.67499999999999982236431605997495353221893310546875

Rounding to two decimal places is 2.67, not 2.68.

Can you explain why we shouldn't close this as Not A Bug?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 05:11:16 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Dec 2019 10:11:16 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576491076.44.0.19545964491.issue39059@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@AVicennA: as the docs you linked to explain, this is not a bug: `round` is giving the correct result in all cases (or at least, as correct as is possible given the use of binary floating-point).

Let's take just the first case, `round(2.675, 2)`. `2.675` is a numeric literal in the source that's converted to a Python object of type `float` whose value is stored[*] using the IEEE 754 binary64 format. The exact value of that object is then 2.67499999999999982236431605997495353221893310546875.

So the value that Python sees when rounding is *less* than the halfway case 2.675, so it rounds down to 2.67. If you think that's not the right thing to do, I have a question for you: what result would you expect `round(2.6749999999999998, 2)` to give?

Your proposed my_round replacement is not a fix: unlike *round*, it does *not* do correct rounding in all cases, and does not always give the naively expected result in all cases either. To give just one example of many:

    >>> my_round(4.395, 2)
    4.39

So I don't really understand what action you're proposing here. `round` is as good as it can reasonably be, and the documentation already explains the weaknesses and links to further reading. Unless you're proposing that Python adopt decimal floating-point for its core float type, or that two-argument round be deprecated, there not really anything to be done here.

[*] Disclaimer: use of IEEE 754 is not guaranteed, but is overwhelmingly likely on common platforms.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 05:12:03 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Dec 2019 10:12:03 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576491123.41.0.34517945213.issue39059@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 05:43:36 2019
From: report at bugs.python.org (jvoisin)
Date: Mon, 16 Dec 2019 10:43:36 +0000
Subject: [issue39062] ValueError in TarFile.getmembers
Message-ID: <1576493016.16.0.2184811666.issue39062@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file produces the following stacktrace when opened via `tarfile.open`  and iterated with `TarFile.getmembers`, on Python 3.7.5rc1:

```
$ cat tarrepro.py
import tarfile
import sys

with tarfile.open(sys.argv[1]) as t:
  for member in t.getmembers():
    pass
```

```
$ python3 tarrepro.py crash-7221297307ab37ac87be6ea6dd9b28d4d453c557aa3da8a2138ab98e015cd42a
Traceback (most recent call last):
  File "tarrepro.py", line 5, in <module>
    for member in t.getmembers():
  File "/usr/lib/python3.7/tarfile.py", line 1763, in getmembers
    self._load()        # all members, we first have to
  File "/usr/lib/python3.7/tarfile.py", line 2350, in _load
    tarinfo = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2281, in next
    self.fileobj.seek(self.offset - 1)
ValueError: cannot fit 'int' into an offset-sized integer
```

This file isn't a valid tar file, it was created by a fuzzer.

----------
components: Library (Lib)
files: crash-7221297307ab37ac87be6ea6dd9b28d4d453c557aa3da8a2138ab98e015cd42a
messages: 358472
nosy: jvoisin
priority: normal
severity: normal
status: open
title: ValueError in TarFile.getmembers
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48781/crash-7221297307ab37ac87be6ea6dd9b28d4d453c557aa3da8a2138ab98e015cd42a

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39062>
_______________________________________

From report at bugs.python.org  Mon Dec 16 06:37:52 2019
From: report at bugs.python.org (AVicennA)
Date: Mon, 16 Dec 2019 11:37:52 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576496272.24.0.752096295983.issue39059@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

@steven.daprano, yes, my_round(2.675, 2) --> gave 2.68 and it's not buggy and not wrong. This is correct in this case. I advise you look at 5th class math book.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 06:38:21 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 16 Dec 2019 11:38:21 +0000
Subject: [issue39060] asyncio.Task.print_stack doesn't print the full stack
In-Reply-To: <1576489918.95.0.196774987509.issue39060@roundup.psfhosted.org>
Message-ID: <1576496301.49.0.997883499318.issue39060@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Technically the output is correct: a stack for async function call doesn't contain the outer async function that is used for awaiting.

Agree, it may sound confusing, but `await f()` is not the same as just `f()`.

Perhaps we can provide *alternative* API for retrieving async call stack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39060>
_______________________________________

From report at bugs.python.org  Mon Dec 16 06:56:05 2019
From: report at bugs.python.org (Amit Itzkovitch)
Date: Mon, 16 Dec 2019 11:56:05 +0000
Subject: [issue39060] asyncio.Task.print_stack doesn't print the full stack
In-Reply-To: <1576489918.95.0.196774987509.issue39060@roundup.psfhosted.org>
Message-ID: <1576497365.99.0.510286658566.issue39060@roundup.psfhosted.org>


Amit Itzkovitch <amit7itz at gmail.com> added the comment:

In is mainly confusing because I expected this function to behave like "traceback.print_stack()", which prints the stack including all the awaits that lead to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39060>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:24:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 12:24:00 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1576499040.16.0.913004005312.issue38811@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 092435e932dee1802784ec28f39454f50fdd879a by Victor Stinner (Toke H?iland-J?rgensen) in branch 'master':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/092435e932dee1802784ec28f39454f50fdd879a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:24:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 12:24:00 +0000
Subject: [issue26978] Implement pathlib.Path.link (Using os.link)
In-Reply-To: <1556420459.86.0.258434208738.issue26978@roundup.psfhosted.org>
Message-ID: <1576499040.04.0.998314677044.issue26978@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 092435e932dee1802784ec28f39454f50fdd879a by Victor Stinner (Toke H?iland-J?rgensen) in branch 'master':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/092435e932dee1802784ec28f39454f50fdd879a


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26978>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:24:41 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 16 Dec 2019 12:24:41 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1576499081.69.0.112296893436.issue38811@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17094
pull_request: https://github.com/python/cpython/pull/17626

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:24:41 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 16 Dec 2019 12:24:41 +0000
Subject: [issue26978] Implement pathlib.Path.link (Using os.link)
In-Reply-To: <1556420459.86.0.258434208738.issue26978@roundup.psfhosted.org>
Message-ID: <1576499081.78.0.480908613663.issue26978@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17095
pull_request: https://github.com/python/cpython/pull/17626

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26978>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:27:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 12:27:03 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1576499223.04.0.292239865788.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset a322f50c369e2e4138266c88e32ef83af95b2da6 by Pablo Galindo (Batuhan Ta?kaya) in branch 'master':
bpo-38870: Remove dead code related with argument unparsing (GH-17613)
https://github.com/python/cpython/commit/a322f50c369e2e4138266c88e32ef83af95b2da6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:27:44 2019
From: report at bugs.python.org (Ramon Medeiros)
Date: Mon, 16 Dec 2019 12:27:44 +0000
Subject: [issue39063] Format string does not work with "in" statement
Message-ID: <1576499264.15.0.522320667153.issue39063@roundup.psfhosted.org>


New submission from Ramon  Medeiros <ramon.rnm at gmail.com>:

Tried to use "in" statement to check if a string exists in a array and failed using string format.

How to reproduce:

~/ ipython
Python 3.7.4 (default, Oct 12 2019, 18:55:28)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.8.0 -- An enhanced Interactive Python. Type '?' for help.

In [2]: "a" in ["a", "b"]
Out[2]: True

In [4]: z = "a"

In [5]: f"{z}" in ["a", "b"]
Out[5]: True

In [6]: z = "b"

In [7]: f"{z}" in ["a", "b"]
Out[7]: True

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 358479
nosy: ramon.rnm at gmail.com
priority: normal
severity: normal
status: open
title: Format string does not work with "in" statement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39063>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:28:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 12:28:38 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1576499318.37.0.806759190193.issue38811@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Toke H?iland-J?rgensen! I merged your fix.

I don't really get why the Debian/Ubuntu image on Travis CI didn't get os.link() function, but I'm not really intersted to dig into this question. It's fine to simply skip the feature if it's not available, we do that in many places in Python.

I asked Toke H?iland-J?rgensen to revert his changes about os.symlink(): the pathlib code to handle missing os.symlink() seems to be broken, but it also seems like Python no longer support platforms without os.symlink(). Only old Windows version didn't support os.symlink(), but Python don't support these versions anymore.

I merged the os.link() change into master and made a 3.8 backport which will be merged automatically soon.

I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:30:32 2019
From: report at bugs.python.org (Ramon Medeiros)
Date: Mon, 16 Dec 2019 12:30:32 +0000
Subject: [issue39063] Format string does not work with "in" statement
In-Reply-To: <1576499264.15.0.522320667153.issue39063@roundup.psfhosted.org>
Message-ID: <1576499432.31.0.636930838032.issue39063@roundup.psfhosted.org>


Change by Ramon  Medeiros <ramon.rnm at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39063>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:39:53 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Dec 2019 12:39:53 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1576499993.47.0.364711727523.issue38993@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:42:24 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 16 Dec 2019 12:42:24 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1576500144.91.0.344661657566.issue38811@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8d0f36940e728989822c3789025b0813a8fe249a by Miss Islington (bot) in branch '3.8':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/8d0f36940e728989822c3789025b0813a8fe249a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:42:24 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 16 Dec 2019 12:42:24 +0000
Subject: [issue26978] Implement pathlib.Path.link (Using os.link)
In-Reply-To: <1556420459.86.0.258434208738.issue26978@roundup.psfhosted.org>
Message-ID: <1576500144.72.0.736098007706.issue26978@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8d0f36940e728989822c3789025b0813a8fe249a by Miss Islington (bot) in branch '3.8':
bpo-38811: Check for presence of os.link method in pathlib (GH-17225)
https://github.com/python/cpython/commit/8d0f36940e728989822c3789025b0813a8fe249a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26978>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:42:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 12:42:56 +0000
Subject: [issue38811] Pathlib crashes when os module is missing 'link' method
In-Reply-To: <1573819474.81.0.395497091024.issue38811@roundup.psfhosted.org>
Message-ID: <1576500176.38.0.840388506492.issue38811@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If someone cares about the missing os.symlink code path: please open a separated issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38811>
_______________________________________

From report at bugs.python.org  Mon Dec 16 07:58:42 2019
From: report at bugs.python.org (jvoisin)
Date: Mon, 16 Dec 2019 12:58:42 +0000
Subject: [issue39064] ValueError in zipfile.ZipFile
Message-ID: <1576501122.43.0.655067405413.issue39064@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file produces the following stacktrace when opened via `zipfile.ZipFile`, on Python 3.7.5rc1:

```
$ cat ziprepro.py 
import zipfile
import sys

zipfile.ZipFile(sys.argv[1])
```

```
$ python3 ziprepro.py crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62
Traceback (most recent call last):
  File "ziprepro.py", line 4, in <module>
    zipfile.ZipFile(sys.argv[1])
  File "/usr/lib/python3.7/zipfile.py", line 1225, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.7/zipfile.py", line 1310, in _RealGetContents
    fp.seek(self.start_dir, 0)
ValueError: cannot fit 'int' into an offset-sized integer
```

The ValueError exception isn't documented as a possible exception when using zipfile.ZipFile ( https://docs.python.org/3/library/tarfile.html ).

----------
components: Library (Lib)
files: crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62
messages: 358484
nosy: jvoisin
priority: normal
severity: normal
status: open
title: ValueError in zipfile.ZipFile
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48782/crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39064>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:07:11 2019
From: report at bugs.python.org (jvoisin)
Date: Mon, 16 Dec 2019 13:07:11 +0000
Subject: [issue39065] OSError in TarFile.getmembers()
Message-ID: <1576501631.49.0.641796091958.issue39065@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file produces the following stacktrace when opened via `tarfile.open` and iterated with `TarFile.getmembers`, on Python 3.7.5rc1:

```
$ cat tarrepro.py 
import tarfile
import sys

with tarfile.open(sys.argv[1]) as t:
  for member in t.getmembers():
    pass
```

```
$ python3 tarrepro.py crash-462a00f845e737bff6df2fe6467fc7cdd4c39cd8e27ef1d3011ec68a9808ca8e
Traceback (most recent call last):
  File "tarrepro.py", line 5, in <module>
    for member in t.getmembers():
  File "/usr/lib/python3.7/tarfile.py", line 1763, in getmembers
    self._load()        # all members, we first have to
  File "/usr/lib/python3.7/tarfile.py", line 2350, in _load
    tarinfo = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2281, in next
    self.fileobj.seek(self.offset - 1)
  File "/usr/lib/python3.7/gzip.py", line 368, in seek
    return self._buffer.seek(offset, whence)
  File "/usr/lib/python3.7/_compression.py", line 143, in seek
    data = self.read(min(io.DEFAULT_BUFFER_SIZE, offset))
  File "/usr/lib/python3.7/gzip.py", line 454, in read
    self._read_eof()
  File "/usr/lib/python3.7/gzip.py", line 501, in _read_eof
    hex(self._crc)))
OSError: CRC check failed 0x21e25017 != 0x7c839e8b
```

The OSError exception isn't documented as a possible exception when using TarFile.getmembers ( https://docs.python.org/3/library/tarfile.html ).

----------
components: Library (Lib)
files: crash-462a00f845e737bff6df2fe6467fc7cdd4c39cd8e27ef1d3011ec68a9808ca8e
messages: 358485
nosy: jvoisin
priority: normal
severity: normal
status: open
title: OSError in TarFile.getmembers()
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48783/crash-462a00f845e737bff6df2fe6467fc7cdd4c39cd8e27ef1d3011ec68a9808ca8e

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39065>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:10:29 2019
From: report at bugs.python.org (Maxime Istasse)
Date: Mon, 16 Dec 2019 13:10:29 +0000
Subject: [issue39061] Garbage Collection optimizations cause "memory leak"
In-Reply-To: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
Message-ID: <1576501829.35.0.849267913226.issue39061@roundup.psfhosted.org>


Maxime Istasse <istassem at gmail.com> added the comment:

TLDR; a short-lived object can make it directly from young generation to old generation if middle generation collection kicks in while it is not freeable yet. Old generation is very rarely collected. Several of those objects, if they imply cyclic references, can therefore stack there and use a lot of RAM if big objects are attached to them. (if no cyclic refs, refcount goes to 0 and everything is OK)

This seems to happen in 3.8 as well, most likely in old versions as well. To me, those conditions shouldn't be exceptional enough to be ignored. 
I'm beginning to work on a fix, no guarantee yet though...

----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:14:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 16 Dec 2019 13:14:55 +0000
Subject: [issue39061] Garbage Collection optimizations cause "memory leak"
In-Reply-To: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
Message-ID: <1576502095.1.0.915844006548.issue39061@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:17:10 2019
From: report at bugs.python.org (joahking)
Date: Mon, 16 Dec 2019 13:17:10 +0000
Subject: [issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 >
 alledged missing X509_VERIFY_PARAM_set1_host() support
In-Reply-To: <1530609211.5.0.56676864532.issue34028@psf.upfronthosting.co.za>
Message-ID: <1576502230.18.0.0934963768208.issue34028@roundup.psfhosted.org>


joahking <joahking at gmail.com> added the comment:

hello,
I ran over this same problem on Ubuntu 14.04

As per
https://github.com/pyenv/pyenv/wiki/Common-build-problems

"Python 3.7.0 will not compile on RHEL6 because it requires OpenSSL 1.0.2 or 1.1 and RHEL6 provides 1.0.1e"

openssl version confirms this to be the case on Ubuntu 14.04

"On Ubuntu 14.04 on Dreamhost, an extra flag is required for Python 3.7+:
First, follow these instructions: https://help.dreamhost.com/hc/en-us/articles/360001435926-Installing-OpenSSL-locally-under-your-username"

then I ran: 
./configure --with-ensurepip=yes CFLAGS="-I$HOME/openssl/include" LDFLAGS="-L$HOME/openssl/lib"

after that python3.7 was correct

hope that helps, kind regards
Joaquin

----------
nosy: +joahking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34028>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:30:56 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 13:30:56 +0000
Subject: [issue39061] Garbage Collection optimizations cause "memory leak"
In-Reply-To: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
Message-ID: <1576503056.75.0.384959964191.issue39061@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> It happens to cause huge memory leaks if the self-referencing objects occupies a lot of RAM, which should be expected.

The fact that the GC will take longer time does not qualify this as memory leaks. A memory leak is by definition memory that cannot be reclaimed and in this case, once the collection of the old generation happens it will be collected, therefore is not a "leak" per se.

> I think the best and simplest solution would be to move the objects one generation at a time. This would avoid the heavy but short-lived objects to make it to the old generation.

This has also other downsides, like objects that won't be collected will suffer more traversals and collections, that can be impactful in performance, so is not that simple. 

I am currently working on an experiment to see if we can detect "nepotism" (check https://www.memorymanagement.org/glossary/n.html for a definition) and this will likely help with your problem.

In the meanwhile, I think the most portable option is forcing collections yourself or adjusting the gc parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:52:16 2019
From: report at bugs.python.org (Ben Boeckel)
Date: Mon, 16 Dec 2019 13:52:16 +0000
Subject: [issue39066] Expose SOABI setting in the header
Message-ID: <1576504336.84.0.358536323475.issue39066@roundup.psfhosted.org>


New submission from Ben Boeckel <mathstuf+bpo at gmail.com>:

Currently, the SOABI suffix is only available by running the Python interpreter to ask `sysconfig` about the setting. This complicates cross compilation because the target platform's Python may not be runnable on the build platform. Exposing this in the header would allow for build processes to know what suffix to add to modules without having to run the interpreter.

----------
components: C API
messages: 358489
nosy: mathstuf
priority: normal
severity: normal
status: open
title: Expose SOABI setting in the header
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39066>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:55:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 16 Dec 2019 13:55:41 +0000
Subject: [issue39066] Expose SOABI setting in the header
In-Reply-To: <1576504336.84.0.358536323475.issue39066@roundup.psfhosted.org>
Message-ID: <1576504541.93.0.756459581709.issue39066@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39066>
_______________________________________

From report at bugs.python.org  Mon Dec 16 09:21:45 2019
From: report at bugs.python.org (jvoisin)
Date: Mon, 16 Dec 2019 14:21:45 +0000
Subject: [issue39067] EOFError in tarfile.open
Message-ID: <1576506105.27.0.112129461214.issue39067@roundup.psfhosted.org>


New submission from jvoisin <jvoisin at google.com>:

The attached file produces the following stacktrace when opened via `tarfile.open`, on Python 3.7.5rc1:


```
$ cat tarrepro.py 
import tarfile
import sys

with tarfile.open(sys.argv[1], errorlevel=2) as t:
  for member in t.getmembers():
    pass
$
```

```
$ python3 tarrepro.py crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4
Traceback (most recent call last):
  File "tarrepro.py", line 4, in <module>
    with tarfile.open(sys.argv[1], errorlevel=2) as t:
  File "/usr/lib/python3.7/tarfile.py", line 1574, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1646, in gzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1622, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1485, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2290, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1094, in fromtarfile
    buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.7/gzip.py", line 276, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 463, in read
    if not self._read_gzip_header():
  File "/usr/lib/python3.7/gzip.py", line 421, in _read_gzip_header
    self._read_exact(extra_len)
  File "/usr/lib/python3.7/gzip.py", line 400, in _read_exact
    raise EOFError("Compressed file ended before the "
EOFError: Compressed file ended before the end-of-stream marker was reached

```

----------
components: Library (Lib)
files: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4
messages: 358490
nosy: jvoisin
priority: normal
severity: normal
status: open
title: EOFError in tarfile.open
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48784/crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39067>
_______________________________________

From report at bugs.python.org  Mon Dec 16 09:31:33 2019
From: report at bugs.python.org (Maxime Istasse)
Date: Mon, 16 Dec 2019 14:31:33 +0000
Subject: [issue39061] Garbage Collection optimizations cause "memory leak"
In-Reply-To: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
Message-ID: <1576506693.01.0.0561513913872.issue39061@roundup.psfhosted.org>


Maxime Istasse <istassem at gmail.com> added the comment:

> The fact that the GC will take longer time does not qualify this as memory leaks. A memory leak is by definition memory that cannot be reclaimed and in this case, once the collection of the old generation happens it will be collected, therefore is not a "leak" per se.

I completely agree, I did not know what to call that. It's just that I was really believing to write GC-friendly code, but that my assumptions were very wrong. The result of my investigation seems so counter-intuitive that I tend to believe this is a bug introduced by a quick implementation shortcut and an optimization.

I wouldn't have reported it if I had been able to mitigate it by setting the gc parameters. My first idea was to set a threshold0 such that I'm certain I don't keep references for that amount of time. But the one I'm using at the moment of the second generation collection will go in the old generation, it is the only one but it will for sure. As those are the only "new" objects that go to the old generation, it really takes a long time for it to grow sufficiently to get collected.

> This has also other downsides, like objects that won't be collected will suffer more traversals and collections, that can be impactful in performance, so is not that simple.

I don't think it will be that impactful because of traversals and collections. I think it was mostly convenient to merge the generations in the "collect" function, and that not merging them will be a bit more tedious.

If there is a second gen collection every 10 young gen collection, then it just introduces some more objects in the next second gen collection every second gen collection rather than putting them in the old generation directly.

To me, it is unintended that all the objects that are reachable during a second gen collection are put in the old generation. There is a high probability we have some short-lived objects there. It wouldn't be as problematic to traverse them once more in the next second gen. I tend to believe it is the purpose of the old gen not to be reachable in less than 2 passes.

Hopefully, for my personal, non artificial case, there are other assumptions I can make so I used weakrefs. I have one parent with children pointing to it, they just point with weakrefs now, and I know I always keep a reference to the parent or are OK to let them all go as refcount(parent) == 0. I'm very grateful I don't have to do gc.collect, which indeed was the next option.

Thank you for taking the problem seriously, and for the time you may dedicate to it. No need to be quick, I just wanted to raise that question. I am of course interested in the bad consequences it could bring (at the core of such a broadly used language, I would expect there are some), but at the same time, it is such a rare event and very localized and counter-intuitive in the implementation that it would surprise me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:12:02 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Dec 2019 15:12:02 +0000
Subject: [issue39067] EOFError in tarfile.open
In-Reply-To: <1576506105.27.0.112129461214.issue39067@roundup.psfhosted.org>
Message-ID: <1576509122.11.0.411041314765.issue39067@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Looks like expected behaviour, the attached file is an incomplete compressed file that does not seem to contain data (according to gzcat)

gzcat: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4: unexpected end of file
gzcat: crash-f4032ed3c7c2ae59a8f4424e0e73ce8b11ad3ef90155b008968f5b1b08499bc4: uncompress failed

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39067>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:17:14 2019
From: report at bugs.python.org (jvoisin)
Date: Mon, 16 Dec 2019 15:17:14 +0000
Subject: [issue39067] EOFError in tarfile.open
In-Reply-To: <1576506105.27.0.112129461214.issue39067@roundup.psfhosted.org>
Message-ID: <1576509434.78.0.697228391054.issue39067@roundup.psfhosted.org>


jvoisin <jvoisin at google.com> added the comment:

Unfortunately, the documentation ( https://docs.python.org/3/library/tarfile.html) doesn't mention that EOFError is an exception that could be raised when using tarfile.open :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39067>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:25:19 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 16 Dec 2019 15:25:19 +0000
Subject: [issue39067] EOFError in tarfile.open
In-Reply-To: <1576506105.27.0.112129461214.issue39067@roundup.psfhosted.org>
Message-ID: <1576509919.25.0.94321672916.issue39067@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The stdlib documentation does in general not contain exhaustive documentation on exceptions that might be raised.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39067>
_______________________________________

From report at bugs.python.org  Mon Dec 16 12:55:04 2019
From: report at bugs.python.org (Brandon Stansbury)
Date: Mon, 16 Dec 2019 17:55:04 +0000
Subject: [issue39068] Base 85 encoding initialization race conditiong
Message-ID: <1576518904.56.0.627490233403.issue39068@roundup.psfhosted.org>


New submission from Brandon Stansbury <brandonrstansbury at gmail.com>:

Under multi-threading scenarios a race condition may occur where a thread sees an initialized `_b85chars` table but an uninitialized `_b85chars2` table due to the guard only checking the first table.

This causes an exception like:

```
  File "/usr/lib/python3.6/base64.py", line 434, in b85encode
    return _85encode(b, _b85chars, _b85chars2, pad),
  File "/usr/lib/python3.6/base64.py", line 294, in _85encode
    for word in words],
  File "/usr/lib/python3.6/base64.py", line 294, in <listcomp>
    for word in words],
 "TypeError: 'NoneType' object is not subscriptable
```

----------
components: Library (Lib)
messages: 358495
nosy: drmonkeysee
priority: normal
pull_requests: 17096
severity: normal
status: open
title: Base 85 encoding initialization race conditiong
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39068>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:06:37 2019
From: report at bugs.python.org (Brandon Stansbury)
Date: Mon, 16 Dec 2019 18:06:37 +0000
Subject: [issue39068] Base 85 encoding initialization race condition
In-Reply-To: <1576518904.56.0.627490233403.issue39068@roundup.psfhosted.org>
Message-ID: <1576519597.5.0.0971269748227.issue39068@roundup.psfhosted.org>


Change by Brandon Stansbury <brandonrstansbury at gmail.com>:


----------
title: Base 85 encoding initialization race conditiong -> Base 85 encoding initialization race condition

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39068>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:12:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:12:54 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
Message-ID: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Pablo Galingo Salgado recently moved Tools/parser/unparse.py to a ast.unparse() function.

Pablo made a change using functools. The additional "import functools" made "import ast" slower and so Pablo reverted his change:

* https://github.com/python/cpython/pull/17376
* https://bugs.python.org/issue38870

The question of using contextlib comes back in another ast.unparse change to get @contextlib.contextmanager:

* https://github.com/python/cpython/pull/17377#discussion_r350239415

On the same PR, I also proposed to use import enum:

* https://github.com/python/cpython/pull/17377#discussion_r357921289

There are different options to not impact "import ast" performance:

* Move ast.unparse() code into a new module
* Write to code so imports can be done lazily

"from ast import unparse" or "ast.unparse()" can be kept using a private _ast_unparse module and add a __getattr__() function to Lib/ast.py to lazily bind _ast_unparse.unparse() to ast.unparse().

Other options:

* Avoid cool enum and functools modules, and use simpler Python code (that makes me sad, but it's ok)
* Accept to make "import ast" slower
* Remove ast.unparse(): I don't think that anyone wants this, ast.unparse() was approved on python-dev.

----------
components: Library (Lib)
messages: 358496
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Move ast.unparse() function to a different module
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:15:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:15:01 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520101.13.0.21228065536.issue39069@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> On the same PR, I also proposed to use import enum:

"import enum" is not the biggest enum. Creating an enum type is expensive, and so we might to do it lazily. For example, "import re" was made betweeen 20 an 30% slower than re constants were converted to enums.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:16:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:16:04 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520164.55.0.0890897914513.issue39069@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Can someone try to run a benchmark to see the actual overhead of adding functools and/or enum imports, and creating a enum type on "import ast"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:16:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:16:37 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520197.32.0.365012812597.issue39069@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:17:01 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:17:01 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520221.75.0.603623116236.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I will be ok with (no particular order):

- Avoid cool enum and functools modules, and use simpler
- Accept to make "import ast" slower
- Lazy import

I think is very important to keep 'ast.unparse' symmetric with 'ast.parse': is consistent, helps with discovery and they are very much related. Whatever option we choose we should try to maintain this IMO.

----------
nosy:  -BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:19:37 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Dec 2019 18:19:37 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576520377.26.0.371970781709.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

In general your solution looks good, just a few naming comments and an additional test request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:21:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:21:37 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520497.37.0.933885521556.issue39069@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Lazy import

IMHO moving unparse code to a new _ast_unparse module, and use ast.__getattr__() to lazily import it and bind it as the ast.unparse() function is the best option, since __getattr__() alone is enough to implement the laziness and it should be simple, something like:

def __getattr__(name):
  if name == 'unparse':
    import _ast_unparse
    globals()['unpase'] = _ast_unparse.unparse
    return _ast_unparse.unparse
  else:
    raise AttributeError

I never used a module __getattr__().

So _ast_unparse could use any super slow but cool Python feature, without having to use dirty hacks to make the code lazy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:23:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:23:36 +0000
Subject: [issue38348] Make python -m ast more configurable
In-Reply-To: <1570029299.56.0.0303865742584.issue38348@roundup.psfhosted.org>
Message-ID: <1576520616.95.0.335138665745.issue38348@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 814d687c7df3e0c60036943b68ece13f9f19dfef by Victor Stinner (Batuhan Ta?kaya) in branch 'master':
bpo-38348: Extend command line options of ast parsing tool (GH-16540)
https://github.com/python/cpython/commit/814d687c7df3e0c60036943b68ece13f9f19dfef


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38348>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:24:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:24:07 +0000
Subject: [issue38348] Make python -m ast more configurable
In-Reply-To: <1570029299.56.0.0303865742584.issue38348@roundup.psfhosted.org>
Message-ID: <1576520647.56.0.728243153797.issue38348@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Batuhan Ta?kaya.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38348>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:25:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 18:25:26 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1576520726.57.0.954833180349.issue38870@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-39069: "Move ast.unparse() function to a different module".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:26:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:26:20 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520780.53.0.367457486301.issue39069@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:27:29 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:27:29 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576520849.37.0.641400666034.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, I think I agree, will make a PR for that.

----------
assignee:  -> pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:29:37 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 16 Dec 2019 18:29:37 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576520849.37.0.641400666034.issue39069@roundup.psfhosted.org>
Message-ID: <CANDBV650Tc0tocH3gzVRB+wWXQroya-=HA8CUBLSt7ZGdEAPxg@mail.gmail.com>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

$ ./python -m pyperf timeit "import ast"
Before: Mean +- std dev: 326 ns +- 13 ns
After: Mean +- std dev: 330 ns +- 19 ns

(applied my first patch with both contextlib and IntEnum)

Pablo Galindo Salgado <report at bugs.python.org>, 16 Ara 2019 Pzt, 21:27
tarihinde ?unu yazd?:

>
> Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:
>
> Ok, I think I agree, will make a PR for that.
>
> ----------
> assignee:  -> pablogsal
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39069>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:35:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:35:24 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576521324.89.0.917930325882.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

That will likely be very dependent on the filesystem. For example, in one of my servers without SSDs:

Before: Mean +- std dev: 412 ns +- 11 ns
After: Mean +- std dev: 472 ns +- 11 ns

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:35:28 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 16 Dec 2019 18:35:28 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1576521328.39.0.850729065831.issue39041@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a76ba362c4d86adf5e7f8254398135d12d7afd25 by Steve Dower in branch 'master':
bpo-39041: Add GitHub Actions support (GH-17594)
https://github.com/python/cpython/commit/a76ba362c4d86adf5e7f8254398135d12d7afd25


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:36:37 2019
From: report at bugs.python.org (AVicennA)
Date: Mon, 16 Dec 2019 18:36:37 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1576521397.24.0.70341848414.issue38993@roundup.psfhosted.org>


Change by AVicennA <tural.jalilov.92 at gmail.com>:


Removed file: https://bugs.python.org/file48764/cProfiling.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:37:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:37:07 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576521427.05.0.0567046508088.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Also, make sure that the module is not cached, for example:

./python -m pyperf timeit 'import sys; sys.modules.pop("ast",None);sys.modules.pop("enum",None)' 'import ast'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:46:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Dec 2019 18:46:59 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576522019.45.0.637049447613.issue39059@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The flaw in my_round is that it rounds twice, not once.  The first rounding is caused by multiplying by a factor that is not a power of 2.  

In the case of 2.675, that rounding is up enough to affect the second rounding.
>>> format(2.675, ".17f")
'2.67499999999999982'
>>> format(2.675 *100, ".17f")
'267.50000000000000000'

In the case of 4.395, the first rounding is down.
>>> format(4.395, ".17f")
'4.39499999999999957'
>>> format(4.395 *100, ".17f")
'439.49999999999994316'
Even if it had been up, it might not have been enough to affect the outcome, as 57 is a lot farther from 100 than 82.

If you want to discuss floating point approximations and rounding further, please post to python-list, not here.

----------
components:  -Documentation, FreeBSD, IDLE, Library (Lib), Tests, Windows, macOS
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:46:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 16 Dec 2019 18:46:57 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1576522017.38.0.108190396459.issue39041@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Have merged the core support. Now that checks are enabled, any updates to the workflow files can be tested in PRs, so that will be much easier.

Other things to do:
* badges
* disable Azure Pipelines for PR builds
* ...? What have I missed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:47:14 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:47:14 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576522034.03.0.227778572518.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

One thing to notice:

Factoring this into a submodule may be a bit annoying as it will have circular imports as the unparse submodule depends directly on stuff from ast and ast will import unparse. Is possible to make it work if we import it at the end but is a bit ugly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:50:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 16 Dec 2019 18:50:57 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1576522257.97.0.955582666858.issue39041@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +17097
pull_request: https://github.com/python/cpython/pull/17628

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:56:56 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:56:56 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576522616.24.0.842288397098.issue39069@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17098
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17629

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:57:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 18:57:21 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576522641.9.0.652258429596.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Opened https://github.com/python/cpython/pull/17629 in case we decide to go this route.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:04:09 2019
From: report at bugs.python.org (AVicennA)
Date: Mon, 16 Dec 2019 19:04:09 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576523049.15.0.612807815225.issue39059@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

@mark.dickinson,

1) Where is your "`round` is giving the correct result in all cases"??

>>> round(4.395, 2)
4.39

2) I wrote it in my post using decimal punct:
''' Because, when the decimal string is converted to a binary floating-point number, it's 
    again replaced with a binary approximation:

    Whose exact value is 5.765 --> 5.76499999999999968025576890795491635799407958984375
                                                 &&
                         2.675 --> 2.67499999999999982236431605997495353221893310546875

    It means that, the 76(5) --> 5 replaced in a memory as 4.(999999999999)
                                                 &&
                       67(5) --> 5 replaced in a memory as 4.(999999999999) '''

3) round(2.6749999999999998, 2) --> this is the same with round(2.675, 2).

4) I also have a question for you.. Do you have any suggestion to solve this problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:06:33 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 19:06:33 +0000
Subject: [issue39061] Garbage Collection makes some object live for very long
In-Reply-To: <1576490494.99.0.0417763312986.issue39061@roundup.psfhosted.org>
Message-ID: <1576523193.83.0.721980449212.issue39061@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
title: Garbage Collection optimizations cause "memory leak" -> Garbage Collection makes some object live for very long

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39061>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:07:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 16 Dec 2019 19:07:57 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576523277.7.0.0801151814115.issue39059@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/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:15:12 2019
From: report at bugs.python.org (AVicennA)
Date: Mon, 16 Dec 2019 19:15:12 +0000
Subject: [issue38993] cProfile behaviour issue with decorator and
 math.factorial() lib.
In-Reply-To: <1575820468.1.0.0299446462176.issue38993@roundup.psfhosted.org>
Message-ID: <1576523712.13.0.57440136453.issue38993@roundup.psfhosted.org>


Change by AVicennA <tural.jalilov.92 at gmail.com>:


----------
resolution: not a bug -> later

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38993>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:15:14 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 16 Dec 2019 19:15:14 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1576523714.81.0.833453086125.issue39041@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6a263cf1adfc18cdba65c788dd76d35997a89acf by Steve Dower in branch 'master':
bpo-39041: Add GitHub Actions badge to README.rst (GH-17628)
https://github.com/python/cpython/commit/6a263cf1adfc18cdba65c788dd76d35997a89acf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:38:00 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 16 Dec 2019 19:38:00 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576525080.22.0.300062580752.issue39059@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@AVicennA: 4.39 *is* the correctly-rounded result for `round(4.395, 2)`. Modulo (as-yet unreported) bugs, `round` does correct-rounding (in the IEEE 754 sense) in all cases. I was pointing out that your `my_round` does not solve the problem you think it does: presumably you'd consider the "correct" result for `round(4.395, 2)` to be `4.4`, so you'd like `my_round(4.395, 2)` to return `4.4`?

> Do you have any suggestion to solve this problem?

The "problem" presumably being that two-argument `round` gives surprising results, to those who haven't thought about the implications of binary floating-point?

Unfortunately, there's no easy solution here. Discouraging use of two-argument round, and perhaps eventually deprecating it, is one possibility; there are few really good use-cases for two-argument round - most of the common use-cases involve rounding for reporting purposes, and that's better handled by string formatting. Keeping two-argument round and documenting the issue is another, and that's the solution the Python core devs have chosen. A more drastic solution would be to have Python's numeric literals use decimal floating-point by default instead of binary floating-point, so that we finally have a What You See Is What You Get behaviour for floating-point. That would be a huge change with many implications, and it's definitely way out of scope for this issue.

If you want to discuss this further, please feel free to do so, but not here: this isn't the right forum for that discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:00:32 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Dec 2019 20:00:32 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576526432.41.0.571946723421.issue39069@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Why is the import speed of ast important enough to uglify this code? Who is using ast.py that isn't also importing lots of other stuff? For example, black imports lots of other stuff (multiprocessing, asyncio, pathlib, typing, ..., even 3rd party attr, click and toml).

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:16:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 20:16:20 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576527380.91.0.58190666199.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

If I remember correctly, the people that were concerned mentioned the usage of 'ast.literal_eval' in some simple command line applications were the import may be noticeable but I will be totally ok to just accept the slower import of ast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:50:23 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Dec 2019 20:50:23 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576529423.92.0.518560289734.issue39069@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

If anything, ast.literal_eval() should be moved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:57:55 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 20:57:55 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576529875.72.0.913411847586.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Victor, are you OK if we close this issue and just use the desired imports directly in the PRs for issue 38870?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:31:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2019 21:31:24 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576531884.1.0.739316350068.issue39069@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Pablo:
> Victor, are you OK if we close this issue and just use the desired imports directly in the PRs for issue 38870?

Yes.

--

*I* don't care of "import ast" performance, since I don't expect it to be commonly used by command line applications. I don't know the story of the revert, but it seems like you don't bother much anymore.

If tomorrow using "functools" and "enum" becomes a performance bottleneck (for import time), maybe we should try to optimize imports and optimize these modules instead?

I opened this issue because I would like to use these modules in ast. I'm unhappy with the current proposed implementation:
---

    class _NoDelimit:
        def __enter__(self): pass
        def __exit__(self, *args): pass

    class _Delimit:
        """A context manager for preparing the source for expressions. It adds
        start of the delimiter  and enters, after exit it adds delimiter end."""
        def __init__(self, unparser, delimiter):
            self.unparser = unparser
            self.delimiter = delimiter
        def __enter__(self):
            self.unparser.write(self.delimiter[0])
        def __exit__(self, exc_type, exc_value, traceback):
            self.unparser.write(self.delimiter[-1])

    def delimit_if(self, condition, delimiter):
        if condition:
            return self._Delimit(self, delimiter)
        else:
            return self._NoDelimit()
---

Having to define two classes just to call the write() method seems overkill to me.

Same remark for the pseudo enum in PR 17377:
---
    PRECEDENCE_LEVELS = {
        "PR_TUPLE": 0,
        "PR_YIELD": 1,
        "PR_TEST": 2,
        "PR_OR": 3,
        "PR_AND": 4,
        "PR_NOT": 5,
        "PR_CMP": 6,
        "PR_EXPR": 7,
        "PR_BOR": 7,
        "PR_BXOR": 8,
        "PR_BAND": 9,
        "PR_SHIFT": 10,
        "PR_ARITH": 11,
        "PR_TERM": 12,
        "PR_FACTOR": 13,
        "PR_POWER": 14,
        "PR_AWAIT": 15,
        "PR_ATOM": 16,
    }
---

It's too easy to introduce a duplicated constant with such construction. The enum module is designed to define unique constants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:36:22 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 16 Dec 2019 21:36:22 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576531884.1.0.739316350068.issue39069@roundup.psfhosted.org>
Message-ID: <CANDBV65tQNuW-3P2Z_xZUWXLnPooGdXOQ=UXqRUJXQtsSZDa9g@mail.gmail.com>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Thanks for having consensus on this. I'll refactor PR 17612 and open
anothor one for reverting PR 17376

On Tue, Dec 17, 2019, 12:31 AM STINNER Victor <report at bugs.python.org>
wrote:

>
> STINNER Victor <vstinner at python.org> added the comment:
>
> Pablo:
> > Victor, are you OK if we close this issue and just use the desired
> imports directly in the PRs for issue 38870?
>
> Yes.
>
> --
>
> *I* don't care of "import ast" performance, since I don't expect it to be
> commonly used by command line applications. I don't know the story of the
> revert, but it seems like you don't bother much anymore.
>
> If tomorrow using "functools" and "enum" becomes a performance bottleneck
> (for import time), maybe we should try to optimize imports and optimize
> these modules instead?
>
> I opened this issue because I would like to use these modules in ast. I'm
> unhappy with the current proposed implementation:
> ---
>
>     class _NoDelimit:
>         def __enter__(self): pass
>         def __exit__(self, *args): pass
>
>     class _Delimit:
>         """A context manager for preparing the source for expressions. It
> adds
>         start of the delimiter  and enters, after exit it adds delimiter
> end."""
>         def __init__(self, unparser, delimiter):
>             self.unparser = unparser
>             self.delimiter = delimiter
>         def __enter__(self):
>             self.unparser.write(self.delimiter[0])
>         def __exit__(self, exc_type, exc_value, traceback):
>             self.unparser.write(self.delimiter[-1])
>
>     def delimit_if(self, condition, delimiter):
>         if condition:
>             return self._Delimit(self, delimiter)
>         else:
>             return self._NoDelimit()
> ---
>
> Having to define two classes just to call the write() method seems
> overkill to me.
>
> Same remark for the pseudo enum in PR 17377:
> ---
>     PRECEDENCE_LEVELS = {
>         "PR_TUPLE": 0,
>         "PR_YIELD": 1,
>         "PR_TEST": 2,
>         "PR_OR": 3,
>         "PR_AND": 4,
>         "PR_NOT": 5,
>         "PR_CMP": 6,
>         "PR_EXPR": 7,
>         "PR_BOR": 7,
>         "PR_BXOR": 8,
>         "PR_BAND": 9,
>         "PR_SHIFT": 10,
>         "PR_ARITH": 11,
>         "PR_TERM": 12,
>         "PR_FACTOR": 13,
>         "PR_POWER": 14,
>         "PR_AWAIT": 15,
>         "PR_ATOM": 16,
>     }
> ---
>
> It's too easy to introduce a duplicated constant with such construction.
> The enum module is designed to define unique constants.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39069>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:58:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 16 Dec 2019 21:58:21 +0000
Subject: [issue39069] Move ast.unparse() function to a different module
In-Reply-To: <1576519974.46.0.601705000564.issue39069@roundup.psfhosted.org>
Message-ID: <1576533501.93.0.543868830271.issue39069@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closing this now that we have consensus. :)

Thanks, everyone for your input!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39069>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:38:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Dec 2019 22:38:40 +0000
Subject: [issue37762] IDLE very slow due a super long line output in chunks
In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org>
Message-ID: <1576535920.3.0.20670438899.issue37762@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python374-4.png shows that Tensorflow prints proper lines, ending with newline, when printing to the Windows console.  The 30 character progress bar is repeated on each new line.  It does not appear to be using either \r or \b.  I consider it a bug in tensorflow that it omits newlines when printing to IDLE, and that it apparently add \bs instead.

https://stackoverflow.com/questions/59309917/tensorflow-printing-weird-symbols-as is about the same issue.  The questioner ran 
 for c in '<boxes>': print(hex(ord(c)))
where <boxes> is the copy and pasted segment printing as the reverse bullets and they are indeed backspaces.  In his output, there are 39 backspaces, which is not at all enough to overprint the entire line.  This makes no sense to me.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37762>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:49:10 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 16 Dec 2019 22:49:10 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576536550.97.0.0592538583887.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17099
pull_request: https://github.com/python/cpython/pull/17630

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:50:06 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 16 Dec 2019 22:50:06 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576536606.78.0.725209358967.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17100
pull_request: https://github.com/python/cpython/pull/17631

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:50:44 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 16 Dec 2019 22:50:44 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576536644.53.0.0203637689485.issue37228@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17101
pull_request: https://github.com/python/cpython/pull/17632

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:20:47 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 16 Dec 2019 23:20:47 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576538447.89.0.304977448316.issue39035@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 7699281b72b862797a89fcad004da8f58e93c800 by Ned Deily (Inada Naoki) in branch '3.6':
bpo-39035: travis: Update image to xenial (GH-17622)
https://github.com/python/cpython/commit/7699281b72b862797a89fcad004da8f58e93c800


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:42:54 2019
From: report at bugs.python.org (tuijatuulia)
Date: Mon, 16 Dec 2019 23:42:54 +0000
Subject: [issue39070] Uninstalling 3.8.0 fails but it says it succeeds..
Message-ID: <1576539774.23.0.330588412038.issue39070@roundup.psfhosted.org>


New submission from tuijatuulia <tuijatuulia at gmail.com>:

I installed 3.8.0 on Windows 10 without problems. Using windows user that has no admin rights - and system was asking for admin info.
Then I wanted to uninstall it because I got a wrong version and 32 bit version when I wanted 64 bit, but uninstalling did nothing, although it said it was successful and asked for admin login and ended into successful -screen - although it was too quick so I figured it did nothing actually, and it did not remove anything.
Only when I gave this same windows user the admin rights to the computer, I could uninstall 3.8.0.

----------
components: Windows
messages: 358526
nosy: paul.moore, steve.dower, tim.golden, tuijatuulia, zach.ware
priority: normal
severity: normal
status: open
title: Uninstalling 3.8.0 fails but it says it succeeds..
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39070>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:28:35 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 17 Dec 2019 00:28:35 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1576542515.88.0.49092139435.issue38730@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +17102
pull_request: https://github.com/python/cpython/pull/17633

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:32:18 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Dec 2019 00:32:18 +0000
Subject: [issue39066] Expose SOABI setting in the header
In-Reply-To: <1576504336.84.0.358536323475.issue39066@roundup.psfhosted.org>
Message-ID: <1576542738.58.0.206409440571.issue39066@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The entire extension suffix is currently available from the pythonX.Y-config command which does not depend on a running interpreter (on Linux systems at least), for example:

$ python3.8-config --extension-suffix
.cpython-38-i386-linux-gnu.so

Is that not sufficient for your needs?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39066>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:40:03 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 17 Dec 2019 00:40:03 +0000
Subject: [issue38730] 2.7 modern compiler warnings
In-Reply-To: <1573102399.46.0.00140143466152.issue38730@roundup.psfhosted.org>
Message-ID: <1576543203.93.0.935320606788.issue38730@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 052f47ef5cc363e842e0e839980cfa55ada123b5 by Benjamin Peterson in branch '2.7':
bpo-38730: Replace strncpy in import.c with memcpy. (GH-17633)
https://github.com/python/cpython/commit/052f47ef5cc363e842e0e839980cfa55ada123b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38730>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:00:35 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 17 Dec 2019 01:00:35 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576544435.15.0.663680460434.issue39059@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/issue39059>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:26:37 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 17 Dec 2019 01:26:37 +0000
Subject: [issue31046] ensurepip does not honour the value of $(prefix)
In-Reply-To: <1501087168.72.0.253170854096.issue31046@psf.upfronthosting.co.za>
Message-ID: <1576545997.93.0.368654994057.issue31046@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17103
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17634

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31046>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:26:56 2019
From: report at bugs.python.org (Ben Boeckel)
Date: Tue, 17 Dec 2019 01:26:56 +0000
Subject: [issue39066] Expose SOABI setting in the header
In-Reply-To: <1576504336.84.0.358536323475.issue39066@roundup.psfhosted.org>
Message-ID: <1576546016.41.0.748754316091.issue39066@roundup.psfhosted.org>


Ben Boeckel <mathstuf+bpo at gmail.com> added the comment:

Ah, that does look like it is suitable (since it is a shell script). I assume it is a batch script on Windows (though I feel cross-compilation is far rarer there). Thanks.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39066>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:26:59 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 17 Dec 2019 01:26:59 +0000
Subject: [issue31046] ensurepip does not honour the value of $(prefix)
In-Reply-To: <1501087168.72.0.253170854096.issue31046@psf.upfronthosting.co.za>
Message-ID: <1576546019.24.0.32250100706.issue31046@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31046>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:30:01 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Tue, 17 Dec 2019 03:30:01 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576553401.49.0.929621769909.issue39040@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Thanks David! I applied the fixes as per  your comments, can you please take another look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:17:35 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 17 Dec 2019 04:17:35 +0000
Subject: [issue37228] UDP sockets created by create_datagram_endpoint() allow
 by default multiple processes to bind the same port
In-Reply-To: <1560245814.37.0.496048869185.issue37228@roundup.psfhosted.org>
Message-ID: <1576556255.13.0.0463725451227.issue37228@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Thanks for taking care of merging the remaining backport PRs for 3.6-3.8, Ned. Now, the only branch left is (potentially) 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:51:50 2019
From: report at bugs.python.org (https403)
Date: Tue, 17 Dec 2019 04:51:50 +0000
Subject: [issue32343] Leak Sanitizer reports memory leaks while building using
 ASAN
In-Reply-To: <1513399699.11.0.213398074469.issue32343@psf.upfronthosting.co.za>
Message-ID: <1576558310.27.0.755391417495.issue32343@roundup.psfhosted.org>


https403 <bugs-python-org at sparvojo.pw> added the comment:

I got similar errors while playing around configure opts, but seems come from different places.

Configure opts: --enable-optimizations --with-address-sanitizer --with-undefined-behavior-sanitizer --with-pymalloc

Build environment: DigitalOcean $5 w/ Ubuntu 18.04 LTS

=================================================================
==26611==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 1 object(s) allocated from:
    #0 0x4f5ac0 in malloc (/tmp/python-build.20191217041116.18861/Python-3.7.5/python+0x4f5ac0)
    #1 0xaf2362 in _PyObject_GC_Alloc /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1696:26
    #2 0xaf285a in _PyObject_GC_Malloc /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1718:12
    #3 0xaf285a in _PyObject_GC_New /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1730
    #4 0x64b03f in new_dict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/dictobject.c:584:14
    #5 0xa7964a in ste_new /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:85:24
    #6 0xa7964a in symtable_enter_block /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:943
    #7 0xa7fd35 in symtable_visit_stmt /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:1131:14
    #8 0xa7f90b in symtable_visit_stmt /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:1153:9
    #9 0xa77bac in PySymtable_BuildObject /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:293:18
    #10 0x95fbc5 in PyAST_CompileObject /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/compile.c:342:14
    #11 0xa6ca51 in Py_CompileStringObject /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/pythonrun.c:1102:10
    #12 0x8f9d61 in builtin_compile_impl /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/bltinmodule.c:878:14    #13 0x8f9d61 in builtin_compile /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/clinic/bltinmodule.c.h:177
    #14 0x58c722 in _PyMethodDef_RawFastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:544:18
    #15 0x58784c in _PyCFunction_FastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:586:14
    #16 0x9193df in do_call_core /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4641:9
    #17 0x9193df in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3191
    #18 0x953711 in _PyEval_EvalCodeWithName /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
    #19 0x588f5e in _PyFunction_FastCallKeywords /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
    #20 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #21 0x91670e in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3139:19
    #22 0x953711 in _PyEval_EvalCodeWithName /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
    #23 0x588f5e in _PyFunction_FastCallKeywords /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
    #24 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #25 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #26 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #27 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #28 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #29 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #30 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #31 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #32 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #33 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x4f5ac0 in malloc (/tmp/python-build.20191217041116.18861/Python-3.7.5/python+0x4f5ac0)
    #1 0xaf2362 in _PyObject_GC_Alloc /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1696:26
    #2 0xaf2a4b in _PyObject_GC_Malloc /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1718:12
    #3 0xaf2a4b in _PyObject_GC_NewVar /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/gcmodule.c:1747
    #4 0x70ff55 in PyTuple_New /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/tupleobject.c:117:14
    #5 0x7fd6eba3727c in module_init /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/_asynciomodule.c:3237:22
    #6 0x7fd6eba3727c in PyInit__asyncio /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/_asynciomodule.c:3333
    #7 0x9f9e72 in _PyImport_LoadDynamicModuleWithSpec /tmp/python-build.20191217041116.18861/Python-3.7.5/./Python/importdl.c:159:9
    #8 0x9f801b in _imp_create_dynamic_impl /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/import.c:2170:11
    #9 0x9f801b in _imp_create_dynamic /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/clinic/import.c.h:289
    #10 0x58cd25 in _PyMethodDef_RawFastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:530:18
    #11 0x58784c in _PyCFunction_FastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:586:14
    #12 0x9193df in do_call_core /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4641:9
    #13 0x9193df in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3191
    #14 0x953711 in _PyEval_EvalCodeWithName /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
    #15 0x588f5e in _PyFunction_FastCallKeywords /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
    #16 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #17 0x91e85d in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3093:23
    #18 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #19 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #20 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #21 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #22 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #23 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19
    #24 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #25 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #26 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19
    #27 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #28 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #29 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19
    #30 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #31 0x586fe1 in _PyFunction_FastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:322:20
    #32 0x5921ac in object_vacall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:1202:14
    #33 0x59240d in _PyObject_CallMethodIdObjArgs /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:1252:14

Indirect leak of 168 byte(s) in 1 object(s) allocated from:
    #0 0x4f5ac0 in malloc (/tmp/python-build.20191217041116.18861/Python-3.7.5/python+0x4f5ac0)
    #1 0x64aa47 in new_keys_object /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/dictobject.c:534:14
    #2 0x64a915 in PyDict_New /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/dictobject.c:674:30
    #3 0xa7964a in ste_new /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:85:24
    #4 0xa7964a in symtable_enter_block /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:943
    #5 0xa7fa69 in symtable_visit_stmt /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:1348:14
    #6 0xa7f90b in symtable_visit_stmt /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:1153:9
    #7 0xa77bac in PySymtable_BuildObject /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/symtable.c:293:18
    #8 0x95fbc5 in PyAST_CompileObject /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/compile.c:342:14
    #9 0xa6ca51 in Py_CompileStringObject /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/pythonrun.c:1102:10    #10 0x8f9d61 in builtin_compile_impl /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/bltinmodule.c:878:14    #11 0x8f9d61 in builtin_compile /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/clinic/bltinmodule.c.h:177
    #12 0x58c722 in _PyMethodDef_RawFastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:544:18
    #13 0x58784c in _PyCFunction_FastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:586:14
    #14 0x9193df in do_call_core /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4641:9
    #15 0x9193df in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3191
    #16 0x953711 in _PyEval_EvalCodeWithName /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
    #17 0x588f5e in _PyFunction_FastCallKeywords /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
    #18 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #19 0x91670e in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3139:19
    #20 0x953711 in _PyEval_EvalCodeWithName /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
    #21 0x588f5e in _PyFunction_FastCallKeywords /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
    #22 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #23 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #24 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #25 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #26 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #27 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #28 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #29 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #30 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #31 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #32 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19

Indirect leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x4f5ac0 in malloc (/tmp/python-build.20191217041116.18861/Python-3.7.5/python+0x4f5ac0)
    #1 0x7a567d in PyUnicode_New /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/unicodeobject.c:1322:24
    #2 0x7eb1ba in _PyUnicodeWriter_PrepareInternal /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/unicodeobject.c:13552:26
    #3 0x7b60a0 in PyUnicode_DecodeUTF8Stateful /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/unicodeobject.c:4856:9
    #4 0x7fd6eba37298 in module_init /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/_asynciomodule.c:3241:29
    #5 0x7fd6eba37298 in PyInit__asyncio /tmp/python-build.20191217041116.18861/Python-3.7.5/Modules/_asynciomodule.c:3333
    #6 0x9f9e72 in _PyImport_LoadDynamicModuleWithSpec /tmp/python-build.20191217041116.18861/Python-3.7.5/./Python/importdl.c:159:9
    #7 0x9f801b in _imp_create_dynamic_impl /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/import.c:2170:11
    #8 0x9f801b in _imp_create_dynamic /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/clinic/import.c.h:289
    #9 0x58cd25 in _PyMethodDef_RawFastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:530:18
    #10 0x58784c in _PyCFunction_FastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:586:14
    #11 0x9193df in do_call_core /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4641:9
    #12 0x9193df in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3191
    #13 0x953711 in _PyEval_EvalCodeWithName /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3930:14
    #14 0x588f5e in _PyFunction_FastCallKeywords /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:433:12
    #15 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #16 0x91e85d in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3093:23
    #17 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #18 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #19 0x91e6eb in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3110:23
    #20 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #21 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #22 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19
    #23 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #24 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #25 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19
    #26 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #27 0x94e195 in call_function /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:4616:17
    #28 0x90cbe2 in _PyEval_EvalFrameDefault /tmp/python-build.20191217041116.18861/Python-3.7.5/Python/ceval.c:3124:19
    #29 0x58b839 in function_code_fastcall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:283:14
    #30 0x586fe1 in _PyFunction_FastCallDict /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:322:20
    #31 0x5921ac in object_vacall /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:1202:14
    #32 0x59240d in _PyObject_CallMethodIdObjArgs /tmp/python-build.20191217041116.18861/Python-3.7.5/Objects/call.c:1252:14

SUMMARY: AddressSanitizer: 368 byte(s) leaked in 4 allocation(s).

----------
nosy: +https403
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32343>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:03:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 17 Dec 2019 08:03:12 +0000
Subject: [issue39048] Reorder the __aenter__ and __aexit__ method checks for
 the async with statement
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1576569792.27.0.319515935967.issue39048@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:32:29 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Tue, 17 Dec 2019 08:32:29 +0000
Subject: [issue39071] email.parser.BytesParser - parse and parsebytes work not
 equivalent
Message-ID: <1576571549.52.0.292971717442.issue39071@roundup.psfhosted.org>


New submission from Manfred Kaiser <manfred.kaiser at logfile.at>:

I used email.parser.BytesParser for parsing mails. 

In one programm I used parse, because the email was stored in a file.
In a second programm the email was stored in memory as a bytes object.

I created hash values from each parts an compared them, to check if a part is already known to my programs. This works for attachments, but not for html and plain text parts.

Documentation for parsebytes:

Similar to the parse() method, except it takes a bytes-like object instead of a file-like object. Calling this method on a bytes-like object is equivalent to wrapping bytes in a BytesIO instance first and calling parse().

When I read the documentation, I expected that both methods will produce the same output.

The testmail contains 2 mimeparts. One with html and one with plain text.

The parse method with a file and the parse method with bytes-data, wrapped in a BytesIO produces the same hashes. The paesebytes method creates different hashes.

Output of my testprogram:

MD5 sums with parsebytes with bytes data
3f4ee7303378b62f723a8d958797507a
45c72465b931d32c7e700d2dd96f8383
------------------------
MD5 sums with parse and BytesIO with bytes data
fb0599d92750b72c25923139670e5127
9a54b64425b9003a9e6bf199ab6ba603
------------------------
MD5 sums with parse from file
fb0599d92750b72c25923139670e5127
9a54b64425b9003a9e6bf199ab6ba603



Is this an expected behavior or is this an error?

----------
components: email
files: test.eml
messages: 358533
nosy: barry, mkaiser, r.david.murray
priority: normal
severity: normal
status: open
title: email.parser.BytesParser - parse and parsebytes work not equivalent
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48785/test.eml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39071>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:32:51 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Tue, 17 Dec 2019 08:32:51 +0000
Subject: [issue39071] email.parser.BytesParser - parse and parsebytes work not
 equivalent
In-Reply-To: <1576571549.52.0.292971717442.issue39071@roundup.psfhosted.org>
Message-ID: <1576571571.03.0.784070010544.issue39071@roundup.psfhosted.org>


Change by Manfred Kaiser <manfred.kaiser at logfile.at>:


Added file: https://bugs.python.org/file48786/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39071>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:47:54 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Dec 2019 08:47:54 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576572474.51.0.656052230359.issue38295@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +17104
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17636

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:52:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 08:52:32 +0000
Subject: [issue39072] Azure Pipelines: git clone failed with: OpenSSL
 SSL_read: Connection was reset
Message-ID: <1576572752.23.0.326503724405.issue39072@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

On https://github.com/python/cpython/pull/17612/ the Windows x86 job failed on git clone:
https://github.com/python/cpython/pull/17612/checks?check_run_id=352102371

Logs:

2019-12-17T08:12:13.9180842Z ##[section]Starting: Request a runner to run this job
2019-12-17T08:12:14.0771595Z Requesting a hosted runner in current repository's account/organization with labels: 'windows-latest', require runner match: True
2019-12-17T08:12:14.1721951Z Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
2019-12-17T08:12:14.1872022Z ##[section]Finishing: Request a runner to run this job
2019-12-17T08:12:23.3365552Z Current runner version: '2.162.0'
2019-12-17T08:12:23.3366903Z Prepare workflow directory
2019-12-17T08:12:23.6967390Z Prepare all required actions
2019-12-17T08:12:23.7007224Z Download action repository 'actions/checkout at v1'
2019-12-17T08:12:27.0952634Z ##[group]Run actions/checkout at v1
2019-12-17T08:12:27.0953142Z with:
2019-12-17T08:12:27.0953435Z   clean: true
2019-12-17T08:12:27.0953668Z ##[endgroup]
2019-12-17T08:12:28.4859915Z Added matchers: 'checkout-git'. Problem matchers scan action output for known warning or error strings and report these inline.
2019-12-17T08:12:28.4860923Z Syncing repository: python/cpython
2019-12-17T08:12:28.4869958Z ##[command]git version
2019-12-17T08:12:28.4952567Z git version 2.24.0.windows.2
2019-12-17T08:12:28.4996331Z ##[command]git lfs version
2019-12-17T08:12:34.2013921Z git-lfs/2.9.0 (GitHub; windows amd64; go 1.12.7; git 8ab05aa7)
2019-12-17T08:12:34.2017699Z ##[command]git init "d:\a\cpython\cpython"
2019-12-17T08:12:34.2020576Z Initialized empty Git repository in d:/a/cpython/cpython/.git/
2019-12-17T08:12:34.2024465Z ##[command]git remote add origin https://github.com/python/cpython
2019-12-17T08:12:34.2027306Z ##[command]git config gc.auto 0
2019-12-17T08:12:34.2029544Z ##[command]git config --get-all http.https://github.com/python/cpython.extraheader
2019-12-17T08:12:34.2031492Z ##[command]git config --get-all http.proxy
2019-12-17T08:12:34.2038718Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/17612/merge:refs/remotes/pull/17612/merge
2019-12-17T08:14:45.6102189Z remote: Enumerating objects: 778568        
2019-12-17T08:14:45.6110192Z remote: Enumerating objects: 36, done.        
2019-12-17T08:14:45.6114528Z remote: Counting objects:   2% (1/36)        
2019-12-17T08:14:45.6114769Z remote: Counting objects:   5% (2/36)        
2019-12-17T08:14:45.6114916Z remote: Counting objects:   8% (3/36)        
2019-12-17T08:14:45.6115364Z remote: Counting objects:  11% (4/36)        
2019-12-17T08:14:45.6115460Z remote: Counting objects:  13% (5/36)        
2019-12-17T08:14:45.6115597Z remote: Counting objects:  16% (6/36)        
2019-12-17T08:14:45.6115773Z remote: Counting objects:  19% (7/36)        
2019-12-17T08:14:45.6115911Z remote: Counting objects:  22% (8/36)        
2019-12-17T08:14:45.6116006Z remote: Counting objects:  25% (9/36)        
2019-12-17T08:14:45.6116140Z remote: Counting objects:  27% (10/36)        
2019-12-17T08:14:45.6116276Z remote: Counting objects:  30% (11/36)        
2019-12-17T08:14:45.6116410Z remote: Counting objects:  33% (12/36)        
2019-12-17T08:14:45.6116505Z remote: Counting objects:  36% (13/36)        
2019-12-17T08:14:45.6117519Z remote: Counting objects:  38% (14/36)        
2019-12-17T08:14:45.6117673Z remote: Counting objects:  41% (15/36)        
2019-12-17T08:14:45.6117797Z remote: Counting objects:  44% (16/36)        
2019-12-17T08:14:45.6117880Z remote: Counting objects:  47% (17/36)        
2019-12-17T08:14:45.6118018Z remote: Counting objects:  50% (18/36)        
2019-12-17T08:14:45.6118143Z remote: Counting objects:  52% (19/36)        
2019-12-17T08:14:45.6118746Z remote: Counting objects:  55% (20/36)        
2019-12-17T08:14:45.6118837Z remote: Counting objects:  58% (21/36)        
2019-12-17T08:14:45.6118967Z remote: Counting objects:  61% (22/36)        
2019-12-17T08:14:45.6119092Z remote: Counting objects:  63% (23/36)        
2019-12-17T08:14:45.6119213Z remote: Counting objects:  66% (24/36)        
2019-12-17T08:14:45.6119467Z remote: Counting objects:  69% (25/36)        
2019-12-17T08:14:45.6119944Z remote: Counting objects:  72% (26/36)        
2019-12-17T08:14:45.6120097Z remote: Counting objects:  75% (27/36)        
2019-12-17T08:14:45.6120223Z remote: Counting objects:  77% (28/36)        
2019-12-17T08:14:45.6120345Z remote: Counting objects:  80% (29/36)        
2019-12-17T08:14:45.6120429Z remote: Counting objects:  83% (30/36)        
2019-12-17T08:14:45.6122262Z remote: Counting objects:  86% (31/36)        
2019-12-17T08:14:45.6122487Z remote: Counting objects:  88% (32/36)        
2019-12-17T08:14:45.6123370Z remote: Counting objects:  91% (33/36)        
2019-12-17T08:14:45.6123564Z remote: Counting objects:  94% (34/36)        
2019-12-17T08:14:45.6123649Z remote: Counting objects:  97% (35/36)        
2019-12-17T08:14:45.6123775Z remote: Counting objects: 100% (36/36)        
2019-12-17T08:14:45.6124092Z remote: Counting objects: 100% (36/36), done.        
2019-12-17T08:14:45.6124450Z remote: Compressing objects:   2% (1/36)        
2019-12-17T08:14:45.6124550Z remote: Compressing objects:   5% (2/36)        
2019-12-17T08:14:45.6124688Z remote: Compressing objects:   8% (3/36)        
2019-12-17T08:14:45.6124824Z remote: Compressing objects:  11% (4/36)        
2019-12-17T08:14:45.6124959Z remote: Compressing objects:  13% (5/36)        
2019-12-17T08:14:45.6125052Z remote: Compressing objects:  16% (6/36)        
2019-12-17T08:14:45.6125204Z remote: Compressing objects:  19% (7/36)        
2019-12-17T08:14:45.6125342Z remote: Compressing objects:  22% (8/36)        
2019-12-17T08:14:45.6125484Z remote: Compressing objects:  25% (9/36)        
2019-12-17T08:14:45.6125579Z remote: Compressing objects:  27% (10/36)        
2019-12-17T08:14:45.6125718Z remote: Compressing objects:  30% (11/36)        
2019-12-17T08:14:45.6125852Z remote: Compressing objects:  33% (12/36)        
2019-12-17T08:14:45.6125989Z remote: Compressing objects:  36% (13/36)        
2019-12-17T08:14:45.6126083Z remote: Compressing objects:  38% (14/36)        
2019-12-17T08:14:45.6126220Z remote: Compressing objects:  41% (15/36)        
2019-12-17T08:14:45.6126355Z remote: Compressing objects:  44% (16/36)        
2019-12-17T08:14:45.6126489Z remote: Compressing objects:  47% (17/36)        
2019-12-17T08:14:45.6126961Z remote: Compressing objects:  50% (18/36)        
2019-12-17T08:14:45.6127119Z remote: Compressing objects:  52% (19/36)        
2019-12-17T08:14:45.6127262Z remote: Compressing objects:  55% (20/36)        
2019-12-17T08:14:45.6127558Z remote: Compressing objects:  58% (21/36)        
2019-12-17T08:14:45.6127653Z remote: Compressing objects:  61% (22/36)        
2019-12-17T08:14:45.6127935Z remote: Compressing objects:  63% (23/36)        
2019-12-17T08:14:45.6128056Z remote: Compressing objects:  66% (24/36)        
2019-12-17T08:14:45.6128177Z remote: Compressing objects:  69% (25/36)        
2019-12-17T08:14:45.6128261Z remote: Compressing objects:  72% (26/36)        
2019-12-17T08:14:45.6128388Z remote: Compressing objects:  75% (27/36)        
2019-12-17T08:14:45.6128509Z remote: Compressing objects:  77% (28/36)        
2019-12-17T08:14:45.6128628Z remote: Compressing objects:  80% (29/36)        
2019-12-17T08:14:45.6128712Z remote: Compressing objects:  83% (30/36)        
2019-12-17T08:14:45.6128834Z remote: Compressing objects:  86% (31/36)        
2019-12-17T08:14:45.6128958Z remote: Compressing objects:  88% (32/36)        
2019-12-17T08:14:45.6129085Z remote: Compressing objects:  91% (33/36)        
2019-12-17T08:14:45.6129169Z remote: Compressing objects:  94% (34/36)        
2019-12-17T08:14:45.6129299Z remote: Compressing objects:  97% (35/36)        
2019-12-17T08:14:45.6129422Z remote: Compressing objects: 100% (36/36)        
2019-12-17T08:14:45.6129546Z remote: Compressing objects: 100% (36/36), done.        
2019-12-17T08:14:46.6103415Z Receiving objects:   0% (1/778604)
2019-12-17T08:14:47.9351300Z Receiving objects:   0% (66/778604), 28.00 KiB | 33.00 KiB/s
2019-12-17T08:14:54.9869233Z Receiving objects:   0% (111/778604), 60.00 KiB | 18.00 KiB/s
2019-12-17T08:14:56.9150492Z Receiving objects:   0% (168/778604), 92.00 KiB | 8.00 KiB/s 
2019-12-17T08:14:57.1452937Z Receiving objects:   0% (239/778604), 132.00 KiB | 10.00 KiB/s
2019-12-17T08:14:58.1193320Z Receiving objects:   0% (249/778604), 132.00 KiB | 10.00 KiB/s
2019-12-17T08:15:01.8268616Z Receiving objects:   0% (293/778604), 148.00 KiB | 11.00 KiB/s
2019-12-17T08:15:02.9750358Z Receiving objects:   0% (304/778604), 172.00 KiB | 9.00 KiB/s 
2019-12-17T08:15:04.3532052Z Receiving objects:   0% (332/778604), 188.00 KiB | 10.00 KiB/s
2019-12-17T08:15:05.3109995Z Receiving objects:   0% (347/778604), 196.00 KiB | 9.00 KiB/s 
2019-12-17T08:15:06.6874725Z Receiving objects:   0% (409/778604), 228.00 KiB | 10.00 KiB/s
2019-12-17T08:15:07.0736627Z Receiving objects:   0% (425/778604), 236.00 KiB | 9.00 KiB/s 
2019-12-17T08:15:08.0524512Z Receiving objects:   0% (644/778604), 236.00 KiB | 9.00 KiB/s
2019-12-17T08:15:09.8870060Z Receiving objects:   0% (712/778604), 364.00 KiB | 15.00 KiB/s
2019-12-17T08:15:11.6491806Z Receiving objects:   0% (751/778604), 404.00 KiB | 20.00 KiB/s
2019-12-17T08:15:14.9081539Z Receiving objects:   0% (765/778604), 412.00 KiB | 19.00 KiB/s
2019-12-17T08:15:28.7720884Z Receiving objects:   0% (779/778604), 420.00 KiB | 18.00 KiB/s
2019-12-17T08:18:54.7618604Z Receiving objects:   0% (837/778604), 452.00 KiB | 10.00 KiB/s
2019-12-17T08:18:54.7729845Z Receiving objects:   0% (849/778604), 460.00 KiB | 1024 bytes/s
2019-12-17T08:18:54.7730362Z Receiving objects:   0% (878/778604), 460.00 KiB | 1024 bytes/s
2019-12-17T08:18:54.7783522Z error: RPC failed; curl 56 OpenSSL SSL_read: No error
2019-12-17T08:18:54.7792069Z ##[error]fatal: the remote end hung up unexpectedly
2019-12-17T08:18:54.7801052Z ##[error]fatal: early EOF
2019-12-17T08:18:54.7802004Z ##[error]fatal: index-pack failed
2019-12-17T08:18:54.7815117Z ##[warning]Git fetch failed with exit code 128, back off 1.361 seconds before retry.
2019-12-17T08:18:56.1289014Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/17612/merge:refs/remotes/pull/17612/merge
2019-12-17T08:22:39.0654492Z ##[error]fatal: unable to access 'https://github.com/python/cpython/': OpenSSL SSL_read: Connection was reset
2019-12-17T08:22:39.0708951Z ##[warning]Git fetch failed with exit code 128, back off 4.414 seconds before retry.
2019-12-17T08:22:43.4941710Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/17612/merge:refs/remotes/pull/17612/merge
2019-12-17T08:23:40.2697794Z remote: Enumerating objects: 36, done.        
2019-12-17T08:23:40.2698302Z remote: Counting objects:   2% (1/36)        
2019-12-17T08:23:40.2699155Z remote: Counting objects:   5% (2/36)        
2019-12-17T08:23:40.2699929Z remote: Counting objects:   8% (3/36)        
2019-12-17T08:23:40.2700026Z remote: Counting objects:  11% (4/36)        
2019-12-17T08:23:40.2700198Z remote: Counting objects:  13% (5/36)        
2019-12-17T08:23:40.2700330Z remote: Counting objects:  16% (6/36)        
2019-12-17T08:23:40.2700464Z remote: Counting objects:  19% (7/36)        
2019-12-17T08:23:40.2700684Z remote: Counting objects:  22% (8/36)        
2019-12-17T08:23:40.2700890Z remote: Counting objects:  25% (9/36)        
2019-12-17T08:23:40.2701056Z remote: Counting objects:  27% (10/36)        
2019-12-17T08:23:40.2701241Z remote: Counting objects:  30% (11/36)        
2019-12-17T08:23:40.2701423Z remote: Counting objects:  33% (12/36)        
2019-12-17T08:23:40.2708741Z remote: Counting objects:  36% (13/36)        
2019-12-17T08:23:40.2709004Z remote: Counting objects:  38% (14/36)        
2019-12-17T08:23:40.2709281Z remote: Counting objects:  41% (15/36)        
2019-12-17T08:23:40.2713438Z remote: Counting objects:  44% (16/36)        
2019-12-17T08:23:40.2713793Z remote: Counting objects:  47% (17/36)        
2019-12-17T08:23:40.2714090Z remote: Counting objects:  50% (18/36)        
2019-12-17T08:23:40.2714831Z remote: Counting objects:  52% (19/36)        
2019-12-17T08:23:40.2715095Z remote: Counting objects:  55% (20/36)        
2019-12-17T08:23:40.2715289Z remote: Counting objects:  58% (21/36)        
2019-12-17T08:23:40.2715827Z remote: Counting objects:  61% (22/36)        
2019-12-17T08:23:40.2715998Z remote: Counting objects:  63% (23/36)        
2019-12-17T08:23:40.2716087Z remote: Counting objects:  66% (24/36)        
2019-12-17T08:23:40.2716912Z remote: Counting objects:  69% (25/36)        
2019-12-17T08:23:40.2717526Z remote: Counting objects:  72% (26/36)        
2019-12-17T08:23:40.2717885Z remote: Counting objects:  75% (27/36)        
2019-12-17T08:23:40.2718001Z remote: Counting objects:  77% (28/36)        
2019-12-17T08:23:40.2718155Z remote: Counting objects:  80% (29/36)        
2019-12-17T08:23:40.2718406Z remote: Counting objects:  83% (30/36)        
2019-12-17T08:23:40.2718563Z remote: Counting objects:  86% (31/36)        
2019-12-17T08:23:40.2718901Z remote: Counting objects:  88% (32/36)        
2019-12-17T08:23:40.2719600Z remote: Counting objects:  91% (33/36)        
2019-12-17T08:23:40.2719952Z remote: Counting objects:  94% (34/36)        
2019-12-17T08:23:40.2720161Z remote: Counting objects:  97% (35/36)        
2019-12-17T08:23:40.2720401Z remote: Counting objects: 100% (36/36)        
2019-12-17T08:23:40.2720560Z remote: Counting objects: 100% (36/36), done.        
2019-12-17T08:23:40.2720731Z remote: Compressing objects:   2% (1/36)        
2019-12-17T08:23:40.2720942Z remote: Compressing objects:   5% (2/36)        
2019-12-17T08:23:40.2721116Z remote: Compressing objects:   8% (3/36)        
2019-12-17T08:23:40.2721320Z remote: Compressing objects:  11% (4/36)        
2019-12-17T08:23:40.2721478Z remote: Compressing objects:  13% (5/36)        
2019-12-17T08:23:40.2721649Z remote: Compressing objects:  16% (6/36)        
2019-12-17T08:23:40.2779881Z remote: Compressing objects:  19% (7/36)        
2019-12-17T08:23:40.2780891Z remote: Compressing objects:  22% (8/36)        
2019-12-17T08:23:40.2781217Z remote: Compressing objects:  25% (9/36)        
2019-12-17T08:23:40.2781437Z remote: Compressing objects:  27% (10/36)        
2019-12-17T08:23:40.2781583Z remote: Compressing objects:  30% (11/36)        
2019-12-17T08:23:40.2781777Z remote: Compressing objects:  33% (12/36)        
2019-12-17T08:23:40.2782005Z remote: Compressing objects:  36% (13/36)        
2019-12-17T08:23:40.2782183Z remote: Compressing objects:  38% (14/36)        
2019-12-17T08:23:40.2782319Z remote: Compressing objects:  41% (15/36)        
2019-12-17T08:23:40.2782539Z remote: Compressing objects:  44% (16/36)        
2019-12-17T08:23:40.2782668Z remote: Compressing objects:  47% (17/36)        
2019-12-17T08:23:40.2783053Z remote: Compressing objects:  50% (18/36)        
2019-12-17T08:23:40.2783406Z remote: Compressing objects:  52% (19/36)        
2019-12-17T08:23:40.2783589Z remote: Compressing objects:  55% (20/36)        
2019-12-17T08:23:40.2783882Z remote: Compressing objects:  58% (21/36)        
2019-12-17T08:23:40.2783998Z remote: Compressing objects:  61% (22/36)        
2019-12-17T08:23:40.2784133Z remote: Compressing objects:  63% (23/36)        
2019-12-17T08:23:40.2784362Z remote: Compressing objects:  66% (24/36)        
2019-12-17T08:23:40.2793412Z remote: Compressing objects:  69% (25/36)        
2019-12-17T08:23:40.2793703Z remote: Compressing objects:  72% (26/36)        
2019-12-17T08:23:40.2793814Z remote: Compressing objects:  75% (27/36)        
2019-12-17T08:23:40.2794060Z remote: Compressing objects:  77% (28/36)        
2019-12-17T08:23:40.2794195Z remote: Compressing objects:  80% (29/36)        
2019-12-17T08:23:40.2794322Z remote: Compressing objects:  83% (30/36)        
2019-12-17T08:23:40.2794453Z remote: Compressing objects:  86% (31/36)        
2019-12-17T08:23:40.2794667Z remote: Compressing objects:  88% (32/36)        
2019-12-17T08:23:40.2794837Z remote: Compressing objects:  91% (33/36)        
2019-12-17T08:23:40.2795045Z remote: Compressing objects:  94% (34/36)        
2019-12-17T08:23:40.2795284Z remote: Compressing objects:  97% (35/36)        
2019-12-17T08:23:40.2795494Z remote: Compressing objects: 100% (36/36)        
2019-12-17T08:23:40.2795860Z remote: Compressing objects: 100% (36/36), done.        
2019-12-17T08:23:41.5636274Z Receiving objects:   0% (1/778604)
2019-12-17T08:23:43.1211697Z Receiving objects:   0% (38/778604), 20.00 KiB | 8.00 KiB/s
2019-12-17T08:23:49.2419812Z Receiving objects:   0% (53/778604), 28.00 KiB | 7.00 KiB/s
2019-12-17T08:23:55.7195787Z Receiving objects:   0% (65/778604), 36.00 KiB | 3.00 KiB/s
2019-12-17T08:23:55.9927602Z Receiving objects:   0% (152/778604), 84.00 KiB | 5.00 KiB/s
2019-12-17T08:23:57.4292004Z Receiving objects:   0% (199/778604), 84.00 KiB | 5.00 KiB/s
2019-12-17T08:23:59.0310311Z Receiving objects:   0% (263/778604), 148.00 KiB | 8.00 KiB/s
2019-12-17T08:24:05.6808838Z Receiving objects:   0% (317/778604), 180.00 KiB | 9.00 KiB/s
2019-12-17T08:24:05.9258262Z Receiving objects:   0% (347/778604), 196.00 KiB | 7.00 KiB/s
2019-12-17T08:24:07.8177821Z Receiving objects:   0% (363/778604), 196.00 KiB | 7.00 KiB/s
2019-12-17T08:24:08.0739166Z Receiving objects:   0% (409/778604), 228.00 KiB | 10.00 KiB/s
2019-12-17T08:24:10.4459540Z Receiving objects:   0% (426/778604), 228.00 KiB | 10.00 KiB/s
2019-12-17T08:24:11.0221152Z Receiving objects:   0% (505/778604), 276.00 KiB | 11.00 KiB/s
2019-12-17T08:24:11.9673927Z Receiving objects:   0% (553/778604), 300.00 KiB | 11.00 KiB/s
2019-12-17T08:24:19.0148937Z Receiving objects:   0% (581/778604), 316.00 KiB | 10.00 KiB/s
2019-12-17T08:24:21.2353599Z Receiving objects:   0% (612/778604), 332.00 KiB | 7.00 KiB/s 
2019-12-17T08:24:21.4127654Z Receiving objects:   0% (643/778604), 348.00 KiB | 10.00 KiB/s
2019-12-17T08:24:22.0971637Z Receiving objects:   0% (673/778604), 364.00 KiB | 10.00 KiB/s
2019-12-17T08:24:24.6868402Z Receiving objects:   0% (686/778604), 372.00 KiB | 10.00 KiB/s
2019-12-17T08:24:25.0468108Z Receiving objects:   0% (711/778604), 380.00 KiB | 7.00 KiB/s 
2019-12-17T08:24:26.6093023Z Receiving objects:   0% (752/778604), 380.00 KiB | 7.00 KiB/s
2019-12-17T08:24:29.8735977Z Receiving objects:   0% (765/778604), 412.00 KiB | 8.00 KiB/s
2019-12-17T08:24:30.1876849Z Receiving objects:   0% (779/778604), 420.00 KiB | 7.00 KiB/s
2019-12-17T08:24:31.0328125Z Receiving objects:   0% (878/778604), 420.00 KiB | 7.00 KiB/s
2019-12-17T08:24:32.0533595Z Receiving objects:   0% (970/778604), 500.00 KiB | 10.00 KiB/s
2019-12-17T08:24:33.3650717Z Receiving objects:   0% (1133/778604), 628.00 KiB | 22.00 KiB/s
2019-12-17T08:24:34.0756946Z Receiving objects:   0% (1216/778604), 676.00 KiB | 26.00 KiB/s
2019-12-17T08:24:36.5852563Z Receiving objects:   0% (1246/778604), 692.00 KiB | 26.00 KiB/s
2019-12-17T08:24:37.0530086Z Receiving objects:   0% (1272/778604), 708.00 KiB | 29.00 KiB/s
2019-12-17T08:24:41.2974359Z Receiving objects:   0% (1290/778604), 708.00 KiB | 29.00 KiB/s
2019-12-17T08:24:43.0892725Z Receiving objects:   0% (1333/778604), 740.00 KiB | 23.00 KiB/s
2019-12-17T08:24:50.7378262Z Receiving objects:   0% (1395/778604), 772.00 KiB | 16.00 KiB/s
2019-12-17T08:31:27.4207316Z Receiving objects:   0% (1470/778604), 804.00 KiB | 8.00 KiB/s 
2019-12-17T08:31:28.0933462Z Receiving objects:   0% (1491/778604), 812.00 KiB | 0 bytes/s 
2019-12-17T08:31:28.4118531Z Receiving objects:   0% (1528/778604), 828.00 KiB | 0 bytes/s
2019-12-17T08:31:30.7460515Z Receiving objects:   0% (1569/778604), 828.00 KiB | 0 bytes/s
2019-12-17T08:31:31.6458381Z Receiving objects:   0% (1623/778604), 876.00 KiB | 0 bytes/s
2019-12-17T08:31:32.1419609Z Receiving objects:   0% (1645/778604), 884.00 KiB | 0 bytes/s
2019-12-17T08:31:32.1420718Z error: RPC failed; curl 56 OpenSSL SSL_read: No error
2019-12-17T08:31:32.1423571Z ##[error]fatal: the remote end hung up unexpectedly
2019-12-17T08:31:32.1446744Z ##[error]fatal: early EOF
2019-12-17T08:31:32.1464680Z ##[error]fatal: index-pack failed
2019-12-17T08:31:32.1650020Z Removed matchers: 'checkout-git'
2019-12-17T08:31:32.1651061Z ##[error]Git fetch failed with exit code: 128
2019-12-17T08:31:32.1876486Z ##[error]Exit code 1 returned from process: file name 'c:\runners\2.162.0\bin\Runner.PluginHost.exe', arguments 'action "GitHub.Runner.Plugins.Repository.v1_0.CheckoutTask, Runner.Plugins"'.
2019-12-17T08:31:32.1934364Z Cleaning up orphan processes

----------
components: Tests
messages: 358534
nosy: steve.dower, vstinner
priority: normal
severity: normal
status: open
title: Azure Pipelines: git clone failed with: OpenSSL SSL_read: Connection was reset
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39072>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:53:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 08:53:28 +0000
Subject: [issue39072] Azure Pipelines: git clone failed with: OpenSSL
 SSL_read: Connection was reset
In-Reply-To: <1576572752.23.0.326503724405.issue39072@roundup.psfhosted.org>
Message-ID: <1576572808.9.0.00474830401548.issue39072@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39072>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:05:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Dec 2019 09:05:49 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576573549.96.0.209632115488.issue38295@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset bf3aa1060a29a05813abbe877193af16e3e7131e by Ned Deily in branch '3.8':
bpo-38295: prevent test_relative_path of test_py_compile failure on macOS Catalina (GH-17636)
https://github.com/python/cpython/commit/bf3aa1060a29a05813abbe877193af16e3e7131e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:06:09 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 17 Dec 2019 09:06:09 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576573569.37.0.528381735795.issue38295@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17105
pull_request: https://github.com/python/cpython/pull/17637

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:06:16 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 17 Dec 2019 09:06:16 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576573576.53.0.279739872135.issue38295@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17106
pull_request: https://github.com/python/cpython/pull/17638

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:06:24 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 17 Dec 2019 09:06:24 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576573584.87.0.642599677829.issue38295@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17107
pull_request: https://github.com/python/cpython/pull/17639

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:16:49 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 17 Dec 2019 09:16:49 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576574209.29.0.846606345804.issue38295@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5f2c1345a79f205c680ed6e0a6ed44199546d79e by Miss Islington (bot) in branch '2.7':
bpo-38295: prevent test_relative_path of test_py_compile failure on macOS Catalina (GH-17636)
https://github.com/python/cpython/commit/5f2c1345a79f205c680ed6e0a6ed44199546d79e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:24:02 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 17 Dec 2019 09:24:02 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576574642.71.0.13558876803.issue38295@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3dbfe0ac93ce031a23342a62edd39506bcdaea0e by Miss Islington (bot) in branch '3.7':
bpo-38295: prevent test_relative_path of test_py_compile failure on macOS Catalina (GH-17636)
https://github.com/python/cpython/commit/3dbfe0ac93ce031a23342a62edd39506bcdaea0e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:26:15 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Dec 2019 09:26:15 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576574775.2.0.880289599513.issue38295@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 5a9b69732ec19b04de459af890bcc26b83d979c5 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-38295: prevent test_relative_path of test_py_compile failure on macOS Catalina (GH-17636) (GH-17638)
https://github.com/python/cpython/commit/5a9b69732ec19b04de459af890bcc26b83d979c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:39:33 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Dec 2019 09:39:33 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576575573.37.0.147281818762.issue38295@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

For master and 3.9.0a2, equivalent workaround was included in a76ba362c4d86adf5e7f8254398135d12d7afd25 (bpo-39041 / GH-17594).

While these changes prevent the specific test failure, they point to more general issues with use of relative paths on macOS particularly with temp files and with 10.15 Catalina. More a bit later ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:45:27 2019
From: report at bugs.python.org (jvoisin)
Date: Tue, 17 Dec 2019 09:45:27 +0000
Subject: [issue39067] EOFError in tarfile.open
In-Reply-To: <1576506105.27.0.112129461214.issue39067@roundup.psfhosted.org>
Message-ID: <1576575927.6.0.597533842472.issue39067@roundup.psfhosted.org>


jvoisin <jvoisin at google.com> added the comment:

Does it means that the right? way to process untrusted tar files is
to wrap every call to functions from tarfile.py in a `try: ? except Exception:` block?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39067>
_______________________________________

From report at bugs.python.org  Tue Dec 17 05:59:08 2019
From: report at bugs.python.org (Bo Anderson)
Date: Tue, 17 Dec 2019 10:59:08 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576580348.95.0.301730873247.issue38295@roundup.psfhosted.org>


Bo Anderson <mail at boanderson.me> added the comment:

Indeed. The issue can be trivially reproduced with:

```
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>
#include <unistd.h>

int main()
{
  char buf[255];
  printf("Current dir: %s\n", getcwd(buf, 255));

  int fd = open("../../tmp/test.txt", O_WRONLY | O_CREAT);
  if (fd < 0)
  {
    printf("errno %d\n", errno);
    return 1;
  }
  close(fd);
  printf("Success\n");
  return 0;
}
```

and running it in /private/tmp.

I filed FB7467762 at the end of November. Downstream projects meanwhile are working around the issue by resolving the file path before passing it into `open`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 06:39:46 2019
From: report at bugs.python.org (AVicennA)
Date: Tue, 17 Dec 2019 11:39:46 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576582786.89.0.783739475458.issue39059@roundup.psfhosted.org>


AVicennA <tural.jalilov.92 at gmail.com> added the comment:

@mark.dickinson:

You asked some questions, then, I also asked you about solving this problem. It seems to me you just love to talk.. I just answered to your questions. If "this isn't the right forum for that discussion" as you mean, it concerns you too. When you ask it's right, but when I answer it's wrong place to discuss ?! I can change this line of my post - "In this case, whatever the range the full right result is a return" to " In this case, sometimes right result can be return like a round". round function also not work properly, my_round too. Each of them must be used in its place. In the end I wanna say that, if you want to discuss this further,  please, we can continue conversation in mailing list or where you want. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39059>
_______________________________________

From report at bugs.python.org  Tue Dec 17 06:40:42 2019
From: report at bugs.python.org (Riccardo Polignieri)
Date: Tue, 17 Dec 2019 11:40:42 +0000
Subject: [issue38671] pathlib.Path.resolve(strict=False) returns relative path
 on Windows if the entry does not exist
In-Reply-To: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>
Message-ID: <1576582842.29.0.158691010185.issue38671@roundup.psfhosted.org>


Change by Riccardo Polignieri <ric.pol at libero.it>:


----------
nosy: +ricpol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38671>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:02:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 12:02:28 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1576584148.02.0.425565461888.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 630c8df5cf126594f8c1c4579c1888ca80a29d59 by Victor Stinner in branch 'master':
bpo-38858: Small integer per interpreter (GH-17315)
https://github.com/python/cpython/commit/630c8df5cf126594f8c1c4579c1888ca80a29d59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:46:43 2019
From: report at bugs.python.org (Jasper Spaans)
Date: Tue, 17 Dec 2019 12:46:43 +0000
Subject: [issue39073] email regression in 3.8: folding
Message-ID: <1576586803.42.0.942657577592.issue39073@roundup.psfhosted.org>


New submission from Jasper Spaans <jasper at startmail.com>:

big-bob:t spaans$ cat fak.py
import sys

from email.message import EmailMessage
from email.policy import SMTP
from email.headerregistry import Address

msg = EmailMessage(policy=SMTP)

a = Address(display_name='Extra Extra Read All About It This Line Does Not Fit In 80 Characters So Should Be Wrapped <dev at local>\r\nX:', addr_spec='evil at local')
msg['To'] = a
print(sys.version)
print(msg.as_string())
big-bob:t spaans$ python3.5 fak.py
3.5.2 (default, Jul 16 2019, 13:40:43) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)]
To: "Extra Extra Read All About It This Line Does Not Fit In 80 Characters So Should Be Wrapped <dev at local>
X:" <evil at local>


big-bob:t spaans$ python3.8 fak.py
3.8.0 (default, Dec 17 2019, 13:32:18) 
[Clang 11.0.0 (clang-1100.0.33.16)]
To: Extra Extra Read All About It This Line Does Not Fit In 80 Characters So
 Should Be Wrapped <dev at local>
X: <evil at local>

----------
components: email
messages: 358544
nosy: barry, jap, r.david.murray
priority: normal
severity: normal
status: open
title: email regression in 3.8: folding
type: security
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39073>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:50:18 2019
From: report at bugs.python.org (Jasper Spaans)
Date: Tue, 17 Dec 2019 12:50:18 +0000
Subject: [issue39073] email regression in 3.8: folding
In-Reply-To: <1576586803.42.0.942657577592.issue39073@roundup.psfhosted.org>
Message-ID: <1576587018.41.0.287474092044.issue39073@roundup.psfhosted.org>


Jasper Spaans <jasper at startmail.com> added the comment:

As can be seen above, 3.5 wraps the realname in a double quote, but 3.8 fails to do so. Note that 3.5 also does not add a whitespace in front of the line starting with "X:", so it is also not merged with the previous line when parsing.

I guess we'll have to disallow \r and \n in displaynames for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39073>
_______________________________________

From report at bugs.python.org  Tue Dec 17 08:36:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 13:36:00 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576589760.61.0.103211610386.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17108
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17640

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:04:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 14:04:41 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576591481.68.0.360167333762.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17109
pull_request: https://github.com/python/cpython/pull/17641

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:17:04 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 14:17:04 +0000
Subject: [issue39059] Getting incorrect results in rounding procedures
In-Reply-To: <1576486251.62.0.0931327693234.issue39059@roundup.psfhosted.org>
Message-ID: <1576592224.15.0.0788898886116.issue39059@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/issue39059>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:31:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 14:31:35 +0000
Subject: [issue37421] Some tests leak temporary files
In-Reply-To: <1561588455.96.0.166877646344.issue37421@roundup.psfhosted.org>
Message-ID: <1576593095.82.0.830432471555.issue37421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17110
pull_request: https://github.com/python/cpython/pull/17641

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37421>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:41:27 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 17 Dec 2019 14:41:27 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576593687.87.0.363370078535.issue38295@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

You don't even need a C program to reproduce:

$ cd /private/tmp
$ touch ../../foo.txt
touch: ../../tmp/foo.txt: No such file or directory

And the "cd" is optional, I get the same error from my home directory (/Users/ronald). 

All of this on macOS 10.15.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:07:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 15:07:13 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576595233.55.0.839939588808.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I managed to reproduce the issue on the RHEL8 worker using:

* terminal 1: ./python -u -m test --fail-env-changed test_concurrent_futures -v -m ProcessPoolSpawnProcessPoolExecutorTest -F -j 15
* terminal 2: ./python -m test -j4 -u all -F -r

I can still reproduce the issue with PR 17641 fix, so it's not enough.

I also applied PR 17640 and 2 extra changes:

diff --git a/Lib/multiprocessing/managers.py b/Lib/multiprocessing/managers.py
index 1f9c2daa25..dbbf84b3d2 100644
--- a/Lib/multiprocessing/managers.py
+++ b/Lib/multiprocessing/managers.py
@@ -661,7 +661,7 @@ class BaseManager(object):
             except Exception:
                 pass
 
-            process.join(timeout=1.0)
+            process.join(timeout=0.1)
             if process.is_alive():
                 util.info('manager still alive')
                 if hasattr(process, 'terminate'):
diff --git a/Lib/test/support/__init__.py b/Lib/test/support/__init__.py
index 215bab8131..110c7f945e 100644
--- a/Lib/test/support/__init__.py
+++ b/Lib/test/support/__init__.py
@@ -2399,6 +2399,7 @@ def reap_children():
 
     # Reap all our dead child processes so we don't leave zombies around.
     # These hog resources and might be causing some of the buildbots to die.
+    time.sleep(0.5)
     while True:
         try:
             # Read the exit status of any child process which already completed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:15:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 15:15:31 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576595731.38.0.517720047335.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Example of failure, with additional debug prints:

                                                                                                                                                                
0:01:02 load avg: 42.13 [ 38/1] test_concurrent_futures failed (env changed)                                                                                                                                                                  
test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.00s reap_children                                                                                                                       
ok                                                                                                                                                                                                                                            
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 3.86s reap_children                                                                                                                
ok                                                                                                                                                                                                                                            
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.22s reap_children                                                                                                                  
ok                                                                                                                                                                                                                                            
test_submit (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.26s reap_children                                                                                                                                    
ok                                                                                                                                                                                                                                            
test_submit_keyword (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.59s reap_children                                                                                                                            
ok                                                                                                                                                                                                                                            
test_traceback (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.60s reap_children                                                                                                                                 
ok                                                                                                                                                                                                                                           
MP cleanup: cleanup process                                                                                                   
MP cleanup: stop forkserver                                                                                                   
MP cleanup: stop res track                                                                                                  
MP cleanup: run finalizers                                                                                                  
reap_children                                                                                                                 
                                                                                                                              
----------------------------------------------------------------------                                                        
                                                                                                                            
Ran 6 tests in 17.210s                                                                                                      
                                                                                                                              
OK                                                                                                                            
reap_children                                                                                                                 
Warning -- reap_children() reaped child process 4992                                                                        
Warning -- multiprocessing.process._dangling was modified by test_concurrent_futures                                        
  Before: set()                                                                                                               
  After:  {<weakref at 0x7fedc87bc7d0; to 'SpawnProcess' at 0x7fedc7abcd70>}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:20:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 15:20:40 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576596040.13.0.724120500664.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I can reproduce the issue with the following match file:

test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest.test_no_stale_references
test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest.test_ressources_gced_in_workers
test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest.test_shutdown_race_issue12456

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:36:47 2019
From: report at bugs.python.org (Bo Anderson)
Date: Tue, 17 Dec 2019 15:36:47 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576597007.7.0.300560397918.issue38295@roundup.psfhosted.org>


Bo Anderson <mail at boanderson.me> added the comment:

> You don't even need a C program to reproduce

Indeed, touch is built upon the POSIX file API (unless Apple modified it). The idea for the Apple bug report was to show it happening at a low level and not specific to a given tool.

> And the "cd" is optional, I get the same error from my home directory

Yes, /private/tmp is just an example but I'd be cautious saying the same happens everywhere. You won't be able to reproduce the issue if your current directory is /usr.

/private/tmp, your home directory, etc. are all "firmlinked" to /System/Volumes/Data in Catalina. /System/Volumes/Data/private/tmp exists but /System/Volumes/Data/tmp doesn't exist. This shouldn't really be an issue as the idea of firmlinks is to make the /System/Volumes/Data invisible and thus you should be able to relatively go back up to the /System/Volumes/Data and be transported back to the root directory, where you can find the /tmp symlink (and indeed that works fine with `ls`). Evidently that doesn't seem to work properly for file operations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:51:34 2019
From: report at bugs.python.org (Adam)
Date: Tue, 17 Dec 2019 15:51:34 +0000
Subject: [issue39074] Threading memory leak in _shutdown_locks for non-daemon
 threads
Message-ID: <1576597894.7.0.119079561961.issue39074@roundup.psfhosted.org>


New submission from Adam <adam.jgrant at gmail.com>:

When running 3.7, we noticed a memory leak in threading._shutdown_locks when non-deamon threads are started but "join()" or "is_alive()" is never called. Here's a test to illustrate the growth:

=========
import threading
import time
import tracemalloc

def test_leaking_locks():
    tracemalloc.start(10)
    snap1 = tracemalloc.take_snapshot()
    def print_things():
        print('.', end='')

    for x in range(500):
        t = threading.Thread(target=print_things)
        t.start()

    time.sleep(5)
    print('')
    gc.collect()
    snap2 = tracemalloc.take_snapshot()
    filters = []
    for stat in snap2.filter_traces(filters).compare_to(snap1.filter_traces(filters), 'traceback')[:10]:
        print("New Bytes: {}\tTotal Bytes {}\tNew blocks: {}\tTotal blocks: {}: ".format(stat.size_diff, stat.size, stat.count_diff ,stat.count))
        for line in stat.traceback.format():
            print(line)

=========

=========
Output in v3.6.8:

New Bytes: 840	Total Bytes 840	New blocks: 1	Total blocks: 1: 
  File "/usr/local/lib/python3.6/threading.py", line 884
    self._bootstrap_inner()
New Bytes: 608	Total Bytes 608	New blocks: 4	Total blocks: 4: 
  File "/usr/local/lib/python3.6/tracemalloc.py", line 387
    self.traces = _Traces(traces)
  File "/usr/local/lib/python3.6/tracemalloc.py", line 524
    return Snapshot(traces, traceback_limit)
  File "/gems/tests/integration/endpoint_connection_test.py", line 856
    snap1 = tracemalloc.take_snapshot()
  File "/usr/local/lib/python3.6/site-packages/_pytest/python.py", line 198
    testfunction(**testargs)
  File "/usr/local/lib/python3.6/site-packages/pluggy/callers.py", line 187
    res = hook_impl.function(*args)
  File "/usr/local/lib/python3.6/site-packages/pluggy/manager.py", line 87
    firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
  File "/usr/local/lib/python3.6/site-packages/pluggy/manager.py", line 93
    return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/local/lib/python3.6/site-packages/pluggy/hooks.py", line 286
    return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/local/lib/python3.6/site-packages/_pytest/python.py", line 1459
    self.ihook.pytest_pyfunc_call(pyfuncitem=self)
  File "/usr/local/lib/python3.6/site-packages/_pytest/runner.py", line 111
    item.runtest()
==========
Output in v3.7.4:

New Bytes: 36000	Total Bytes 36000	New blocks: 1000	Total blocks: 1000: 
  File "/usr/local/lib/python3.7/threading.py", line 890
    self._bootstrap_inner()
  File "/usr/local/lib/python3.7/threading.py", line 914
    self._set_tstate_lock()
  File "/usr/local/lib/python3.7/threading.py", line 904
    self._tstate_lock = _set_sentinel()
New Bytes: 32768	Total Bytes 32768	New blocks: 1	Total blocks: 1: 
  File "/usr/local/lib/python3.7/threading.py", line 890
    self._bootstrap_inner()
  File "/usr/local/lib/python3.7/threading.py", line 914
    self._set_tstate_lock()
  File "/usr/local/lib/python3.7/threading.py", line 909
    _shutdown_locks.add(self._tstate_lock)
=================

It looks like this commit didn't take into account the tstate_lock cleanup that happens in the C code, and it's not removing the _tstate_lock of completed threads from the _shutdown_locks once the thread finishes, unless the code manually calls "join()" or "is_alive()" on the thread:

https://github.com/python/cpython/commit/468e5fec8a2f534f1685d59da3ca4fad425c38dd

Let me know if I can provide more clarity on this!

----------
messages: 358551
nosy: krypticus
priority: normal
severity: normal
status: open
title: Threading memory leak in _shutdown_locks for non-daemon threads
type: resource usage
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39074>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:52:50 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 15:52:50 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1576292881.15.0.856522308314.issue37224@roundup.psfhosted.org>
Message-ID: <CALFfu7Bsykz9zaW0tPWofGxTsr_xXoduugHj=-1LUjU+Q+SLiA@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Fri, Dec 13, 2019 at 8:08 PM Kyle Stanley <report at bugs.python.org> wrote:
> Yeah, I named it "_PyInterpreterIsFinalizing" and it's within Include/cpython. Definitely open
> to suggestions on the name though, it's basically just a private getter for interp->finalizing.

For a struct-specific getter we usually end the prefix with an
underscore: _PyInterpreter_IsFinalizing.  Otherwise, that's the same
name I would have used. :)

> Oh, awesome! In that case, I'll do some more rigorous testing before opening the PR then;
> [snip]
> This might be a bit of a time consuming process, but I should have time in the next week
> or so to work on it.

No worries (or hurries).  Just request a review from me when you're
ready.  Thanks again for working on this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:21:21 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 16:21:21 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
Message-ID: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

types.SimpleNamespace was added in 3.3 (for use in sys.implementation; see PEP 421), which predates the change to preserving insertion order in dict.  At the time we chose to sort the attributes in the repr, both for ease of reading and for a consistent output.

The question is, should SimpleNamespace stay as it is (sorted repr) or should it show the order in which attributes were added?

On the one hand, alphabetical order can be useful since it makes it easier for readers to find attributes, especially when there are many.  However, for other cases it is helpful for the repr to show the order in which attributes were added.

FWIW, I favor changing the ordering in the repr to insertion-order.  Either is relatively trivial to get after the fact (whether "sorted(vars(ns))" or "list(vars(ns))"), so I don't think any folks that benefit from alphabetical order will be seriously impacted.

----------
components: Interpreter Core
messages: 358553
nosy: eric.snow
priority: normal
severity: normal
status: open
title: types.SimpleNamespace should preserve attribute ordering (?)
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:24:41 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 16:24:41 +0000
Subject: [issue39058] argparse should preserve argument ordering in Namespace
In-Reply-To: <1576448164.39.0.171350779582.issue39058@roundup.psfhosted.org>
Message-ID: <CALFfu7Ao2=MPM9+n0T3hUw0fApX24xDcHp0QdDu8OYAMq6Ed5A@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Currently, Namespace() objects sort the attributes in the __repr__.  This is annoying because argument
> order matters and because everywhere else in the module we preserve order (i.e. users see help in the
> order that arguments are added).

Hmm, I was going to suggest switching to types.SimpleNamespace, but
realized we sort that repr too (likely for the same reason).  I've
opened issue #39075 to address that.

In writing up that issue, I considered that a sorted repr can be
useful in some cases.  However, I don't think any of those cases
really apply here.

Anyway, I agree with your conclusion. :)

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39058>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:30:05 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 16:30:05 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1576600205.58.0.213005479483.issue39075@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:34:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 17 Dec 2019 16:34:19 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1576600459.8.0.70352022581.issue39033@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +17111
pull_request: https://github.com/python/cpython/pull/17642

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:35:51 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 16:35:51 +0000
Subject: [issue39076] Use types.SimpleNamespace for argparse.Namespace
Message-ID: <1576600551.73.0.829151608014.issue39076@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

types.SimpleNamespace does pretty much exactly the same thing as argparse.Namespace.  We should have the latter subclass the former.  I expect the only reason that wasn't done before is because SimpleNamespace is newer.

The only thing argparse.Namespace does differently is it supports the contains() builtin.  So the subclass would look like this:

class Namespace(types.SimpleNamespace):
    """..."""
    def __contains__(self, key):
        return key in self.__dict__

Alternately, we could add __contains__() to SimpleNamespace and then the subclass would effectively have an empty body.

----------
components: Library (Lib)
messages: 358555
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Use types.SimpleNamespace for argparse.Namespace
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39076>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:37:11 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 16:37:11 +0000
Subject: [issue39058] argparse should preserve argument ordering in Namespace
In-Reply-To: <1576448164.39.0.171350779582.issue39058@roundup.psfhosted.org>
Message-ID: <1576600631.85.0.96177108195.issue39058@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, I've also opened issue #39076 about subclassing types.SimpleNamespace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39058>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:42:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 17 Dec 2019 16:42:13 +0000
Subject: [issue39076] Use types.SimpleNamespace for argparse.Namespace
In-Reply-To: <1576600551.73.0.829151608014.issue39076@roundup.psfhosted.org>
Message-ID: <1576600933.37.0.943859447832.issue39076@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39076>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:46:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 17 Dec 2019 16:46:26 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1576601186.15.0.53984733363.issue39075@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/issue39075>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:09:19 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 17:09:19 +0000
Subject: [issue39042] Use the runtime's main thread ID in the threading module.
In-Reply-To: <1576275682.19.0.998306709118.issue39042@roundup.psfhosted.org>
Message-ID: <1576602559.16.0.995481992445.issue39042@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Hmm, I wonder if this should be considered a regression in 3.8.  As demonstrated in issue38904, the following code changed behavior as of 3.8, under certain conditions:


import signal
import threading

def int_handler():
   ...

if threading.current_thread() == threading.main_thread():
    signal.signal(signal.SIGINT, int_handler)


Note the specific conditions:

* threading and signal have not been imported yet
* the current thread when the module is *imported* is not the main thread (this only affects folks embedding Python)

Also note that the only other help we offer is a "private" function in the C-API: _PyOS_IsMainThread().  That would have given the correct answer, but we do not expect users to call it, and it doesn't help them from Python code anyway.

Also, the same problem existed pre-3.8 if signal and threading were imported in different threads before the above script ran.

Finally, I'm (mostly) confident that this would be a backward-compatible fix.

What do you think about this being a 3.8 regression, ?ukasz?

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39042>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:10:52 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2019 17:10:52 +0000
Subject: [issue38904] "signal only works in main thread" in main thread
In-Reply-To: <CAJLv-k_Y3_7Jd7yoXYY8nZsyW2CoPO5V0g_8GhzAJ+ELw8yi7g@mail.gmail.com>
Message-ID: <CALFfu7CSAn3MjaeO3NOJ5vSHeQjBjmRYi8uh8JpEwXujUuY2Kg@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

So resolving issue39042 would be enough, particularly if we backported
the change to 3.8?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38904>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:14:27 2019
From: report at bugs.python.org (Richard Warfield)
Date: Tue, 17 Dec 2019 17:14:27 +0000
Subject: [issue38904] "signal only works in main thread" in main thread
In-Reply-To: <CALFfu7CSAn3MjaeO3NOJ5vSHeQjBjmRYi8uh8JpEwXujUuY2Kg@mail.gmail.com>
Message-ID: <CAJLv-k_XC1K-MrE0-SEv37dAix248LCiGjf6AOjS79uzre6-Zw@mail.gmail.com>


Richard Warfield <warfield at gmail.com> added the comment:

I think so, yes.

On Wed, Dec 18, 2019 at 1:10 AM Eric Snow <report at bugs.python.org> wrote:

>
> Eric Snow <ericsnowcurrently at gmail.com> added the comment:
>
> So resolving issue39042 would be enough, particularly if we backported
> the change to 3.8?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38904>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38904>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:37:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 17:37:45 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576604265.98.0.750545809448.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9707e8e22d80ca97bf7a9812816701cecde6d226 by Victor Stinner in branch 'master':
bpo-38546: multiprocessing tests stop the resource tracker (GH-17641)
https://github.com/python/cpython/commit/9707e8e22d80ca97bf7a9812816701cecde6d226


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:48:02 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Tue, 17 Dec 2019 17:48:02 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
Message-ID: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>


New submission from Michael Amrhein <michael at adrhinum.de>:

The __format__ methods of int, float and Decimal (C and Python implementation) do not interpret the Format Specification Mini-Language in the same way:

>>> import decimal as cdec
... cdec.__file__
...
'/usr/lib64/python3.6/decimal.py'
>>> import _pydecimal as pydec
... pydec.__file__
...
'/usr/lib64/python3.6/_pydecimal.py'

>>> i = -1234567890
... f = float(i)
... d = cdec.Decimal(i)
... p = pydec.Decimal(i)
...
>>> # Case 1: no fill, no align, no zeropad
... fmt = "28,"
>>> format(i, fmt)
'              -1,234,567,890'
>>> format(f, fmt)
'            -1,234,567,890.0'
>>> format(d, fmt)
'              -1,234,567,890'
>>> format(p, fmt)
'              -1,234,567,890'

>>> # Case 2: no fill, no align, but zeropad
... fmt = "028,"
>>> format(i, fmt)
'-000,000,000,001,234,567,890'
>>> format(f, fmt)
'-0,000,000,001,234,567,890.0'
>>> format(d, fmt)
'-000,000,000,001,234,567,890'
>>> format(p, fmt)
'-000,000,000,001,234,567,890'

>>> # Case 3: no fill, but align '>' + zeropad
... fmt = ">028,"
>>> format(i, fmt)
'00000000000000-1,234,567,890'
>>> format(f, fmt)
'000000000000-1,234,567,890.0'
>>> format(d, fmt)
ValueError: invalid format string
>>> format(p, fmt)
ValueError: Alignment conflicts with '0' in format specifier: >028,

>>> # Case 4: no fill, but align '=' + zeropad
... fmt = "=028,"
>>> format(i, fmt)
'-000,000,000,001,234,567,890'
>>> format(f, fmt)
'-0,000,000,001,234,567,890.0'
>>> format(d, fmt)
ValueError: invalid format string
>>> format(p, fmt)
ValueError: Alignment conflicts with '0' in format specifier: =028,

>>> # Case 5: fill '0', align '=' + zeropad
... fmt = "0=028,"
>>> format(i, fmt)
'-000,000,000,001,234,567,890'
>>> format(f, fmt)
'-0,000,000,001,234,567,890.0'
>>> format(d, fmt)
ValueError: invalid format string
>>> format(p, fmt)
ValueError: Fill character conflicts with '0' in format specifier: 0=028,

>>> # Case 6: fill ' ', align '=' + zeropad
... fmt = " =028,"
>>> format(i, fmt)
'-              1,234,567,890'
>>> format(f, fmt)
'-            1,234,567,890.0'
>>> format(d, fmt)
ValueError: invalid format string
>>> format(p, fmt)
ValueError: Fill character conflicts with '0' in format specifier:  =028,

>>> # Case 7: fill ' ', align '>' + zeropad
... fmt = " >028,"
>>> format(i, fmt)
'              -1,234,567,890'
>>> format(f, fmt)
'            -1,234,567,890.0'
>>> format(d, fmt)
ValueError: invalid format string
>>> format(p, fmt)
ValueError: Fill character conflicts with '0' in format specifier:  >028,

>>> # Case 8: fill ' ', no align, but zeropad
... fmt = " 028,"
>>> format(i, fmt)
'-000,000,000,001,234,567,890'
>>> format(f, fmt)
'-0,000,000,001,234,567,890.0'
>>> format(d, fmt)
'-000,000,000,001,234,567,890'
>>> format(p, fmt)
'-000,000,000,001,234,567,890'

>>> # Case 9: fill '_', no align, but zeropad
... fmt = "_028,"
>>> format(i, fmt)
ValueError: Invalid format specifier
>>> format(f, fmt)
ValueError: Invalid format specifier
>>> format(d, fmt)
ValueError: invalid format string
>>> format(p, fmt)
ValueError: Invalid format specifier: _028,

>>> # Case 10: fill '_', no align, no zeropad
... fmt = "_28,"
>>> format(i, fmt)
ValueError: Invalid format specifier
>>> format(f, fmt)
ValueError: Invalid format specifier
>>> format(d, fmt)
ValueError: Invalid format string
>>> format(p, fmt)
ValueError: Invalid format specifier: _28,

>>> # Case 11: fill '0', align '>', no zeropad
... fmt = "0>28,"
>>> format(i, fmt)
'00000000000000-1,234,567,890'
>>> format(f, fmt)
'000000000000-1,234,567,890.0'
>>> format(d, fmt)
'00000000000000-1,234,567,890'
>>> format(p, fmt)
'00000000000000-1,234,567,890'

>>> # Case 12: fill '0', align '<', no zeropad
... fmt = "0<28,"
>>> format(i, fmt)
'-1,234,567,89000000000000000'
>>> format(f, fmt)
'-1,234,567,890.0000000000000'
>>> format(d, fmt)
'-1,234,567,89000000000000000'
>>> format(p, fmt)
'-1,234,567,89000000000000000'

>>> # Case 13: fixed-point notation w/o precision
... fmt = "f"
>>> format(f, fmt)
'-1234567890.000000'
>>> format(d, fmt)
'-1234567890'
>>> format(p, fmt)
'-1234567890'

Case 1 & 2:
For a format string not giving a type ("None") the spec says: "Similar to 'g', except that fixed-point notation, when used, has at least one digit past the decimal point." float does follow this rule, Decimal does not.
While this may be regarded as reasonable, it should be noted in the doc. 

Cases 3 to 7:
Both implementations of Decimal do not allow to combine align and zeropad, while int and float do. When also fill is given, int and float ignore zeropad, but use '0' instead of ' ' (default), if not. 
(For an exception see the following case.)
The spec says: "When no explicit alignment is given, preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='." That does not explicitly give a rule for align + zeropad together, but IMHO it suggests to use zeropad *only* if no align is given and that it should *not* overwrite the default fill ' '.

Cases 8 - 10:
The syntax given by the spec IMHO says: no fill without align! There is no mention of an exception for a blank as fill.

Case 11 & 12:
While all implementation "agree" here, combining '0' as fill with align other than '=' gives really odd results.
See also https://bugs.python.org/issue17247.

Case 13:
For fixed-point notation the spec says: "The default precision is 6." float does follow this rule, Decimal does not.
While this may be regarded as reasonable, it should be noted in the doc.

----------
messages: 358561
nosy: mamrhein
priority: normal
severity: normal
status: open
title: Numeric formatting inconsistent between int, float and Decimal
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:51:54 2019
From: report at bugs.python.org (=?utf-8?q?Veith_R=C3=B6thlingsh=C3=B6fer?=)
Date: Tue, 17 Dec 2019 17:51:54 +0000
Subject: [issue39078] __function.__defaults__ breaks for __init__ of
 dataclasses with default factory
Message-ID: <1576605114.21.0.115662739436.issue39078@roundup.psfhosted.org>


New submission from Veith R?thlingsh?fer <veith21 at gmail.com>:

When creating a dataclass with a default that is a field with a default factory, the factory is not correctly resolved in cls.__init__.__defaults__. It evaluates to the __repr__ of dataclasses._HAS_DEFAULT_FACTORY_CLASS, which is "<factory>".

The expected behavior would be to have a value of whatever the default factory produces as a default.

This causes issues for example when using inspect.BoundParameters.apply_defaults() on the __init__ of such a dataclass.

Code to reproduce:

```
from dataclasses import dataclass, field
from typing import Any, Dict


@dataclass()
class Test:
    a: int
    b: Dict[Any, Any] = field(default_factory=dict)

print(Test.__init__.__defaults__)  # <factory>
```

The affected packages are on a high-level dataclasses, on a lower level the issue is in the builtin __function.__defaults__.

----------
components: C API
messages: 358562
nosy: RunOrVeith
priority: normal
severity: normal
status: open
title: __function.__defaults__ breaks for __init__ of dataclasses with default factory
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39078>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:54:02 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 17:54:02 +0000
Subject: [issue39078] __function.__defaults__ breaks for __init__ of
 dataclasses with default factory
In-Reply-To: <1576605114.21.0.115662739436.issue39078@roundup.psfhosted.org>
Message-ID: <1576605242.7.0.135610263642.issue39078@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39078>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:10:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2019 18:10:16 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1576606216.52.0.0904951602424.issue39075@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

We usually do not iterate all attributes, and dir() always sort attribute names.

----------
nosy: +rhettinger, serhiy.storchaka, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:19:21 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 18:19:21 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576606761.67.0.139117317713.issue39077@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:29:58 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 18:29:58 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576607398.94.0.128003823371.issue39077@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/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:52:27 2019
From: report at bugs.python.org (Alfred Morgan)
Date: Tue, 17 Dec 2019 18:52:27 +0000
Subject: [issue39079] help() modifies the string module
Message-ID: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>


New submission from Alfred Morgan <alfred at 54.org>:

import string
a = string.letters
help(int)
b = string.letters
a == b # False

----------
components: Library (Lib)
messages: 358564
nosy: Zectbumo
priority: normal
severity: normal
status: open
title: help() modifies the string module
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:04:04 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 19:04:04 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576609444.84.0.921801715225.issue39077@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report. I think most of this is a documentation issue: we either need to make clear that the formatting documentation applies only to the float type and that Decimal follows its own rules (usually for good reason, namely that it's required to follow Mike Cowlishaw's General Decimal Arithmetic Specification), or adjust the main string formatting documentation to make sure it covers the Decimal type as well as float.

Michael: thank you for including both the _pydecimal and decimal results here. Just to double check, I'm not seeing any differences between just those two here (other than the exact exception messages); are you seeing differences just between those two types that you think shouldn't exist?

In more detail:

Cases 1-2: these look like a documentation issue. The decimal behaviour is definitely desirable here: when possible, we want the string representation to preserve the information about the decimal exponent.

Case 3: This looks like a bug in the float formatting to me: the "0" prefix for the width implies "=" for the alignment, which conflicts with the explicit ">". But making something that previously worked a ValueError is hazardous; perhaps we can accept that in this case the explicitly-given alignment overrides the implicit "=", and modify decimal accordingly.

Case 4: This is a weaker case than case 3, where the implicit alignment matches the explicitly given one; I think we should fix decimal to accept this, since there's no ambiguity.

Case 5: Same reasoning as case 4: let's fix decimal.

Case 6: Like case 3: there's a conflict between the implicit fill of "0" and the explicitly given fill of " ". Again, it seems reasonable to let the explicit win over the implicit here.

Case 7: like case 3 and case 6 combined; if we fix those, we might as well also fix this one for consistency, even though at that point the "0" prefix for the width is doing nothing at all.

Cases 8-10: the space in case 8 isn't being interpreted as a fill character here; it's being interpreted as the sign character. I don't think there's anything to fix for these cases.

Cases 11-12: I don't think there's anything to be fixed here: yes, padding on the right with zeros creates misleading results, but I don't think it's Python's job to prevent the user from doing that.

Case 13: This is a doc issue; without a precision, the Decimal output again tries to preserve the exponent information, while also ensuring that the value is printed in a form that doesn't use the exponent.


So cases 3-7 look like the only ones where we should consider changing the behaviour; the issue 17247 that you pointed to proposed tightening the behaviour for float to match Decimal, but I think it would be just as reasonable to loosen the Decimal behaviour to match float.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:04:33 2019
From: report at bugs.python.org (Manfred Kaiser)
Date: Tue, 17 Dec 2019 19:04:33 +0000
Subject: [issue39071] email.parser.BytesParser - parse and parsebytes work not
 equivalent
In-Reply-To: <1576571549.52.0.292971717442.issue39071@roundup.psfhosted.org>
Message-ID: <1576609473.97.0.302565941716.issue39071@roundup.psfhosted.org>


Manfred Kaiser <manfred.kaiser at logfile.at> added the comment:

I think, the best way is to fix the documentation. The reason is, when a developer rely to the behavior of the function but the behavior is changed, a program may work incorrect.

Just think about forensic stuff. If a hash value will be created with the "parsebytes" method and the behavior will be changed to match the behavior of the "parse" method, the the evidence can not be validated with the latest python versions.

We could add a comment to the documentation. For example "parsebytes parses the mail in a different way than parse, which may produce slightly different messages. If you rely on the same behavior for file and byte like objects you can use the parse method with BytesIO"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39071>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:07:50 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 19:07:50 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576609670.42.0.46216794265.issue39077@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report. I think most of this is a documentation issue: we either need to make clear that the formatting documentation applies only to the float type and that Decimal follows its own rules (usually for good reason, namely that it's required to follow Mike Cowlishaw's General Decimal Arithmetic Specification), or adjust the main string formatting documentation to make sure it covers the Decimal type as well as float.

Michael: thank you for including both the _pydecimal and decimal results here. Just to double check, I'm not seeing any differences between just those two here (other than the exact exception messages); are you seeing differences just between those two types that you think shouldn't exist?

In more detail:

Cases 1-2: these look like a documentation issue. The decimal behaviour is definitely desirable here: when possible, we want the string representation to preserve the information about the decimal exponent.

Case 3: This looks like a bug in the float formatting to me: the "0" prefix for the width implies "=" for the alignment, which conflicts with the explicit ">". But making something that previously worked a ValueError is hazardous; perhaps we can accept that in this case the explicitly-given alignment overrides the implicit "=", and modify decimal accordingly.

Case 4: This is a weaker case than case 3, where the implicit alignment matches the explicitly given one; I think we should fix decimal to accept this, since there's no ambiguity.

Case 5: Same reasoning as case 4: let's fix decimal.

Case 6: Like case 3: there's a conflict between the implicit fill of "0" and the explicitly given fill of " ". Again, it seems reasonable to let the explicit win over the implicit here.

Case 7: like case 3 and case 6 combined; if we fix those, we might as well also fix this one for consistency, even though at that point the "0" prefix for the width is doing nothing at all.

Cases 8-10: the space in case 8 isn't being interpreted as a fill character here; it's being interpreted as the sign character. I don't think there's anything to fix for these cases.

Cases 11-12: I don't think there's anything to be fixed here: yes, padding on the right with zeros creates misleading results, but I don't think it's Python's job to prevent the user from doing that.

Case 13: This is a doc issue; that

----------
nosy: +facundobatista, rhettinger, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:08:13 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 19:08:13 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576609693.43.0.31177052628.issue39077@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
Removed message: https://bugs.python.org/msg358567

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:52:54 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 19:52:54 +0000
Subject: [issue39078] __function.__defaults__ breaks for __init__ of
 dataclasses with default factory
In-Reply-To: <1576605114.21.0.115662739436.issue39078@roundup.psfhosted.org>
Message-ID: <1576612374.26.0.251059522206.issue39078@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The problem is that __init__ has to have a sentinel to know whether or not to call the default value. If the default were just "dict", should it call it, or is the passed in value really dict, in which case it doesn't get called?

dataclass()
class Test:
    a: int
    b: Dict[Any, Any] = field(default_factory=dict)

The generated __init__ looks like:

def __init__(self, a, b=_HAS_DEFAULT_FACTORY):
   self.a = a
   self.b = dict() if b is _HAS_DEFAULT_FACTORY else b

If it were:

def __init__(self, a, b=dict):
   self.a = a

Then what would the assignment to self.b look like? What if you instantiated an object as Test(0, dict)? You wouldn't want dict to get called. You need to differentiate between Test(0, dict) and Test(0). The former does not call b, but the latter does call b.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39078>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:55:39 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Dec 2019 19:55:39 +0000
Subject: [issue39070] Uninstalling 3.8.0 fails but it says it succeeds..
In-Reply-To: <1576539774.23.0.330588412038.issue39070@roundup.psfhosted.org>
Message-ID: <1576612539.78.0.0297256975703.issue39070@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Hi tuijatuulia

In your %TEMP% directory there should be a few sets of log files for Python. Would you be able to zip them up and attach them to this issue? That will help us figure out what hasn't worked for you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39070>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:10:29 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2019 20:10:29 +0000
Subject: [issue39071] email.parser.BytesParser - parse and parsebytes work not
 equivalent
In-Reply-To: <1576571549.52.0.292971717442.issue39071@roundup.psfhosted.org>
Message-ID: <1576613429.53.0.509320276884.issue39071@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem is that you are starting with different inputs.  unicode strings and bytes are different things, and so parsing them can produce different results.  The fact of that matter is that email messages are defined to be bytes, so parsing a unicode string pretending it is an email message is just asking for errors anyway.  The string parsing methods are really only provided for backward compatibility and historical reasons.

I thought this was clear from the existing documentation, but clearly it isn't :)  I'll review a suggested doc change, but the thing to explain is not that parse and parsebytes might produce different results, but that parsing email from strings is not a good idea and will likely produce unexpected results for anything except the simplest non-mime messages.

Note: the reason you got different checksums might have had to do with line ends, depending on how you calculated the checksums.  You should also consider using get_content and not get_payload.  get_payload has a weird legacy API that doesn't always do what you think it will, and that might be another source of checksum issues.  But really, parsing a unicode representation of a mime message is just likely to be buggy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39071>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:13:36 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2019 20:13:36 +0000
Subject: [issue39071] email.parser.BytesParser - parse and parsebytes work not
 equivalent
In-Reply-To: <1576571549.52.0.292971717442.issue39071@roundup.psfhosted.org>
Message-ID: <1576613616.83.0.974062255946.issue39071@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

All of which isn't to discount that you might have a found a bug, by the way, if you want to investigate further :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39071>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:24:21 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2019 20:24:21 +0000
Subject: [issue39073] email incorrect handling of crlf in Address objects.
In-Reply-To: <1576586803.42.0.942657577592.issue39073@roundup.psfhosted.org>
Message-ID: <1576614261.34.0.137998553615.issue39073@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Yes, \r\n should be disallowed in the arguments to Address.  I thought it already was, so that's a bug.  That bug produces the other apparent bug as well: because the X: was treated as a separate line, the previous header did not need double quotes so they are no longer added.

So there's no 3.8 specific bug here, but there is a bug.

----------
title: email regression in 3.8: folding -> email incorrect handling of crlf in Address objects.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39073>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:32:29 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2019 20:32:29 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576614749.77.0.782987151126.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

One more tweak to the test and we'll be good to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:36:32 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 17 Dec 2019 20:36:32 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576614992.26.0.844194823118.issue39079@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I am unable to reproduce this.

Can you double check that this occurs in the plain Python interpreter or IDLE, and provide a minimum reproducible example? (No third-party IDEs or interpreters, such as Jupyter.)

These guidelines may help:

https://en.wikipedia.org/wiki/Minimal_working_example

http://sscce.org/

https://stackoverflow.com/help/minimal-reproducible-example

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:05:28 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 21:05:28 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576616728.68.0.0266253895394.issue39079@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I *can* reproduce, on macOS 10.14.6, Python 2.7.17 (from macports).

Python 2.7.17 (default, Oct 20 2019, 14:46:50) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import string
>>> string.letters
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>> help(int)  # brings up pager; page through to the end

>>> string.letters
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:06:49 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Tue, 17 Dec 2019 21:06:49 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576616809.85.0.92458789694.issue39077@roundup.psfhosted.org>


Michael Amrhein <michael at adrhinum.de> added the comment:

Mark, I mostly agree with your classifications / proposals.
Regarding cases 3-7 I'd like to suggest a slightly different resolution:
Following my interpretation of the spec ("use zeropad *only* if no align is given"), "<020", ">020", "^020" and "=020" would be treated equivalent to "<20", ">20", "^20" and "=20":

format(12345, "<020") -> '-12345              ', not '-1234500000000000000'
format(12345, ">020") -> '              -12345', not '00000000000000-12345'
format(12345, "^020") -> '       -12345       ', not '0000000-123450000000'
format(12345, "=020") -> '-              12345', not '-0000000000000012345'

For '<', '>' and '^' I can't imagine any code depending on the current behaviour of int and float, so this change is unlikely to break anything. 
For '=' it might be reasonable to make an exception (and state it in the doc), so that "020", "=020", "0=020" and "0=20" are treated as equivalent.
For Decimal this would mean to loosen the behaviour, as you proposed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:08:15 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 21:08:15 +0000
Subject: [issue39078] __function.__defaults__ breaks for __init__ of
 dataclasses with default factory
In-Reply-To: <1576605114.21.0.115662739436.issue39078@roundup.psfhosted.org>
Message-ID: <1576616895.74.0.160900060289.issue39078@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I guess I could make the default value something like _CALLABLE(dict), but I'm not sure that would do you any good. But at least you could tell from the repr what it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39078>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:13:05 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 21:13:05 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576617185.01.0.681700134085.issue39079@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

With 2.7.16 on cygwin, I get:

>>> import string
>>> string.letters
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>> help(int)
>>> string.letters
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'

But given that there's only 2 weeks of support left for 2.7, I don't see this getting changed.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:20:41 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 21:20:41 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576617641.78.0.652083971804.issue39079@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's where `string.letters` is reassigned: https://github.com/python/cpython/blob/5f2c1345a79f205c680ed6e0a6ed44199546d79e/Modules/_localemodule.c#L136-L147

That code looks like it's exercised whenever setlocale is (or possibly just when LC_CTYPE is changed). I haven't yet figured out which part of the help machinery causes that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:21:32 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Dec 2019 21:21:32 +0000
Subject: [issue36500] Add "regen-*" equivalent projects for Windows builds
In-Reply-To: <1554164014.38.0.603917502843.issue36500@roundup.psfhosted.org>
Message-ID: <1576617692.85.0.457758639573.issue36500@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 9e36589d49c1d6b06c0239fa69e8274d7e89e375 by Steve Dower (Anthony Shaw) in branch 'master':
bpo-36500: Add --regen option to PCbuild/build.bat so Windows users can regen grammar, opcodes, tokens and symbols (GH-12654)
https://github.com/python/cpython/commit/9e36589d49c1d6b06c0239fa69e8274d7e89e375


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36500>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:22:45 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Tue, 17 Dec 2019 21:22:45 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576617765.93.0.117727945326.issue39077@roundup.psfhosted.org>


Michael Amrhein <michael at adrhinum.de> added the comment:

Mark, to answer your question regarding the two implementations of Decimals:
No, in the cases I stated above there are no differences in their behaviour.

In order to dig a bit deeper, I wrote a little test:

d = cdec.Decimal("1234567890.1234")
p = pydec.Decimal("1234567890.1234")
for fill in ('', ' ', '_'):
    for align in ('', '<', '>', '^', '='):
        for sign in ('', '-', '+', ' '):
            for zeropad in ('', '0'):
                for min_width in ('', '25'):
                    for thousands_sep in ('', ','):
                        for precision in ('', '.3', '.5'):
                            for ftype in ('', 'e', 'f', 'g'): 
                                fmt = f"{fill}{align}{sign}{zeropad}{min_width}{thousands_sep}{precision}{ftype}"
                                try:
                                    df = format(d, fmt)
                                except ValueError:
                                    df = "<ValueError>"
                                try:
                                    pf = format(p, fmt)
                                except ValueError:
                                    pf = "<ValueError>"
                                if df != pf:
                                    print(fmt, df, pf)

It did not reveal any differences. The two implementations are equivalent regarding the tested combinations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:22:55 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 21:22:55 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576617775.0.0.289464598677.issue39079@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> But given that there's only 2 weeks of support left for 2.7, I don't see this getting changed.

Agreed: I can't reproduce on Python 3, and it looks as though the offending code is gone from the codebase in Python 3, so this is pretty much just a historical oddity at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:30:35 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 21:30:35 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576618235.95.0.522591979719.issue39077@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Regarding cases 3-7 I'd like to suggest a slightly different resolution:

Hmm, yes. I was concentrating on the Decimal results, but I agree that these int/float results are disturbing:

>>> format(12345, "<020")
'12345000000000000000'
>>> format(12345.0, "<020")
'12345.00000000000000'
>>> format(12345, "^020")
'00000001234500000000'

I'm fine with an explicit *fill* character of zero producing misleading results; the user just gets what they ask for in that case. (And the filling could be happening in generic code that isn't aware of the numeric context any more, so it could be tricky to change.)

But having the pre-width 0 be interpreted this way is questionable. Eric: thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:32:08 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 17 Dec 2019 21:32:08 +0000
Subject: [issue39080] Inconsistency with Starred Expression line/col info
Message-ID: <1576618328.23.0.851602684205.issue39080@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

When a starred expression like *[0, 1] is parsed, the following AST gets generated:

Module(
    body=[
        Expr(
            value=Starred(
                value=List(
                    elts=[
                        Constant(
                            value=0,
                            kind=None,
                            lineno=1,
                            col_offset=2,
                            end_lineno=1,
                            end_col_offset=3,
                        ),
                        Constant(
                            value=1,
                            kind=None,
                            lineno=1,
                            col_offset=5,
                            end_lineno=1,
                            end_col_offset=6,
                        ),
                    ],
                    ctx=Load(),
                    lineno=1,
                    col_offset=1,
                    end_lineno=1,
                    end_col_offset=7,
                ),
                ctx=Load(),
                lineno=1,
                col_offset=0,
                end_lineno=1,
                end_col_offset=7,
            ),
            lineno=1,
            col_offset=0,
            end_lineno=1,
            end_col_offset=7,
        )
    ],
    type_ignores=[],
)


But, when a starred expression is an argument to a function call then the line/col info are wrong (end_col_offset is always equal to col_offset + 1):

Module(
    body=[
        Expr(
            value=Call(
                func=Name(
                    id="f", ctx=Load(), lineno=1, col_offset=0, end_lineno=1, end_col_offset=1
                ),
                args=[
                    Starred(
                        value=List(
                            elts=[
                                Constant(
                                    value=0,
                                    kind=None,
                                    lineno=1,
                                    col_offset=4,
                                    end_lineno=1,
                                    end_col_offset=5,
                                ),
                                Constant(
                                    value=1,
                                    kind=None,
                                    lineno=1,
                                    col_offset=7,
                                    end_lineno=1,
                                    end_col_offset=8,
                                ),
                            ],
                            ctx=Load(),
                            lineno=1,
                            col_offset=3,
                            end_lineno=1,
                            end_col_offset=9,
                        ),
                        ctx=Load(),
                        lineno=1,
                        col_offset=2,
                        end_lineno=1,
                        end_col_offset=9,
                    )
                ],
                keywords=[],
                lineno=1,
                col_offset=0,
                end_lineno=1,
                end_col_offset=10,
            ),
            lineno=1,
            col_offset=0,
            end_lineno=1,
            end_col_offset=10,
        )
    ],
    type_ignores=[],
)

----------
components: Interpreter Core
messages: 358584
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: Inconsistency with Starred Expression line/col info
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39080>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:32:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Dec 2019 21:32:57 +0000
Subject: [issue36500] Add "regen-*" equivalent projects for Windows builds
In-Reply-To: <1554164014.38.0.603917502843.issue36500@roundup.psfhosted.org>
Message-ID: <1576618377.33.0.639917991206.issue36500@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17112
pull_request: https://github.com/python/cpython/pull/17644

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36500>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:37:13 2019
From: report at bugs.python.org (paul j3)
Date: Tue, 17 Dec 2019 21:37:13 +0000
Subject: [issue39076] Use types.SimpleNamespace for argparse.Namespace
In-Reply-To: <1576600551.73.0.829151608014.issue39076@roundup.psfhosted.org>
Message-ID: <1576618633.33.0.934277493065.issue39076@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39076>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:40:08 2019
From: report at bugs.python.org (Bluebird)
Date: Tue, 17 Dec 2019 21:40:08 +0000
Subject: [issue39025] Windows Python Launcher does not update PATH to Scripts
 directory
In-Reply-To: <1576063856.43.0.431001018192.issue39025@roundup.psfhosted.org>
Message-ID: <1576618808.17.0.871213473739.issue39025@roundup.psfhosted.org>


Bluebird <phil at freehackers.org> added the comment:

Ok, I'll close my request if you do not think of any value in it. 

Py is such an elegant solution, I wish something as simple would also address this problem.

Virtual environement do have the downside of not coming directly with Python. In my work environment, extra Python packages are strongly discouraged and my colleagues are not proficient enough in the Python ecosystem to use venv.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39025>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:42:50 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Dec 2019 21:42:50 +0000
Subject: [issue36500] Add "regen-*" equivalent projects for Windows builds
In-Reply-To: <1554164014.38.0.603917502843.issue36500@roundup.psfhosted.org>
Message-ID: <1576618970.63.0.0134555917175.issue36500@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Adding just a couple of minor touch-ups in PR 17644, but otherwise thanks Anthony!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36500>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:43:03 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 17 Dec 2019 21:43:03 +0000
Subject: [issue39080] Inconsistency with Starred Expression line/col info
In-Reply-To: <1576618328.23.0.851602684205.issue39080@roundup.psfhosted.org>
Message-ID: <1576618983.92.0.299533174107.issue39080@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
keywords: +patch
pull_requests: +17113
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17645

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39080>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:45:28 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 21:45:28 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576619128.26.0.595732005929.issue39077@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure what you mean by the "pre-width 0". Is that the "0" here:

format_spec ::=  [[fill]align][sign][#][0][width][grouping_option][.precision][type]

?

And now that I write out the question, I'm sure that's what you mean.

PEP 3101 says "If the width field is preceded by a zero ('0') character, this enables zero-padding. This is equivalent to an alignment type of '=' and a fill character of '0'.". I don't see any other discussion of it in the PEP. In particular, what if you specify a different alignment type with the pre-width 0?

I believe this all originated in C's printf, via PEP 3101. Has anyone checked what C does?

But in any event, I don't think we can change the int formatting, in particular. There's no doubt someone who's relying on every little quirk. I'm less concerned about float and decimal, although we'd still need to be very careful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:48:32 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 21:48:32 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576619312.81.0.186811397237.issue39079@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For completeness, here's the path leading to the reassignment (after hacking in a raise to the appropriate place in _localemodule.c). It's a side-effect of calling `locale.getpreferredencoding`.

>>> help(int)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mdickinson/GitHub/python/cpython/Lib/site.py", line 445, in __call__
    import pydoc
  File "/Users/mdickinson/GitHub/python/cpython/Lib/pydoc.py", line 202, in <module>
    _encoding = locale.getpreferredencoding()
  File "/Users/mdickinson/GitHub/python/cpython/Lib/locale.py", line 616, in getpreferredencoding
    setlocale(LC_CTYPE, "")
  File "/Users/mdickinson/GitHub/python/cpython/Lib/locale.py", line 581, in setlocale
    return _setlocale(category, locale)
ValueError: about to reassign string.letters


So a minimal reproducer is something like:

Python 2.7.17 (default, Oct 20 2019, 14:46:50) 
[GCC 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import string, locale
>>> string.letters
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>> locale.getpreferredencoding()
'UTF-8'
>>> string.letters
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:48:45 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 21:48:45 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576619325.71.0.873170872512.issue39079@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

@Zectbumo: is this causing you any practical problem? Or is it just a curiosity?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:54:56 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 21:54:56 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576619696.92.0.252151337767.issue39077@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Eric]

> Is that the "0" here: [...]

Yes, sorry; that could have been clearer.

> In particular, what if you specify a different alignment type with the pre-width 0?

Right, that's the critical question here. For floats and ints, an explicitly-specified alignment type overrides the implicit "=". But Decimal raises. The Decimal behaviour seems more reasonable, but the float and int behaviours are more historically baked-in, and riskier to change.

And then there's a parallel question with the fill character: should an explicitly-given fill override the "0"-fill character that's implicit in that "[0]"? int and float say "yes". Decimal says "ValueError".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:10:31 2019
From: report at bugs.python.org (paul j3)
Date: Tue, 17 Dec 2019 22:10:31 +0000
Subject: [issue39058] argparse should preserve argument ordering in Namespace
In-Reply-To: <1576448164.39.0.171350779582.issue39058@roundup.psfhosted.org>
Message-ID: <1576620631.19.0.692742579814.issue39058@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

This patch changes the super class, _AttributeHolder.  ArgumentParser and Actions also inherit from this, though they have their own _get_kwargs methods, and so aren't affected by the sort and its removal.

I just had occasion on stackoverflow to discuss the order in which attributes are added.  A poster wanted to preserve the sys.argv order.

https://stackoverflow.com/questions/58904423/find-the-order-of-arguments-in-argparse-python3/58905067#58905067

Most attributes are added as defaults at the start of parsing - via a loop through parser._actions.  Predefining the namespace, SUPPRESS defaults, parser.set_defaults may alter this default order.

Anyways removing the sort makes sense, and the proposed change phrase "in the order attributes were added" is sufficiently general.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39058>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:12:05 2019
From: report at bugs.python.org (Jendrik Seipp)
Date: Tue, 17 Dec 2019 22:12:05 +0000
Subject: [issue13601] sys.stderr should be line-buffered when stderr is not a
 TTY
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1576620725.02.0.128666564999.issue13601@roundup.psfhosted.org>


Change by Jendrik Seipp <jendrikseipp at gmail.com>:


----------
keywords: +patch
pull_requests: +17114
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17646

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:14:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Dec 2019 22:14:19 +0000
Subject: [issue36500] Add "regen-*" equivalent projects for Windows builds
In-Reply-To: <1554164014.38.0.603917502843.issue36500@roundup.psfhosted.org>
Message-ID: <1576620859.64.0.399932422787.issue36500@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a9d0a6a1b932752873e04714c5dda707729078e4 by Steve Dower in branch 'master':
bpo-36500: Simplify PCbuild/build.bat and prevent path separator changing in comments (GH-17644)
https://github.com/python/cpython/commit/a9d0a6a1b932752873e04714c5dda707729078e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36500>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:14:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Dec 2019 22:14:36 +0000
Subject: [issue36500] Add "regen-*" equivalent projects for Windows builds
In-Reply-To: <1554164014.38.0.603917502843.issue36500@roundup.psfhosted.org>
Message-ID: <1576620876.86.0.326855491196.issue36500@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36500>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:17:59 2019
From: report at bugs.python.org (Jendrik Seipp)
Date: Tue, 17 Dec 2019 22:17:59 +0000
Subject: [issue13601] sys.stderr should be line-buffered when stderr is not a
 TTY
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1576621079.24.0.179607096445.issue13601@roundup.psfhosted.org>


Jendrik Seipp <jendrikseipp at gmail.com> added the comment:

I took the liberty of increasing the target version. It would be great if someone could review my patch for this issue at https://github.com/python/cpython/pull/17646 .

----------
nosy: +jendrik
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:21:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2019 22:21:52 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576621312.14.0.918985980984.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17115
pull_request: https://github.com/python/cpython/pull/17647

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:33:42 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 17 Dec 2019 22:33:42 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576622022.77.0.999813547426.issue39079@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's no reasonable way I can see to fix this. The reassignment of those string attributes is clearly intentional (it's even documented) and there's probably code somewhere that relies on it. I think the best we can do is close as "won't fix" though "not a bug" may be more accurate: the code is clearly behaving as intended and designed, even if the design is questionable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:35:43 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Tue, 17 Dec 2019 22:35:43 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576622143.15.0.0183250114771.issue39077@roundup.psfhosted.org>


Michael Amrhein <michael at adrhinum.de> added the comment:

>
> ... Has anyone checked what C does?
>

#include <stdio.h>
int main() {
    int i = -12345;
    double f = -12345.0;
    printf("%-020d\n", i);
    printf("%020d\n", i);
    printf("%20d\n", i);
    printf("%-020f\n", f);
    printf("%020f\n", f);
    printf("%20f\n", f);
    return 0;
}

Output:

-12345             
-0000000000000012345
              -12345
-12345.000000      
-000000012345.000000
       -12345.000000

https://en.cppreference.com/w/c/io/fprintf:

Each conversion specification has the following format:

  introductory % character 

  (optional) one or more flags that modify the behavior of the conversion: 

    -: the result of the conversion is left-justified within the field (by default it is right-justified)
    +: the sign of signed conversions is always prepended to the result of the conversion (by default the result is preceded by minus only when it is negative)
    space: if the result of a signed conversion does not start with a sign character, or is empty, space is prepended to the result. It is ignored if + flag is present.
    # : alternative form of the conversion is performed. See the table below for exact effects otherwise the behavior is undefined.
    0 : for integer and floating point number conversions, leading zeros are used to pad the field instead of space characters. For integer numbers it is ignored if the precision is explicitly specified. For other conversions using this flag results in undefined behavior. It is ignored if - flag is present. 

Last sentence means that zero-padding is only done when the output is right-aligned. I can't find an equivalent for Pythons '=' align option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:42:22 2019
From: report at bugs.python.org (Zectbumo)
Date: Tue, 17 Dec 2019 22:42:22 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576622542.03.0.237507194061.issue39079@roundup.psfhosted.org>


Zectbumo <alfred at 54.org> added the comment:

@eric.smith
It actually caused a problem and then turned into a curiosity. At the beginning I wanted to remind myself about the string module so I did a help(string). Then right after that I wrote a program that generated filenames from string.letters. I closed the python interpreter down and then reopened it and regenerated filenames again using string.letters. To my surprise I found the second iteration to come out with completely different results messing up my work. Once I found that help() was causing this problem and it became a curiosity because you would think help() would not modify anything. Obviously this problem is easy to work around in my case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:45:58 2019
From: report at bugs.python.org (Adam)
Date: Tue, 17 Dec 2019 22:45:58 +0000
Subject: [issue39074] Threading memory leak in _shutdown_locks for non-daemon
 threads
In-Reply-To: <1576597894.7.0.119079561961.issue39074@roundup.psfhosted.org>
Message-ID: <1576622758.31.0.69811919579.issue39074@roundup.psfhosted.org>


Change by Adam <adam.jgrant at gmail.com>:


----------
type: resource usage -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39074>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:56:31 2019
From: report at bugs.python.org (Adam)
Date: Tue, 17 Dec 2019 22:56:31 +0000
Subject: [issue39074] Threading memory leak in _shutdown_locks for non-daemon
 threads
In-Reply-To: <1576597894.7.0.119079561961.issue39074@roundup.psfhosted.org>
Message-ID: <1576623391.38.0.833157556176.issue39074@roundup.psfhosted.org>


Adam <adam.jgrant at gmail.com> added the comment:

Looks like this issue might be a duplicate of https://bugs.python.org/issue37788

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39074>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:37:20 2019
From: report at bugs.python.org (Andrew Ni)
Date: Tue, 17 Dec 2019 23:37:20 +0000
Subject: [issue39081] pathlib '/' operator does not resolve Enums with str
 mixin as expected
Message-ID: <1576625840.56.0.0179543914349.issue39081@roundup.psfhosted.org>


New submission from Andrew Ni <niandrew7 at gmail.com>:

import os
import pathlib
import enum

class MyEnum(str, enum.Enum):
    RED = 'red'

# this resolves to: '/Users/niandrew/MyEnum.RED'
# EXPECTED: '/Users/niandrew/red'
str(pathlib.Path.home() / MyEnum.RED)

# this resolves to: '/Users/niandrew/red'
os.path.join(pathlib.Path.home(), MyEnum.RED)

----------
components: Library (Lib)
messages: 358598
nosy: andrewni
priority: normal
severity: normal
status: open
title: pathlib '/' operator does not resolve Enums with str mixin as expected
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39081>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:54:22 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2019 23:54:22 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576626862.2.0.0166668107986.issue39077@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that a quick glance in the rear view mirror shows that the design isn't awesome. But I just don't see how we can change it at this point. It is what it is.

And it's no surprise that int and float have the same behavior: they share the same code in Python/formatter_unicode.h. Which means that even if we did want to change one but not the other, we'd have to duplicate a lot of code and live with the maintenance hassle forever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Tue Dec 17 19:21:09 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 18 Dec 2019 00:21:09 +0000
Subject: [issue39080] Inconsistency with Starred Expression line/col info
In-Reply-To: <1576618328.23.0.851602684205.issue39080@roundup.psfhosted.org>
Message-ID: <1576628469.71.0.868939059315.issue39080@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 50d4f12958bf806a4e1a1021d70cfd5d448c5cba by Pablo Galindo (Lysandros Nikolaou) in branch 'master':
bpo-39080: Starred Expression's column offset fix when inside a CALL (GH-17645)
https://github.com/python/cpython/commit/50d4f12958bf806a4e1a1021d70cfd5d448c5cba


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39080>
_______________________________________

From report at bugs.python.org  Tue Dec 17 19:23:04 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 18 Dec 2019 00:23:04 +0000
Subject: [issue39080] Inconsistency with Starred Expression line/col info
In-Reply-To: <1576618328.23.0.851602684205.issue39080@roundup.psfhosted.org>
Message-ID: <1576628584.33.0.0947540964473.issue39080@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17116
pull_request: https://github.com/python/cpython/pull/17649

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39080>
_______________________________________

From report at bugs.python.org  Tue Dec 17 19:36:45 2019
From: report at bugs.python.org (Aniket Panse)
Date: Wed, 18 Dec 2019 00:36:45 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
Message-ID: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>


New submission from Aniket Panse <aniketpanse at gmail.com>:

Currently, patch is unable to correctly patch coroutinefunctions decorated with `@staticmethod` or `@classmethod`.

Example:

```
[*] aniketpanse [~/git/cpython] -> ./python                                                                                                                                                                                                         ?[master]
Python 3.9.0a1+ (heads/master:50d4f12958, Dec 17 2019, 16:31:30) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Helper:
...     @classmethod
...     async def async_class_method(cls):
...         pass
... 
>>> from unittest.mock import patch
>>> patch("Helper.async_class_method")
<unittest.mock._patch object at 0x7fc28ddbbf40>
```

This should ideally return an `AsyncMock()`.

----------
components: Tests, asyncio
messages: 358601
nosy: asvetlov, czardoz, yselivanov
priority: normal
severity: normal
status: open
title: AsyncMock is unable to correctly patch static or class methods
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:15:17 2019
From: report at bugs.python.org (Martin Meo)
Date: Wed, 18 Dec 2019 01:15:17 +0000
Subject: [issue39083] Dictionary get(key,
 default-expression) not short circuit behavior
Message-ID: <1576631717.88.0.0905545804197.issue39083@roundup.psfhosted.org>


New submission from Martin Meo <martin.meo at gmail.com>:

"""
Unexpected behavior report

Dictionary get(key, default-expression) not short circuit behavior

MacOS 10.14.6
sys.version_info(major=3, minor=6, micro=5, releaselevel='final', serial=0)

BACKGROUND
A python dictionary is a data structure that associates a set of keys with a set of values.
Accessing a non-existent key produces a KeyError.
Dictionaries have a get() method.
get(key[, default-expression])
Return the value for key if key is in the dictionary, else default-expression.
If default-expression is not given, it defaults to None, so that this method never raises a KeyError.

EXPECTED BEHAVIOR
get() would only evaluate default-expression if it has to, when key is not found.  It would have short-circuit behavior like boolean operators.

ACTUAL BEHAVIOR
The default-expression DOES get evaluated even when the key IS found in the dictionary. And if default-expression is a function call, the function DOES get called.

"""

denominations = {0:'zero', 1:'one', 2:'two', 3:'three', 4:'four'}
        
def foo(n):
    print('FOO CALLED. n =', n)
    return str(n*10)

words = []
words.append(denominations[1])
words.append(denominations[4])
words.append(denominations.get(1))
words.append(denominations.get(4))
words.append(denominations.get(1, 'ERROR-A'))
words.append(denominations.get(4, 'ERROR-B'))

words.append(denominations.get(22, 'ERROR-1'))
words.append(denominations.get(88, 'ERROR-2'))

words.append(denominations.get(1, foo(1)))
words.append(denominations.get(4, foo(4)))

print(words)



def isItZero(n):
    print('ISITZERO CALLED.  n=', n)
    return False

a = (True or isItZero(9))   # (True or x) is always True so x is not evaluated

----------
messages: 358602
nosy: martinmeo
priority: normal
severity: normal
status: open
title: Dictionary get(key, default-expression) not short circuit behavior
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39083>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:42:03 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 18 Dec 2019 01:42:03 +0000
Subject: [issue39080] Inconsistency with Starred Expression line/col info
In-Reply-To: <1576618328.23.0.851602684205.issue39080@roundup.psfhosted.org>
Message-ID: <1576633323.84.0.562885208762.issue39080@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b1f204471092678dd89117e608fa041a9589d14c by Miss Islington (bot) (Pablo Galindo) in branch '3.8':
[3.8] bpo-39080: Starred Expression's column offset fix when inside a CALL (GH-17645) (GH-17649)
https://github.com/python/cpython/commit/b1f204471092678dd89117e608fa041a9589d14c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39080>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:45:28 2019
From: report at bugs.python.org (Manish)
Date: Wed, 18 Dec 2019 01:45:28 +0000
Subject: [issue39084] string.letters is flipped after setlocale is called
Message-ID: <1576633528.14.0.930532068678.issue39084@roundup.psfhosted.org>


New submission from Manish <manishsmail at gmail.com>:

Steps to reproduce:

>>> import string
>>> string.letters
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>> help(string)
......
>>> string.letters
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'


The help(string) can also be replaced with locale.setlocale(locale.LC_CTYPE, "en_US.UTF-8")

What's happening here is that any call to setlocale() (which help() calls internally) recomputes string.letters. The recomputation flips the order in the current implementation.

----------
messages: 358604
nosy: Manishearth
priority: normal
severity: normal
status: open
title: string.letters is flipped after setlocale is called
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39084>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:51:54 2019
From: report at bugs.python.org (Manish)
Date: Wed, 18 Dec 2019 01:51:54 +0000
Subject: [issue39084] string.letters is flipped after setlocale is called
In-Reply-To: <1576633528.14.0.930532068678.issue39084@roundup.psfhosted.org>
Message-ID: <1576633914.34.0.117517113001.issue39084@roundup.psfhosted.org>


Change by Manish <manishsmail at gmail.com>:


----------
keywords: +patch
pull_requests: +17117
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17650

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39084>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:58:56 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 18 Dec 2019 01:58:56 +0000
Subject: [issue39083] Dictionary get(key,
 default-expression) not short circuit behavior
In-Reply-To: <1576631717.88.0.0905545804197.issue39083@roundup.psfhosted.org>
Message-ID: <1576634336.6.0.0275807301385.issue39083@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

.get() is just a regular function call. And like all python functions, all of the arguments are evaluated before the function is called. There is no mechanism in python to delay the evaluation of a arguments.

You might want to look at collections.defaultdict. You can supply a factory function, so that the call is delayed until a missing key is found.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39083>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:59:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 18 Dec 2019 01:59:34 +0000
Subject: [issue39080] Inconsistency with Starred Expression line/col info
In-Reply-To: <1576618328.23.0.851602684205.issue39080@roundup.psfhosted.org>
Message-ID: <1576634374.69.0.631688559764.issue39080@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/issue39080>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:01:49 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 18 Dec 2019 02:01:49 +0000
Subject: [issue39084] string.letters is flipped after setlocale is called
In-Reply-To: <1576633528.14.0.930532068678.issue39084@roundup.psfhosted.org>
Message-ID: <1576634509.41.0.783642886546.issue39084@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This is a duplicate of issue 39079.

I recommend that we don't "fix" this. It is only an issue with 2.7, and hasn't been a problem for years.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39084>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:12:12 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 18 Dec 2019 02:12:12 +0000
Subject: [issue39084] string.letters is flipped after setlocale is called
In-Reply-To: <1576633528.14.0.930532068678.issue39084@roundup.psfhosted.org>
Message-ID: <1576635132.11.0.275696285683.issue39084@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> help() modifies the string module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39084>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:15:45 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 18 Dec 2019 02:15:45 +0000
Subject: [issue39079] help() modifies the string module
In-Reply-To: <1576608747.4.0.324829457478.issue39079@roundup.psfhosted.org>
Message-ID: <1576635345.59.0.921136531797.issue39079@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Since this has been this way for 22 years without a previous report that I can find, +1 to closing as "won't fix"/"not a bug" and so doing.  However, I'm also adding the 2.7 release manager to make sure he knows about it and can reopen if he wants.

----------
nosy: +benjamin.peterson, zach.ware
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39079>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:20:21 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Wed, 18 Dec 2019 02:20:21 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1576635621.85.0.0927183335134.issue39040@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

Sure, fixed as per your comments in the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Tue Dec 17 22:21:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 18 Dec 2019 03:21:39 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1576639299.88.0.962771514292.issue39082@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Using patch as a function just returns a patch object. You need to call start method on the patch object to return a Mock.

----------
nosy: +lisroach, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Tue Dec 17 22:47:41 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 18 Dec 2019 03:47:41 +0000
Subject: [issue39085] Improve docs for await expression
Message-ID: <1576640861.79.0.333385908669.issue39085@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

For context, I decided to open this issue after receiving a substantial volume of very similar questions and misconceptions from users of asyncio and trio about what `await` does, mostly within a dedicated "async" topical help chat (in the "Python Discord" community). For the most part, the brief explanation provided in the language reference docs (https://docs.python.org/3/reference/expressions.html#await-expression) did not help to clear up their understanding.

Also, speaking from personal experience, I did not have a clear understanding of what `await` actually did until I gained some experience working with asyncio. When I read the language reference definition for the await expression for the first time, it did not make much sense to me either.

As a result, I think the documentation for the `await` expression could be made significantly more clear. To users that are already familiar with asynchronous programming it likely makes more sense, but I don't think it's as helpful as it could be for those who are trying to fundamentally understand how `await` works (without having prior experience):

"Suspend the execution of coroutine on an awaitable object. Can only be used inside a coroutine function."

(https://docs.python.org/3/reference/expressions.html#await-expression)

(Also, note that there's a typo in the current version, "of coroutine" should probably be "of a coroutine")

While this explanation is technically accurate, it also looks to be the _shortest_ one out of all of the defined expressions on the page. To me, this doesn't seem right considering that the await expression is not the easiest one to learn or understand.

The vast majority of the questions and misunderstandings on `await` that I've seen typically fall under some variation of one of the following:

1) What exactly is being suspended?
2) When is it resumed/unsuspended?
3) How is it useful?

>From what I can tell, (1) is unclear to them is partly because the awaitable object that is after the `await` can be a coroutine object. It's not at all uncommon to see "await some_coro()".

I think this would be much more clear if it were to instead be something along the lines of one the following (changes indicated with *):

1) "Suspend the execution of *the current coroutine function* on an awaitable object. Can only be used inside a coroutine function."

Where "the current coroutine function" is the coroutine function that contains the await expression. I think this would help to clear up the first question, "What exactly is being suspended?".

2) "Suspend the execution of *the current coroutine function* on an awaitable object. *The coroutine function is resumed when the awaitable object is completed and returns its result*. Can only be used inside a coroutine function."

This would likely help to clear up "When is it resumed/unsuspended?".

Optimally, this definition could also include some form of example code like several of the other expressions have. It's not particularly easy to use a demonstrable example without using an async library (such as asyncio), but using a specific async library would not make sense to have in this location of the docs because the language reference is supposed to be as implementation agnostic as possible.

However, I think a very brief visual example with some explanation could still be useful for explaining the basics of how await works:

3) ```
async def coro():
    # before await
    await some_awaitable
    # after await

When the coroutine function `coro()` is executed, it will behave roughly the same as any subroutine function in the "before await" section. However, upon reaching `await some_awaitable`, the execution of `coro()` will be suspended on `some_awaitable`, preventing the execution of anything in the "after await" section until `some_awaitable` is completed. This process is repeated with successive await expressions. Also, multiple coroutines can be suspended at the same time.

Suspension can be used to indicate that other coroutines can be executed in the meantime. This can be used to write asynchronous and concurrent programs without the usage of callbacks.
```

Including the brief example and explanation would likely help to further clear up all three of the questions.

The present version has a high degree of technical accuracy, but I don't think its as helpful as it could be for furthering the understanding of users or providing an introduction to the await expression. I'm sure that there will still be some questions regarding `await` even if any of these changes are made, but it would at least provide a good place to link to for an informative explanation of `await` that's entirely agnostic from any specific implementation.

I'm entirely open to any alternative suggestions, or making a change that's some combination or variation of the above three ideas. Alternatively, if there are determined to be no suitable changes that would be both technically accurate and more helpful to users, I could just apply a fix to the typo.

If any of these ideas are approved, I'll likely open a PR.

----------
assignee: aeros
components: Documentation, asyncio
messages: 358610
nosy: aeros, asvetlov, njs, yselivanov
priority: normal
severity: normal
status: open
title: Improve docs for await expression
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39085>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:42:15 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Dec 2019 05:42:15 +0000
Subject: [issue39076] Use types.SimpleNamespace for argparse.Namespace
In-Reply-To: <1576600551.73.0.829151608014.issue39076@roundup.psfhosted.org>
Message-ID: <1576647735.64.0.921659793768.issue39076@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There are some sticking points:

* types.SimpleNamespace() sorts attributes, so this would get in the way of issue #39058.

* argparse.Namespace() supports a __contains__() method that isn't offered by types.SimpleNamespace():

    >>> 'abc' in Namespace(abc=10)
    True

* Argparse is sensitive to start-up time so we mostly want to avoid adding new dependencies.  Start-up time recently got worse when the re module added a number of dependencies.

* The __repr__ for SimpleNamespace() doesn't round-trip and isn't what we have now with Namespace.  That potentially breaks doctests and diverges from published examples:

    >>> Namespace(abc=10)
    Namespace(abc=10)
    >>> SimpleNamespace(abc=10)
    namespace(abc=10)

* Ironically, the class name "Namespace" is simpler than "SimpleNamespace" ;-)

* Much of the code in argparse.Namespace() inherits from _AttributeHolder, so switching to types.SimpleNamespace() doesn't really save us much code.

Are there any upsides to switching?  Attribute lookup is almost equally fast using either approach, so there is no speed benefit:

    $ python3.8 -m timeit -r 11 -s 'from argparse import Namespace as NS' -s 'args=NS(abc=10)' 'args.abc'
    10000000 loops, best of 11: 32.7 nsec per loop

    $ python3.8 -m timeit -r 11 -s 'from types import SimpleNamespace as NS' -s 'args=NS(abc=10)' 'args.abc'
    10000000 loops, best of 11: 32.4 nsec per loop

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39076>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:52:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 18 Dec 2019 05:52:11 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1576648331.48.0.214494385886.issue39082@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There seems to be a difference in obtaining the attribute out of the __dict__ and getattr. patch uses __dict__ [0] to access the attribute to be patched and falls back to getattr. There is a difference in detecting normal attribute access to be a coroutine function versus the one obtained from __dict__ . We can perhaps make _is_async_obj [1] to see if the passed obj is a classmethod/staticmethod and to use __func__ to detect a coroutine function.

As a workaround for now you can pass AsyncMock explicitly to patch to return an AsyncMock. There was an open issue (issue36092) about patch and staticmethods/classmethods but not sure this is related to this.

Retagging it to remove asyncio. Thanks for the report!

# bpo39082.py

from unittest.mock import patch
import inspect

class Helper:

    @classmethod
    async def async_class_method(cls):
        pass

    @staticmethod
    async def async_static_method(*args, **kwargs):
        pass


print("Patching async static method")
async_patcher = patch("__main__.Helper.async_class_method")
print(f"{Helper.async_class_method = }")
print(f"{Helper.__dict__['async_class_method'] = }")
print(f"{inspect.iscoroutinefunction(Helper.async_class_method) = }")
print(f"{inspect.iscoroutinefunction(Helper.__dict__['async_class_method']) = }")
print(f"{inspect.iscoroutinefunction(getattr(Helper, 'async_class_method')) = }")

mock_ = async_patcher.start()
print(mock_)

print("\nPatching async static method")
async_patcher = patch("__main__.Helper.async_static_method")
print(f"{Helper.async_static_method = }")
print(f"{Helper.__dict__['async_static_method'] = }")
print(f"{inspect.iscoroutinefunction(Helper.async_static_method) = }")
print(f"{inspect.iscoroutinefunction(Helper.__dict__['async_static_method']) = }")
print(f"{inspect.iscoroutinefunction(getattr(Helper, 'async_static_method')) = }")

mock_ = async_patcher.start()
print(mock_)


$ python3.8 bpo39082.py
Patching async static method
Helper.async_class_method = <bound method Helper.async_class_method of <class '__main__.Helper'>>
Helper.__dict__['async_class_method'] = <classmethod object at 0x10de7bcd0>
inspect.iscoroutinefunction(Helper.async_class_method) = True
inspect.iscoroutinefunction(Helper.__dict__['async_class_method']) = False
inspect.iscoroutinefunction(getattr(Helper, 'async_class_method')) = True
<MagicMock name='async_class_method' id='4537489440'>

Patching async static method
Helper.async_static_method = <function Helper.async_static_method at 0x10e77baf0>
Helper.__dict__['async_static_method'] = <staticmethod object at 0x10de7bbb0>
inspect.iscoroutinefunction(Helper.async_static_method) = True
inspect.iscoroutinefunction(Helper.__dict__['async_static_method']) = False
inspect.iscoroutinefunction(getattr(Helper, 'async_static_method')) = True
<MagicMock name='async_static_method' id='4537741520'>


Detect __func__ to be used for iscoroutinefunction

diff --git Lib/unittest/mock.py Lib/unittest/mock.py
index cd5a2aeb60..572468ca8d 100644
--- Lib/unittest/mock.py
+++ Lib/unittest/mock.py
@@ -48,6 +48,8 @@ _safe_super = super
 def _is_async_obj(obj):
     if _is_instance_mock(obj) and not isinstance(obj, AsyncMock):
         return False
+    if hasattr(obj, '__func__'):
+        obj = getattr(obj, '__func__')
     return asyncio.iscoroutinefunction(obj) or inspect.isawaitable(obj)

[0] https://github.com/python/cpython/blob/50d4f12958bf806a4e1a1021d70cfd5d448c5cba/Lib/unittest/mock.py#L1387
[1] https://github.com/python/cpython/blob/50d4f12958bf806a4e1a1021d70cfd5d448c5cba/Lib/unittest/mock.py#L48

----------
components: +Library (Lib) -Tests, asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Wed Dec 18 01:07:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Dec 2019 06:07:21 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1576649241.21.0.0844951836081.issue39075@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for dropping the sort.  Also, the repr should be made to round-trip with eval().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Wed Dec 18 01:25:31 2019
From: report at bugs.python.org (Mateusz Bysiek)
Date: Wed, 18 Dec 2019 06:25:31 +0000
Subject: [issue32954] Lazy Literal String Interpolation (PEP-498-based
 fl-strings)
In-Reply-To: <1519640359.67.0.467229070634.issue32954@psf.upfronthosting.co.za>
Message-ID: <1576650331.68.0.668365470506.issue32954@roundup.psfhosted.org>


Change by Mateusz Bysiek <reg at mbdev.pl>:


----------
nosy: +mbdevpl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32954>
_______________________________________

From report at bugs.python.org  Wed Dec 18 01:51:42 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 18 Dec 2019 06:51:42 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576651902.36.0.204863560929.issue39028@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Wed Dec 18 01:51:48 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 18 Dec 2019 06:51:48 +0000
Subject: [issue39028] ENH: Fix performance issue in keyword extraction
In-Reply-To: <1576123495.69.0.334207747364.issue39028@roundup.psfhosted.org>
Message-ID: <1576651908.35.0.714566830346.issue39028@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 75bb07e92baa7267a61056d03d7e6b475588e793 by Inada Naoki (Sebastian Berg) in branch 'master':
bpo-39028: Performance enhancement in keyword extraction (GH-17576)
https://github.com/python/cpython/commit/75bb07e92baa7267a61056d03d7e6b475588e793


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39028>
_______________________________________

From report at bugs.python.org  Wed Dec 18 02:40:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 18 Dec 2019 07:40:18 +0000
Subject: [issue39081] pathlib '/' operator does not resolve Enums with str
 mixin as expected
In-Reply-To: <1576625840.56.0.0179543914349.issue39081@roundup.psfhosted.org>
Message-ID: <1576654818.41.0.0678326938839.issue39081@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

As per the fspath PEP https://www.python.org/dev/peps/pep-0519/#c-api the below precedence is set. So for the enum inheriting from str the object itself is returned and MyEnum.RED.__str__ is used returning MyEnum.RED. You can remove inheritance from str and implement __fspath__ for your enum class to be used as per fspath protocol.

> If the object is str or bytes, then allow it to pass through with
  an incremented refcount. If the object defines __fspath__(), then
  return the result of that method. All other types raise a TypeError.

# bpo39081.py

import os
import pathlib
import enum

class MyEnum(enum.Enum):
    RED = 'red'

    def __fspath__(self):
        return self.name

print(os.fspath(MyEnum.RED))
print(pathlib.Path.home() / MyEnum.RED)

$ python3.8 bpo39081.py
RED
/Users/kasingar/RED

----------
nosy: +ethan.furman, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39081>
_______________________________________

From report at bugs.python.org  Wed Dec 18 04:07:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 18 Dec 2019 09:07:20 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1576660040.16.0.155897286355.issue34480@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Attaching a test case for this issue since the self.error code path was not covered in the current test suite. A PR is open proposing match variable initialisation with None https://github.com/python/cpython/pull/17643 .

diff --git Lib/test/test_htmlparser.py Lib/test/test_htmlparser.py
index a2bfb39d16..a9aff11706 100644
--- Lib/test/test_htmlparser.py
+++ Lib/test/test_htmlparser.py
@@ -766,6 +766,18 @@ class AttributesTestCase(TestCaseBase):
                           [("href", "http://www.example.org/\">;")]),
                          ("data", "spam"), ("endtag", "a")])
 
+    def test_invalid_keyword_error_exception(self):
+        class InvalidMarkupException(Exception):
+            pass
+
+        class MyHTMLParser(html.parser.HTMLParser):
+
+            def error(self, message):
+                raise InvalidMarkupException(message)
+
+        parser = MyHTMLParser()
+        with self.assertRaises(InvalidMarkupException):
+            parser.feed('<![invalid>')
 
 if __name__ == "__main__":
     unittest.main()

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34480>
_______________________________________

From report at bugs.python.org  Wed Dec 18 04:11:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 09:11:21 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576660281.58.0.630439685118.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 35acb3597208e10a101140474adec86859d57f61 by Victor Stinner in branch '3.8':
bpo-38546: multiprocessing tests stop the resource tracker (GH-17641) (GH-17647)
https://github.com/python/cpython/commit/35acb3597208e10a101140474adec86859d57f61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 04:21:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 18 Dec 2019 09:21:58 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1576660918.92.0.586776462909.issue39082@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Found Raymond's answer on the difference between __dict__ and attribute lookup regarding descriptors to be useful here : https://stackoverflow.com/a/44600603

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Wed Dec 18 05:13:22 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 18 Dec 2019 10:13:22 +0000
Subject: [issue24416] Have date.isocalendar() return a structseq instance
In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za>
Message-ID: <1576664002.6.0.508407981385.issue24416@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17118
pull_request: https://github.com/python/cpython/pull/17651

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24416>
_______________________________________

From report at bugs.python.org  Wed Dec 18 05:56:02 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 18 Dec 2019 10:56:02 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576666562.88.0.431539278919.issue39077@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Eric. I'm now convinced that we shouldn't weaken the Decimal behaviour, and I agree that it's risky to change the float and int behaviour. So it's sounding as though we're looking at a "won't fix" resolution here.

There are still the documentation issues: the trailing ".0" and the 6-digits after the point for "f" with no precision. Michael: would you be willing to open a separate bug report for those? (It's awkward to track two different issues, potentially needing different resolutions, in a single bugs.python.org issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Wed Dec 18 06:04:00 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 18 Dec 2019 11:04:00 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576667040.07.0.271056433478.issue39077@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with your approach, Mark.

And Michael: thanks for your report on the C behavior. I just wish we'd thought to look at this 13 years ago when .format() was being discussed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Wed Dec 18 06:10:19 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 18 Dec 2019 11:10:19 +0000
Subject: [issue39085] Improve docs for await expression
In-Reply-To: <1576640861.79.0.333385908669.issue39085@roundup.psfhosted.org>
Message-ID: <1576667419.88.0.221193895617.issue39085@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for raising the very interesting question!

Sorry, my English is bad; I cannot help with docs too much.

Anyway, technically an awaited coroutine *can* be suspended but the suspension is not always necessary. The most deep awaited function decides. 

For example, if you want to read 16 bytes from a stream and these bytes are already fetched there is no suspension at this point  (at least libraries are designed in this way usually).

Also, technical speaking about awaits is hard without telling that a coroutine is a specialized version of generator object with (partially) overlapped methods and properties, e.g. send() and throw().

To run a coroutine you need a framework which calls these methods depending on the framework rules, the rules for asyncio are different from trio.

Not sure how long should be the section but looking on `yield expressions` https://docs.python.org/3/reference/expressions.html#yield-expressions above I expect that awaits can take two-three times longer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39085>
_______________________________________

From report at bugs.python.org  Wed Dec 18 06:57:14 2019
From: report at bugs.python.org (Mradul Tiwari)
Date: Wed, 18 Dec 2019 11:57:14 +0000
Subject: [issue39086] Division "/" error on Long Integers
Message-ID: <1576670234.02.0.553582573696.issue39086@roundup.psfhosted.org>


New submission from Mradul Tiwari <mradul at mnnit.ac.in>:

I'm a Competitive programmer and got Wrong Answer because of this division issue, which I figured out post Contest. Please See the attached screenshot.

The "/" operator gives float division but for long integers, it's giving integer answer. I've tested it on several values but the result doesn't matched with expected answers. I've also googled a lot about this but can't get the explanation.

Please go to link "https://codeforces.com/contest/1266/submission/67106918"
and see the actual arise of problem on SEVERAL VALUES, in detail section, in TestCase 3 which have very large integers.

In my code at that link, the error arises inside the function get(x) at line "c=(x-i)/14"

----------
assignee: docs at python
components: Documentation
files: Tested values.png
messages: 358622
nosy: Mradul, docs at python
priority: normal
severity: normal
status: open
title: Division "/" error on Long Integers
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48787/Tested values.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39086>
_______________________________________

From report at bugs.python.org  Wed Dec 18 07:10:15 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 18 Dec 2019 12:10:15 +0000
Subject: [issue39087] No efficient API to get UTF-8 string from unicode object.
Message-ID: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

Assume you are writing an extension module that reads string.  For example, HTML escape or JSON encode.

There are two courses:

(a) Support three KINDs in the flexible unicode representation.
(b) Get UTF-8 data from the unicode.

(a) will be the fastest on CPython, but there are few drawbacks:

 * This is tightly coupled with CPython implementation.  It will be slow on PyPy.
 * CPython may change the internal representation to UTF-8 in the future, like PyPy.
 * You can not easily reuse algorithms written in C that handle `char*`.

So I believe (b) should be the preferred way.
But CPython doesn't provide an efficient way to get UTF-8 from the unicode object.

 * PyUnicode_AsUTF8AndSize(): When the unicode contains non-ASCII character, it will create a UTF-8 cache.  The cache will be remained for longer than required.  And there is additional malloc + memcpy to create the cache.

 * PyUnicode_DecodeUTF8(): It creates bytes object even when the unicode object is ASCII-only or there is a UTF-8 cache already.

For speed and efficiency, I propose a new API:

```
  /* Borrow the UTF-8 C string from the unicode.
   *
   * Store a pointer to the UTF-8 encoding of the unicode to *utf8* and its size to *size*.
   * The returned object is the owner of the *utf8*.  You need to Py_DECREF() it after
   * you finished to using the *utf8*.  The owner may be not the unicode.
   * Returns NULL when the error occurred while decoding the unicode.
   */
  PyObject* PyUnicode_BorrowUTF8(PyObject *unicode, const char **utf8, Py_ssize_t *len);
```

When the unicode object is ASCII or has UTF-8 cache, this API increment refcnt of the unicode and return it.
Otherwise, this API calls `_PyUnicode_AsUTF8String(unicode, NULL)` and return it.

----------
components: C API
messages: 358623
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: No efficient API to get UTF-8 string from unicode object.
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Wed Dec 18 07:16:54 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 18 Dec 2019 12:16:54 +0000
Subject: [issue39086] Division "/" error on Long Integers
In-Reply-To: <1576670234.02.0.553582573696.issue39086@roundup.psfhosted.org>
Message-ID: <1576671414.72.0.25103039279.issue39086@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Please don't post unnecessary screen shots of text. They are impossible for us to copy your code, we have to re-type it from scratch, and retyping 17-digit numbers is prone to typos. Screenshots make it difficult or impossible for the blind and visually impaired, who may be using screen readers, to contribute. Please copy and paste the actual text of your code, the results and the expected values.

You say you tested the values with a calculator, but which calculator and how do you know it is accurate?

I can't work out the connection between the competition and your calculations. Clicking on the "Problem" link takes me to a problem about dice.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39086>
_______________________________________

From report at bugs.python.org  Wed Dec 18 07:28:38 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 18 Dec 2019 12:28:38 +0000
Subject: [issue39086] Division "/" error on Long Integers
In-Reply-To: <1576670234.02.0.553582573696.issue39086@roundup.psfhosted.org>
Message-ID: <1576672118.94.0.461357044364.issue39086@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Looking at your first example, you calculate:

   >>> 63945173192649609/13
   4918859476357662.0


which is correct when using floats (64-bit C doubles). 64 bits are not enough to be any more precise, and you would get the same result in C or any other language using the same precision.

Using Decimal with the default precision, you could get:

    >>> decimal.Decimal(63945173192649609)/13
    Decimal('4918859476357662.230769230769')

but the exact result is 4918859476357662.[230769] where the decimal part inside the square brackets [...] repeats forever.

So within the limitations of the C 64-bit double floating point format, the calculation is correct and there is no bug here.

Please see

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

for more information.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39086>
_______________________________________

From report at bugs.python.org  Wed Dec 18 08:43:01 2019
From: report at bugs.python.org (Fabio Sangiovanni)
Date: Wed, 18 Dec 2019 13:43:01 +0000
Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass
 documentation
In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za>
Message-ID: <1576676581.65.0.847994852194.issue33961@roundup.psfhosted.org>


Fabio Sangiovanni <sjh+bugspython at sanjioh.org> added the comment:

Hi,

I was looking at the dataclasses docs and it seems to me that the PR associated to this issue has been merged into 3.7 only, but should be backported to 3.8 and to master.

I will post a comment on the PR itself as well.

Thanks,

Fabio

----------
nosy: +sanjioh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33961>
_______________________________________

From report at bugs.python.org  Wed Dec 18 08:54:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 13:54:08 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576677248.14.0.499521574723.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17119
pull_request: https://github.com/python/cpython/pull/17652

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 09:50:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 14:50:12 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576680612.95.0.719271009771.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 673c39331f844a80c465efd7cff88ac55c432bfb by Victor Stinner in branch 'master':
bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652)
https://github.com/python/cpython/commit/673c39331f844a80c465efd7cff88ac55c432bfb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 09:50:35 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 18 Dec 2019 14:50:35 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576680635.32.0.923503956522.issue38546@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17120
pull_request: https://github.com/python/cpython/pull/17653

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 09:50:42 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 18 Dec 2019 14:50:42 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576680642.98.0.184133885477.issue38546@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17121
pull_request: https://github.com/python/cpython/pull/17654

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 10:29:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 15:29:27 +0000
Subject: [issue39087] No efficient API to get UTF-8 string from unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576682967.7.0.449783170981.issue39087@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Wed Dec 18 10:32:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 15:32:26 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576683146.19.0.864166692584.issue39087@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: No efficient API to get UTF-8 string from unicode object. -> [C API] No efficient C API to get UTF-8 string from unicode object.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Wed Dec 18 11:37:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 16:37:39 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576687059.48.0.11777525504.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17122
pull_request: https://github.com/python/cpython/pull/17655

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 11:49:32 2019
From: report at bugs.python.org (tuijatuulia)
Date: Wed, 18 Dec 2019 16:49:32 +0000
Subject: [issue39070] Uninstalling 3.8.0 fails but it says it succeeds..
In-Reply-To: <1576539774.23.0.330588412038.issue39070@roundup.psfhosted.org>
Message-ID: <1576687772.75.0.799147766175.issue39070@roundup.psfhosted.org>


tuijatuulia <tuijatuulia at gmail.com> added the comment:

Thank you for the suggestion - I did not find any python-related log files in Windows /Temp - is there some identification I could search for?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39070>
_______________________________________

From report at bugs.python.org  Wed Dec 18 11:53:16 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Wed, 18 Dec 2019 16:53:16 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576687996.63.0.722662381803.issue39077@roundup.psfhosted.org>


Michael Amrhein <michael at adrhinum.de> added the comment:

Mark, Eric,
sometimes the pressure to be backwards compatible is more of a curse than a blessing. But I can live with your decision.
And, yes, I will create two separate issues regarding the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:05:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 17:05:09 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576688709.02.0.354822807512.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652)

I tested manually on the RHEL8 worker and I confirm that this change prevents the reap_children() warning.

I close the issue. The change will be shortly backported to 3.7 and 3.8.

--

I'm not sure if PR 17640 is useful, let's discuss it on the PR directly.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:05:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 17:05:24 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576688724.71.0.178484890907.issue38546@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:11:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 18 Dec 2019 17:11:26 +0000
Subject: [issue39070] Uninstalling 3.8.0 fails but it says it succeeds..
In-Reply-To: <1576539774.23.0.330588412038.issue39070@roundup.psfhosted.org>
Message-ID: <1576689086.93.0.272645669986.issue39070@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It will be in your user TEMP directory: C:\Users\<you>\AppData\Local\Temp (or just type "%TEMP%" into the File Explorer address bar and it will take you there)

They should all start with "Python" and end with ".log" (or be marked as text files if you don't see the extension).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39070>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:29:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 17:29:16 +0000
Subject: [issue39014] test_concurrent_futures: test_crash() timed out on AMD64
 Fedora Rawhide Refleaks 3.x
In-Reply-To: <1575981777.91.0.383152425566.issue39014@roundup.psfhosted.org>
Message-ID: <1576690156.26.0.252658256984.issue39014@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another issue on AMD64 Fedora Rawhide Refleaks 3.7 where test_map_chunksize() hangs.

https://buildbot.python.org/all/#/builders/133/builds/18

(...)
test_initializer (test.test_concurrent_futures.ProcessPoolForkInitializerTest) ... 0.13s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.17s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.15s ok
test_map (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.17s ok
.....Timeout (3:15:00)!
Thread 0x00007f095aa00700 (most recent call first):
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 296 in wait
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/queues.py", line 224 in _feed
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 870 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 926 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x00007f095a1ff700 (most recent call first):
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/selectors.py", line 415 in select
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/multiprocessing/connection.py", line 920 in wait
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py", line 361 in _queue_management_worker
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 870 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 926 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x00007f096a552740 (most recent call first):
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/threading.py", line 296 in wait
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/_base.py", line 430 in result
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/_base.py", line 598 in result_iterator
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/concurrent/futures/process.py", line 483 in _chain_from_iterable_of_lists
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 782 in test_map_chunksize
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 628 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/case.py", line 676 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 1919 in _run_suite
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2015 in run_unittest
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/test_concurrent_futures.py", line 1245 in test_main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/support/__init__.py", line 2147 in decorator
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/refleak.py", line 87 in dash_R
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 232 in _runtest_inner2
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 313 in rerun_failed_tests
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 685 in _main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 629 in main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/libregrtest/main.py", line 706 in main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 85 in _run_code
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.refleak/build/Lib/runpy.py", line 193 in _run_module_as_main

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:31:06 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Dec 2019 17:31:06 +0000
Subject: [issue39081] pathlib '/' operator does not resolve Enums with str
 mixin as expected
In-Reply-To: <1576625840.56.0.0179543914349.issue39081@roundup.psfhosted.org>
Message-ID: <1576690266.25.0.193884641377.issue39081@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Karthikeyan is right and this is working as expected. If you want the semantics you're after you can either implement __fspath__ as was suggested or get the 'value' attribute of the enum when constructing your path.

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39081>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:37:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 17:37:48 +0000
Subject: [issue39088] test_concurrent_futures crashed with python.core core
 dump on AMD64 FreeBSD Shared 3.x
Message-ID: <1576690668.17.0.971544115619.issue39088@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Yesterday and today, I pushed two test_concurrent_futures fixes in bpo-38546:

* commit 673c39331f844a80c465efd7cff88ac55c432bfb
* commit 9707e8e22d80ca97bf7a9812816701cecde6d226

Maybe it fixed this crash, maybe not.

https://buildbot.python.org/all/#/builders/152/builds/70

0:19:28 load avg: 4.96 [242/420/1] test_concurrent_futures failed (env changed) (5 min 4 sec) -- running: test_io (2 min 1 sec), test_largefile (31.3 sec)
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_successful (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises_already_succeeded (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_multiple_set_exception (test.test_concurrent_futures.FutureTests) ... ok
test_multiple_set_result (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.35s ok
test_duplicate_futures (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 2.40s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.37s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.24s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 2.40s ok
test_crash (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 1.12s ok
test_shutdown_deadlock (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 0.57s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkFailingInitializerTest) ... 0.19s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkInitializerTest) ... 0.26s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.50s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.25s ok
test_map (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.37s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.40s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.58s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 6.42s ok
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.32s ok
test_max_workers_too_large (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... skipped 'Windows-only process limit'
test_no_stale_references (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.31s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.86s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.69s ok
test_submit (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.51s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_traceback (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.18s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.06s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.07s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 1.22s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 2.13s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.05s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.42s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 0.16s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 1.70s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 1.80s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 3.18s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 2.24s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 1.86s ok
test_timeout (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 6.26s ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 1.98s ok
test_duplicate_futures (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 3.44s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 1.76s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 1.90s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 3.66s ok
test_crash (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ... 12.13s ok
test_shutdown_deadlock (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ... 3.03s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkserverFailingInitializerTest) ... 1.12s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkserverInitializerTest) ... 1.39s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 2.09s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.93s ok
test_map (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 2.02s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.87s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.90s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 7.73s ok
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.55s ok
test_max_workers_too_large (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... skipped 'Windows-only process limit'
test_no_stale_references (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.78s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 3.01s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.70s ok
test_submit (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.67s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 1.99s ok
test_traceback (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 2.03s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.16s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.11s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 2.94s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 3.31s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 1.53s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 1.50s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 2.03s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 3.41s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 3.74s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 5.07s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 3.91s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 3.46s ok
test_timeout (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 7.47s ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 2.44s ok
test_duplicate_futures (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 4.78s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 2.63s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 2.74s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 4.35s ok
test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 17.00s ok
test_shutdown_deadlock (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 3.79s ok
test_initializer (test.test_concurrent_futures.ProcessPoolSpawnFailingInitializerTest) ... 1.78s ok
test_initializer (test.test_concurrent_futures.ProcessPoolSpawnInitializerTest) ... 1.57s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.47s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.27s ok
test_map (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.24s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.27s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 3.02s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 8.39s ok
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.49s ok
test_max_workers_too_large (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... skipped 'Windows-only process limit'
test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.32s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 4.27s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.21s ok
test_submit (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 3.45s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.75s ok
test_traceback (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 2.49s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.07s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.14s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 3.37s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 3.11s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 2.28s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 1.53s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 3.10s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 3.82s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 3.92s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 4.87s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 4.14s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 3.48s ok
test_timeout (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 8.20s ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 0.34s ok
test_duplicate_futures (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 2.38s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 0.30s ok
test_no_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 0.34s ok
test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 2.29s ok
test_default_workers (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.45s ok
test_free_reference (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_idle_thread_reuse (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_map (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_map_exception (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_map_submits_without_iteration (test.test_concurrent_futures.ThreadPoolExecutorTest)
Tests verifying issue 11777. ... 0.11s ok
test_map_timeout (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 6.15s ok
test_max_workers_negative (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_no_stale_references (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_saturation (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.32s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.15s ok
test_submit (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_submit_keyword (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_initializer (test.test_concurrent_futures.ThreadPoolFailingInitializerTest) ... 0.11s ok
test_initializer (test.test_concurrent_futures.ThreadPoolInitializerTest) ... 0.19s ok
test_context_manager_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.12s ok
test_del_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.00s ok
test_hang_issue12364 (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 1.25s ok
test_interpreter_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 1.55s ok
test_run_after_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.16s ok
test_thread_names_assigned (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.01s ok
test_thread_names_default (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.00s ok
test_threads_terminate (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.00s ok
test_all_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.11s ok
test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.71s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.62s ok
test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests) ... 3.65s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 2.17s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.92s ok
test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.65s ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... 6.69s ok

----------------------------------------------------------------------

Ran 168 tests in 303.707s

OK (skipped=3)
Warning -- files was modified by test_concurrent_futures
  Before: []
  After:  ['python.core']

----------
components: Tests
messages: 358634
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_concurrent_futures crashed with python.core core dump on AMD64 FreeBSD Shared 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39088>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:40:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 17:40:51 +0000
Subject: [issue39014] test_concurrent_futures: test_crash() timed out on AMD64
 Fedora Rawhide Refleaks 3.x
In-Reply-To: <1575981777.91.0.383152425566.issue39014@roundup.psfhosted.org>
Message-ID: <1576690851.4.0.142644480553.issue39014@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another timeout on AMD64 Fedora Rawhide LTO + PGO 3.7:
https://buildbot.python.org/all/#/builders/63/builds/21

test_all_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 0.14s ok
Timeout (0:15:00)!
Thread 0x00007f4983fff700 (most recent call first):
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 296 in wait
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/multiprocessing/queues.py", line 224 in _feed
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 870 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 926 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x00007f49a337e700 (most recent call first):
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/selectors.py", line 415 in select
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/multiprocessing/connection.py", line 920 in wait
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/concurrent/futures/process.py", line 361 in _queue_management_worker
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 870 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 926 in _bootstrap_inner
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 890 in _bootstrap

Thread 0x00007f49b192f740 (most recent call first):
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/threading.py", line 296 in wait
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/concurrent/futures/_base.py", line 430 in result
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_concurrent_futures.py", line 147 in _prime_executor
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_concurrent_futures.py", line 125 in setUp
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/case.py", line 624 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/case.py", line 676 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py", line 122 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/unittest/runner.py", line 176 in run
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/support/__init__.py", line 1919 in _run_suite
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/support/__init__.py", line 2015 in run_unittest
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/test_concurrent_futures.py", line 1245 in test_main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/support/__init__.py", line 2147 in decorator
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py", line 154 in _runtest
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/main.py", line 313 in rerun_failed_tests
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/main.py", line 685 in _main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/main.py", line 629 in main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/libregrtest/main.py", line 706 in main
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/runpy.py", line 85 in _run_code
  File "/home/buildbot/buildarea/3.7.cstratak-fedora-rawhide-x86_64.lto-pgo/build/Lib/runpy.py", line 193 in _run_module_as_main
make: *** [Makefile:1116: buildbottest] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:44:49 2019
From: report at bugs.python.org (Tal Einat)
Date: Wed, 18 Dec 2019 17:44:49 +0000
Subject: [issue39089] Update IDLE's credits
Message-ID: <1576691089.83.0.499008805758.issue39089@roundup.psfhosted.org>


New submission from Tal Einat <taleinat+python at gmail.com>:

The "Credits" document in the "About" dialog could use some updating. It fails to mention Saimadhav Heblikar's important work during GSoC 2014 as well as Terry J. Reedy's tireless work over the past few years which has helped keep IDLE in working order and the codebase in reasonable shape given its age.

----------
assignee: terry.reedy
components: IDLE
messages: 358636
nosy: taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: Update IDLE's credits
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39089>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:48:52 2019
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Dec 2019 17:48:52 +0000
Subject: [issue39081] pathlib '/' operator does not resolve Enums with str
 mixin as expected
In-Reply-To: <1576625840.56.0.0179543914349.issue39081@roundup.psfhosted.org>
Message-ID: <1576691332.12.0.520515128458.issue39081@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

The other option is to continue to inherit from `str`, but override the `__str__` method:

    class MyEnum(str, enum.Enum):
        #
        def __str__(self):
            return self.value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39081>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:20:50 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Dec 2019 18:20:50 +0000
Subject: [issue39090] Document various options for getting the absolute path
 from pathlib.Path objects
Message-ID: <1576693250.66.0.453775762211.issue39090@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

The question on how best to get an absolute path from a pathlib.Path object keeps coming up (see https://bugs.python.org/issue29688, https://discuss.python.org/t/add-absolute-name-to-pathlib-path/2882/, and https://discuss.python.org/t/pathlib-absolute-vs-resolve/2573 as examples).

As pointed out across those posts, getting the absolute path is surprisingly subtle and varied depending on your needs. As such we should probably add a section somewhere in the pathlib docs explaining the various ways and why you would choose one over the other.

----------
assignee: docs at python
components: Documentation
messages: 358638
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document various options for getting the absolute path from pathlib.Path objects
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:45:15 2019
From: report at bugs.python.org (Sebastian Krause)
Date: Wed, 18 Dec 2019 18:45:15 +0000
Subject: [issue39091] CPython Segfault in 5 lines of code
Message-ID: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>


New submission from Sebastian Krause <sebastian at realpath.org>:

The following lines trigger a segmentation fault:

class E(BaseException):
    def __new__(cls, *args, **kwargs):
        return cls
def a(): yield
a().throw(E)

Source with a bit more explanation: https://gist.github.com/coolreader18/6dbe0be2ae2192e90e1a809f1624c694 (I'm not the author of that gist, just reporting it here).

----------
components: Interpreter Core
messages: 358639
nosy: skrause
priority: normal
severity: normal
status: open
title: CPython Segfault in 5 lines of code
type: crash
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:54:20 2019
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 18 Dec 2019 18:54:20 +0000
Subject: [issue39091] CPython Segfault in 5 lines of code
In-Reply-To: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>
Message-ID: <1576695259.99.0.00307205987417.issue39091@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I can reproduce the issue on master:

>>> class E(BaseException):
...     def __new__(cls, *args, **kwargs):
...         return cls
... 
>>> def a(): yield
... 
>>> a().throw(E)

Program received signal SIGSEGV, Segmentation fault.
_Py_DECREF (op=<unknown at remote 0x48>, lineno=541, filename=0x61717f "./Include/object.h") at ./Include/object.h:470
470         if (--op->ob_refcnt != 0) {
(gdb) bt
#0  _Py_DECREF (op=<unknown at remote 0x48>, lineno=541, filename=0x61717f "./Include/object.h") at ./Include/object.h:470
#1  _Py_XDECREF (op=<unknown at remote 0x48>) at ./Include/object.h:541
#2  BaseException_set_tb (self=0x837290, tb=<traceback at remote 0x7fffeaaa2c80>, _unused_ignored=_unused_ignored at entry=0x0) at Objects/exceptions.c:234
#3  0x00000000004335bd in PyException_SetTraceback (self=<optimized out>, tb=<optimized out>) at Objects/exceptions.c:319
#4  0x000000000051b6df in _PyErr_PrintEx (tstate=0x78c7c0, set_sys_last_vars=set_sys_last_vars at entry=1) at Python/pythonrun.c:680
#5  0x000000000051bc1f in PyErr_PrintEx (set_sys_last_vars=set_sys_last_vars at entry=1) at Python/pythonrun.c:763
#6  0x000000000051bc32 in PyErr_Print () at Python/pythonrun.c:769
#7  0x000000000051ca1e in PyRun_InteractiveLoopFlags (fp=fp at entry=0x7ffff7de07e0 <_IO_2_1_stdin_>, filename_str=filename_str at entry=0x617126 "<stdin>", flags=flags at entry=0x7fffffffd7f0) at Python/pythonrun.c:135
#8  0x000000000051d0d0 in PyRun_AnyFileExFlags (fp=0x7ffff7de07e0 <_IO_2_1_stdin_>, filename=filename at entry=0x617126 "<stdin>", closeit=closeit at entry=0, flags=flags at entry=0x7fffffffd7f0) at Python/pythonrun.c:80
#9  0x000000000041deda in pymain_run_stdin (config=config at entry=0x78b0e0, cf=cf at entry=0x7fffffffd7f0) at Modules/main.c:467
#10 0x000000000041ea37 in pymain_run_python (exitcode=exitcode at entry=0x7fffffffd82c) at Modules/main.c:556
#11 0x000000000041ea76 in Py_RunMain () at Modules/main.c:632
#12 0x000000000041eacb in pymain_main (args=args at entry=0x7fffffffd870) at Modules/main.c:662
#13 0x000000000041eb47 in Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:686
#14 0x000000000041d6df in main (argc=<optimized out>, argv=<optimized out>) at ./Programs/python.c:16

----------
nosy: +christian.heimes
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:43:46 2019
From: report at bugs.python.org (Adam)
Date: Wed, 18 Dec 2019 19:43:46 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1576698226.61.0.943374427011.issue37788@roundup.psfhosted.org>


Adam <adam.jgrant at gmail.com> added the comment:

I ran into this bug as well, and opened an issue for it (before I saw this issue): https://bugs.python.org/issue39074

Was there a conclusion on the best way to fix this? It seems like the previous __del__ implementation would correct the resource leakage by removing the _tstate_lock from _shutdown_locks.

----------
nosy: +krypticus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:46:31 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Dec 2019 19:46:31 +0000
Subject: [issue29688] Add support for Path.absolute()
In-Reply-To: <1488389848.79.0.700814097868.issue29688@psf.upfronthosting.co.za>
Message-ID: <1576698391.79.0.0268434755531.issue29688@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I have opened https://bugs.python.org/issue39090 to track updating the pathlib docs to have a section on getting the absolute path in various ways along with what the trade-offs are for each approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29688>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:50:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2019 19:50:39 +0000
Subject: [issue39091] CPython Segfault in 5 lines of code
In-Reply-To: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>
Message-ID: <1576698639.03.0.820877688775.issue39091@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:05:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2019 20:05:09 +0000
Subject: [issue39091] CPython Segfault in 5 lines of code
In-Reply-To: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>
Message-ID: <1576699509.86.0.704344820387.issue39091@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Good catch! Since you already investigated the code, do you mind to create a PR which fixes a crash? I think that adding PyExceptionInstance_Check() in _PyErr_CreateException() could fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:26:02 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Dec 2019 20:26:02 +0000
Subject: [issue900092] hotshot.stats.load fails with AssertionError
Message-ID: <1576700762.03.0.895984237942.issue900092@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue900092>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:31:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2019 20:31:01 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576701061.79.0.11642302786.issue38546@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b0eb046cbd0dbb7b17f16aad6de20fac5305f387 by Victor Stinner in branch '3.8':
bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652) (GH-17655)
https://github.com/python/cpython/commit/b0eb046cbd0dbb7b17f16aad6de20fac5305f387


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:31:01 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 18 Dec 2019 20:31:01 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576701061.43.0.531403569563.issue38546@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17123
pull_request: https://github.com/python/cpython/pull/17656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:50:42 2019
From: report at bugs.python.org (Evan)
Date: Wed, 18 Dec 2019 20:50:42 +0000
Subject: [issue39092] Csv sniffer doesn't attempt to determine and set escape
 character.
Message-ID: <1576702242.94.0.201901935137.issue39092@roundup.psfhosted.org>


New submission from Evan <evan.whitfield at gmail.com>:

I observed a false positive for the csv sniffer has_header method. (It thought there was a header when there was not.) This is due to the fact that in has_header, it determines the csv dialect by sniffing it, and failed to determine that the file I was using had an escape character of '\'. Since it doesn't set the escape character, it then incorrectly broke the first line of the file into columns, since it encountered an escaped quote within a quoted column, and treated that as the end of that column. (It correctly determined that the dialect wasn't doublequote, but apparently still needs to have the escape character set to handle an escaped quotechar.) 

I think one (or both) of these things should be done here to avoid this false positive:
1.) Allow a dialect to be passed to has_header, so that someone could specify the escape character of the dialect if it were known.
2.) Allow the sniff method of the Sniffer class to detect and set the escapechar.

----------
components: Library (Lib)
messages: 358645
nosy: evan.whitfield
priority: normal
severity: normal
status: open
title: Csv sniffer doesn't attempt to determine and set escape character.
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39092>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:51:16 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 18 Dec 2019 20:51:16 +0000
Subject: [issue38546] test_concurrent_futures: reap_children() warnings on
 RHEL7 and RHEL8 buildbots
In-Reply-To: <1571656800.65.0.31860297071.issue38546@roundup.psfhosted.org>
Message-ID: <1576702276.68.0.570653912339.issue38546@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b8bbdf049b0472b8edc4298bfa61e62e3a584e98 by Miss Islington (bot) in branch '3.7':
bpo-38546: Fix concurrent.futures test_ressources_gced_in_workers() (GH-17652) (GH-17655)
https://github.com/python/cpython/commit/b8bbdf049b0472b8edc4298bfa61e62e3a584e98


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38546>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:15:22 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 18 Dec 2019 21:15:22 +0000
Subject: [issue900092] hotshot.stats.load fails with AssertionError
Message-ID: <1576703722.35.0.484995091035.issue900092@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue900092>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:55:24 2019
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Dec 2019 21:55:24 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1576706124.37.0.660156759637.issue37788@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:08:26 2019
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Dec 2019 22:08:26 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1576706906.62.0.471901946597.issue37193@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

FTR I have been trialling a patched Python 3.7 based on Maru's changes (revision 6ac217c) + review suggestions, and it has reduced the size of the leak (hit 1 GB over a couple days, vs only 60 MB increase over three days). The remaining leak could be explained by Issue 37788.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:32:45 2019
From: report at bugs.python.org (tuijatuulia)
Date: Wed, 18 Dec 2019 22:32:45 +0000
Subject: [issue39070] Uninstalling 3.8.0 fails but it says it succeeds..
In-Reply-To: <1576539774.23.0.330588412038.issue39070@roundup.psfhosted.org>
Message-ID: <1576708365.37.0.656438418041.issue39070@roundup.psfhosted.org>


tuijatuulia <tuijatuulia at gmail.com> added the comment:

alright have some, I'll just put them here, I guess nothing secret there. There are quite many of those - and also log files say it is uninstalling properly but no, it did not disappear from Windows / Programs or files did not go anywhere, also when I rebooted. Only when I added privileges to user I was able to uninstall properly. (and it did ask for privileges, so I did not suspect anything before noticing that hey it did not uninstall)

I have also other log files that have additional name JustForMe

----------
Added file: https://bugs.python.org/file48788/Python 3.8.0 (32-bit)_20191217003514.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39070>
_______________________________________

From report at bugs.python.org  Wed Dec 18 18:46:43 2019
From: report at bugs.python.org (Noah)
Date: Wed, 18 Dec 2019 23:46:43 +0000
Subject: [issue39091] CPython Segfault in 5 lines of code
In-Reply-To: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>
Message-ID: <1576712803.18.0.273253797817.issue39091@roundup.psfhosted.org>


Noah <blueshuk2 at gmail.com> added the comment:

I'm not sure if this will actually appear as a message (I just registered for the bug tracker and I'm not sure how it works), but I wrote the gist and I can definitely make a PR.

----------
nosy: +coolreader18

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:29:24 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 19 Dec 2019 00:29:24 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1576715364.74.0.556749241615.issue1116520@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:30:17 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 19 Dec 2019 00:30:17 +0000
Subject: [issue1298835] Add a vendor-packages directory for system-supplied
 modules
Message-ID: <1576715417.89.0.183572317792.issue1298835@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1298835>
_______________________________________

From report at bugs.python.org  Wed Dec 18 20:50:09 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Dec 2019 01:50:09 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1576720209.87.0.994251557714.issue39035@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 9af497419540cdb4659927e66c67d861c5ea48c2 by Ned Deily (Inada Naoki) in branch '3.7':
bpo-39035: travis: Don't use beta group (GH-17604)
https://github.com/python/cpython/commit/9af497419540cdb4659927e66c67d861c5ea48c2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Wed Dec 18 20:50:10 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Dec 2019 01:50:10 +0000
Subject: [issue38295] test_relative_path of test_py_compile fails on macOS
 10.15 Catalina
In-Reply-To: <1569605043.98.0.657218273343.issue38295@roundup.psfhosted.org>
Message-ID: <1576720210.01.0.0257688109062.issue38295@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 13ee023c03caf85101778b9323cdffbad695a4e0 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-38295: prevent test_relative_path of test_py_compile failure on macOS Catalina (GH-17636)
https://github.com/python/cpython/commit/13ee023c03caf85101778b9323cdffbad695a4e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38295>
_______________________________________

From report at bugs.python.org  Wed Dec 18 21:56:56 2019
From: report at bugs.python.org (obserience)
Date: Thu, 19 Dec 2019 02:56:56 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause panic and core dump
Message-ID: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>


New submission from obserience <obserience at gmail.com>:

All tkinter objects have a reference to the TCL interpreter object "self.tk". The current cleanup code does not remove these when a widget is destroyed.

Garbage collection of the TCL interpreter object occurs only after all gui objects are garbage collected. This may  be triggered from another thread causing TCL to panic and trigger a core dump.

Error message:
>Tcl_AsyncDelete: async handler deleted by the wrong thread
>Aborted (core dumped)

Adding:
"self.tk = None"
to the end of Misc.destroy() (tkinter/__init__.py line:439) should fix this by removing these reference when widgets are destroyed. (Note:destroy is recursive on the widget tree and called on the root object when a Tkinter GUI exits)

I can't see any problem with removing the interpreter object from a widget when it is destroyed. There doesn't seem to be any way to reassign a widget to a new parent so this shouldn't affect anything.

Doing this makes it safe(r) to use tkinter from a non-main thread since if the GUI cleans up properly no "landmines" are left to cause a crash when garbage collected in the wrong thread.

----------
components: Tkinter
files: error_case.py
messages: 358652
nosy: obserience
priority: normal
severity: normal
status: open
title: tkinter objects garbage collected from non-tkinter thread cause panic and core dump
type: crash
Added file: https://bugs.python.org/file48789/error_case.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:06:41 2019
From: report at bugs.python.org (Yoni Lavi)
Date: Thu, 19 Dec 2019 03:06:41 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
Message-ID: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>


New submission from Yoni Lavi <yoni at lavi.fm>:

I would like to put forward an argument in favour of a `default` parameter in the statistics.mean function and the related function. 

What motivated me to open this is that my code would more often than not include a check (or try-except) whenever I calculate a mean and add a default/sentinel value, and I felt that there should be a better way.

Please also note that we have a precedent for this in a similar parameter added to min & max in 3.4 (https://bugs.python.org/issue18111)

----------
components: Library (Lib)
messages: 358653
nosy: Yoni Lavi
priority: normal
severity: normal
status: open
title: Add a default to statistics.mean and related functions
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:07:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 19 Dec 2019 03:07:43 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576724863.19.0.301752156051.issue39094@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger, steven.daprano, taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:10:37 2019
From: report at bugs.python.org (Yoni Lavi)
Date: Thu, 19 Dec 2019 03:10:37 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576725037.91.0.29036240774.issue39094@roundup.psfhosted.org>


Change by Yoni Lavi <yoni at lavi.fm>:


----------
keywords: +patch
pull_requests: +17124
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17657

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:25:41 2019
From: report at bugs.python.org (obserience)
Date: Thu, 19 Dec 2019 03:25:41 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause panic and core dump
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1576725941.2.0.178684077701.issue39093@roundup.psfhosted.org>


obserience <obserience at gmail.com> added the comment:

A quick google search for "Tcl_AsyncDelete: async handler deleted by the wrong thread" yields plenty of users complaining about this error case. Usually they're trying add a gui to an existing application. They run it in a thread other than main and then leak a reference to a GUI widget into another thread. The GUI exits and then some time later, the last reference to a widget dissapears but this is triggered by the leaked reference and occurs in another thread context. The TK library panics and the application crashes.

https://github.com/matplotlib/matplotlib/issues/12085
https://github.com/gboeing/osmnx/issues/75
https://stackoverflow.com/questions/27073762/tcl-asyncdelete-error-multithreading-python
(and so on)

The response time and time again is just "you can't run tkinter in any thread but main". Hopefully if this fix is implemented, that becomes less true.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Wed Dec 18 23:13:20 2019
From: report at bugs.python.org (NNN)
Date: Thu, 19 Dec 2019 04:13:20 +0000
Subject: [issue39095] Negative Array Index not Yielding "Index Out Of Bounds"
Message-ID: <1576728800.29.0.743612590948.issue39095@roundup.psfhosted.org>


New submission from NNN <fibulator777 at hotmail.com>:

Created an 2D array:
bigFloorLayout = []       
        bigFloorLayout=[[False for row in range(0,45] for col in range(0,70]


for y in range (offsetY, storageY + offsetY):
            for x in range (offsetX, storageX + offsetX):
                bigFloorLayout[x][y] = True

Offset is a negative number, and thus accessing bigFloorLayout[0][-1], which did not yield "Index out of Bounds" as it should.
This is in Blender 2.81, so I have no idea what version of python it is.

----------
messages: 358655
nosy: NNN
priority: normal
severity: normal
status: open
title: Negative Array Index not Yielding "Index Out Of Bounds"
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39095>
_______________________________________

From report at bugs.python.org  Wed Dec 18 23:33:04 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2019 04:33:04 +0000
Subject: [issue39095] Negative Array Index not Yielding "Index Out Of Bounds"
In-Reply-To: <1576728800.29.0.743612590948.issue39095@roundup.psfhosted.org>
Message-ID: <1576729984.8.0.87245063853.issue39095@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

`-1` is not out of bounds unless the array is empty; negative indices count from the other end:

>>> a = list("some array")
>>> a
['s', 'o', 'm', 'e', ' ', 'a', 'r', 'r', 'a', 'y']
>>> a[-1]
'y'
>>> b = []
>>> b[-1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: list index out of range



See about halfway down this [1] section; look for "Indices may also be negative".

[1] https://docs.python.org/3/tutorial/introduction.html?highlight=Indices+negative+numbers#strings

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39095>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:08:21 2019
From: report at bugs.python.org (Noah)
Date: Thu, 19 Dec 2019 05:08:21 +0000
Subject: [issue39091] CPython Segfault in 5 lines of code
In-Reply-To: <1576694715.09.0.414064649134.issue39091@roundup.psfhosted.org>
Message-ID: <1576732101.67.0.280456799403.issue39091@roundup.psfhosted.org>


Change by Noah <blueshuk2 at gmail.com>:


----------
keywords: +patch
pull_requests: +17126
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17658

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39091>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:09:14 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 19 Dec 2019 05:09:14 +0000
Subject: [issue37218] Default hmac.new() digestmod has not been removed from
 documentation
In-Reply-To: <1560200535.68.0.253007657272.issue37218@roundup.psfhosted.org>
Message-ID: <1576732154.51.0.621181419086.issue37218@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37218>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:24:09 2019
From: report at bugs.python.org (NNN)
Date: Thu, 19 Dec 2019 05:24:09 +0000
Subject: [issue39095] Negative Array Index not Yielding "Index Out Of Bounds"
In-Reply-To: <1576728800.29.0.743612590948.issue39095@roundup.psfhosted.org>
Message-ID: <1576733049.28.0.675792337715.issue39095@roundup.psfhosted.org>


NNN <fibulator777 at hotmail.com> added the comment:

Ahh, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39095>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:28:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 19 Dec 2019 05:28:19 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause panic and core dump
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1576733299.43.0.601299170599.issue39093@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +gpolo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Thu Dec 19 01:55:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Dec 2019 06:55:44 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576738544.8.0.957243899629.issue39094@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I vote -1.  We don't have defaults for stdev() or median() or mode().  And it isn't clear what one would use for a meaningful default value in most cases.  Also, I'm not seeing anything like this in Pandas, Excel, etc.  So, I recommend keeping the current simple and clean APIs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Thu Dec 19 02:49:18 2019
From: report at bugs.python.org (Tal Einat)
Date: Thu, 19 Dec 2019 07:49:18 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576741758.69.0.300915142149.issue39094@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

It seems to me that this would follow the same argument as in issue #18111: The real issue is that there's no good way to check if an arbitrary iterable is empty, unlike with sequences. Currently, callers need to wrap with try/except to handle empty iterators properly, or do non-trivial iterator "magic" to check whether the iterator is empty before passing it in.

I've tried think of other solutions, such as a generic wrapper for such functions or a helper to check whether an iterable is empty, and they all turn out to be very clunky to use and un-Pythonic.

Since we provide first-class support for iterators, and many builtins return iterators, giving the tools to handle the case where they are empty elegantly and simply seems prudent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Thu Dec 19 02:59:03 2019
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 19 Dec 2019 07:59:03 +0000
Subject: [issue39085] Improve docs for await expression
In-Reply-To: <1576640861.79.0.333385908669.issue39085@roundup.psfhosted.org>
Message-ID: <1576742343.37.0.0358238317799.issue39085@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Sorry, my English is bad; I cannot help with docs too much.

No problem. Your feedback is still incredibly helpful and very much appreciated either way. (: 

> Anyway, technically an awaited coroutine *can* be suspended but the suspension is not always necessary. The most deep awaited function decides.

Ah, I see. It took a bit of experimentation for me to understand how this works, but I think that I get it now. Specifically, the suspension occurs when the deepest coroutine function awaits an awaitable object and a `yield` is reached (usually through a defined __await__ method that returns an iterator). When that awaitable object is completed and returns, the coroutine function with the `await` (and everything else that directly awaited it) is resumed. A good example of this is `asyncio.sleep(0)`, as it just awaits `__sleep0()`, which is just a generator-based coroutine with a bare `yield`.

```
import asyncio
import inspect

tracked_coro = None

async def main():
  # loop isn't entirely needed, just used to track event loop time
  loop = asyncio.get_running_loop()
  global tracked_coro
  tracked_coro = coro(loop)
  await asyncio.gather(tracked_coro, other_coro(loop))


# This is the coroutine being tracked
async def coro(loop):
  print(loop.time())
  print("Start of coro():",
           inspect.getcoroutinestate(tracked_coro))
  await nested_coro(loop)


async def nested_coro(loop):
  print(loop.time())
  # coro() is not suspended yet, because we did not reach a `yield`
  print("Start of nested_coro():",
           inspect.getcoroutinestate(tracked_coro))
  # This will call await `__sleep0()`, reaching a `yield` which suspends `coro()` and `nested_coro()`
  await asyncio.sleep(0)
  print(loop.time())
  print("After the await, coro() is resumed:",
           inspect.getcoroutinestate(tracked_coro))


async def other_coro(loop):
  print(loop.time())
  print("Start of other_coro():",
           inspect.getcoroutinestate(tracked_coro))

asyncio.run(main())
```

Output:

```
8687.907528533
Start of coro(): CORO_RUNNING
8687.907800424
Start of nested_coro(): CORO_RUNNING
8687.912218812
Start of other_coro(): CORO_SUSPENDED
8687.912291694
After the await, coro() is resumed: CORO_RUNNING
```

> For example, if you want to read 16 bytes from a stream and these bytes are already fetched there is no suspension at this point  (at least libraries are designed in this way)

After realizing that the suspend only occurs when `yield` is reached, I think I understand how this works for `StreamReader.read()`. 

In sum, a `yield` is reached when `read()` is called with an empty buffer, resulting in `await self._wait_for_data('read')`. Specifically within `_wait_for_data()`, the `yield` is reached within `await self._waiter` (because _waiter is a Future, which defines an __await__ method with a `yield`). However, if `read()` is called after the bytes were fetched and are contained in the buffer, the bytes are read from the buffer and returned directly without ever reaching a `yield`; thus there is no suspension that occurs.

Is my interpretation mostly correct? I want to make sure that I have a good understanding of how await really works, as that will both help with improving the documentation of the await expression and improve my understanding of asyncio.

> Also, technical speaking about awaits is hard without telling that a coroutine is a specialized version of generator object with (partially) overlapped methods and properties, e.g. send() and throw().

Good point. If I understand correctly, send() and throw() were specifically added to the generator API in PEP 342 for the purpose of implementing coroutines in the first place, so it makes sense to explain how they relate to await. 

> To run a coroutine you need a framework which calls these methods depending on the framework rules, the rules for asyncio are different from trio.

That's mainly why I added Nathaniel to the nosy list. I wanted to make sure that we describe the await expression in a way that's as accurate and informative as possible for both, as well as any other async library that uses await.

> Not sure how long should be the section but looking on `yield expressions` https://docs.python.org/3/reference/expressions.html#yield-expressions above I expect that awaits can take two-three times longer.

That would be a great goal to move towards, but I think that might have to be completed in multiple steps over a longer period of time rather than in a single change. Even if it ends up being not quite as long as 2-3 times the length of the reference for the yield expression, I think we can still make a substantial improvement to the existing version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39085>
_______________________________________

From report at bugs.python.org  Thu Dec 19 03:59:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2019 08:59:14 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1576745954.45.0.625700432027.issue20443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reverted my change, so I remove "release blocker" priority.

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Thu Dec 19 04:43:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2019 09:43:13 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576748593.06.0.128693518249.issue39087@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mean some concrete code? Several times I wished similar feature. To get a UTF-8 cache if it exists and encode to UTF-8 without creating a cache otherwise. 

The private _PyUnicode_UTF8() macro could help

if ((s = _PyUnicode_UTF8(str))) {
    size = _PyUnicode_UTF8_LENGTH(str);
    tmpbytes = NULL;
}
else {
    tmpbytes = _PyUnicode_AsUTF8String(str, "replace");
    s = PyBytes_AS_STRING(tmpbytes);
    size = PyBytes_GET_SIZE(tmpbytes);
}

but it is not even available outside of unicodeobject.c.

PyUnicode_BorrowUTF8() looks too complex for the public API. I am not sure that it will be easy to implement it in PyPy. It also does not cover all use cases -- sometimes you want to convert to UTF-8 but does not use any memory allocation at all (either use an existing buffer or raise an error if there is no cached UTF-8 or the string is not ASCII).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 04:46:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2019 09:46:19 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576748779.21.0.681480841458.issue39087@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The returned object is the owner of the *utf8*.  You need to Py_DECREF() it after
> you finished to using the *utf8*.  The owner may be not the unicode.

Would it be possible to use a "container" object like a Py_buffer? Is there a way to customize the code executed when a Py_buffer is "released"?

Py_buffer would be nice since it already has a pointer attribute (data) and a length attribute, and there is an API to "release" a Py_buffer. It can be marked as read-only, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:01:31 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2019 10:01:31 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576749691.92.0.343246105995.issue39087@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Would it be possible to use a "container" object like a Py_buffer?

Looks like a good idea.

int PyUnicode_GetUTF8Buffer(Py_buffer *view, const char *errors)

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:04:30 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 19 Dec 2019 10:04:30 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576749870.0.0.934436255608.issue39087@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Would it be possible to use a "container" object like a Py_buffer? Is there a way to customize the code executed when a Py_buffer is "released"?

It looks nice idea!  Py_buffer.obj is decref-ed when releasing the buffer.
https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_Release


int PyUnicode_GetUTF8Buffer(PyObject *unicode, Py_buffer *view)
{
    if (!PyUnicode_Check(unicode)) {
        PyErr_BadArgument();
        return NULL;
    }
    if (PyUnicode_READY(unicode) == -1) {
        return NULL;
    }

    if (PyUnicode_UTF8(unicode) != NULL) {
        return PyBuffer_FillInfo(view, unicode,
                                 PyUnicode_UTF8(unicode),
                                 PyUnicode_UTF8_LENGTH(unicode),
                                 1, PyBUF_CONTIG_RO);
    }
    PyObject *bytes = _PyUnicode_AsUTF8String(unicode, NULL);
    if (bytes == NULL) {
        return NULL;
    }
    return PyBytesType.tp_as_buffer(bytes, view, PyBUF_CONTIG_RO);
}

----------
nosy:  -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:05:12 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 19 Dec 2019 10:05:12 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576749912.09.0.297971760861.issue39087@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

s/return NULL/return -1/g

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:11:20 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Thu, 19 Dec 2019 10:11:20 +0000
Subject: [issue39096] Description of "Format Specification Mini-Language" not
 accurate for Decimal
Message-ID: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>


New submission from Michael Amrhein <michael at adrhinum.de>:

The description of the "Format Specification Mini-Language" states for float and Decimal regarding presentation type 'f':
"The default precision is 6."
Regarding presentation type None it reads:
"Similar to 'g', except that fixed-point notation, when used, has at least one digit past the decimal point."
While both statements are accurate for float, they don't hold for Decimal.
In order to preserve the information about the decimal exponent, in both cases Decimal formatting displays as many fractional digits as dictated by it's exponent.

----------
assignee: docs at python
components: Documentation
messages: 358667
nosy: docs at python, mamrhein
priority: normal
severity: normal
status: open
title: Description of "Format Specification Mini-Language" not accurate for Decimal
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:19:41 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Thu, 19 Dec 2019 10:19:41 +0000
Subject: [issue39077] Numeric formatting inconsistent between int,
 float and Decimal
In-Reply-To: <1576604882.94.0.74204520541.issue39077@roundup.psfhosted.org>
Message-ID: <1576750781.53.0.186515941546.issue39077@roundup.psfhosted.org>


Michael Amrhein <michael at adrhinum.de> added the comment:

Created new issue for tracking the deficiencies in the documentation:
https://bugs.python.org/issue39096.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39077>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:21:19 2019
From: report at bugs.python.org (Michael Amrhein)
Date: Thu, 19 Dec 2019 10:21:19 +0000
Subject: [issue39096] Description of "Format Specification Mini-Language" not
 accurate for Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1576750879.22.0.666273818521.issue39096@roundup.psfhosted.org>


Michael Amrhein <michael at adrhinum.de> added the comment:

For a discussion of the different behaviour of float and Decimal see https://bugs.python.org/issue39077.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:37:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2019 10:37:20 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576751840.69.0.228803409022.issue39087@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

return PyBytesType.tp_as_buffer(bytes, view, PyBUF_CONTIG_RO);

Don't you need to DECREF bytes somehow, at least, in case of failure?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:54:46 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 19 Dec 2019 10:54:46 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576752886.74.0.552643914848.issue39094@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What would the proposal look like for `statistics.stdev`? There you need at least two data points to compute a result, and a user might want to do different things for an empty dataset versus a single data point.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Thu Dec 19 06:12:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2019 11:12:06 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576753926.23.0.0437809592277.issue39094@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I've tried think of other solutions, such as a generic wrapper for such functions or a helper to check whether an iterable is empty, and they all turn out to be very clunky to use and un-Pythonic.

So the main use case would be to detect an empty iterable in an efficient fashion? Something like the following code?

sentinel = objet()
avg = mean(data, default=sentinel)
if avg is sentinel:
   ... # special code path

Why not adding a statistics.StatisticsError subclass for empty set (ex: StatisticsEmptyError)? Something like:

try:
   avg = mean(data)
except statistics.StatisticsEmptyError:
   ... # special code path, ex: avg = default

Or is there another use case for the proposed default parameter?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Thu Dec 19 06:20:38 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 19 Dec 2019 11:20:38 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576754438.08.0.490113990253.issue39087@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Don't you need to DECREF bytes somehow, at least, in case of failure?

Thanks.  I will create a pull request with suggested changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 06:21:33 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 19 Dec 2019 11:21:33 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576754493.39.0.306516948018.issue39094@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

TL;DR: I'm not likely to accept this feature request without at least one of (1) a practical use-case, (2) prior art in other statistics software, or (3) a strong mathematical justification for why this is meaningful and useful.


I'm not categorically against this idea, but it seems a bit fishy to me. If you have no data, how do you know what default value to give that would be appropriate for your (non-existent) observations?

It might help if you could show a real-life example of how, and why, you would use this, and how you would choose the default?

Another possibility would be to find prior-art: another language, library or stats calculator which already offers this feature.

Alternatively, a mathematical/statistical justification for a default. For example, the empty sum is normally taken as 0 and the empty product as 1. R returns either a NAN or NA for the empty mean (depending on precisely how you calculate it).

While I'm personally sympathetic to the nuisance factor of having to wrap code in try...except blocks (my *personal* preference would have been for mean to return NAN on empty input) I think you will need to make a stronger case than just the analogy with min and max.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Thu Dec 19 06:59:20 2019
From: report at bugs.python.org (songyuc)
Date: Thu, 19 Dec 2019 11:59:20 +0000
Subject: [issue39097] The description of multiprocessing.cpu_count() is not
 accurate in the documentation
Message-ID: <1576756760.59.0.899129841323.issue39097@roundup.psfhosted.org>


New submission from songyuc <466309936 at qq.com>:

In the documentation of Python 3.7, the description of multiprocessing.cpu_count() is "Return the number of CPUs in the system.", but, in fact, this function return the CPU threads number.

----------
assignee: docs at python
components: Documentation
messages: 358675
nosy: docs at python, songyuc
priority: normal
severity: normal
status: open
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39097>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:13:08 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 19 Dec 2019 12:13:08 +0000
Subject: [issue39097] The description of multiprocessing.cpu_count() is not
 accurate in the documentation
In-Reply-To: <1576756760.59.0.899129841323.issue39097@roundup.psfhosted.org>
Message-ID: <1576757588.66.0.346045852029.issue39097@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

While your suggestion is technically correct, CPU as a shortcut for "logical processor" is very common in software engineering.

For me, "number of CPU threads" is more unclear than just "number of CPUs"

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39097>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:26:56 2019
From: report at bugs.python.org (songyuc)
Date: Thu, 19 Dec 2019 12:26:56 +0000
Subject: [issue39097] The description of multiprocessing.cpu_count() is not
 accurate in the documentation
In-Reply-To: <1576756760.59.0.899129841323.issue39097@roundup.psfhosted.org>
Message-ID: <1576758416.11.0.954906225865.issue39097@roundup.psfhosted.org>


songyuc <466309936 at qq.com> added the comment:

Hi, Andrew!
Thanks for your explanation! I am sorry about my unfamiliarity about the shortcut, as a student from China whose mother tongue is not English. So I am not quite familiar with the English customs in Computer engineering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39097>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:36:22 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 19 Dec 2019 12:36:22 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576758982.91.0.632991882407.issue39087@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +17127
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17659

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:58:09 2019
From: report at bugs.python.org (Josh de Kock)
Date: Thu, 19 Dec 2019 12:58:09 +0000
Subject: [issue11245] Implementation of IMAP IDLE in imaplib?
In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za>
Message-ID: <1576760289.78.0.981880767559.issue11245@roundup.psfhosted.org>


Josh de Kock <josh at itanimul.li> added the comment:

Hi, I'm new to python but I had a go at implementing this for imaplib(1) using a different approach. It works but it has a couple issues (see patch), I would appreciate any thoughts/improvements.

----------
nosy: +jdek
versions: +Python 3.9 -Python 3.6
Added file: https://bugs.python.org/file48790/0001-Add-IDLE-support-to-imaplib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11245>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:19:43 2019
From: report at bugs.python.org (Patrick Buxton)
Date: Thu, 19 Dec 2019 13:19:43 +0000
Subject: [issue39098] OSError: handle is closed in ProcessPoolExecutor on
 shutdown(wait=False)
Message-ID: <1576761583.89.0.930155685361.issue39098@roundup.psfhosted.org>


New submission from Patrick Buxton <patrick.buxton at tartansolutions.com>:

When shutting down a ProcessPoolExecutor with wait=False, an `OSError: handle is closed` is raised.

The error can be replicated with a script as simple as:

```
from concurrent.futures import ProcessPoolExecutor

e = ProcessPoolExecutor()
e.submit(id)
e.shutdown(wait=False)

----------
components: Library (Lib)
messages: 358679
nosy: patbuxton
priority: normal
severity: normal
status: open
title: OSError: handle is closed in ProcessPoolExecutor  on shutdown(wait=False)
type: crash
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39098>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:39:18 2019
From: report at bugs.python.org (thautwarm)
Date: Thu, 19 Dec 2019 13:39:18 +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: <1576762758.0.0.000530704653187.issue34850@roundup.psfhosted.org>


thautwarm <yaoxiansamma at gmail.com> added the comment:

Thanks.
However, unfortunately, this warning seems impossible to suppress.

Use following example:

  import warnings
  warnings.filterwarnings('ignore')

  warnings.warn(SyntaxWarning("test"))

  def f(x):
    return x is 5

  print(f(5))

I succeeded in suppressing my own  SyntaxWarning("test") , but the output is still:
  
  python a.py
  a.py:7: SyntaxWarning: "is" with a literal. Did you mean "=="?
    return x is 5
  True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:26:59 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 19 Dec 2019 14:26:59 +0000
Subject: [issue39096] Description of "Format Specification Mini-Language" not
 accurate for Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1576765619.97.0.351844847105.issue39096@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:36:08 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 19 Dec 2019 14:36:08 +0000
Subject: [issue38316] docs: Code object's "co_stacksize" field is described
 with mistake
In-Reply-To: <1569789294.48.0.284805020981.issue38316@roundup.psfhosted.org>
Message-ID: <1576766168.12.0.290652533414.issue38316@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17128
pull_request: https://github.com/python/cpython/pull/17660

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38316>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:38:40 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 19 Dec 2019 14:38:40 +0000
Subject: [issue38316] docs: Code object's "co_stacksize" field is described
 with mistake
In-Reply-To: <1569789294.48.0.284805020981.issue38316@roundup.psfhosted.org>
Message-ID: <1576766320.26.0.152278850345.issue38316@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17129
pull_request: https://github.com/python/cpython/pull/17661

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38316>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:41:54 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 19 Dec 2019 14:41:54 +0000
Subject: [issue38316] docs: Code object's "co_stacksize" field is described
 with mistake
In-Reply-To: <1569789294.48.0.284805020981.issue38316@roundup.psfhosted.org>
Message-ID: <1576766514.01.0.801723848065.issue38316@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 917419f58b2869d71691c5ba54a9e02e5dcf73b2 by Miss Islington (bot) (Batuhan Ta?kaya) in branch '3.7':
[3.7] bpo-38316: Fix co_stacksize documentation (GH-16983). (GH-17660)
https://github.com/python/cpython/commit/917419f58b2869d71691c5ba54a9e02e5dcf73b2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38316>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:44:33 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 19 Dec 2019 14:44:33 +0000
Subject: [issue38316] docs: Code object's "co_stacksize" field is described
 with mistake
In-Reply-To: <1569789294.48.0.284805020981.issue38316@roundup.psfhosted.org>
Message-ID: <1576766673.58.0.892823919796.issue38316@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset eba61f33d60cc63e35d5f5fcada837a66c89774a by Miss Islington (bot) (Batuhan Ta?kaya) in branch '3.8':
[3.8] bpo-38316: Fix co_stacksize documentation (GH-16983) (GH-17661)
https://github.com/python/cpython/commit/eba61f33d60cc63e35d5f5fcada837a66c89774a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38316>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:51:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2019 14:51:51 +0000
Subject: [issue38316] docs: Code object's "co_stacksize" field is described
 with mistake
In-Reply-To: <1569789294.48.0.284805020981.issue38316@roundup.psfhosted.org>
Message-ID: <1576767111.67.0.951405505147.issue38316@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Paul Sokolovsky for the bug report and thanks Batuhan Ta?kaya for the fix ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38316>
_______________________________________

From report at bugs.python.org  Thu Dec 19 10:15:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2019 15:15:21 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1576768521.61.0.0858417845046.issue38980@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Pablo:
> I have seen people using LD_PRELOAD (...) to interpose faster versions of some functions or to collect metrics (although there are better ways).

IMHO if someone has to go so far into "hacking" Python, they should recompile Python with specific options. I'm not sure that using LD_PRELOAD to get "faster versions of some functions" is the best approach in term of performance, but I expect it to be convenient :-)


Charalampos:
> I think it will add to the complexity of the --with-optimizations flag which already implies PGO and LTO.

It doesn't enable LTO, only PGO :-) We had to disable LTO because of multiple compiler bugs last years.


Serhiy:
> I am sure some C API functions are purposed to be overridden.

Is it a theorical use case, or are you aware of such use case being currently used in the wild?


Ammar Askar:
> Just for a quick datapoint: llvm/clang do this by default and you need an explicit `-fsemantic-interposition` to disable it http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html

Oh, that's really interesting, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38980>
_______________________________________

From report at bugs.python.org  Thu Dec 19 10:26:59 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 19 Dec 2019 15:26:59 +0000
Subject: [issue32888] Improve exception message in ast.literal_eval
In-Reply-To: <1519147581.54.0.467229070634.issue32888@psf.upfronthosting.co.za>
Message-ID: <1576769219.37.0.561351584666.issue32888@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17130
pull_request: https://github.com/python/cpython/pull/17662

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32888>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:36:27 2019
From: report at bugs.python.org (obserience)
Date: Thu, 19 Dec 2019 16:36:27 +0000
Subject: [issue39093] tkinter objects garbage collected from non-tkinter
 thread cause panic and core dump
In-Reply-To: <1576724216.68.0.395572121912.issue39093@roundup.psfhosted.org>
Message-ID: <1576773387.52.0.231612141338.issue39093@roundup.psfhosted.org>


obserience <obserience at gmail.com> added the comment:

My proposed fix isn't compatible with a lot of current Tkinter using code. It was a naive first attempt and breaks existing code and doesn't completely solve the problem.

Variables currently retain a reference to the TCL interpreter self._tk and aren't linked into the widget tree or otherwise accessible to any cleanup logic.

Existing code:
-may expect the self.tk attribute of destroyed widgets to still be set

Existing code (after calling root.destroy()):
-calls methods like Tk.quit() which runs Tcl commands requiring self.tk to still be there
--Idle does this "# (Needed for clean exit on Windows 98)" <--apparently
---is this still the case??
-may call get() and set() on Variable instances (this currently works)


Given this it might be better to track all references to the TCL interpreter in a separate data structure and add a Tk.cleanup() method that gets rid of them all with documentation indicating all calls after this will fail. Alternate implementation of this deallocates the TCL interpreter in the _tkinter.c bindings with the same results.

One of the core issues here is that the cause of the crash is asynchronous signal handlers installed by the TCL library and necessary for the TCL interpreter to run at all. If you can run TCL commands, the crash can still be triggered.

###separate issue###
The Tk.Quit() doc is wrong. Current inline docs say that it destroys all widgets, which it does not. All it seems to do is cause mainloop to return after which mainloop can be called again and the GUI resumes functioning. This has caused problems when the main thread doesn't exit since the GUI continues to exist but is frozen. (See quit_behavior.py)

----------
Added file: https://bugs.python.org/file48791/quit_behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39093>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:29:01 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 19 Dec 2019 18:29:01 +0000
Subject: [issue39099] scandir.dirfd() method
Message-ID: <1576780141.57.0.935904677179.issue39099@roundup.psfhosted.org>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

PR in attachment adds a new dirfd() method to the scandir() object (POSIX only). This can be be passed to os.* functions supporting the "dir_fd" parameter, and avoid opening a new fd as in:

    >>> dirfd = os.open("basename", os.O_RDONLY, dir_fd=topfd)

At the moment I am not sure if it's possible to also support Windows.

----------
components: Library (Lib)
messages: 358686
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: scandir.dirfd() method
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39099>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:29:56 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 19 Dec 2019 18:29:56 +0000
Subject: [issue39099] scandir.dirfd() method
In-Reply-To: <1576780141.57.0.935904677179.issue39099@roundup.psfhosted.org>
Message-ID: <1576780196.02.0.512484069614.issue39099@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
keywords: +patch
pull_requests: +17131
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17664

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39099>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:47:40 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 19 Dec 2019 18:47:40 +0000
Subject: [issue39099] scandir.dirfd() method
In-Reply-To: <1576780141.57.0.935904677179.issue39099@roundup.psfhosted.org>
Message-ID: <1576781260.34.0.702233677652.issue39099@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Why not just os.open the directory yourself and pass it to os.scandir?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39099>
_______________________________________

From report at bugs.python.org  Thu Dec 19 14:08:15 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 19 Dec 2019 19:08:15 +0000
Subject: [issue39099] scandir.dirfd() method
In-Reply-To: <1576780141.57.0.935904677179.issue39099@roundup.psfhosted.org>
Message-ID: <1576782495.56.0.0155423261081.issue39099@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Good point, I didn't consider that. I suppose you're right. =)
Closing.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39099>
_______________________________________

From report at bugs.python.org  Thu Dec 19 14:32:14 2019
From: report at bugs.python.org (Anton Khirnov)
Date: Thu, 19 Dec 2019 19:32:14 +0000
Subject: [issue39100] email.policy.SMTP throws AttributeError on invalid header
Message-ID: <1576783934.54.0.946649596481.issue39100@roundup.psfhosted.org>


New submission from Anton Khirnov <anton at khirnov.net>:

When parsing a (broken) mail from linux-media at vger.kernel.org (message-id 20190212181908.Horde.pEiGHvV2KHy9EkUy8TA8D1o at webmail.your-server.de, headers attached) with email.policy.SMTP, I get an AttributeError on trying to read the 'to' header:

/usr/lib/python3.7/email/headerregistry.py in <listcomp>(.0)
    345                                              mb.local_part or '',
    346                                              mb.domain or '')
--> 347                                      for mb in addr.all_mailboxes]))
    348             defects = list(address_list.all_defects)
    349         else:

AttributeError: 'Group' object has no attribute 'local_part'

The header in question is:
To:     unlisted-recipients:; (no To-header on input)

The problem seems to be that mb is a Group and not an Address, gets token_type of 'invalid-mailbox', but does not have the attributes local_part/domain that are expected in mailboxes. Copying the line

local_part = domain = route = addr_spec = display_name

from InvalidMailbox to Group fixes this, but it is not clear to me this is the right solution, so not sending a patch.

----------
components: email
files: mail.eml
messages: 358689
nosy: barry, elenril, r.david.murray
priority: normal
severity: normal
status: open
title: email.policy.SMTP throws AttributeError on invalid header
type: behavior
Added file: https://bugs.python.org/file48792/mail.eml

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39100>
_______________________________________

From report at bugs.python.org  Thu Dec 19 14:44:59 2019
From: report at bugs.python.org (Fabio Pugliese Ornellas)
Date: Thu, 19 Dec 2019 19:44:59 +0000
Subject: [issue39101] IsolatedAsyncioTestCase freezes when exception is raised
Message-ID: <1576784699.03.0.850711294275.issue39101@roundup.psfhosted.org>


New submission from Fabio Pugliese Ornellas <fabio.ornellas at gmail.com>:

IsolatedAsyncioTestCase freezes whenever an exception that inherits from BaseException is raised:


import unittest
class TestHangsForever(unittest.IsolatedAsyncioTestCase):
    async def test_hangs_forever(self):
        raise BaseException("Hangs forever")
if __name__ == "__main__":
    import unittest
    unittest.main()

A kind of similar issue present on 3.7 was fixed on 3.8 here https://github.com/python/cpython/blob/3.8/Lib/asyncio/events.py#L84, where BaseExceptions would not be correctly handled by the event loop, this seems somewhat related.

I had a look at IsolatedAsyncioTestCase implementation, did not spot any obvious broken thing there, I could use some light here. Thanks.

----------
components: asyncio
messages: 358690
nosy: asvetlov, fornellas, yselivanov
priority: normal
severity: normal
status: open
title: IsolatedAsyncioTestCase freezes when exception is raised
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39101>
_______________________________________

From report at bugs.python.org  Thu Dec 19 14:55:52 2019
From: report at bugs.python.org (Fabio Pugliese Ornellas)
Date: Thu, 19 Dec 2019 19:55:52 +0000
Subject: [issue39101] IsolatedAsyncioTestCase freezes when exception is raised
In-Reply-To: <1576784699.03.0.850711294275.issue39101@roundup.psfhosted.org>
Message-ID: <1576785352.46.0.54957498068.issue39101@roundup.psfhosted.org>


Change by Fabio Pugliese Ornellas <fabio.ornellas at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39101>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:50:24 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 19 Dec 2019 21:50:24 +0000
Subject: [issue39070] Uninstalling 3.8.0 fails but it says it succeeds..
In-Reply-To: <1576539774.23.0.330588412038.issue39070@roundup.psfhosted.org>
Message-ID: <1576792224.93.0.287564721492.issue39070@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The only issue I see in that log is an apparent failure communicating between the unelevated and the elevated components of the uninstaller. But that doesn't seem to have interfered with the rest of the process, so I'm at a bit of a loss.

Possibly it has gotten confused because of running as administrator to install the py.exe launcher for all users, but not the rest of it.

When you say the system asked for admin right - do you mean you had to authenticate as a different user? Or you had to click "Yes" to give it permissions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39070>
_______________________________________

From report at bugs.python.org  Thu Dec 19 17:31:26 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2019 22:31:26 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1576794686.95.0.530637903784.issue38971@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17132
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17666

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38971>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:11:30 2019
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 20 Dec 2019 01:11:30 +0000
Subject: [issue39099] scandir.dirfd() method
In-Reply-To: <1576780141.57.0.935904677179.issue39099@roundup.psfhosted.org>
Message-ID: <1576804290.18.0.340904662411.issue39099@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I am not sure if it's possible to also support Windows.

For reference, FindFirstFileW doesn't support handle-relative names, and neither does CreateFileW. At a lower level in Windows NT, NtCreateFile has always supported handle-relative names, but CPython doesn't use the NT API.

fd support (not dirfd) could be added to listdir and scandir in Windows. A directory can be listed via GetFileInformationByHandleEx: FileFullDirectoryInfo. This doesn't query the short name, so it may perform better than FindFirstFileW. However, opening a directory with os.open can't be supported. VC++ still hasn't documented the _O_OBTAIN_DIR (0x2000) flag.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39099>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:07:46 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Fri, 20 Dec 2019 02:07:46 +0000
Subject: [issue38815] test_ssl: test_min_max_version() fails on FreeBSD and
 Fedora
In-Reply-To: <1573836860.92.0.531253629667.issue38815@roundup.psfhosted.org>
Message-ID: <1576807666.95.0.296499175235.issue38815@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

@Christian As current assignee, are you able to produce a test that fixes the remaining issue (per msg357792)? I can rebuild OpenSSL on the worker at your direction at any time to make the test fail again or provide you with an SSH account to assist

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:48:28 2019
From: report at bugs.python.org (Arseny Boykov)
Date: Fri, 20 Dec 2019 02:48:28 +0000
Subject: [issue39102] Increase Enum performance
Message-ID: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>


New submission from Arseny Boykov <appkiller16 at gmail.com>:

Now enum has very poor speed on trying values and attributes access (especially when it comes to accessing members name/value attrs)

There are two major reasons why attrs access is slow:
  - All values/names access going through DynamicClassAttribute (x10 slower than accessing attr directly)
  - EnumMeta has __getattr__ which is slowing down even direct class attributes access (up to x6 slower)

However, there are no need to use it, as we could just set value and name to newly created enum members without affecting its class.

The main issue with values check is the slow _missing_ hook handling when it raising exception, which happens pretty much always, if value is not valid enum and we talking about vanilla Enum class.

Also I found Flag performance issue being fixed already:
https://bugs.python.org/issue38045
It's also related, because new Flag creation involves many member.name lookups


My proposal:
  - I think we should completely get rid of __getattr__ on Enum (~6x speed boost)
  - Rework DynamicClassAttribute so it could work without __getattr__ or perhaps completely get rid of it
  - Don't use DynamicClassAttribute for member.name and .value (~10x speed boost)
  - Think of faster handling of _missing_ hook  (~2x speed boost)
  - Make other improvements to the code


Proposed changes doesn't require changing public API or behaviour.

By far I were able to implement almost things proposed here and will be happy to make a PR.

----------
components: Library (Lib)
files: benchmark_result.txt
messages: 358694
nosy: MrMrRobat
priority: normal
severity: normal
status: open
title: Increase Enum performance
type: performance
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48793/benchmark_result.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Thu Dec 19 22:01:57 2019
From: report at bugs.python.org (Arseny Boykov)
Date: Fri, 20 Dec 2019 03:01:57 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1576810917.97.0.80910405675.issue39102@roundup.psfhosted.org>


Change by Arseny Boykov <appkiller16 at gmail.com>:


----------
keywords: +patch
pull_requests: +17133
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17669

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Thu Dec 19 23:07:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 20 Dec 2019 04:07:29 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1576814849.82.0.413642230314.issue39102@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +barry, eli.bendersky, ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Fri Dec 20 00:32:00 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 20 Dec 2019 05:32:00 +0000
Subject: [issue39103] [linux] strftime renders %Y with only 3 characters
Message-ID: <1576819920.4.0.445555745721.issue39103@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

On Python 3.8, there's a difference between how datetime.datetime.strftime renders %Y for years < 1000 between Linux and other platforms.

# Linux
$ docker run -it python python -c 'import datetime; print(datetime.date(900,1,1).strftime("%Y"))'                       
900

# macOS
$ python -c 'import datetime; print(datetime.date(900,1,1).strftime("%Y"))'                                             
0900


According to the docs (https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior), one should expect `'0000'` for year zero and so I'd expect `'0900'` for the year 900, so the macOS behavior looks correct to me.

----------
components: Library (Lib)
messages: 358695
nosy: jaraco
priority: normal
severity: normal
status: open
title: [linux] strftime renders %Y with only 3 characters
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39103>
_______________________________________

From report at bugs.python.org  Fri Dec 20 00:48:45 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Dec 2019 05:48:45 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576820925.55.0.410977262527.issue39094@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thought experiment: Suppose someone proposed, "math.log(x) should take an optional default argument because it is inconvenient to a catch a ValueError if the input is non-positive".   Or more generally, what if someone proposed, "every function in Python that can raise a ValueError should offer a default argument."  One could imagine a use case for both of these proposals but that doesn't mean that the API extensions would be warranted.

Also, ISTM the analogy to min() and max() is imperfect.  Those aren't descriptive statistics.  For min() and max() we can know a priori that a probability is never lower than 0.0 or greater than 1.0 for example.

Lastly, in common cases where the input is a sequence (rather than just an iterator), we already have a ternary operator to does the job nicely:

   central_value = mean(data) if data else 'unknown'

For the less common case, a try/except is not an undue burden; after all, it is a basic core language feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Fri Dec 20 01:18:03 2019
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 20 Dec 2019 06:18:03 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1576822683.59.0.20542878472.issue39102@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Fri Dec 20 01:21:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 20 Dec 2019 06:21:30 +0000
Subject: [issue39103] [linux] strftime renders %Y with only 3 characters
In-Reply-To: <1576819920.4.0.445555745721.issue39103@roundup.psfhosted.org>
Message-ID: <1576822890.58.0.082933819855.issue39103@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/issue39103>
_______________________________________

From report at bugs.python.org  Fri Dec 20 01:52:22 2019
From: report at bugs.python.org (Thomas Moreau)
Date: Fri, 20 Dec 2019 06:52:22 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
Message-ID: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>


New submission from Thomas Moreau <thomas.moreau.2010 at gmail.com>:

The attached scripts hangs on python3.7+.
This is due to the fact that the main process closes the communication channels directly while the queue_management_thread might still use them.

To prevent that, all the closing should be handled by the queue_management_thread.

----------
components: Library (Lib)
files: main.py
messages: 358697
nosy: tomMoral
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor hangs on shutdown nowait with pickling failure
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48794/main.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Fri Dec 20 01:54:22 2019
From: report at bugs.python.org (Thomas Moreau)
Date: Fri, 20 Dec 2019 06:54:22 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
In-Reply-To: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>
Message-ID: <1576824862.7.0.235397483134.issue39104@roundup.psfhosted.org>


Change by Thomas Moreau <thomas.moreau.2010 at gmail.com>:


----------
keywords: +patch
pull_requests: +17134
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17670

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Fri Dec 20 02:17:39 2019
From: report at bugs.python.org (Printer offline)
Date: Fri, 20 Dec 2019 07:17:39 +0000
Subject: [issue39105] Printer offline
Message-ID: <1576826259.24.0.691283351338.issue39105@roundup.psfhosted.org>


New submission from Printer offline <printeroff888 at gmail.com>:

This blog has increased the level of information sharing. I just simply loved this blog. It has helped me a lot. A great and learning blog. I am very satisfied after reading this. https://www.printer-offline.com/

----------
components: asyncio
files: Roko-Logo-2-fi18353094x260.png
messages: 358698
nosy: Printer offline, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Printer offline
type: resource usage
versions: Python 3.8
Added file: https://bugs.python.org/file48795/Roko-Logo-2-fi18353094x260.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39105>
_______________________________________

From report at bugs.python.org  Fri Dec 20 02:19:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 20 Dec 2019 07:19:49 +0000
Subject: [issue39105] Spam
In-Reply-To: <1576826259.24.0.691283351338.issue39105@roundup.psfhosted.org>
Message-ID: <1576826389.67.0.868966790735.issue39105@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components:  -asyncio
nosy:  -asvetlov, yselivanov
stage:  -> resolved
status: open -> closed
title: Printer offline -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39105>
_______________________________________

From report at bugs.python.org  Fri Dec 20 03:56:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 20 Dec 2019 08:56:09 +0000
Subject: [issue39106] Add suggestions to argparse error message output for
 unrecognized arguments
Message-ID: <1576832169.43.0.680374670537.issue39106@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I came across this idea while working on error messages for click at https://github.com/pallets/click/issues/1446. Currently for unknown arguments which could in some case be typos argparse throws an error but doesn't make any suggestions. It could do some heuristic to suggest matches. The unrecognized argument error prints all unrecognized arguments so in that case it will be less useful to mix match suggestions. It can be helpful for single argument usages. argparse is performance sensitive since it's used in cli environments so I feel the tradeoff to do simple match to make suggestions as a good user experience.

# ssl_helper.py

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('--include-ssl', action='store_true')
namespace = parser.parse_args()

No suggestions are included currently

$ python3.8 ssl_helper.py --include-ssll
usage: ssl_helper.py [-h] [--include-ssl]
ssl_helper.py: error: unrecognized arguments: --include-ssll

Include suggestions based when one of the option starts with the argument supplied similar to click

$ ./python.exe ssl_helper.py --include-ssll
usage: ssl_helper.py [-h] [--include-ssl]
ssl_helper.py: error: unrecognized argument: --include-ssll . Did you mean --include-ssl?

difflib.get_close_matches could also provide better suggestions in some cases but comes at import cost and could be imported only during error messages as proposed in the click issue

./python.exe ssl_helper.py --exclude-ssl
usage: ssl_helper.py [-h] [--include-ssl]
ssl_helper.py: error: unrecognized argument: --exclude-ssl . Did you mean --include-ssl?


Attached is a simple patch of the implementation with startswith which is more simple and difflib.get_close_matches

diff --git Lib/argparse.py Lib/argparse.py
index 5d3ce2ad70..e10a4f0c9b 100644
--- Lib/argparse.py
+++ Lib/argparse.py
@@ -1818,8 +1818,29 @@ class ArgumentParser(_AttributeHolder, _ActionsContainer):
     def parse_args(self, args=None, namespace=None):
         args, argv = self.parse_known_args(args, namespace)
         if argv:
-            msg = _('unrecognized arguments: %s')
-            self.error(msg % ' '.join(argv))
+            suggestion = None
+            if len(argv) == 1:
+                argument = argv[0]
+
+                # simple startswith
+                for option in self._option_string_actions:
+                    if argument.startswith(option):
+                        suggestion = option
+                        break
+
+                # difflib impl
+                import difflib
+                try:
+                    suggestion = difflib.get_close_matches(argv[0], self._option_string_actions, n=1)[0]
+                except IndexError:
+                    pass
+
+            if suggestion:
+                msg = _('unrecognized argument: %s . Did you mean %s?')
+                self.error(msg % (' '.join(argv), suggestion))
+            else:
+                msg = _('unrecognized arguments: %s')
+                self.error(msg % ' '.join(argv))
         return args
 
     def parse_known_args(self, args=None, namespace=None):

----------
components: Library (Lib)
messages: 358699
nosy: paul.j3, rhettinger, xtreak
priority: normal
severity: normal
status: open
title: Add suggestions to argparse error message output for unrecognized arguments
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39106>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:02:04 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 20 Dec 2019 10:02:04 +0000
Subject: [issue39097] The description of multiprocessing.cpu_count() is not
 accurate in the documentation
In-Reply-To: <1576756760.59.0.899129841323.issue39097@roundup.psfhosted.org>
Message-ID: <1576836124.61.0.216231446584.issue39097@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39097>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:02:55 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 20 Dec 2019 10:02:55 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576836175.06.0.054495493372.issue39094@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I agree with Raymond's comments, except that because I'm sometimes a bit
of a pedant, I have to make one minor correction: max and min can be
descriptive statistics.

The sample minimum is the 1st order statistic, and the sample maximum is
the N-th order statistic:

https://www2.stat.duke.edu/courses/Spring12/sta104.1/Lectures/Lec15.pdf

This doesn't invalidate the rest of what Raymond says.

Yoni Lavi, thank you for the suggestion, but I'm going to close this ticket. If you think you have a really strong argument for the feature, please feel free to make it here, and we will rethink the closure. But I don't want to give you false hope: it would have to be a very strong argument.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:35:40 2019
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 20 Dec 2019 10:35:40 +0000
Subject: [issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1576838140.05.0.711044709551.issue13153@roundup.psfhosted.org>


Aivar Annamaa <aivar.annamaa at gmail.com> added the comment:

>>> '\N{PERSONAL COMPUTER}'

freezes IDLE 3.7.6 (64-bit, downloaded from python.org) on macOS 10.15

Can it be because Tk 8.6.8 is still used there?

----------
nosy: +Aivar.Annamaa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:42:20 2019
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 20 Dec 2019 10:42:20 +0000
Subject: [issue39107] Consider upgrading Tkinter to Tk 8.6.10
Message-ID: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>


New submission from Aivar Annamaa <aivar.annamaa at gmail.com>:

It includes several Mac-related enhancements
https://sourceforge.net/projects/tcl/files/Tcl/8.6.10/tcltk-release-notes-8.6.10.txt/view

----------
components: Tkinter
messages: 358702
nosy: Aivar.Annamaa
priority: normal
severity: normal
status: open
title: Consider upgrading Tkinter to Tk 8.6.10
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:44:08 2019
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 20 Dec 2019 10:44:08 +0000
Subject: [issue39107] Consider upgrading Tkinter to Tk 8.6.10
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1576838648.72.0.459083829522.issue39107@roundup.psfhosted.org>


Change by Aivar Annamaa <aivar.annamaa at gmail.com>:


----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:45:48 2019
From: report at bugs.python.org (Aivar Annamaa)
Date: Fri, 20 Dec 2019 10:45:48 +0000
Subject: [issue39107] Consider building Tkinter with Tk 8.6.10
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1576838748.04.0.745841756012.issue39107@roundup.psfhosted.org>


Change by Aivar Annamaa <aivar.annamaa at gmail.com>:


----------
title: Consider upgrading Tkinter to Tk 8.6.10 -> Consider building Tkinter with Tk 8.6.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Fri Dec 20 06:45:13 2019
From: report at bugs.python.org (Charles Newey)
Date: Fri, 20 Dec 2019 11:45:13 +0000
Subject: [issue39108] Documentation for "random.gauss" vs
 "random.normalvariate" is lacking
Message-ID: <1576842313.59.0.109867222427.issue39108@roundup.psfhosted.org>


New submission from Charles Newey <charlie at newey.me>:

The Python 3 documentation for the "random" module mentions two possible ways to generate a random variate drawn from a normal distribution - "random.gauss" and "random.normalvariate" (see: https://docs.python.org/3/library/random.html#random.gauss).

It's not clear what the distinction is other than apparently the "random.gauss" function is faster. Digging through the source code, it eventually becomes apparent that "random.gauss" is NOT thread safe... but this isn't mentioned in the documentation anywhere.

Further, the documentation doesn't make explicit reference to the particular method used for generating these Gaussian variates.

Basically what I'm getting at is that it's difficult to tell which function ("gauss" or "randomvariate") I should be using. I feel that the documentation could be clarified here. I'm happy to do this in a PR at some point if required.

----------
assignee: docs at python
components: Documentation
messages: 358703
nosy: cnewey, docs at python
priority: normal
severity: normal
status: open
title: Documentation for "random.gauss" vs "random.normalvariate" is lacking
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39108>
_______________________________________

From report at bugs.python.org  Fri Dec 20 06:54:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 20 Dec 2019 11:54:56 +0000
Subject: [issue39108] Documentation for "random.gauss" vs
 "random.normalvariate" is lacking
In-Reply-To: <1576842313.59.0.109867222427.issue39108@roundup.psfhosted.org>
Message-ID: <1576842896.61.0.214577138316.issue39108@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39108>
_______________________________________

From report at bugs.python.org  Fri Dec 20 06:55:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 20 Dec 2019 11:55:22 +0000
Subject: [issue39107] Consider building Tkinter with Tk 8.6.10
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1576842922.95.0.779141589298.issue39107@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Fri Dec 20 07:13:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 12:13:44 +0000
Subject: [issue13153] IDLE 3.x on Windows exits when pasting non-BMP unicode
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1576844024.29.0.627317142013.issue13153@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On Windows with 8.6.9, I see '\U0001f4bb' on 3.7.5 and '?' on 3.8.0 and 3.9.0a0.  I don't know why the difference as Serhiy's patch was backported. I will upgrade 3.7 and 3.8 and try again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Dec 20 07:18:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 12:18:57 +0000
Subject: [issue39107] Consider building Tkinter with Tk 8.6.10
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1576844337.3.0.295866000151.issue39107@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ned is aware of this and needs to verify that it works with _tkinter and tkinter on multiple versions of macOS.

----------
assignee: terry.reedy -> ned.deily
components: +macOS -IDLE
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Fri Dec 20 07:33:15 2019
From: report at bugs.python.org (Yannick)
Date: Fri, 20 Dec 2019 12:33:15 +0000
Subject: [issue39109] [C-API] PyUnicode_FromString
Message-ID: <1576845195.58.0.163622932603.issue39109@roundup.psfhosted.org>


New submission from Yannick <schmetzyannick at gmail.com>:

Python version: 3.5
Tested with VS Studio 2017 in an C-API extension.

When you have a UTF-8 encoded char buffer which is filled with a 0 or empty, and you youse the PyUnicode_FromString() method on this buffer, you will get a PyObject*. The content looks good, but the refence counter looks strange. 

In case of an 0 as char in the buffer, the ob_refcnt Field is set to 100 and in case of an empty buffer, the ob_refcnt Field is set to something around 9xx. 

Example Code: 
      string s1 = u8"";
      string s2 = u8"0";

      PyObject *o1 = PyUnicode_FromString(s1.c_str());
      //o1->ob_refcnt = 9xx
      PyObject *o2 = PyUnicode_FromString(s2.c_str());
      //o2->ob_refcnt = 100

I think the ob_refcnt Field should be 1 in both cases. Or why is the refcnt here so high?

----------
components: C API
messages: 358706
nosy: YannickSchmetz
priority: normal
severity: normal
status: open
title: [C-API] PyUnicode_FromString
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39109>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:07:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2019 13:07:41 +0000
Subject: [issue39109] [C-API] PyUnicode_FromString
In-Reply-To: <1576845195.58.0.163622932603.issue39109@roundup.psfhosted.org>
Message-ID: <1576847261.67.0.448662637576.issue39109@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I think the ob_refcnt Field should be 1 in both cases. Or why is the refcnt here so high?

Python has singletons for short strings: empty string and 1-character latin1 characters (unicode range [U+0000; U+00FF]).

Examples:

>>> sys.getrefcount("")
103
>>> sys.getrefcount("a")
11

It's not a bug, but an optimization to reduce the memory footprint ;-)

----------
nosy: +vstinner
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39109>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:32:13 2019
From: report at bugs.python.org (Yoni Lavi)
Date: Fri, 20 Dec 2019 13:32:13 +0000
Subject: [issue39094] Add a default to statistics.mean and related functions
In-Reply-To: <1576724801.65.0.624887209777.issue39094@roundup.psfhosted.org>
Message-ID: <1576848733.9.0.99118825467.issue39094@roundup.psfhosted.org>


Yoni Lavi <yoni at lavi.fm> added the comment:

Thanks for the good feedback everyone and apologies for the unresponsiveness over the past day.

I understand that my use cases may not reflect wider usage patterns and am not looking to argue against the closing. But anyway, for future reference, I'll add two real-life usage examples, which I should have included originally (again, apologies for the delay, things have been hectic).

The context is that I'm involved in running a coding bootcamp, and these are two recent cases when I needed a default of zero recently:

1. (Separately of the final grade calculations) We are interested in students' average grades on their projects as an indicator of their skills gained and their striving for excellence. When calculating this indicator, we use an average of 0 for a student who haven't yet submitted anything.

2. When providing tutoring support, we classify the "complexity" of each student issue, and then one of our indicators involves the average complexity of questions in a particular slice of time and the programme (this is particularly interesting around changes to the content). For this as well, a slice of time/programme/tutor during which there were no issues would be considered as having a complexity of 0.

Again, not disputing the decision to close, just adding these examples for future reference.
Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39094>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:00:48 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:00:48 +0000
Subject: [issue39110] It
Message-ID: <1576854048.12.0.922057499656.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


----------
files: bug.py
nosy: ctarn
priority: normal
severity: normal
status: open
title: It
type: behavior
Added file: https://bugs.python.org/file48796/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:02:33 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:02:33 +0000
Subject: [issue39110] It seems that TestCase.assertListEqual change the value
 of its parameters
Message-ID: <1576854153.89.0.902616679369.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


----------
nosy:  -ctarn
title: It -> It seems that TestCase.assertListEqual change the value of its parameters
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:04:44 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:04:44 +0000
Subject: [issue39110] It seems that unittest.TestCase.assertListEqual changes
 the value of its parameters
Message-ID: <1576854284.92.0.382609236676.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


----------
title: It seems that TestCase.assertListEqual change the value of its parameters -> It seems that unittest.TestCase.assertListEqual changes the value of its parameters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:06:58 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:06:58 +0000
Subject: [issue39110] It seems that unittest.TestCase.assertListEqual changes
 the value of its parameters
Message-ID: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>


New submission from ctarn <i at ctarn.io>:

Sorry, it is caused by list(). I will update the issue very soon.

----------
nosy: +ctarn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:15:30 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:15:30 +0000
Subject: [issue39110] It seems that unittest.TestCase.assertListEqual changes
 the value of its parameters
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576854930.89.0.383897921118.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


Removed file: https://bugs.python.org/file48796/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:17:39 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:17:39 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576855059.62.0.541197592059.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


----------
title: It seems that unittest.TestCase.assertListEqual changes the value of its parameters -> It seems that list() changes the value of the parameter
Added file: https://bugs.python.org/file48797/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:23:33 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:23:33 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576855413.96.0.33371882267.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

In the code, each item of ls = [[0], [1], [2],...] has an owner pointing to d, which is a Tree inheriting from collections.UserList.
When `d[0] = a`, and `a.owner = d`, and `_ = list(d[0:1])` is called, a.owner will be changed to d[0:1].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:24:44 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 20 Dec 2019 15:24:44 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576855484.52.0.392801050579.issue39110@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Can you give an example? Something simple, showing what you tried, what you expected, and what happened instead.

This may help: http://sscce.org/

Your bug.py file doesn't ever use the result of calling list(), so how do you know it changes the value of the parameter?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:26:53 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:26:53 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576855613.29.0.845938315725.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

Hi, thanks. It did call `list()` through `_ = list(d[0:2])`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:30:36 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:30:36 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576855836.26.0.567161116308.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

I printed the value of *.owner before and after `_ = list(d...)`, and marked the results in the comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:38:19 2019
From: report at bugs.python.org (ctarn)
Date: Fri, 20 Dec 2019 15:38:19 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576856299.16.0.146470109161.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

OK, I mean... when I call `a = list(b)`, list() changes `b` unexpectedly, not `a != b` in this case. That is why I replace the left operand with `_`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:06:27 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 20 Dec 2019 16:06:27 +0000
Subject: [issue18930] os.spawnXX functions terminates process if second
 argument is empty list
In-Reply-To: <1378378354.78.0.544374922966.issue18930@psf.upfronthosting.co.za>
Message-ID: <1576857987.35.0.346613634754.issue18930@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@SSchukat can you reproduce this issue in python 3?

----------
components: +Windows -Interpreter Core
nosy: +BTaskaya, paul.moore, steve.dower, tim.golden, zach.ware
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18930>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:10:38 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 20 Dec 2019 16:10:38 +0000
Subject: [issue23868] Uninitialized objects are tracked by the garbage
 collector
In-Reply-To: <1428159634.21.0.640344593113.issue23868@psf.upfronthosting.co.za>
Message-ID: <1576858238.15.0.932776210007.issue23868@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, pablogsal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23868>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:22:44 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 20 Dec 2019 16:22:44 +0000
Subject: [issue26845] Misleading variable name in exception handling
In-Reply-To: <1461614167.42.0.470146541912.issue26845@psf.upfronthosting.co.za>
Message-ID: <1576858964.13.0.801483412137.issue26845@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I am not sure if calls like this constitutes a problem. By the way most of the things changed in Python/ceval.c including removal of END_FINALLY (issue 33387) but calls to _PyErr_Restore is still there with that same arguments.

----------
nosy: +BTaskaya, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26845>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:25:54 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 20 Dec 2019 16:25:54 +0000
Subject: [issue26767] Inconsistant error messages for failed attribute
 modification
In-Reply-To: <1460715032.51.0.36886496046.issue26767@psf.upfronthosting.co.za>
Message-ID: <1576859154.83.0.486273257105.issue26767@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> I think it would be nice to unify error messages and make them more specific.

How can they can be more specific when they are unified?

----------
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26767>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:29:05 2019
From: report at bugs.python.org (YoSTEALTH)
Date: Fri, 20 Dec 2019 16:29:05 +0000
Subject: [issue34938] Fix mimetype.init() to account for from import
In-Reply-To: <1539036789.21.0.545547206417.issue34938@psf.upfronthosting.co.za>
Message-ID: <1576859345.02.0.310316694653.issue34938@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

I didn't receive any notification of replay on this topic.

`_default_mime_types()` should never have been a function. This function should be safe to remove as its an internal function. This would avoid unneeded function call and globals used.

Stuff like `_suffix_map_default` could be constants like `SUFFIX_MAP_DEFAULT` with `suffix_map = SUFFIX_MAP_DEFAULT.copy()`

Ashley if you feel like making these changes (optional)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34938>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:42:56 2019
From: report at bugs.python.org (Murali Ganapathy)
Date: Fri, 20 Dec 2019 16:42:56 +0000
Subject: [issue39111] Misleading documentation
Message-ID: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>


New submission from Murali Ganapathy <murali at google.com>:

The documentation at https://docs.python.org/3.6/library/constants.html#NotImplemented states

If all attempts return NotImplemented, the interpreter will raise an appropriate exception. However this is not true for __eq__.

===
class Foo:
  def __eq__(self, other):
    return NotImplemented

Foo() == Foo() # returns False, does not throw an exception
====

----------
assignee: docs at python
components: Documentation
messages: 358719
nosy: docs at python, murali
priority: normal
severity: normal
status: open
title: Misleading documentation
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:51:41 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2019 16:51:41 +0000
Subject: [issue39105] Spam
In-Reply-To: <1576826259.24.0.691283351338.issue39105@roundup.psfhosted.org>
Message-ID: <1576860701.83.0.313487003228.issue39105@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


Removed file: https://bugs.python.org/file48795/Roko-Logo-2-fi18353094x260.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39105>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:53:15 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2019 16:53:15 +0000
Subject: [issue39105] Spam
Message-ID: <1576860795.21.0.896068607604.issue39105@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
Removed message: https://bugs.python.org/msg358698

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39105>
_______________________________________

From report at bugs.python.org  Fri Dec 20 11:53:48 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2019 16:53:48 +0000
Subject: [issue39105] Spam
Message-ID: <1576860828.29.0.611324175728.issue39105@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
type: resource usage -> 
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39105>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:00:46 2019
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2019 17:00:46 +0000
Subject: [issue39107] Consider building Tkinter with Tk 8.6.10
In-Reply-To: <1576838540.23.0.689551930127.issue39107@roundup.psfhosted.org>
Message-ID: <1576861246.35.0.1320219927.issue39107@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Looks like some enhancements on Windows as well; we should upgrade at least 3.9.

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39107>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:37:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Dec 2019 17:37:54 +0000
Subject: [issue39103] [linux] strftime renders %Y with only 3 characters
In-Reply-To: <1576819920.4.0.445555745721.issue39103@roundup.psfhosted.org>
Message-ID: <1576863474.92.0.837830150096.issue39103@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Due note, though, that there's a difference in the implementation of strftime versus strptime, as the former (at least the last time I looked ages ago) uses the libc version of the function and thus probably doesn't try to smooth out differences like this, while the latter is implemented in Python code in the stdlib itself.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39103>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:39:47 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Dec 2019 17:39:47 +0000
Subject: [issue39111] Misleading documentation
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1576863587.27.0.124174885349.issue39111@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

This is because your class implicitly inherits from object and object.__eq__() is implemented and does not return NotImplemented.

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:42:00 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Dec 2019 17:42:00 +0000
Subject: [issue39111] Misleading documentation
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1576863720.36.0.540838549972.issue39111@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

And to be more specific, == is guaranteed to work by falling back to object.__eq__() which falls back to object identity if the object doesn't have a custom __eq__() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:48:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2019 17:48:28 +0000
Subject: [issue26767] Inconsistant error messages for failed attribute
 modification
In-Reply-To: <1460715032.51.0.36886496046.issue26767@psf.upfronthosting.co.za>
Message-ID: <1576864108.6.0.100271448504.issue26767@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Not all error messages contain an attribute name, an object type name and a reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26767>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:12:26 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 18:12:26 +0000
Subject: [issue39110] It seems that list() changes the value of the parameter
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576865546.43.0.437105179752.issue39110@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Your problem is with UserList.  This is from the implementation:

    def __getitem__(self, i):
        if isinstance(i, slice):
            return self.__class__(self.data[i])
        else:
            return self.data[i]

So each slice is creating a new Tree.  Then the __setitem__() of that new Tree gets triggered for each item, causing the owner to be set to the new Tree.  So that's the cause.

Is there a particular reason you are subclassing UserList?  Consider subclassing list or collections.abc.MutableSequence instead.  Or deal with the slice semantics manually.

Also, perhaps you expected that a slice would produce a view into the sequence?  I know that's how it works in some programming languages (but not Python, though you could make it do that if you wanted to).

Regardless, as far as I can tell everything is working as designed.  I recommend closing this.

----------
nosy: +eric.snow
resolution:  -> not a bug
status: open -> pending
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:40:55 2019
From: report at bugs.python.org (Murali Ganapathy)
Date: Fri, 20 Dec 2019 18:40:55 +0000
Subject: [issue39111] Misleading documentation
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1576867255.8.0.798121189135.issue39111@roundup.psfhosted.org>


Murali Ganapathy <murali at google.com> added the comment:

===
# python3
class Base:
  def __eq__(self, other):
    print("base called")
    return super().__eq__(other)


class Foo(Base):

  def __eq__(self, other):
    print("foo called")
    return NotImplemented

Foo() == Foo()
# foo called
# foo called
False
====

Base.__eq__ is not called here. Is calling of object.__eq__ special cased?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:49:45 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 20 Dec 2019 18:49:45 +0000
Subject: [issue39046] collections.abc.Reversible should not be a subclass of
 Hashable
In-Reply-To: <1576317847.63.0.718393349876.issue39046@roundup.psfhosted.org>
Message-ID: <1576867785.46.0.154686216608.issue39046@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39046>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:56:37 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 20 Dec 2019 18:56:37 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1576868197.89.0.898711350362.issue39102@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:57:08 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 18:57:08 +0000
Subject: [issue39042] Use the runtime's main thread ID in the threading module.
In-Reply-To: <1576275682.19.0.998306709118.issue39042@roundup.psfhosted.org>
Message-ID: <1576868228.49.0.62280250663.issue39042@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I don't see a reason not to consider this is a regression.

The only problem with the fix would be for any users that rely on the inaccurate reporting of the threading module.  Considering that possibly includes only some embedders (and folks using _thread module directly), I expect the impact would be extremely small.  A porting entry in the whats-new doc.

----------
keywords: +3.8regression
priority: normal -> release blocker
stage: test needed -> needs patch
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39042>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:10:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2019 19:10:58 +0000
Subject: [issue26845] Misleading variable name in exception handling
In-Reply-To: <1461614167.42.0.470146541912.issue26845@psf.upfronthosting.co.za>
Message-ID: <1576869058.93.0.619008398858.issue26845@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Variable names have no impact on the execution. Sometimes, it's called "exc", sometimes "val", sometimes "exc_val" :-) This issue is not a bug.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26845>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:11:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 20 Dec 2019 19:11:57 +0000
Subject: [issue23868] Uninitialized objects are tracked by the garbage
 collector
In-Reply-To: <1428159634.21.0.640344593113.issue23868@psf.upfronthosting.co.za>
Message-ID: <1576869117.75.0.207947605037.issue23868@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

If I understand what you say correctly, it does not seem correct, the object will only be tracked by the collector when you call PyObject_GC_Track. indeed, the documentation warns about this:

void PyObject_GC_Track(PyObject *op)?
Adds the object op to the set of container objects tracked by the collector. The collector can run at unexpected times so objects must be valid while being tracked. This should be called once all the fields followed by the tp_traverse handler become valid, usually near the end of the constructor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23868>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:18:41 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 20 Dec 2019 19:18:41 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1576869521.86.0.981342798774.issue38918@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f522a6ddb67a238bab5673608111f74ec4e22205 by Miss Islington (bot) (Parth Sharma) in branch 'master':
bpo-38918: Add __module__ entry for function & method type in inspect docs table (GH-17408)
https://github.com/python/cpython/commit/f522a6ddb67a238bab5673608111f74ec4e22205


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:20:35 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 20 Dec 2019 19:20:35 +0000
Subject: [issue23868] Uninitialized objects are tracked by the garbage
 collector
In-Reply-To: <1428159634.21.0.640344593113.issue23868@psf.upfronthosting.co.za>
Message-ID: <1576869635.8.0.24069832964.issue23868@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

In summary, a normal allocation for an object tracked by the Garbage collector follows these steps:

1.- Call PyObject_GC_New or PyObject_GC_NewVar or related APIs.
2.- Initialize everything and make sure the object is consistent.
3.- Call PyObject_GC_Track

You can check the implementation of containers types in the stdlib for reference or the documentation for the C API.

Closing this, feel free to reopen of you think there is something missing.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23868>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:20:53 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 20 Dec 2019 19:20:53 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1576869653.58.0.393339403602.issue38918@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17135
pull_request: https://github.com/python/cpython/pull/17675

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:21:00 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 20 Dec 2019 19:21:00 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1576869660.67.0.855203332108.issue38918@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17136
pull_request: https://github.com/python/cpython/pull/17676

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:26:20 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 20 Dec 2019 19:26:20 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1576869980.66.0.933972818185.issue38918@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0ffc90031cadf5637cfc13a40899e71c259c49b1 by Miss Islington (bot) in branch '3.7':
bpo-38918: Add __module__ entry for function & method type in inspect docs table (GH-17408)
https://github.com/python/cpython/commit/0ffc90031cadf5637cfc13a40899e71c259c49b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:26:43 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 20 Dec 2019 19:26:43 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1576870003.76.0.393108399792.issue38918@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 44683bbc634bd007df572dce0d8bb348a469a6bb by Miss Islington (bot) in branch '3.8':
bpo-38918: Add __module__ entry for function & method type in inspect docs table (GH-17408)
https://github.com/python/cpython/commit/44683bbc634bd007df572dce0d8bb348a469a6bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:29:09 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 19:29:09 +0000
Subject: [issue38918] Add __module__ entry for function type in inspect docs
 table.
In-Reply-To: <1574782032.53.0.612246813906.issue38918@roundup.psfhosted.org>
Message-ID: <1576870149.5.0.750816626548.issue38918@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for working on this, @parthsharma2!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38918>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:34:12 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 20 Dec 2019 19:34:12 +0000
Subject: [issue39103] [linux] strftime renders %Y with only 3 characters
In-Reply-To: <1576819920.4.0.445555745721.issue39103@roundup.psfhosted.org>
Message-ID: <1576870452.53.0.417995520964.issue39103@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

This is a duplicate of issue 13305.

Right now we have some shims around `strftime` to improve consistency in some situations and for other reasons, but mostly we just call the libc version.

There is an open issue from 2008 (#3173) to ship our own implementation of strftime that could smooth out some of these issues and try and make the behavior more consistent (though presumably some people have started to rely on platform-specific behaviors by now, so it may be a decent amount of work to roll it out).

I'm going to close this in favor of 13305, but thanks for reporting it!

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> datetime.strftime("%Y") not consistent for years < 1000
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39103>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:34:44 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 20 Dec 2019 19:34:44 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1576870484.49.0.93314894526.issue13305@roundup.psfhosted.org>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:03:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 20:03:46 +0000
Subject: [issue39048] Reorder __aenter__ & __aexit__ checks for async with
 statement
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1576872226.15.0.011244663349.issue39048@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Reorder the __aenter__ and __aexit__ method checks for the async with statement -> Reorder  __aenter__ & __aexit__ checks for async with statement
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:18:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 20:18:38 +0000
Subject: [issue39060] asyncio.Task.print_stack doesn't print the full stack
In-Reply-To: <1576489918.95.0.196774987509.issue39060@roundup.psfhosted.org>
Message-ID: <1576873118.92.0.616137152734.issue39060@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Amit, is there a simple doc change that would have made the result clearer? (before getting Andrew's response?)

----------
nosy: +terry.reedy
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39060>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:39:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 20:39:31 +0000
Subject: [issue39062] ValueError in TarFile.getmembers
In-Reply-To: <1576493016.16.0.2184811666.issue39062@roundup.psfhosted.org>
Message-ID: <1576874371.02.0.435364932101.issue39062@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +lars.gustaebel, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39062>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:41:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 20:41:37 +0000
Subject: [issue39062] ValueError in TarFile.getmembers
In-Reply-To: <1576493016.16.0.2184811666.issue39062@roundup.psfhosted.org>
Message-ID: <1576874497.26.0.509550294203.issue39062@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

See #39065, #39067 for similar tarfile issues.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39062>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:52:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 20:52:47 +0000
Subject: [issue39062] ValueError in TarFile.getmembers
In-Reply-To: <1576493016.16.0.2184811666.issue39062@roundup.psfhosted.org>
Message-ID: <1576875167.99.0.0447824045172.issue39062@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

jvoisin, what do you consider to be the bug?  Raising an exception  is exactly the right thing to do on bad input.  I leave it to others to decide if this should be closed as 'not a bug' or if the internal exception should be caught and replaced.  We don't pretend to document all possible exception from all functions.

The more important aim of fuzzing is to find inputs that cause no-exception crashes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39062>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:56:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 20:56:53 +0000
Subject: [issue39062] ValueError in TarFile.getmembers
In-Reply-To: <1576493016.16.0.2184811666.issue39062@roundup.psfhosted.org>
Message-ID: <1576875413.96.0.56739513102.issue39062@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

jvoisin, please consider rerunning such reproducers with lastest 3.8 and 3.9 before submitting.  It is much easier for you to do so when you have the fuzz file, script, and command line already present.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39062>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:42:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:42:34 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1576878154.11.0.326068019859.issue39096@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Description of "Format Specification Mini-Language" not accurate for Decimal -> "Format Specification Mini-Language" doc mistake for Decimal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:44:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:44:31 +0000
Subject: [issue39098] OSError: handle closed,
 ProcessPoolExecutor shutdown(wait=False)
In-Reply-To: <1576761583.89.0.930155685361.issue39098@roundup.psfhosted.org>
Message-ID: <1576878271.81.0.275843556039.issue39098@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: OSError: handle is closed in ProcessPoolExecutor  on shutdown(wait=False) -> OSError: handle closed, ProcessPoolExecutor shutdown(wait=False)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39098>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:46:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:46:21 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1576878381.65.0.474811037339.issue39102@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:49:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:49:30 +0000
Subject: [issue39108] random needs doc for "gauss" versus "normalvariate"
In-Reply-To: <1576842313.59.0.109867222427.issue39108@roundup.psfhosted.org>
Message-ID: <1576878570.94.0.610786060131.issue39108@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You could start by posting suggested new text here.

----------
nosy: +terry.reedy
title: Documentation for "random.gauss" vs "random.normalvariate" is lacking -> random needs doc for "gauss" versus "normalvariate"
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39108>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:56:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:56:23 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes node attribute
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576878983.75.0.032195795728.issue39110@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> open
title: It seems that list() changes the value of the parameter -> UserList-subclass Tree slicing changes node attribute

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:56:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:56:49 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes node attribute
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576879009.87.0.487293152992.issue39110@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:57:45 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:57:45 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes node attribute
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576879065.8.0.665616828443.issue39110@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:59:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2019 21:59:10 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes node attribute
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576879150.83.0.580057489579.issue39110@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

(ctarn), if you want to discuss what you are doing further, please try a discussion list, such as python-list.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 17:59:56 2019
From: report at bugs.python.org (Arseny Boykov)
Date: Fri, 20 Dec 2019 22:59:56 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1576882796.22.0.410196922217.issue39102@roundup.psfhosted.org>


Arseny Boykov <appkiller16 at gmail.com> added the comment:

Also, do we need to leave compatibility with python <3.8? 
If not, we could use the fact that python 3.8 dicts and sets which are preserve order to speed things up even more. Also I'd replace % string formatting with f-strings, as they also faster.

And another thing to think about: maybe we can calculate values returned by __str__, __repr__ and __invert__ once on member creation, since they not supposed to change during its life?

For example __invert__ on Flag does a lot of work on every call:
    def __invert__(self):
        cls = self.__class__
        members, uncovered = _decompose(cls, self._value_)
        inverted = cls(0)
        for m in cls:
            if m not in members and not (m._value_ & self._value_):
                inverted = inverted | m
        return cls(inverted)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:05:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:05:27 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
 thread
Message-ID: <1576883127.62.0.977311294753.issue1596321@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

related: issue #39042 "Use the runtime's main thread ID in the threading module."

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:07:40 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:07:40 +0000
Subject: [issue1332869] Fatal Python error: Interpreter not initialized
Message-ID: <1576883260.97.0.306760837057.issue1332869@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/issue1332869>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:09:15 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:09:15 +0000
Subject: [issue28812] Deadlock between GIL and pystate head_mutex.
In-Reply-To: <1480241598.29.0.901358230906.issue28812@psf.upfronthosting.co.za>
Message-ID: <1576883355.68.0.245364004371.issue28812@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/issue28812>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:10:00 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:10:00 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1576883400.35.0.374068199606.issue14073@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/issue14073>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:12:47 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:12:47 +0000
Subject: [issue31517] MainThread association logic is fragile
In-Reply-To: <1505826011.26.0.999867844657.issue31517@psf.upfronthosting.co.za>
Message-ID: <1576883567.63.0.383793401756.issue31517@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

probably a duplicate: issue #39042 "Use the runtime's main thread ID in the threading module."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31517>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:13:14 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:13:14 +0000
Subject: [issue34296] Speed up python startup by pre-warming the vm
In-Reply-To: <1533058284.7.0.56676864532.issue34296@psf.upfronthosting.co.za>
Message-ID: <1576883594.21.0.900123616991.issue34296@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/issue34296>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:21:06 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:21:06 +0000
Subject: [issue13077] Unclear behavior of daemon threads on main thread exit
In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>
Message-ID: <1576884066.07.0.324285767334.issue13077@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/issue13077>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:30:08 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:30:08 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576884608.24.0.822836900711.issue36476@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Adding to the list:

* any OS threads created by an extension module or embedding application

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:30:22 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:30:22 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576884622.06.0.595752214137.issue36476@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:33:07 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:33:07 +0000
Subject: [issue24770] Py_Finalize() doesn't stop daemon threads
In-Reply-To: <1438409335.5.0.147877338692.issue24770@psf.upfronthosting.co.za>
Message-ID: <1576884787.63.0.274535368104.issue24770@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'm closing this in favor of #36476 "Runtime finalization assumes all other threads have exited."

----------
nosy: +eric.snow
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Runtime finalization assumes all other threads have exited.
versions: +Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24770>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:40:58 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:40:58 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576885258.51.0.270302945148.issue36476@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Problems with lingering threads during/after runtime finalization continue to be a problem.  I'm going to use this issue as the focal point for efforts to resolve this.


Related issues:
* #36479 "Exit threads when interpreter is finalizing rather than runtime."
* #24770 "Py_Finalize() doesn't stop daemon threads"
* #23592 "SIGSEGV on interpreter shutdown, with daemon threads running wild"
* #37127 "Handling pending calls during runtime finalization may cause problems."
* #33608 "Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed."
* #36818 "Add PyInterpreterState.runtime."
* #36724 "Clear _PyRuntime at exit"
* #14073 "allow per-thread atexit()"
* #1596321 "KeyError at exit after 'import threading' in other thread"
* #37266 "Daemon threads must be forbidden in subinterpreters"
* #31517 "MainThread association logic is fragile"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:44:55 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:44:55 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576885495.27.0.0179562285919.issue36476@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +pconnell

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:46:05 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:46:05 +0000
Subject: [issue33608] 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: <1576885565.18.0.0983762055017.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for the detailed analysis, Phil.  I think the results are pretty conclusive: daemon threads are the worst. :)  But seriously, thanks.

As you demonstrated, it isn't just Python "daemon" threads that cause the problem.  It is essentially any external access of the C-API once runtime finalization has started.  The docs [1] aren't super clear about it, but there are some fundamental assumptions we make about runtime finalization:

* no use of the C-API while Py_FinalizeEx() is executing (except for a few helpers like Py_Initialized)
* only a small portion of the C-API is available afterward (at least until Py_Initialize() is run)

I guess the real question is what to do about this?

Given that this is essentially a separate problem, let's move further discussion and effort over related to sorting out problematic threads to #36476, "Runtime finalization assumes all other threads have exited."  @Phil, would you mind attaching those same two files to that issue?


[1] https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:48:58 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:48:58 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576885738.22.0.189587786105.issue36476@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Analysis by @pconnell:

* https://bugs.python.org/issue33608#msg357169
* https://bugs.python.org/issue33608#msg357170
* https://bugs.python.org/issue33608#msg357179

tl;dr daemon threads and external C-API access during/after runtime finalization are causing crashes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:54:01 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2019 23:54:01 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576886041.93.0.942317170669.issue36476@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

To put it another way:

(from issue33608#msg358748)

> The docs [1] aren't super clear about it, but there are some fundamental
> assumptions we make about runtime finalization:
>
> * no use of the C-API while Py_FinalizeEx() is executing (except for a
> few helpers like Py_Initialized)
> * only a small portion of the C-API is available afterward (at least
> until Py_Initialize() is run)
>
> I guess the real question is what to do about this?
> 
>[1] https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx

Adding to that list:

* no other Python threads are running once we start finalizing the runtime (not far into Py_FinalizeEx())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:07:29 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 21 Dec 2019 00:07:29 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576886849.14.0.218777019521.issue36476@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

So I see 3 things to address here:

1. Python daemon threads
2. Python threads created in atexit handlers
3. non-Python threads accessing the C-API

Possible solutions (starting point for discussion):

1. stop them at the point we stop waiting for non-daemon threads (at the beginning of finalization)
2. disallow them?  do one more pass of wait-for-threads?
3. cause all (external) attempts to access the C-API to fail once finalization begins

Regarding daemon threads, the docs already say "Daemon threads are abruptly stopped at shutdown." [1]  So let's force them to stop.  Can we do that?  If we *can* simply kill the threads, can we do so without leaking resources?  Regardless, the mechanism we currently use (check for finalizing each(?) time through the eval loop) mostly works fine.  The problem is when C code called from Python in a daemon thread blocks long enough that it makes C-API calls (or even the eval loop) *after* we've started cleaning up the runtime state.  So if there was a way to interrupt that blocking code, that would probably be good enough.

The other two possible solutions are, I suppose, a bit more drastic.  What are the alternatives?


[1] https://docs.python.org/3/library/threading.html#thread-objects

----------
nosy: +nanjekyejoannah, ncoghlan, pablogsal, pitrou, tim.peters, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:08:22 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 21 Dec 2019 00:08:22 +0000
Subject: [issue39111] Misleading documentation
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1576886902.04.0.544865401241.issue39111@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The behaviour is correct: `==` should not raise, even if both objects' `__eq__` method returns NotImplemented.

I agree that the documentation needs improvement. Looking at the current version:

https://docs.python.org/3/library/constants.html#NotImplemented

it says:

    Note: When a binary (or in-place) method returns NotImplemented 
    the interpreter will try the reflected operation on the other 
    type (or some other fallback, depending on the operator). If all
    attempts return NotImplemented, the interpreter will raise an
    appropriate exception. Incorrectly returning NotImplemented will
    result in a misleading error message or the NotImplemented value
    being returned to Python code.


(1) In the case of `==` and `!=`, an exception is not raised even all relevant methods return NotImplemented.

The source code for PyObject_RichCompare in object.c says:

    /* If neither object implements it, provide a sensible default
       for == and !=, but raise an exception for ordering. */

and then falls back to object identity.

If we wanted to lawyer up, the current docs don't say that "some other fallback" is limited to Python dunder methods. But that's the strong impression it gives, and it is actively misleading in that there's no hint that the fallback includes a default notion of equality as object identity, built right into the interpreter itself.

Even Brett got this wrong: object.__eq__ can return NotImplemented, so it isn't a suitable final fallback:

    py> object.__eq__(o, None)
    NotImplemented


so I think these docs could do with some improvement. Based on the current docs, I too would expect equality to raise an exception for a class that defines `__eq__`  and `__ne__` to always return NotImplemented.


(2) The last sentence, about "incorrectly returning NotImplemented", confuses me. Why are we warning about that? If you incorrectly return any value, whether it is NotImplemented, True, False, None or 3.1415, it will result in a misleading error message or incorrect value being returned.

Is it perhaps meant to say "incorrectly *raising* NotImplemented"?

I'm reopening this for a doc enhancement. Unfortunately I can't use github for technical reasons, so can't do a PR, but I'll suggest an updated description for the first part. (I have no idea what to do for the second part.)

    When a binary (or in-place) method returns NotImplemented 
    the interpreter will try the reflected operation on the other 
    type (or some other fallback, depending on the operator). If all
    attempts return NotImplemented, the interpreter will fall back
    to object identity for `==` and `!=` or raise an appropriate
    exception for all other comparisons.

----------
nosy: +steven.daprano
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:09:14 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 21 Dec 2019 00:09:14 +0000
Subject: [issue39111] Misleading documentation for NotImplemented
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1576886954.28.0.84768245208.issue39111@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
title: Misleading documentation -> Misleading documentation for NotImplemented

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Fri Dec 20 20:28:19 2019
From: report at bugs.python.org (Simon Berens)
Date: Sat, 21 Dec 2019 01:28:19 +0000
Subject: [issue39112] Misleading documentation for tuple
Message-ID: <1576891699.24.0.656089355811.issue39112@roundup.psfhosted.org>


New submission from Simon Berens <sberensnyc at gmail.com>:

Sorry if this is a silly question (my first bug report), but it seems that https://docs.python.org/3/library/functions.html#func-tuple
should say "class tuple" instead of just "tuple", as list, dict, and set do.

----------
assignee: docs at python
components: Documentation
messages: 358753
nosy: docs at python, sberens
priority: normal
severity: normal
status: open
title: Misleading documentation for tuple
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39112>
_______________________________________

From report at bugs.python.org  Fri Dec 20 20:54:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Dec 2019 01:54:17 +0000
Subject: [issue39108] random needs doc for "gauss" versus "normalvariate"
In-Reply-To: <1576842313.59.0.109867222427.issue39108@roundup.psfhosted.org>
Message-ID: <1576893257.0.0.761025071828.issue39108@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I can make the update for you.

----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39108>
_______________________________________

From report at bugs.python.org  Fri Dec 20 22:32:54 2019
From: report at bugs.python.org (william.ayd)
Date: Sat, 21 Dec 2019 03:32:54 +0000
Subject: [issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With
 Incomplete Surrogate Pair
Message-ID: <1576899174.72.0.883256961456.issue39113@roundup.psfhosted.org>


New submission from william.ayd <william.ayd at icloud.com>:

With the attached extension module, if I run the following in the REPL:

>>> import libtest
>>>
>>> libtest.error_if_not_utf8("foo")
'foo'
>>> libtest.error_if_not_utf8("\ud83d")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud83d' in position 0: surrogates not allowed
>>> libtest.error_if_not_utf8("foo")
'foo'

Things seem OK. But the next invocation of

>>> libtest.error_if_not_utf8("\ud83d")

Then causes a segfault. Note that the order of the input seems important; simply repeating the call with the invalid surrogate doesn't cause the segfault

----------
files: testmodule.c
messages: 358755
nosy: william.ayd
priority: normal
severity: normal
status: open
title: PyUnicode_AsUTF8AndSize Sometimes Segfaults With Incomplete Surrogate Pair
Added file: https://bugs.python.org/file48798/testmodule.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39113>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:54:51 2019
From: report at bugs.python.org (ctarn)
Date: Sat, 21 Dec 2019 04:54:51 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes node attribute
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576904091.43.0.94215302814.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

Sorry but it is not. See the first time I print ls[4].owner. We get d as expected, not a slice of d, that is, d[0:2].

However the next time we print it after _ = list(d[0:1]), noticed that ls[4] == d[0:1], we get d[0:1], it?s extremely surprising!!!

I have to highlight it: we just print *.owner before and after `_ = list(d[0:1])`, and the results are different!!!

The latest 3 lines show more strange results.

By the way, it?s my first time to report bug, and I don?t know what is discussion list, and reopened the issue. Thank you.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:55:25 2019
From: report at bugs.python.org (ctarn)
Date: Sat, 21 Dec 2019 04:55:25 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes node attribute
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576904125.31.0.0257607929585.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


----------
resolution: not a bug -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:40:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2019 05:40:56 +0000
Subject: [issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With
 Incomplete Surrogate Pair
In-Reply-To: <1576899174.72.0.883256961456.issue39113@roundup.psfhosted.org>
Message-ID: <1576906856.66.0.884580260173.issue39113@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Your function returns a borrowed reference. It xiuld cause  ceash even without calling PyUnicode_AsUTF8AndSize. Add Py_INCREF(str)

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39113>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:25:47 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Dec 2019 06:25:47 +0000
Subject: [issue39106] Add suggestions to argparse error message output for
 unrecognized arguments
In-Reply-To: <1576832169.43.0.680374670537.issue39106@roundup.psfhosted.org>
Message-ID: <1576909547.93.0.77682415553.issue39106@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1  Given an unknown argument, we really can't know what the user intended.  The usage string already lists all available options and -h --help gives more detail when requested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39106>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:36:11 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 06:36:11 +0000
Subject: [issue33772] Fix few dead code paths
In-Reply-To: <1564293672.48.0.573302806093.issue33772@roundup.psfhosted.org>
Message-ID: <1576910171.62.0.562086840883.issue33772@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I agree, can be closed

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33772>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:37:22 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 06:37:22 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1576910242.69.0.118814804332.issue36051@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:37:46 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 06:37:46 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1576910266.57.0.51482161004.issue36051@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:40:19 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 06:40:19 +0000
Subject: [issue13047] imp.find_module("") and imp.find_module(".")
In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>
Message-ID: <1576910419.73.0.922684777728.issue13047@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

`imp` is now deprecated and IMHO no reason to make this change after this deprecation.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13047>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:43:00 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 06:43:00 +0000
Subject: [issue24945] Expose Py_TPFLAGS_ values from Python
In-Reply-To: <1440683454.06.0.831934129277.issue24945@psf.upfronthosting.co.za>
Message-ID: <1576910580.45.0.700308424141.issue24945@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

IMHO inspect would be a better place to put these constants (like CO_ flags).

----------
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24945>
_______________________________________

From report at bugs.python.org  Sat Dec 21 02:15:50 2019
From: report at bugs.python.org (william.ayd)
Date: Sat, 21 Dec 2019 07:15:50 +0000
Subject: [issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With
 Incomplete Surrogate Pair
In-Reply-To: <1576899174.72.0.883256961456.issue39113@roundup.psfhosted.org>
Message-ID: <1576912550.82.0.00153907418547.issue39113@roundup.psfhosted.org>


william.ayd <william.ayd at icloud.com> added the comment:

Hmm my mistake - thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39113>
_______________________________________

From report at bugs.python.org  Sat Dec 21 02:20:51 2019
From: report at bugs.python.org (ctarn)
Date: Sat, 21 Dec 2019 07:20:51 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes the original list
 unexpectedly
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576912851.37.0.86662037792.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

I tried to remove list(), and just use cmd like `_ = d[0:1]`, and it surprisingly changed d[0].owner from d to d[0:1]!
The file attached is updated.
I pretty sure that it is a (serious) bug. Please check it more carefully. Thanks.

----------
title: UserList-subclass Tree slicing changes node attribute -> UserList-subclass Tree slicing changes the original list unexpectedly
Added file: https://bugs.python.org/file48799/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 02:24:21 2019
From: report at bugs.python.org (ctarn)
Date: Sat, 21 Dec 2019 07:24:21 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes the original list
 unexpectedly
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576913061.41.0.667764861969.issue39110@roundup.psfhosted.org>


Change by ctarn <i at ctarn.io>:


Removed file: https://bugs.python.org/file48797/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 02:25:51 2019
From: report at bugs.python.org (ctarn)
Date: Sat, 21 Dec 2019 07:25:51 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes the original list
 unexpectedly
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576913151.78.0.138093206058.issue39110@roundup.psfhosted.org>


ctarn <i at ctarn.io> added the comment:

Moreover, it works as expected with Python 3.6 (the owner of each of them is d), and Python 3.8 and Python 3.7 work differently.
I didn't try it using Python 3.9 yet.

----------
versions: +Python 3.7 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 02:56:29 2019
From: report at bugs.python.org (Tarn Yeong Ching)
Date: Sat, 21 Dec 2019 07:56:29 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes the original list
 unexpectedly
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576914989.46.0.69394937407.issue39110@roundup.psfhosted.org>


Tarn Yeong Ching <i at ctarn.io> added the comment:

and more... It doesn't happen when Tree directly subclasses list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 03:12:40 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 08:12:40 +0000
Subject: [issue30905] Embedding should have public API for interactive mode
In-Reply-To: <1499783657.19.0.814858997931.issue30905@psf.upfronthosting.co.za>
Message-ID: <1576915960.42.0.984326631069.issue30905@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> (1) BUT: The value of 'a' is not printed

Isn't this the expected behavior for file input? You need to call print() in order to get 'a' printed.

> (2) This is OK! We run one statement at a time

As it should be for "single input". 

> (3) This is NOT OK! Python throws a SyntaxError because we used Py_single_input.

Yes, because AFAIK single stands for single statement. There are 2 (assign + expression)

> These two requirements are in conflict, because while Py_single_input enables the first, it forbids the second.

It is why there is a code module which allows implementation of REPL loops.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30905>
_______________________________________

From report at bugs.python.org  Sat Dec 21 03:34:17 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 08:34:17 +0000
Subject: [issue36000] __debug__ is a keyword but not a keyword
In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org>
Message-ID: <1576917257.87.0.271796536748.issue36000@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

import builtins
builtins.__dict__['__debug__'] = 'Surprise!'
builtins.__dict__['None'] = 'Surprise!'

print(__debug__)
print(None)

 $ ./python ../t.py
True
None

I guess this is related to Python/ast_opt.c transformation

    case Name_kind:
        if (_PyUnicode_EqualToASCIIString(node_->v.Name.id, "__debug__")) {
            return make_const(node_, PyBool_FromLong(!optimize_), ctx_);
        }
        break;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36000>
_______________________________________

From report at bugs.python.org  Sat Dec 21 06:21:40 2019
From: report at bugs.python.org (Fabio Sangiovanni)
Date: Sat, 21 Dec 2019 11:21:40 +0000
Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass
 documentation
In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za>
Message-ID: <1576927300.97.0.447677108764.issue33961@roundup.psfhosted.org>


Change by Fabio Sangiovanni <sjh+bugspython at sanjioh.org>:


----------
pull_requests: +17137
pull_request: https://github.com/python/cpython/pull/17677

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33961>
_______________________________________

From report at bugs.python.org  Sat Dec 21 06:55:33 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 Dec 2019 11:55:33 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes the original list
 unexpectedly
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576929333.21.0.923981259038.issue39110@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[ctarn]

> it works as expected with Python 3.6 (the owner of each of them is d), and Python 3.8 and Python 3.7 work differently

The change in behaviour is the result of a bug fix that was applied in 3.7 and upwards: see GH-13169 and #27639.

As Eric says, UserList is behaving as intended here. Your problem stems from a design flaw in your code, namely that Nodes have owners. If a node exists both in a Tree *and* in a slice of that Tree (which slice, since the #27639 fix, is again a Tree), that node can't have both the original Tree *and* the slice as owner. In this case, what's happening is that accessing `d[0:1]` creates a new Tree object, and the __init__ method for that Tree object then reassigns the "owner" of the node in that slice.

> I don?t know what is discussion list

See https://www.python.org/community/lists/, and particularly https://mail.python.org/mailman/listinfo/python-list

Closing again here, but feel free to start a discussion or ask questions on the list above.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 07:43:31 2019
From: report at bugs.python.org (Tarn Yeong Ching)
Date: Sat, 21 Dec 2019 12:43:31 +0000
Subject: [issue39110] UserList-subclass Tree slicing changes the original list
 unexpectedly
In-Reply-To: <1576854418.21.0.40274274641.issue39110@roundup.psfhosted.org>
Message-ID: <1576932211.45.0.634144236285.issue39110@roundup.psfhosted.org>


Tarn Yeong Ching <i at ctarn.io> added the comment:

GOD... I see. Thank you very much!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39110>
_______________________________________

From report at bugs.python.org  Sat Dec 21 08:27:10 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2019 13:27:10 +0000
Subject: [issue39052] import error when in python -m pdb debug mode
In-Reply-To: <1576394399.54.0.25584896953.issue39052@roundup.psfhosted.org>
Message-ID: <1576934830.95.0.909274205222.issue39052@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

As a workaround insert the following hard-coded breakpoint before the import statement and run your script with python, i.e. 'python myhome.py' instead of 'python -m pdb myhome.p'.

from pdb import Pdb; Pdb(skip=['importlib*']).set_trace()

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39052>
_______________________________________

From report at bugs.python.org  Sat Dec 21 08:40:45 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 21 Dec 2019 13:40:45 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
Message-ID: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

The way trace function reports return-finally has changed in Python 3.9.0a2. I don't know if this change is intentional or not.

(BTW: I want to put a 3.9regression keyword on this, but it doesn't exist.)

Consider this code:

--- 8< ----------------------------------------------------
import linecache, sys

def trace(frame, event, arg):
    lineno = frame.f_lineno
    print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, lineno).rstrip()))
    return trace

print(sys.version)
sys.settrace(trace)

a = []
def finally_return():
    try:
        return 14
    finally:
        a.append(16)
assert finally_return() == 14
assert a == [16]
--- 8< ----------------------------------------------------


(My habit is to use line numbers in the lines themselves to help keep things straight.)

In Python 3.7 (and before), the last traces are line 14, line 16, return 16.

In Python 3.8, the last traces are line 14, line 16, line 14, return 14.

In Python 3.9a1, the traces are the same as 3.8.

In Python 3.9a2, the traces are now line 14, line 16, line 14, line 16, return 16.

This doesn't make sense to me: why does it bounce back and forth?

Full output from different versions of Python:

% /usr/local/pythonz/pythons/CPython-3.7.1/bin/python3.7 bpo.py
3.7.1 (default, Oct 20 2018, 18:25:32)
[Clang 10.0.0 (clang-1000.11.45.2)]
call 12: def finally_return():
line 13:     try:
line 14:         return 14
line 16:         a.append(16)
retu 16:         a.append(16)
% /usr/local/pythonz/pythons/CPython-3.8.1/bin/python3.8 bpo.py
3.8.1 (default, Dec 19 2019, 08:38:38)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13:     try:
line 14:         return 14
line 16:         a.append(16)
line 14:         return 14
retu 14:         return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a1/bin/python3.9 bpo.py
3.9.0a1 (default, Nov 20 2019, 18:52:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13:     try:
line 14:         return 14
line 16:         a.append(16)
line 14:         return 14
retu 14:         return 14
% /usr/local/pythonz/pythons/CPython-3.9.0a2/bin/python3.9 bpo.py
3.9.0a2 (default, Dec 19 2019, 08:42:29)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 12: def finally_return():
line 13:     try:
line 14:         return 14
line 16:         a.append(16)
line 14:         return 14
line 16:         a.append(16)
retu 16:         a.append(16)

----------
messages: 358771
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.9.0a2 changed how finally/return is traced
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sat Dec 21 09:14:39 2019
From: report at bugs.python.org (Josh de Kock)
Date: Sat, 21 Dec 2019 14:14:39 +0000
Subject: [issue39115] Clarify Python MIME type
Message-ID: <1576937679.64.0.394621240723.issue39115@roundup.psfhosted.org>


New submission from Josh de Kock <josh at itanimul.li>:

I'd like to add Python's MIME types to a database so that they can be properly used by other services. However, apart from the source code[1][2], I can't find any documentation from Python which highlights this. Is the source code correct here, and can it be taken as the 'official' MIME types from the project?

text/x-python py
application/x-python-code pyc pyo

[1]: https://github.com/python/cpython/blob/19a3d873005e5730eeabdc394c961e93f2ec02f0/Lib/mimetypes.py#L457
[2]: https://github.com/python/cpython/blob/19a3d873005e5730eeabdc394c961e93f2ec02f0/Lib/mimetypes.py#L528

----------
assignee: docs at python
components: Documentation
messages: 358772
nosy: docs at python, jdek
priority: normal
severity: normal
status: open
title: Clarify Python MIME type
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39115>
_______________________________________

From report at bugs.python.org  Sat Dec 21 09:44:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 21 Dec 2019 14:44:37 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1576939477.11.0.888258801884.issue39114@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/issue39114>
_______________________________________

From report at bugs.python.org  Sat Dec 21 09:52:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 21 Dec 2019 14:52:40 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1576939960.53.0.811375595882.issue39114@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Looking at changes to alpha2 I think it bisects to https://github.com/python/cpython/pull/6641


?  cpython git:(5dcc06f6e0) git checkout fee552669f21ca294f57fe0df826945edc779090 && make -s -j4 > /dev/null 
Previous HEAD position was 5dcc06f6e0... bpo-38858: Allocate small integers on the heap (GH-17301)
HEAD is now at fee552669f... Produce cleaner bytecode for 'with' and 'async with' by generating separate code for normal and exceptional paths. (#6641)
?  cpython git:(fee552669f) ./python ../backups/bpo39114.py                                                 
3.9.0a1+ (tags/v3.9.0a1-43-gfee552669f:fee552669f, Dec 21 2019, 20:18:54) 
[GCC 4.8.4]
call 12: def finally_return():
line 13:     try:
line 14:         return 14
line 16:         a.append(16)
line 14:         return 14
line 16:         a.append(16)
retu 16:         a.append(16)
?  cpython git:(fee552669f) git checkout fee552669f21ca294f57fe0df826945edc779090~1 && make -s -j4 > /dev/null
Previous HEAD position was fee552669f... Produce cleaner bytecode for 'with' and 'async with' by generating separate code for normal and exceptional paths. (#6641)
HEAD is now at 5dcc06f6e0... bpo-38858: Allocate small integers on the heap (GH-17301)
?  cpython git:(5dcc06f6e0) ./python ../backups/bpo39114.py                                                   
3.9.0a1+ (tags/v3.9.0a1-42-g5dcc06f6e0:5dcc06f6e0, Dec 21 2019, 20:21:07) 
[GCC 4.8.4]
call 12: def finally_return():
line 13:     try:
line 14:         return 14
line 16:         a.append(16)
line 14:         return 14
retu 14:         return 14

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sat Dec 21 11:03:39 2019
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 21 Dec 2019 16:03:39 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1576944219.08.0.591329680426.issue39114@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords: +3.9regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sat Dec 21 11:04:36 2019
From: report at bugs.python.org (twisteroid ambassador)
Date: Sat, 21 Dec 2019 16:04:36 +0000
Subject: [issue39116] StreamReader.readexactly() raises GeneratorExit on
 ProactorEventLoop
Message-ID: <1576944276.46.0.229840779815.issue39116@roundup.psfhosted.org>


New submission from twisteroid ambassador <twisteroid.ambassador at gmail.com>:

I have been getting these strange exception since Python 3.8 on my Windows 10 machine. The external symptoms are many errors like "RuntimeError: aclose(): asynchronous generator is already running" and "Task was destroyed but it is pending!".

By adding try..except..logging around my code, I found that my StreamReaders would raise GeneratorExit on readexactly(). Digging deeper, it seems like the following line in StreamReader._wait_for_data():

await self._waiter

would raise a GeneratorExit.

There are only two other methods on StreamReader that actually does anything to _waiter, set_exception() and _wakeup_waiter(), but neither of these methods were called before GeneratorExit is raised. In fact, both these methods sets self._waiter to None, so normally after _wait_for_data() does "await self._waiter", self._waiter is None. However, after GeneratorExit is raised, I can see that self._waiter is not None. So it seems the GeneratorExit came from nowhere.

I have not been able to reproduce this behavior in other code. This is with Python 3.8.1 on latest Windows 10 1909, using ProactorEventLoop. I don't remember seeing this ever on Python 3.7.

----------
components: asyncio
messages: 358774
nosy: asvetlov, twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: StreamReader.readexactly() raises GeneratorExit on ProactorEventLoop
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39116>
_______________________________________

From report at bugs.python.org  Sat Dec 21 11:10:33 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 21 Dec 2019 16:10:33 +0000
Subject: [issue33772] Fix few dead code paths
In-Reply-To: <1564293672.48.0.573302806093.issue33772@roundup.psfhosted.org>
Message-ID: <1576944633.06.0.299574661587.issue33772@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33772>
_______________________________________

From report at bugs.python.org  Sat Dec 21 11:48:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2019 16:48:44 +0000
Subject: [issue39113] PyUnicode_AsUTF8AndSize Sometimes Segfaults With
 Incomplete Surrogate Pair
In-Reply-To: <1576899174.72.0.883256961456.issue39113@roundup.psfhosted.org>
Message-ID: <1576946924.9.0.494418635212.issue39113@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39113>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:18:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2019 18:18:15 +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: <1576952295.18.0.0808190940783.issue34850@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It cannot be suppressed by the code in the module caused a warning, because the warning is emitted at compile time. You need to silence it before compiling that module. Once you have compiled it, warning will no longer be emitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34850>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:47:12 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 18:47:12 +0000
Subject: [issue32599] Add dtrace hook for PyCFunction_Call
In-Reply-To: <1516383576.04.0.467229070634.issue32599@psf.upfronthosting.co.za>
Message-ID: <1576954032.0.0.381359672009.issue32599@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

If there are no objections, I can work on a patch.

----------
nosy: +BTaskaya, christian.heimes, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32599>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:52:29 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 18:52:29 +0000
Subject: [issue34444] Module's __file__ should be absolute always ("." in
 sys.path)
In-Reply-To: <1534784236.56.0.56676864532.issue34444@psf.upfronthosting.co.za>
Message-ID: <1576954349.59.0.621064132841.issue34444@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I am not sure about computing absolute path every time when `__file__` called. I guess it is a static thing, that get setted on the import time and never changes. What you are proposing is to compute it dynamically which IMHO isn't the best way.

----------
nosy: +BTaskaya, brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34444>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:57:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2019 18:57:08 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1576954628.28.0.210102134231.issue39087@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I like this idea, but I think that we should at least notify Python-Dev about all additions to the public C API. If somebody have objections or better idea, it is better to know earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:04:36 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 19:04:36 +0000
Subject: [issue29732] Heap out of bounds read in tok_nextc()
In-Reply-To: <1488788024.7.0.161413972339.issue29732@psf.upfronthosting.co.za>
Message-ID: <1576955076.3.0.46102921892.issue29732@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

(.venv) [ 10:04?S ]  [ isidentical at x200:~/Downloads ]
 $ python -V
Python 3.9.0a1+
(.venv) [ 10:04?S ]  [ isidentical at x200:~/Downloads ]
 $ python python_hoobr_tok_nextc.py
  File "/home/isidentical/Downloads/python_hoobr_tok_nextc.py", line 5
    
    ^
SyntaxError: EOF while scanning triple-quoted string literal

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29732>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:06:51 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 21 Dec 2019 19:06:51 +0000
Subject: [issue36788] Add clamp() function to builtins
In-Reply-To: <1556920200.45.0.0628062537563.issue36788@roundup.psfhosted.org>
Message-ID: <1576955211.86.0.448730750138.issue36788@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Should this issue stay? Maybe port this discussion over python-ideas and after the resolution open it again?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36788>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:45:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2019 19:45:12 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1576957512.66.0.601653736054.issue39114@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:13:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Dec 2019 20:13:01 +0000
Subject: [issue39117] Performance regression for making bound methods
Message-ID: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

$ python3.9 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
1000000 loops, best of 11: 230 nsec per loop

$ python3.8 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
2000000 loops, best of 11: 149 nsec per loop

$ python3.7 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
2000000 loops, best of 11: 159 nsec per loop

$ python3.6 -m timeit -r 11 -s 'class A: pass' -s 'A.m = lambda s: None' -s 'a = A()' 'a.m; a.m; a.m; a.m; a.m'
10000000 loops, best of 11: 0.159 usec per loop

Timings made using the recent released python.org macOS 64-bit builds.

----------
components: Interpreter Core
messages: 358781
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Performance regression for making bound methods
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:15:13 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2019 20:15:13 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1576959313.86.0.467220651576.issue36476@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 1. Python daemon threads

I think the answer is to document a bit more clearly that they can pose all kinds of problems.  Perhaps we could even display a visible warning when people create daemon threads.

> 2. Python threads created in atexit handlers

We could run the "join non-daemon threads" routine a *second time* after atexit handlers have been called.  It probably can't hurt (unless people do silly things?).

> 3. non-Python threads accessing the C-API

This one I don't know how to handle. By construction, a non-Python thread can do anything it wants, and we cannot add guards against this at the beginning of each C API function. I think that when someone calls the C API, we're clearly in the realm of "consenting adults".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:21:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2019 20:21:54 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1576959714.2.0.691331164902.issue36051@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Could you show evidences that dropping the GIL can help you? bytes.join() needs to perform operations which needs to hold the GIL (allocating the memory, iterating the list, getting the data of bytes-like objects). I afraid that the cost of memcpy() is a minor part of this.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:31:43 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2019 20:31:43 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1576960303.16.0.479636488682.issue36051@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

If there is a large chunk (e.g. several MBs), dropping the GIL during the memcpy of that chunk may be beneficial.  This kind of optimization may be applicable in other similar cases (such as extending a bytearray or a BytesIO object).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:33:51 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2019 20:33:51 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1576960431.45.0.811447346011.issue36051@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Sat Dec 21 18:16:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2019 23:16:38 +0000
Subject: [issue33608] 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: <1576970198.13.0.141308777837.issue33608@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Sat Dec 21 19:38:15 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 22 Dec 2019 00:38:15 +0000
Subject: [issue39071] email.parser.BytesParser - parse and parsebytes work not
 equivalent
In-Reply-To: <1576571549.52.0.292971717442.issue39071@roundup.psfhosted.org>
Message-ID: <1576975095.02.0.180586510282.issue39071@roundup.psfhosted.org>


Change by Abhilash Raj <raj.abhilash1 at gmail.com>:


----------
nosy: +maxking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39071>
_______________________________________

From report at bugs.python.org  Sun Dec 22 00:08:03 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 22 Dec 2019 05:08:03 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1576991283.04.0.49981225159.issue39075@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

IMHO, dropping the sort should be a default behavior. If some user need  
this feature, maybe we could supply a param to open the sort function or not?

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Sun Dec 22 03:13:37 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Dec 2019 08:13:37 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1577002417.03.0.457718691086.issue39075@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

@haisai SimpleNamespace can't use keyword arguments because those are already used to pass in data.  Also, we want to keep it simple; hence, the name :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:57:57 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 22 Dec 2019 09:57:57 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1577008677.4.0.42581674239.issue38878@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset eae87e3e4e0cb9a0ce10c2e101acb6995d79e09c by Ivan Levkivskyi (Bar Harel) in branch 'master':
bpo-38878: Fix os.PathLike __subclasshook__ (GH-17336)
https://github.com/python/cpython/commit/eae87e3e4e0cb9a0ce10c2e101acb6995d79e09c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Sun Dec 22 05:23:49 2019
From: report at bugs.python.org (Tibor Baranya)
Date: Sun, 22 Dec 2019 10:23:49 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
 single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1577010229.92.0.803218507016.issue11416@roundup.psfhosted.org>


Tibor Baranya <tibi at fallen.hu> added the comment:

As I understand this issue is there up to 3.8 (and will live into 3.9). As urllib3 supports netrc and requests uses urllib3, this issue can potentially cause a lot of inconsistencies. In case of multile entries (with no user provided), curl and wget takes the first entry, while cpython netrc takes the last.
I see there is a proposed implementation, but I couldn't find it's pull request on github. Is there any chance this will be resolved in the near future?
Alternatively, I can create a pull request, but I only bother if there is an actual intention to fix the current behavior.

----------
nosy: +arsyee
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11416>
_______________________________________

From report at bugs.python.org  Sun Dec 22 05:24:44 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 22 Dec 2019 10:24:44 +0000
Subject: [issue36788] Add clamp() function to builtins
In-Reply-To: <1556920200.45.0.0628062537563.issue36788@roundup.psfhosted.org>
Message-ID: <1577010284.43.0.35186393904.issue36788@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Maybe port this discussion over python-ideas and after the resolution open it again?

Sounds good to me. Adding a new builtin function is a big deal that would likely need a PEP. I'm not keen on adding something like this to the math module, either, when it's so simple to construct from max and min.

Closing as rejected here; it can be re-opened if there's a strong consensus for adding it on the ideas list.

----------
nosy: +mark.dickinson
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36788>
_______________________________________

From report at bugs.python.org  Sun Dec 22 06:45:39 2019
From: report at bugs.python.org (Leonardo)
Date: Sun, 22 Dec 2019 11:45:39 +0000
Subject: [issue39118] Variables changing values on their own
Message-ID: <1577015139.29.0.995275157746.issue39118@roundup.psfhosted.org>


New submission from Leonardo <leonardo.simunovic at gmail.com>:

in this code the variable o changes on its own:

x=[[-1, 7, 3], [12, 2, -13], [14, 18, -8], [17, 4, -4]]
x1=[[-8, -10, 0], [5, 5, 10], [2, -7, 3], [9, -8, -3]]
y=[[0,0,0],[0,0,0],[0,0,0],[0,0,0]]
k=True
f=0
z=[]
d=[]
while k:
    print(k)
    o=x
    print(o)
    for i in range(len(x)):
        for n in range(len(x)):
            if i!=n:
                for g in range(3):
                    if x[i][g]>x[n][g]:
                        y[i][g]-=1
                    if x[i][g]<x[n][g]:
                        y[i][g]+=1
    for i in range(len(x)):
        for n in range(3):
            x[i][n]+=y[i][n]
    for i in range(len(z)):
        if z[i]==x and d[i]==y:
            print("")   
    print(o)
    k=False


A similar error happens when I try to append x values to a list, the list is filled with the same x value (the last one that has been appended) the number of times a x value had been appended in general.

For example:

if I had a values of x at the end of the while loop as 1, 2 and 3 and I appended them to a list the list would be [3, 3, 3] instead of [1, 2, 3]. If i wrote the list out each time a new x value is appended it would write it [1] first, then [2, 2] and then [3, 3, 3] at the end. 

I am really sorry for wasting time if this is just me being really dumb and messing something up.

----------
assignee: terry.reedy
components: IDLE
messages: 358790
nosy: leonardo.simunovic at gmail.com, terry.reedy
priority: normal
severity: normal
status: open
title: Variables changing values on their own
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39118>
_______________________________________

From report at bugs.python.org  Sun Dec 22 07:11:01 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 22 Dec 2019 12:11:01 +0000
Subject: [issue39118] Variables changing values on their own
In-Reply-To: <1577015139.29.0.995275157746.issue39118@roundup.psfhosted.org>
Message-ID: <1577016661.42.0.88226532309.issue39118@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This isn't a bug. After this line in your code:

   o = x

both o and x refer to the same list object. So any modification you make to that list through the name "x" (for example, x[i][n]+=y[i][n]) will be seen through the name "o" as well.

There's lots written elsewhere explaining Python's assignment semantics. I highly recommend this presentation by Ned Batchelder: https://nedbatchelder.com/text/names1.html

You can also ask further questions on the Python mailing list: https://mail.python.org/mailman/listinfo/python-list

Closing here.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39118>
_______________________________________

From report at bugs.python.org  Sun Dec 22 09:59:29 2019
From: report at bugs.python.org (Amit Itzkovitch)
Date: Sun, 22 Dec 2019 14:59:29 +0000
Subject: [issue39060] asyncio.Task.print_stack doesn't print the full stack
In-Reply-To: <1576489918.95.0.196774987509.issue39060@roundup.psfhosted.org>
Message-ID: <1577026769.25.0.038867025495.issue39060@roundup.psfhosted.org>


Amit Itzkovitch <amit7itz at gmail.com> added the comment:

Hi Terry,
I guess the right place to update the Task.get_stack doc: https://docs.python.org/3/library/asyncio-task.html#asyncio.Task.get_stack

I'm not sure I know the terminology enough to phrase it right, but I would add there something like:
Note that the task's stack does not include the stack of coroutines that were awaited inside the task, as it is not part of the Task itself. 

But I am sure one of you can phrase it more professionally than me :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39060>
_______________________________________

From report at bugs.python.org  Sun Dec 22 11:04:57 2019
From: report at bugs.python.org (hai shi)
Date: Sun, 22 Dec 2019 16:04:57 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1577030696.99.0.444106860274.issue39075@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

@Raymond OK, copy that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Sun Dec 22 11:35:18 2019
From: report at bugs.python.org (Drew DeVault)
Date: Sun, 22 Dec 2019 16:35:18 +0000
Subject: [issue39119] email/_header_value_parser.py:parse_message_id:
 UnblondLocalError
Message-ID: <1577032518.62.0.64044225834.issue39119@roundup.psfhosted.org>


New submission from Drew DeVault <sir at cmpwn.com>:

File "/usr/lib/python3.8/site-packages/emailthreads/threads.py", line 14, in get_message_by_id
    if msg["message-id"] == msg_id:
  File "/usr/lib/python3.8/email/message.py", line 391, in __getitem__
    return self.get(name)
  File "/usr/lib/python3.8/email/message.py", line 471, in get
    return self.policy.header_fetch_parse(k, v)
  File "/usr/lib/python3.8/email/policy.py", line 163, in header_fetch_parse
    return self.header_factory(name, value)
  File "/usr/lib/python3.8/email/headerregistry.py", line 602, in __call__
    return self[name](name, value)
  File "/usr/lib/python3.8/email/headerregistry.py", line 197, in __new__
    cls.parse(value, kwds)
  File "/usr/lib/python3.8/email/headerregistry.py", line 530, in parse
    kwds['parse_tree'] = parse_tree = cls.value_parser(value)
  File "/usr/lib/python3.8/email/_header_value_parser.py", line 2116, in parse_message_id
    message_id.append(token)

----------
components: Library (Lib)
messages: 358794
nosy: ddevault
priority: normal
severity: normal
status: open
title: email/_header_value_parser.py:parse_message_id: UnblondLocalError
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39119>
_______________________________________

From report at bugs.python.org  Sun Dec 22 12:03:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 22 Dec 2019 17:03:09 +0000
Subject: [issue39119] email/_header_value_parser.py:parse_message_id:
 UnblondLocalError
In-Reply-To: <1577032518.62.0.64044225834.issue39119@roundup.psfhosted.org>
Message-ID: <1577034189.15.0.617625633142.issue39119@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this should be fixed with issue38698 in 3.8.1 . Can you please try the latest stable release.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39119>
_______________________________________

From report at bugs.python.org  Sun Dec 22 12:31:20 2019
From: report at bugs.python.org (Neil Faulkner)
Date: Sun, 22 Dec 2019 17:31:20 +0000
Subject: [issue39120] pyodbc dll load failed
Message-ID: <1577035880.74.0.752421559917.issue39120@roundup.psfhosted.org>


New submission from Neil Faulkner <nf00038 at nkfaulknerandsons.co.uk>:

Please can someone advise as to the root cause of this error?

----------
components: Library (Lib)
files: DLL.PNG
messages: 358796
nosy: nf00038
priority: normal
severity: normal
status: open
title: pyodbc dll load failed
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file48800/DLL.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39120>
_______________________________________

From report at bugs.python.org  Sun Dec 22 13:28:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 22 Dec 2019 18:28:49 +0000
Subject: [issue39120] pyodbc dll load failed
In-Reply-To: <1577035880.74.0.752421559917.issue39120@roundup.psfhosted.org>
Message-ID: <1577039329.98.0.00240474594615.issue39120@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a tracker for CPython issues. Please use the bug tracker for pyodbc or other forums like stack overflow for better solutions.

----------
nosy: +xtreak
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39120>
_______________________________________

From report at bugs.python.org  Sun Dec 22 15:23:41 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 22 Dec 2019 20:23:41 +0000
Subject: [issue39120] pyodbc dll load failed
In-Reply-To: <1577035880.74.0.752421559917.issue39120@roundup.psfhosted.org>
Message-ID: <1577046221.79.0.673394240717.issue39120@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This may be due to changes regarding DLL dependency resolution in 3.8. If so, you can find the missing DLL using Process Monitor, configured to monitor file access in python.exe and pythonw.exe. Add the DLL's directory to the search path via os.add_dll_directory [1] before importing from pyodbc. 

The developers of pyodbc should be directed to the porting notes for the DLL search requirements in 3.8 [2]. The interpreter and ctypes no longer support the old DLL search path that includes the working directory and PATH [3].

[1] https://docs.python.org/3/library/os.html#os.add_dll_directory
[2] https://docs.python.org/3/whatsnew/3.8.html#bpo-36085-whatsnew
[3] https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39120>
_______________________________________

From report at bugs.python.org  Sun Dec 22 17:38:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Dec 2019 22:38:37 +0000
Subject: [issue39118] Variables changing values on their own
In-Reply-To: <1577015139.29.0.995275157746.issue39118@roundup.psfhosted.org>
Message-ID: <1577054317.68.0.387506219037.issue39118@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Leonardo, even if this were a bug, it would be a mistake to ascribe it to IDLE.  The IDLE Shell is an alternative display window. IDLE sends your code to Python and displays values computed by Python and output by print statements.  I second Mark's suggestion to first ask questions on python-list or other forums (at least until one has substantial experience with Python).

----------
assignee: terry.reedy -> 
components:  -IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39118>
_______________________________________

From report at bugs.python.org  Sun Dec 22 19:30:21 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 23 Dec 2019 00:30:21 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577061021.04.0.871536574388.issue36051@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

https://github.com/python/cpython/blob/068768faf6b82478de239d7ab903dfb249ad96a4/Objects/stringlib/join.h#L105-L126

It seems we can release GIL during iterating the buffer array.
Even though there is no one big chunk, it would be beneficial if the output size is large enough (8MB+?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Sun Dec 22 19:39:47 2019
From: report at bugs.python.org (Rob Man)
Date: Mon, 23 Dec 2019 00:39:47 +0000
Subject: [issue39121] gzip header write OS field
Message-ID: <1577061587.89.0.561530879196.issue39121@roundup.psfhosted.org>


New submission from Rob Man <sir.mandic at gmail.com>:

Files written with gzip module write a value of 255 (unknown) at the 10th position in the header which defined what OS was used when gzip file was written. 
Files written with gzip linux command correctly set that field to the value of 3 (Unix).
This ehancement does that.

----------
components: Library (Lib)
messages: 358801
nosy: wungad
priority: normal
severity: normal
status: open
title: gzip header write OS field
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39121>
_______________________________________

From report at bugs.python.org  Sun Dec 22 19:49:48 2019
From: report at bugs.python.org (Rob Man)
Date: Mon, 23 Dec 2019 00:49:48 +0000
Subject: [issue39121] gzip header write OS field
In-Reply-To: <1577061587.89.0.561530879196.issue39121@roundup.psfhosted.org>
Message-ID: <1577062188.6.0.666823460474.issue39121@roundup.psfhosted.org>


Change by Rob Man <sir.mandic at gmail.com>:


----------
keywords: +patch
pull_requests: +17138
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17682

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39121>
_______________________________________

From report at bugs.python.org  Sun Dec 22 20:27:24 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 23 Dec 2019 01:27:24 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1577064444.17.0.128163347737.issue39117@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Probably #37340

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Sun Dec 22 21:52:19 2019
From: report at bugs.python.org (Rob Man)
Date: Mon, 23 Dec 2019 02:52:19 +0000
Subject: [issue39121] gzip header write OS field
In-Reply-To: <1577061587.89.0.561530879196.issue39121@roundup.psfhosted.org>
Message-ID: <1577069539.58.0.0755990534869.issue39121@roundup.psfhosted.org>


Change by Rob Man <sir.mandic at gmail.com>:


----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39121>
_______________________________________

From report at bugs.python.org  Mon Dec 23 00:12:29 2019
From: report at bugs.python.org (Bruce Merry)
Date: Mon, 23 Dec 2019 05:12:29 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577077949.12.0.729723320775.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

> It seems we can release GIL during iterating the buffer array.

That's what I had in mind. Naturally it would require a bit of benchmarking to pick a threshold such that the small case doesn't lose performance due to locking overheads. If no one else is working on it, I can give that a try early next year.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Mon Dec 23 02:23:11 2019
From: report at bugs.python.org (SilentGhost)
Date: Mon, 23 Dec 2019 07:23:11 +0000
Subject: [issue39121] gzip header write OS field
In-Reply-To: <1577061587.89.0.561530879196.issue39121@roundup.psfhosted.org>
Message-ID: <1577085791.4.0.128385963983.issue39121@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39121>
_______________________________________

From report at bugs.python.org  Mon Dec 23 02:41:07 2019
From: report at bugs.python.org (Michael Rolle)
Date: Mon, 23 Dec 2019 07:41:07 +0000
Subject: [issue20905] Adapt heapq push/pop/replace to allow passing a
 comparator.
In-Reply-To: <1394698697.56.0.738511180994.issue20905@psf.upfronthosting.co.za>
Message-ID: <1577086867.41.0.330181424402.issue20905@roundup.psfhosted.org>


Michael Rolle <m at rolle.name> added the comment:

I realize this request is closed, but I hope people will still be reading this comment, and can perhaps either reopen it or submit a new request.  I don't know how to submit a new request myself.
...

I'd like to see (key=) capability somehow, without degrading performance of time-critical applications.
I've got some ideas for your consideration, if you please.

1. Make the heapq into a heap class.  It would be more natural (for me, anyway) to push/pop using the heap's methods, rather than calling a function in the heap package and having to specify the heap list as well.

A heap class in C could outperform current heapq with lists by storing the member objects in an internal array.

This would also solve the issue of having the user switch comparison methods in the middle of things.  The comparison method would be specified when the heap is constructed.  It could be changed later, at the expense of resorting the heap.  I suggest the comparison method parameters be the same as for .sort () and sorted ().

By default, the heap class would directly compare elements using __lt__, and so the performance would be as good, or slightly better, than the current heapq package functions.

2. In my own use case, I have to define __lt__ for the objects in my heapq by comparing the _keys_ of the two items.  So push/pop wind up calling the key function many times anyway.  The heap push/pop themselves could do this same work probably a bit faster in C code than would calling my own __lt__ method.

3. Performance could be improved when there is a key function by having the heap store both the heap elements and their keys.  I believe a C implementation could benefit by storing key and value objects next to each other in the internal array.

4. I'd be happy to submit a reference implementation, only I don't have time to do that right now, sorry.  I'm sure someone else would be up to the challenge.

----------
nosy: +mrolle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20905>
_______________________________________

From report at bugs.python.org  Mon Dec 23 03:04:50 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2019 08:04:50 +0000
Subject: [issue39121] gzip header write OS field
In-Reply-To: <1577061587.89.0.561530879196.issue39121@roundup.psfhosted.org>
Message-ID: <1577088290.12.0.333221273709.issue39121@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The OS field is used in determining end-of-line convention for text files. But since we do not set the FTEXT flag, all files are binary. RFC 1952

Why do you need to set this field?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39121>
_______________________________________

From report at bugs.python.org  Mon Dec 23 03:08:04 2019
From: report at bugs.python.org (mattip)
Date: Mon, 23 Dec 2019 08:08:04 +0000
Subject: [issue32780] ctypes: memoryview gives incorrect PEP3118 format
 strings for both packed and unpacked structs
In-Reply-To: <1517894879.39.0.467229070634.issue32780@psf.upfronthosting.co.za>
Message-ID: <1577088484.2.0.785574256083.issue32780@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

Is there a ctypes or PEP-3118 core-dev who could review the issue and the PR solution?

----------
nosy: +mattip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32780>
_______________________________________

From report at bugs.python.org  Mon Dec 23 03:15:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2019 08:15:02 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1577088902.83.0.780282772911.issue39117@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +inada.naoki, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Mon Dec 23 03:50:39 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 23 Dec 2019 08:50:39 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1577091039.77.0.150266354441.issue39117@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Is this regression is large enough to revive the free_list for bound methods?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Mon Dec 23 06:10:22 2019
From: report at bugs.python.org (=?utf-8?q?Sara_Mart=C3=ADnez_Giner?=)
Date: Mon, 23 Dec 2019 11:10:22 +0000
Subject: [issue39122] Environment variable PYTHONUSERBASE is not set during
 customized Python Installation
Message-ID: <1577099422.36.0.0774544638319.issue39122@roundup.psfhosted.org>


New submission from Sara Mart?nez Giner <smg.sara90 at gmail.com>:

Environment variable PYTHONUSERBASE is not set during customized Python Installation.

Python installer 3.7.6(x64) / Windows 10

Check 1: Customize the installation to install Python in C:\Python37 for all users. 
  Result: Access Denied using pip

Check 2: Check 1: Customize the installation to install Python in C:\Program Files\Python37 for all users (default). 
  Result: pip works, but error appears trying to install anything with pip. For example:
>>pip install virtualenv
 WARNING: The script virtualenv.exe is intalled in 'C:\Users\XXX\AppData\Roaming\Python\Python37\Scripts' which is not on path

By default APPDATA matches with C:\Users\XXX\AppData\Roaming
and PYHTONUSERBASE is empty

-----------------------------------------------------------------

I've found the path constructor in \Python37\Lib\site.py (_getuserbase)

So I try the following steps:
- Create folder with full control in C:\ (C:\Python)
- Set environment variable PYTHONUSERBASE=C:\Python
- Install Python for all users in C:\Python\Python37

That works for me.

----------
components: Windows
messages: 358808
nosy: paul.moore, sarmar11, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Environment variable PYTHONUSERBASE is not set during customized Python Installation
type: security
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39122>
_______________________________________

From report at bugs.python.org  Mon Dec 23 06:56:16 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 23 Dec 2019 11:56:16 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1577102176.6.0.813298217055.issue39087@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17140
pull_request: https://github.com/python/cpython/pull/17683

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:09:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 23 Dec 2019 12:09:34 +0000
Subject: [issue39112] Misleading documentation for tuple
In-Reply-To: <1576891699.24.0.656089355811.issue39112@roundup.psfhosted.org>
Message-ID: <1577102974.86.0.368685875779.issue39112@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

FWIW, built-in types page has the class prefix : https://docs.python.org/3/library/stdtypes.html#tuple . Similar difference between range in the two pages.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39112>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:45:10 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 23 Dec 2019 12:45:10 +0000
Subject: [issue39115] Clarify Python MIME type
In-Reply-To: <1576937679.64.0.394621240723.issue39115@roundup.psfhosted.org>
Message-ID: <1577105110.12.0.233091491626.issue39115@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Do you mean adding a record to https://www.iana.org/assignments/media-types/media-types.xhtml?

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39115>
_______________________________________

From report at bugs.python.org  Mon Dec 23 08:14:46 2019
From: report at bugs.python.org (Bar Harel)
Date: Mon, 23 Dec 2019 13:14:46 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1577106886.38.0.91888244313.issue38878@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
pull_requests: +17141
pull_request: https://github.com/python/cpython/pull/17684

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Mon Dec 23 08:18:34 2019
From: report at bugs.python.org (Bar Harel)
Date: Mon, 23 Dec 2019 13:18:34 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1577107114.09.0.44569667209.issue38878@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
pull_requests: +17142
pull_request: https://github.com/python/cpython/pull/17685

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Mon Dec 23 08:40:46 2019
From: report at bugs.python.org (Josh de Kock)
Date: Mon, 23 Dec 2019 13:40:46 +0000
Subject: [issue39115] Clarify Python MIME type
In-Reply-To: <1576937679.64.0.394621240723.issue39115@roundup.psfhosted.org>
Message-ID: <1577108446.84.0.692809914406.issue39115@roundup.psfhosted.org>


Josh de Kock <josh at itanimul.li> added the comment:

An IANA media type assignment would be even better than a '*/x-*' MIME, of course, but my original intention was just to clarify that the MIMEs in the cpython source can be used as documentation for 'which MIME should you use when sending .py,.pyc,.pyo'. 

I'm unsure if Python is eligible for a 'real' assignment, as far as I can tell, the main factor is if they are willing to take a reference implementation as 'a permanent and readily available public specification of the format for the media type' [1].

[1]: https://tools.ietf.org/html/rfc6838#section-4.4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39115>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:13:47 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 23 Dec 2019 14:13:47 +0000
Subject: [issue39115] Clarify Python MIME type
In-Reply-To: <1576937679.64.0.394621240723.issue39115@roundup.psfhosted.org>
Message-ID: <1577110427.78.0.898775526195.issue39115@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

If you are not talking about IANA registration (I doubt if Python needs it) what do you propose?
I've missed what do you want to update in Python or its docs to satisfy your needs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39115>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:23:44 2019
From: report at bugs.python.org (Vadim Zeitlin)
Date: Mon, 23 Dec 2019 14:23:44 +0000
Subject: [issue39123] PyThread_xxx() not available when using limited API
Message-ID: <1577111024.93.0.368390768924.issue39123@roundup.psfhosted.org>


New submission from Vadim Zeitlin <vz-python at zeitlins.org>:

These functions (e.g. PyThread_allocate_lock() etc) are not declared inside

#if !defined(Py_LIMITED_API)

in pythread.h, yet they're not exported from python3.lib.

IMHO, ideal would be to just provide these functions in the library, as they exist since basically always, but if the intention is to not make them part of the limited API, a guard around their declarations in the header should be added so that using them at least results in link-time errors instead of compile-time ones when using limited API.

----------
components: C API
messages: 358813
nosy: VZ
priority: normal
severity: normal
status: open
title: PyThread_xxx() not available when using limited API
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39123>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:34:58 2019
From: report at bugs.python.org (Adelson Luiz de Lima)
Date: Mon, 23 Dec 2019 14:34:58 +0000
Subject: [issue39124] round Decimal error
Message-ID: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>


New submission from Adelson Luiz de Lima <adelsontads at gmail.com>:

When I round this: round(Decimal('9.925'), 2), in Python 3.7.5 the result is Decimal('9.92'), but in Python 2.7.17 is 9.93

----------
messages: 358814
nosy: adelsonllima
priority: normal
severity: normal
status: open
title: round Decimal error
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:37:38 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Dec 2019 14:37:38 +0000
Subject: [issue39124] round Decimal error
In-Reply-To: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>
Message-ID: <1577111858.28.0.544651397221.issue39124@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

In Python 3, the rounding mode is round-ties-to-even. (In Python 2, it's round-ties-to-away.)

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:39:16 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Dec 2019 14:39:16 +0000
Subject: [issue39124] round Decimal error
In-Reply-To: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>
Message-ID: <1577111956.87.0.75636440873.issue39124@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

More details on the change here:  https://docs.python.org/3/whatsnew/3.0.html#builtins

and in the library documentation:
https://docs.python.org/3/library/functions.html#round

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:47:09 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Dec 2019 14:47:09 +0000
Subject: [issue20905] Adapt heapq push/pop/replace to allow passing a
 comparator.
In-Reply-To: <1394698697.56.0.738511180994.issue20905@psf.upfronthosting.co.za>
Message-ID: <1577112429.43.0.0964610642264.issue20905@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Michael: if you want to take this further, your best bet would probably be to start a discussion on the python-ideas mailing list (https://mail.python.org/mailman3/lists/python-ideas.python.org/).

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20905>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:51:19 2019
From: report at bugs.python.org (Rob Man)
Date: Mon, 23 Dec 2019 14:51:19 +0000
Subject: [issue39121] gzip header write OS field
In-Reply-To: <1577088290.12.0.333221273709.issue39121@roundup.psfhosted.org>
Message-ID: <CACNSdQ3mLgTnzbLjRxt6zYR16GyjmFmVWUfaWxZts2V5svni2g@mail.gmail.com>


Rob Man <sir.mandic at gmail.com> added the comment:

I do not need it for personaly, but since RFC exists and since linux
command line equivalent writes OS information, why should python gzip
implementation not include that.
The same goes for the FCOMMENT field for wich I also have a patch ready and
I they're both nice enhancements.

On Mon, 23 Dec 2019 at 09:04, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> The OS field is used in determining end-of-line convention for text files.
> But since we do not set the FTEXT flag, all files are binary. RFC 1952
>
> Why do you need to set this field?
>
> ----------
> nosy: +serhiy.storchaka
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39121>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39121>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:53:21 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 23 Dec 2019 14:53:21 +0000
Subject: [issue38914] Clarify wording for warning message when checking a
 package
In-Reply-To: <1574761271.03.0.166396347338.issue38914@roundup.psfhosted.org>
Message-ID: <1577112801.89.0.604122854402.issue38914@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9f9dac0a4e58d5c72aa3b644701cb155c009cb2c by Miss Islington (bot) (J?rgen Gmach) in branch 'master':
bpo-38914 Do not require email field in setup.py. (GH-17388)
https://github.com/python/cpython/commit/9f9dac0a4e58d5c72aa3b644701cb155c009cb2c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38914>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:20:12 2019
From: report at bugs.python.org (Adelson Luiz de Lima)
Date: Mon, 23 Dec 2019 15:20:12 +0000
Subject: [issue39124] round Decimal error
In-Reply-To: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>
Message-ID: <1577114412.82.0.327137304747.issue39124@roundup.psfhosted.org>


Adelson Luiz de Lima <adelsontads at gmail.com> added the comment:

Thanks for the quick response. 
I try the follow code in python 3.7: 
round(9.925, 2) => 9.93
round(Decimal('9.925'), 2) => Decimal('9.92')

I do not understande why behavior of float is diferrent of the Decimal.

In python 2.7 I have the same result: 9.93

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:31:55 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Mon, 23 Dec 2019 15:31:55 +0000
Subject: [issue39124] round Decimal error
In-Reply-To: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>
Message-ID: <1577115115.0.0.95756664273.issue39124@roundup.psfhosted.org>


J?rn Heissler <launchpad2019 at tutnicht.de> added the comment:

> round(9.925, 2) => 9.93

9.925 is 9.925000000000000710542735760100185871124267578125 on my platform.
This is larger than 9.925, so the "round-ties-to-even" rule can't be applied. Instead it is rounded up to 9.93 (9.92999999999999971578290569595992565155029296875).

----------
nosy: +joernheissler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:39:44 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Dec 2019 15:39:44 +0000
Subject: [issue39124] round Decimal error
In-Reply-To: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>
Message-ID: <1577115584.61.0.518009540188.issue39124@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@adelsonllima: Take a look at the documentation that I linked to for the round function, and in particular this note:

"The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it?s a result of the fact that most decimal fractions can?t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information."

As J?rn Heissler observed, the issue here is that the numeric literal 9.925 in the source gets turned into a float whose exact value is just slightly larger than 9.925 (because 9.925 can't be exactly represented in the IEEE 754 binary64 floating-point format that your machine is almost certainly using). So because it's a touch larger than 9.925, it rounds up when rounding to two decimal places.

Closing again here: believe it or not, round is working as designed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:39:52 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Dec 2019 15:39:52 +0000
Subject: [issue39124] round Decimal error
In-Reply-To: <1577111698.59.0.695595778809.issue39124@roundup.psfhosted.org>
Message-ID: <1577115592.5.0.778175270173.issue39124@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39124>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:40:00 2019
From: report at bugs.python.org (=?utf-8?q?Nguy=E1=BB=85n_Gia_Phong?=)
Date: Mon, 23 Dec 2019 15:40:00 +0000
Subject: [issue39125] Type signature of @property not shown in help()
Message-ID: <1577115600.68.0.0436692507171.issue39125@roundup.psfhosted.org>


New submission from Nguy?n Gia Phong <vn.mcsinyx at gmail.com>:

Dear Maintainer,

I want to request a feature on the generative documentation of type-hinting.
As of December 2019, I believe there is no support for generating such
information in help().  For demonstration, I have this tiny piece of code

class Foo:
    @property
    def bar(self) -> int: return 42

    @bar.setter
    def bar(self, value: int) -> None: pass

    def baz(self, arg: float) -> str: pass

whose documentation on CPython 3.7.5 (on Debian testing amd64 if that matters)
is generated as

class Foo(builtins.object)
 |  Methods defined here:
 |  
 |  baz(self, arg: float) -> str
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __dict__
 |      dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |      list of weak references to the object (if defined)
 |  
 |  bar

I expect the documentation for bar to be as informative as bar, i.e. something
similar to ``bar: int''.  As pointed out by ChrisWarrick on freenode#python,
the annotations are already present, yet help() is not making use of them:

>>> Foo.bar.fget.__annotations__
{'return': <class 'int'>}
>>> Foo.bar.fset.__annotations__
{'value': <class 'int'>, 'return': None}

Have a Merry Christmas or other holiday of your choice,
Nguy?n Gia Phong

----------
assignee: docs at python
components: Documentation
messages: 358823
nosy: McSinyx, docs at python
priority: normal
severity: normal
status: open
title: Type signature of @property not shown in help()
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39125>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:11:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 23 Dec 2019 16:11:07 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577117467.42.0.267948681041.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 4b3b1226e86df6cd45e921c8f2ad23c3639c43b2 by Pablo Galindo (Batuhan Ta?kaya) in branch 'master':
bpo-38870: Refactor delimiting with context managers in ast.unparse (GH-17612)
https://github.com/python/cpython/commit/4b3b1226e86df6cd45e921c8f2ad23c3639c43b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:18:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 23 Dec 2019 16:18:18 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577117898.1.0.188660299011.issue38870@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17143
pull_request: https://github.com/python/cpython/pull/17687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:30:10 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 23 Dec 2019 16:30:10 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577118610.44.0.131475313468.issue38870@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/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:37:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 23 Dec 2019 16:37:13 +0000
Subject: [issue39125] Type signature of @property not shown in help()
In-Reply-To: <1577115600.68.0.0436692507171.issue39125@roundup.psfhosted.org>
Message-ID: <1577119033.83.0.314040027369.issue39125@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Currently docstring written for even property.setter is ignored in help as inspect.getdoc only inspects property.fget [0] for docstrings. I feel docs for setter could also be included. The docs also indicate the same at https://docs.python.org/3.6/library/functions.html#property . In the absence of docs maybe the signature for getter and setter could be included as per this proposal.

class Foo:
    @property
    def bar(self) -> int:
        '''Bar docs for property'''
        return 42

    @bar.setter
    def bar(self, value: int) -> None:
        '''Bar docs for setter'''
        pass

help(Foo.bar)

Help on property:

    Bar docs for property


[0] https://github.com/python/cpython/blob/4b3b1226e86df6cd45e921c8f2ad23c3639c43b2/Lib/inspect.py#L580

----------
nosy: +rhettinger, xtreak
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39125>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:42:54 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 23 Dec 2019 16:42:54 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577119374.96.0.609822517097.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset d69cbeb99d5fd0d5464e937202cca6a2024d1bcf by Pablo Galindo in branch 'master':
Revert "bpo-38870: Remove dependency on contextlib to avoid performance regression on import (GH-17376)" (GH-17687)
https://github.com/python/cpython/commit/d69cbeb99d5fd0d5464e937202cca6a2024d1bcf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:45:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 23 Dec 2019 16:45:03 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577119503.7.0.494766334695.issue39114@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Mon Dec 23 11:45:45 2019
From: report at bugs.python.org (jvoisin)
Date: Mon, 23 Dec 2019 16:45:45 +0000
Subject: [issue39062] ValueError in TarFile.getmembers
In-Reply-To: <1576493016.16.0.2184811666.issue39062@roundup.psfhosted.org>
Message-ID: <1577119545.21.0.350932012331.issue39062@roundup.psfhosted.org>


jvoisin <jvoisin at google.com> added the comment:

Raising an except is ok, if it's documented, so I know which ones I should catch to prevent my program to quit when processing untrusted files, without having to catch `Exception`.

Reliability is important in my use-case as well, not only exploitable memory-corruption issues.

I'll try to reproduce future issues on more recent Python versions before reporting them :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39062>
_______________________________________

From report at bugs.python.org  Mon Dec 23 12:24:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 23 Dec 2019 17:24:49 +0000
Subject: [issue32780] ctypes: memoryview gives incorrect PEP3118 format
 strings for both packed and unpacked structs
In-Reply-To: <1517894879.39.0.467229070634.issue32780@psf.upfronthosting.co.za>
Message-ID: <1577121889.05.0.410518071109.issue32780@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32780>
_______________________________________

From report at bugs.python.org  Mon Dec 23 12:55:43 2019
From: report at bugs.python.org (=?utf-8?b?Q8Opc2Fy?=)
Date: Mon, 23 Dec 2019 17:55:43 +0000
Subject: [issue31711] ssl.SSLSocket.send(b"") fails
In-Reply-To: <1507282980.19.0.213398074469.issue31711@psf.upfronthosting.co.za>
Message-ID: <1577123743.55.0.316607715956.issue31711@roundup.psfhosted.org>


Change by C?sar <cesar91hoyos at gmail.com>:


----------
pull_requests: +17144
pull_request: https://github.com/python/cpython/pull/17671

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31711>
_______________________________________

From report at bugs.python.org  Mon Dec 23 13:31:08 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 23 Dec 2019 18:31:08 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1577125868.71.0.0497325294646.issue38878@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 0846e5d4603434c2bbf8a528677cf1ff3fe29b95 by Ivan Levkivskyi (Bar Harel) in branch '3.8':
[3.8] bpo-38878: Fix os.PathLike __subclasshook__ (GH-17336) (GH-17684)
https://github.com/python/cpython/commit/0846e5d4603434c2bbf8a528677cf1ff3fe29b95


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Mon Dec 23 13:31:18 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 23 Dec 2019 18:31:18 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1577125878.64.0.773962040101.issue38878@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 59d06b987db34cde8783e265709366d244c9e35b by Ivan Levkivskyi (Bar Harel) in branch '3.7':
[3.7] bpo-38878: Fix os.PathLike __subclasshook__ (GH-17336) (GH-17685)
https://github.com/python/cpython/commit/59d06b987db34cde8783e265709366d244c9e35b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38878>
_______________________________________

From report at bugs.python.org  Mon Dec 23 13:32:01 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 23 Dec 2019 18:32:01 +0000
Subject: [issue38878] os.PathLike subclasshook causes subclass checks true on
 abstract implementation
In-Reply-To: <1574348421.53.0.110066874407.issue38878@roundup.psfhosted.org>
Message-ID: <1577125921.18.0.847144782403.issue38878@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi 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/issue38878>
_______________________________________

From report at bugs.python.org  Mon Dec 23 13:47:33 2019
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Mon, 23 Dec 2019 18:47:33 +0000
Subject: [issue31711] ssl.SSLSocket.send(b"") fails
In-Reply-To: <1507282980.19.0.213398074469.issue31711@psf.upfronthosting.co.za>
Message-ID: <1577126853.56.0.652495588592.issue31711@roundup.psfhosted.org>


J?rn Heissler <launchpad2019 at tutnicht.de> added the comment:

Manpage (openssl 1.1.1d) now states:

You should not call SSL_write() with num=0, it will return an error.  SSL_write_ex() can be called with num=0, but will not send application data to the peer. SSL_write_ex was added in 1.1.1

So it looks like openssl cleaned up another mistake by defining SSL_write_ex's behaviour to be a noop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31711>
_______________________________________

From report at bugs.python.org  Mon Dec 23 14:19:53 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 23 Dec 2019 19:19:53 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1577128793.47.0.762943865514.issue39011@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think we did it wrong in issue 17582. Parser behaviour is not a reason why the *serialisation* should modify the content.

Luckily, fixing this does not impact the C14N serialisation (which aims to guarantee byte identical serialisation), but it changes the "normal" serialisation. I would therefore suggest that we remove the newline replacement code in the next release only, Py3.9.

@mefistotelis, do you want to submit a PR?

----------
stage:  -> needs patch
versions: +Python 3.9 -Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:21:24 2019
From: report at bugs.python.org (Josh de Kock)
Date: Mon, 23 Dec 2019 20:21:24 +0000
Subject: [issue39115] Clarify Python MIME type
In-Reply-To: <1576937679.64.0.394621240723.issue39115@roundup.psfhosted.org>
Message-ID: <1577132484.75.0.93157445727.issue39115@roundup.psfhosted.org>


Josh de Kock <josh at itanimul.li> added the comment:

I just wanted the intended MIME type for sending python over various mediums to be written down somewhere other than the source code, but I'm not sure where it should go.

Though if you don't think it is necessary then that is fine too, I mostly just wanted someone else's opinion. After looking into it further I couldn't find much on other languages specifically stating which MIME you should use, it's mostly somewhat of an infrequent unofficial convention.

If you don't think there is an appropriate place to put this information, other than the source code itself, then feel free to close this bug. Thank you for your replies, and sorry for wasting your time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39115>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:35:39 2019
From: report at bugs.python.org (Tim Burke)
Date: Mon, 23 Dec 2019 20:35:39 +0000
Subject: [issue37093] http.client aborts header parsing upon encountering
 non-ASCII header names
In-Reply-To: <1559172729.29.0.908018369806.issue37093@roundup.psfhosted.org>
Message-ID: <1577133339.21.0.310043555445.issue37093@roundup.psfhosted.org>


Tim Burke <tim.burke at gmail.com> added the comment:

Note that because http.server uses http.client to parse headers [0], this can pose a request-smuggling vector depending on how you've designed your system. For example, you might have a storage system with a user-facing HTTP server that is in charge of

* authenticating and authorizing users,
* determining where data should be stored, and
* proxying the user request to the backend

and a separate (unauthenticated) HTTP server for actually storing that data. If the proxy and backend are running different versions of CPython (say, because you're trying to upgrade an existing py2 cluster to run on py3), they may disagree about where the request begins and ends -- potentially causing the backend to process multiple requests, only the first of which was authorized.

See, for example, https://bugs.launchpad.net/swift/+bug/1840507

For what it's worth, most http server libraries (that I tested; take it with a grain of salt) seem to implement their own header parsing. Eventlet was a notable exception [1].

[0] https://github.com/python/cpython/blob/v3.8.0/Lib/http/server.py#L336-L337
[1] https://github.com/eventlet/eventlet/pull/574

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37093>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:51:42 2019
From: report at bugs.python.org (Marco Sulla)
Date: Mon, 23 Dec 2019 20:51:42 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1577134302.21.0.896389515214.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

marco at buzz:~$ python3.9
Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01) 
[GCC 9.2.1 20190909] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as Dec, BasicContext as Bctx
>>> a = Dec("1981", Bctx)
>>> b = Dec("nan", Bctx)
>>> a.max(b)
Decimal('1981')
>>> b.max(a)
Decimal('1981')
>>> Bctx.max(a, b)
Decimal('1981')
>>> Bctx.max(b, a)
Decimal('1981')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Mon Dec 23 16:00:16 2019
From: report at bugs.python.org (Marco Sulla)
Date: Mon, 23 Dec 2019 21:00:16 +0000
Subject: [issue36095] Better NaN sorting.
In-Reply-To: <1550950757.55.0.405574866511.issue36095@roundup.psfhosted.org>
Message-ID: <1577134816.01.0.724549951241.issue36095@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Excuse me, ignore my previous post.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________

From report at bugs.python.org  Mon Dec 23 16:11:54 2019
From: report at bugs.python.org (dmaxime)
Date: Mon, 23 Dec 2019 21:11:54 +0000
Subject: [issue39126] Some characters confuse the editor
Message-ID: <1577135514.42.0.144036776783.issue39126@roundup.psfhosted.org>


New submission from dmaxime <dmaxime at hotmail.it>:

>>> b'\xf0\x9f\x98\x86'.decode('utf8')
'?'
>>> '?'.encode('utf8')
b'\xf0\x9f\x98\x86'

...now if you write '?'.encode() then you move the cursor between the brackets and type "'utf8'" you will have this result while the cursor remains in the brackets:

>>> '?'.encode()''8ftu
SyntaxError: invalid syntax
>>>

I've attached a video that shows this behavior.
Thanks for your attention. Cheers.

----------
assignee: terry.reedy
components: IDLE
files: python3ide bug.mp4
messages: 358836
nosy: dmaxime, terry.reedy
priority: normal
severity: normal
status: open
title: Some characters confuse the editor
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48801/python3ide bug.mp4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39126>
_______________________________________

From report at bugs.python.org  Mon Dec 23 16:35:06 2019
From: report at bugs.python.org (Marco Sulla)
Date: Mon, 23 Dec 2019 21:35:06 +0000
Subject: [issue11986] Min/max not symmetric in presence of NaN
In-Reply-To: <1304447488.99.0.598234391452.issue11986@psf.upfronthosting.co.za>
Message-ID: <1577136906.98.0.60833081943.issue11986@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

marco at buzz:~$ python3.9
Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01) 
[GCC 9.2.1 20190909] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as Dec, BasicContext as Bctx
>>> a = Dec("1981", Bctx)
>>> b = Dec("nan", Bctx)
>>> a.max(b)
Decimal('1981')
>>> b.max(a)
Decimal('1981')
>>> Bctx.max(a, b)
Decimal('1981')
>>> Bctx.max(b, a)
Decimal('1981')


`Decimal` completely adheres to IEEE 754 standard.

There's a very, very simple and generic solution for builtin min and max:



_sentinel = object()

def max(*args, key=None, default=_sentinel):
    args_len = len(args)
    
    if args_len == 0:
        if default is _sentinel:
            fname = max.__name__
            raise ValueError(f"{fname}() expected 1 argument, got 0")
        
        return default
    elif args_len == 1:
        seq = args[0]
    else:
        seq = args
    
    it = iter(seq)
    
    vmax = next(it, _sentinel)
    
    if vmax is _sentinel:
        if default is _sentinel:
            fname = max.__name__
            raise ValueError(f"{fname}() arg is an empty sequence")
        
        return default
    
    
    first_comparable = False
    
    if key is None:
        for val in it:
            if vmax < val:
                vmax = val
                first_comparable = True
            elif not first_comparable and not val < vmax :
                # equal, or not comparable object, like NaN
                vmax = val
    else:
        fmax = key(vmax)
        
        for val in it:
            fval = key(val)
            
            if fmax < fval :
                fmax = fval
                vmax = val
                first_comparable = True
            elif not first_comparable and not fval < fmax:
                fmax = fval
                vmax = val
    
    return vmax


This function continues to give undefined behavior with sets... but who calculates the "maximum" or "minimum" of sets?

----------
nosy: +Marco Sulla

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11986>
_______________________________________

From report at bugs.python.org  Mon Dec 23 17:20:52 2019
From: report at bugs.python.org (Eric Snow)
Date: Mon, 23 Dec 2019 22:20:52 +0000
Subject: [issue37340] remove free_list for bound method objects
In-Reply-To: <1560948861.51.0.564500331945.issue37340@roundup.psfhosted.org>
Message-ID: <1577139652.66.0.287262253781.issue37340@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/issue37340>
_______________________________________

From report at bugs.python.org  Mon Dec 23 17:22:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 23 Dec 2019 22:22:38 +0000
Subject: [issue39126] Non-bmp (astral) unicode characters confuse the editor
In-Reply-To: <1577135514.42.0.144036776783.issue39126@roundup.psfhosted.org>
Message-ID: <1577139758.54.0.830255590615.issue39126@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am aware of this.  Before the recent (Oct 4) fix for #13153, pasting an astral character into an edit line or window crashed IDLE.  After the fix, the character appears (and printing such chars also works reliably).  But astral chars confuse the tk text widget, which cannot properly handle them. (I believe that they are stored as 2 surrogate chars, displayed as one.)

I don't want to immediately replace such chars with escape sequences.

>>> hex(ord('?'))
'0x1f606'
>>> '\U0001f606'
'?'

The effect is limited to the line containing the odd char, and once entered, strange cursor placement does not matter too much.  But we probably should document the situation and add an option to escape or unescape such chars.

----------
title: Some characters confuse the editor -> Non-bmp (astral) unicode characters confuse the editor
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39126>
_______________________________________

From report at bugs.python.org  Mon Dec 23 23:43:00 2019
From: report at bugs.python.org (Andy Lester)
Date: Tue, 24 Dec 2019 04:43:00 +0000
Subject: [issue39127] _Py_HashPointer's void * argument should be const
Message-ID: <1577162580.85.0.922460323342.issue39127@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

_Py_HashPointer in Python/pyhash.c takes a pointer argument that can be made const.  This will let compiler and static analyzers know that the pointer's target is not modified.  You can also change calls to _Py_HashPointer that are down-casting pointers.

For example, in meth_hash in Objects/methodobject.c, this call can have the void * changed to const void *.

    y = _Py_HashPointer((void*)(a->m_ml->ml_meth));

----------
components: Interpreter Core
messages: 358839
nosy: petdance
priority: normal
severity: normal
status: open
title: _Py_HashPointer's void * argument should be const

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39127>
_______________________________________

From report at bugs.python.org  Tue Dec 24 00:01:40 2019
From: report at bugs.python.org (Andy Lester)
Date: Tue, 24 Dec 2019 05:01:40 +0000
Subject: [issue39127] _Py_HashPointer's void * argument should be const
In-Reply-To: <1577162580.85.0.922460323342.issue39127@roundup.psfhosted.org>
Message-ID: <1577163700.52.0.791851810196.issue39127@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17145
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17690

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39127>
_______________________________________

From report at bugs.python.org  Tue Dec 24 01:38:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 24 Dec 2019 06:38:19 +0000
Subject: [issue39128] Document happy eyeball parameters in
 loop.create_connection signature docs
Message-ID: <1577169499.92.0.148035578334.issue39128@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Created from https://github.com/aio-libs/aiohttp/issues/4451 . happy_eyeballs_delay and interleave are not documented in the signature at [0] though the parameters were explained below . Andrew, feel free to update if there is any additional action needed besides signature update. I guess it could be tagged as a good newcomer friendly issue.

[0] https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_connection

----------
assignee: docs at python
components: Documentation, asyncio
messages: 358840
nosy: asvetlov, docs at python, xtreak, yselivanov
priority: normal
severity: normal
status: open
title: Document happy eyeball parameters in loop.create_connection signature docs
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Tue Dec 24 02:04:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 24 Dec 2019 07:04:13 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
Message-ID: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I guess the TimeoutError exception needs to be imported from asyncio.exceptions and not from asyncio.futures that causes AttributeError while instantiating a connection with happy eyeballs.

./python.exe -m asyncio
asyncio REPL 3.9.0a2+ (heads/master:068768faf6, Dec 23 2019, 18:35:26)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> conn = await asyncio.open_connection("localhost", port=8000, happy_eyeballs_delay=1)
Traceback (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/concurrent/futures/_base.py", line 439, in result
    return self.__get_result()
  File "/Users/kasingar/stuff/python/cpython/Lib/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
  File "<console>", line 1, in <module>
  File "/Users/kasingar/stuff/python/cpython/Lib/asyncio/streams.py", line 52, in open_connection
    transport, _ = await loop.create_connection(
  File "/Users/kasingar/stuff/python/cpython/Lib/asyncio/base_events.py", line 1041, in create_connection
    sock, _, _ = await staggered.staggered_race(
  File "/Users/kasingar/stuff/python/cpython/Lib/asyncio/staggered.py", line 144, in staggered_race
    raise d.exception()
  File "/Users/kasingar/stuff/python/cpython/Lib/asyncio/staggered.py", line 86, in run_one_coro
    with contextlib.suppress(futures.TimeoutError):
AttributeError: module 'asyncio.futures' has no attribute 'TimeoutError'

----------
components: asyncio
messages: 358841
nosy: asvetlov, xtreak, yselivanov
priority: normal
severity: normal
status: open
title: Incorrect import of TimeoutError while creating happy eyeballs connection
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Tue Dec 24 02:50:33 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 24 Dec 2019 07:50:33 +0000
Subject: [issue38225] iscoroutinefunction broken with cython - allow tagging
 of functions as async?
In-Reply-To: <1568918319.91.0.348855638851.issue38225@roundup.psfhosted.org>
Message-ID: <1577173833.17.0.181161230202.issue38225@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

FWIW, it seems reasonable to have a protocol for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38225>
_______________________________________

From report at bugs.python.org  Tue Dec 24 03:24:44 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 24 Dec 2019 08:24:44 +0000
Subject: [issue38225] iscoroutinefunction broken with cython - allow tagging
 of functions as async?
In-Reply-To: <1568918319.91.0.348855638851.issue38225@roundup.psfhosted.org>
Message-ID: <1577175884.05.0.887895863072.issue38225@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I'd like to hear Yuri's opinion for the idea of adding an attribute.
Another question is the name: I have proposed __awaitable__ but maybe __async__ is slightly better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38225>
_______________________________________

From report at bugs.python.org  Tue Dec 24 03:36:45 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 24 Dec 2019 08:36:45 +0000
Subject: [issue39128] Document happy eyeball parameters in
 loop.create_connection signature docs
In-Reply-To: <1577169499.92.0.148035578334.issue39128@roundup.psfhosted.org>
Message-ID: <1577176605.02.0.470963553492.issue39128@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Ideally, a small chapter with a description of Happy Eyeballs algorithm would be nice to have but I don't insist.

Updating the method signature is a big step anyway.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Tue Dec 24 03:42:21 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 24 Dec 2019 08:42:21 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
In-Reply-To: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>
Message-ID: <1577176941.11.0.532623311174.issue39129@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

You are right.

Hmm, I thought that Happy Eyeballs is better tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Tue Dec 24 03:44:08 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 24 Dec 2019 08:44:08 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
In-Reply-To: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>
Message-ID: <1577177048.86.0.00971418315875.issue39129@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +17146
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17691

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Tue Dec 24 05:02:31 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 24 Dec 2019 10:02:31 +0000
Subject: [issue39115] Clarify Python MIME type
In-Reply-To: <1576937679.64.0.394621240723.issue39115@roundup.psfhosted.org>
Message-ID: <1577181751.8.0.12396788259.issue39115@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

As you mentioned, IANA did not registry any programming language except JavaScript; I think that's fine.

You can consider text/x-python and application/x-python-code as unofficial but permanent MIME types that are used in Python written programs at least; feel free to use them.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39115>
_______________________________________

From report at bugs.python.org  Tue Dec 24 05:48:26 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 24 Dec 2019 10:48:26 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
In-Reply-To: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>
Message-ID: <1577184506.27.0.884669969626.issue39129@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17147
pull_request: https://github.com/python/cpython/pull/17693

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Tue Dec 24 06:23:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 24 Dec 2019 11:23:15 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
In-Reply-To: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>
Message-ID: <1577186595.84.0.0970776256712.issue39129@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is there a way this can be tested? I tried simulating OSError for IPv4 address and returning socket for ipv6 one like it resolves correctly. I guess that's the underlying idea of happy eyeballs but a test can be added for basic workflow since it lacks tests.

@patch_socket
def test_create_connection_happy_eyeballs_exception(self, sock_mock):
    async def getaddrinfo(*args, **kw):
        return [(2, 1, 6, '', ('127.0.0.1', 8000)),
                (2, 1, 6, '', ('::1', 8000, 0, 0)),]

    def getaddrinfo_task(*args, **kwds):
        return self.loop.create_task(getaddrinfo(*args, **kwds))

    self.loop.getaddrinfo = getaddrinfo_task
    with mock.patch.object(self.loop, 'sock_connect',
                           side_effect=[OSError, sock_mock]):
        coro = self.loop.create_connection(MyProto, host='localhost', port=8000,
                                           happy_eyeballs_delay=1)
        transport, _ = self.loop.run_until_complete(coro)
        transport.close()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Tue Dec 24 08:27:15 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 24 Dec 2019 13:27:15 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
In-Reply-To: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>
Message-ID: <1577194035.0.0.363664530137.issue39129@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The main problem of mock-based tests in asyncio is that the tests become unreliably very easy after mocked asyncio internal changes.

I'm +0 on adding the proposed test. The better idea is serving on explicit AF_INET '127.0.0.1:<port>' address when the connection is established to AF_INET6 '[::1]:<port>'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Tue Dec 24 08:30:50 2019
From: report at bugs.python.org (Khalid Mammadov)
Date: Tue, 24 Dec 2019 13:30:50 +0000
Subject: [issue39130] Dict is reversable from v3.8 and should say that in the
 doc
Message-ID: <1577194250.11.0.350136379073.issue39130@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, khalidmammadov
priority: normal
severity: normal
status: open
title: Dict is reversable from v3.8 and should say that in the doc
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39130>
_______________________________________

From report at bugs.python.org  Tue Dec 24 08:34:21 2019
From: report at bugs.python.org (Khalid Mammadov)
Date: Tue, 24 Dec 2019 13:34:21 +0000
Subject: [issue39130] Dict is reversable from v3.8 and should say that in the
 doc
Message-ID: <1577194461.06.0.473297243708.issue39130@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
keywords: +patch
pull_requests: +17148
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17694

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39130>
_______________________________________

From report at bugs.python.org  Tue Dec 24 10:24:15 2019
From: report at bugs.python.org (Jasper Spaans)
Date: Tue, 24 Dec 2019 15:24:15 +0000
Subject: [issue39131] signing needs two serialisation passes
Message-ID: <1577201055.68.0.886293230442.issue39131@roundup.psfhosted.org>


New submission from Jasper Spaans <jasper at startmail.com>:

When creating multipart/signed messages, this currently require two serialisation passes: once to extract the flattened contents to be signed, and once to actually serialise the message.

The PR this ticket will be linked to contains a new class, MIMEMultipartSigned, which can be instantiated with a signer function that can perform the signing while serialising, reducing this to only once.

Besides, this ensures that the signed contents cannot changed between signing and outputting.

Patch is against py3.8

----------
components: email
messages: 358849
nosy: barry, jap, r.david.murray
priority: normal
severity: normal
status: open
title: signing needs two serialisation passes
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39131>
_______________________________________

From report at bugs.python.org  Tue Dec 24 10:24:49 2019
From: report at bugs.python.org (Batuhan)
Date: Tue, 24 Dec 2019 15:24:49 +0000
Subject: [issue39132] Adding funcitonality to determine if a constant string
 node is triple quoted
Message-ID: <1577201089.29.0.516911847589.issue39132@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

I was working on a preceding system for AST unparser and @pablogsal said there is an issue with docstrings (they printed in the same line even it was like 1000 chars long). So determining something is a triple quoted or not is simple with preceding system but I think it would be better if we can do it simpler and public. 

What I am thinking is using col_offset and end_col_offset information to determine if a string is a triple quoted or not. With a function called `ast.is_triple_quoted` or `ast.get_quote_count` etc. 

I can submit a patch if this wanted.I dont think this is big enough to discuss it on python-ideas but if it is, then I'm happy to port discussion over there.

----------
components: Library (Lib)
messages: 358850
nosy: BTaskaya, pablogsal
priority: normal
severity: normal
status: open
title: Adding funcitonality to determine if a constant string node is triple quoted
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39132>
_______________________________________

From report at bugs.python.org  Tue Dec 24 10:25:51 2019
From: report at bugs.python.org (Jasper Spaans)
Date: Tue, 24 Dec 2019 15:25:51 +0000
Subject: [issue39131] signing needs two serialisation passes
In-Reply-To: <1577201055.68.0.886293230442.issue39131@roundup.psfhosted.org>
Message-ID: <1577201151.07.0.364470719031.issue39131@roundup.psfhosted.org>


Change by Jasper Spaans <jasper at startmail.com>:


----------
keywords: +patch
pull_requests: +17149
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39131>
_______________________________________

From report at bugs.python.org  Tue Dec 24 12:53:24 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2019 17:53:24 +0000
Subject: [issue39131] signing needs two serialisation passes
In-Reply-To: <1577201055.68.0.886293230442.issue39131@roundup.psfhosted.org>
Message-ID: <1577210004.68.0.850173252048.issue39131@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ideally this should be exposed by extending the content manager.  Instantiating MIME classes is part of the old API, not the new. The code in the PR may well be correct, but class should be hidden from the normal user (of the new API).  I'm not sure what the best way to specify the signing function will be, but I'm guessing a new keyword parameter in the content API.

Note that the current content management API is more of a framework than a fully worked out system, so figuring out the best way to add this may require some design discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39131>
_______________________________________

From report at bugs.python.org  Tue Dec 24 12:54:06 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 Dec 2019 17:54:06 +0000
Subject: [issue39111] Misleading documentation for NotImplemented
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1577210046.55.0.0493276994816.issue39111@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Tue Dec 24 12:59:52 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 Dec 2019 17:59:52 +0000
Subject: [issue34444] Module's __file__ should be absolute always ("." in
 sys.path)
In-Reply-To: <1534784236.56.0.56676864532.issue34444@psf.upfronthosting.co.za>
Message-ID: <1577210392.94.0.980953015135.issue34444@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

So if you were to insert '.' via PYTHONPATH it would be made absolute as the site module makes all entries in sys.path absolute during startup.

And changing this to have to check every time import runs if an entry in sys.path is absolute would be costly (that's not a insignificant number of stat calls which we always try to avoid during import when possible). Your best option is to insert an absolute path to begin with. Also realize that manipulating sys.path is an advanced thing to do and so I don't think asking people to be "consenting adults" and be careful about adding relative paths on sys.path is an unreasonable thing to ask.

So while I appreciate the report, Daniel, and the motivation, I'm closing this as "won't fix" as the overhead of implementing this is too high.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34444>
_______________________________________

From report at bugs.python.org  Tue Dec 24 13:17:11 2019
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2019 18:17:11 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1577211431.66.0.228406852512.issue39040@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see the change to the test in the PR.  Did you miss a push or is github doing something wonky with the review?  (I haven't used github review in a while and I had forgetten how hard it is to use...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Tue Dec 24 13:17:28 2019
From: report at bugs.python.org (Chris Barker)
Date: Tue, 24 Dec 2019 18:17:28 +0000
Subject: [issue39090] Document various options for getting the absolute path
 from pathlib.Path objects
In-Reply-To: <1576693250.66.0.453775762211.issue39090@roundup.psfhosted.org>
Message-ID: <1577211448.33.0.195975094887.issue39090@roundup.psfhosted.org>


Chris Barker <Chris.Barker at noaa.gov> added the comment:

Yes Please!

I'd offer to help, but I really don't get the intricacies involved. I will offer to proofread and copy-edit though, if that's helpful.

And I note that coincidentally, just in the last week, I needed to make an absolute path from a Path, and it took me far too long to figure out that .resolve() would do it for me. Then I needed to do it again three days later, and it again took a while -- "resolve" is simply not mnemonic for me, and I'm guessing a lot of people have the same issue.

And I didn't find .absolute(), cause it's not documented. I see in issue #29688 that there are reasons for that, but I'll make a plea:

Please document .absolute(), even if those docs say something like "may not work in all circumstances, not well tested". Alternatively, if it's decided that folks should just use .resolve() in all cases anyway, then make .absolute() an alias for .resolve(). 

Or if that's not a good option, then at least put some prominent notes in resolve() so people will find it.

Also -- I needed to read the resolve() docs carefully (and then test) to see if it was what I wanted - which I know, is what this issue is about.

In short -- I understand that this is a complex issue, but making an absolute path is a pretty common use case, and we've had os.path.abspath() for decades, so there should be one obvious way to do it, and it should be easily discoverable.

NOTE: even if there is no one to do the work of properly testing .absolute() at this point, it would b nice to at least decide now what the long term goal is -- will there be an absolute() or is resolve() all we really need?

----------
nosy: +ChrisBarker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Tue Dec 24 13:29:34 2019
From: report at bugs.python.org (daniel hahler)
Date: Tue, 24 Dec 2019 18:29:34 +0000
Subject: [issue34444] Module's __file__ should be absolute always ("." in
 sys.path)
In-Reply-To: <1534784236.56.0.56676864532.issue34444@psf.upfronthosting.co.za>
Message-ID: <1577212174.43.0.235131612.issue34444@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

> And changing this to have to check every time import runs if an entry in sys.path is absolute would be costly (that's not a insignificant number of stat calls which we always try to avoid during import when possible).

This could be done when inserting something into `sys.path` maybe then only?
But might only make sense when there is some special handling in that case already though - and would change existing behavior of course.
(Therefore I am OK with rejecting this, but wanted to mention it anyway)

> Your best option is to insert an absolute path to begin with.

That's a good enough option to have anyway, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34444>
_______________________________________

From report at bugs.python.org  Tue Dec 24 13:57:50 2019
From: report at bugs.python.org (Ross Boylan)
Date: Tue, 24 Dec 2019 18:57:50 +0000
Subject: [issue38999] Python launcher on Windows does not detect active venv
In-Reply-To: <1575830943.65.0.538772164668.issue38999@roundup.psfhosted.org>
Message-ID: <1577213870.85.0.485593351352.issue38999@roundup.psfhosted.org>


Ross Boylan <ross.boylan at ucsf.edu> added the comment:

As someone who finds the current behavior surprising, and having lost significant time because of it, I have a couple of comments.

1) If the venv created a python3 (or 2, as appropriate) file, would the expected behavior with !#/usr/bin/env python3 be restored?  I think the previous analysis said that python3 doesn't match the venv because there is no python3 in the venv path.  So putting one there would fix it.  Of course, it would only help for newly created venvs.  The pythonN file would need to be in addition to the python file, not instead of it, so that invocations of python without a number continued to work as expected.

2) There appear to be two separate sections of the documentation which govern this case. 3.7.1.2 of Python Setup and Usage says "If the launcher is run with no explicit Python version specification, and a virtual environment (created with the standard library venv module or the external virtualenv tool) active, the launcher will run the virtual environment?s interpreter rather than the global one. "
If py myscript.py is invoked that seems to fit this case, but obviously that's not what's happening.  I realize one could interpret the python3 in the shebang as an "explicit version specification", but a) that's not on the command line, which seems the more natural reading and b) it's only a partial specification, since it doesn't say which python3 to use.

Then section 3.7.2 is about !# lines.  So if you invoke py without a version specifier, but the invoked file has a !#, does 3.7.1.2 or 3.2 apply?

----------
nosy: +rossb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38999>
_______________________________________

From report at bugs.python.org  Tue Dec 24 14:41:53 2019
From: report at bugs.python.org (Abhilash Raj)
Date: Tue, 24 Dec 2019 19:41:53 +0000
Subject: [issue39040] Wrong attachement filename when mail mime header was too
 long
In-Reply-To: <1576256391.68.0.734335189474.issue39040@roundup.psfhosted.org>
Message-ID: <1577216513.66.0.312758709566.issue39040@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:

I double checked, there should be 4 commits in the PR and last 2 have the changes that you asked for in the test case and NEWS entry.

Your previous comment will point at the old diff, you might have to look at the full diff here: https://github.com/python/cpython/pull/17620/files or if you want, this is the diff for the 2 commits with the changes you requested: https://github.com/python/cpython/pull/17620/files/bf2cb76009d72869d9df6550b473b5818ceab311..016ceb3ef00b3b940993d35d539ce63d68437d4f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39040>
_______________________________________

From report at bugs.python.org  Tue Dec 24 23:42:27 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 25 Dec 2019 04:42:27 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1577248947.57.0.563122482901.issue38753@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8c0f0016e2d39f86589187db75012238c4e760e9 by Miss Islington (bot) in branch '3.8':
bpo-38753: AsyncMock added in version 3.8 (GH-17102)
https://github.com/python/cpython/commit/8c0f0016e2d39f86589187db75012238c4e760e9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Wed Dec 25 01:06:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 25 Dec 2019 06:06:09 +0000
Subject: [issue38753] AsyncMock not cited as new in 3.8
In-Reply-To: <1573282134.53.0.966916153749.issue38753@roundup.psfhosted.org>
Message-ID: <1577253969.01.0.379910195751.issue38753@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks John for the report and patch. Closing it as resolved.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38753>
_______________________________________

From report at bugs.python.org  Wed Dec 25 02:41:22 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 25 Dec 2019 07:41:22 +0000
Subject: [issue39087] [C API] No efficient C API to get UTF-8 string from
 unicode object.
In-Reply-To: <1576671015.48.0.740860223179.issue39087@roundup.psfhosted.org>
Message-ID: <1577259682.38.0.863998143401.issue39087@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> I like this idea, but I think that we should at least notify Python-Dev about all additions to the public C API. If somebody have objections or better idea, it is better to know earlier.

I created a post about this issue in discuss.python.org.
https://discuss.python.org/t/better-api-for-encoding-unicode-objects-with-utf-8/2909

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Wed Dec 25 07:52:17 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 25 Dec 2019 12:52:17 +0000
Subject: [issue39119] email/_header_value_parser.py:parse_message_id:
 UnblondLocalError
In-Reply-To: <1577032518.62.0.64044225834.issue39119@roundup.psfhosted.org>
Message-ID: <1577278337.15.0.492761835865.issue39119@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing it as duplicate. Feel free to reopen if it's reproducible on latest stable release. Thanks.

----------
nosy: +maxking
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> While parsing email message id: UnboundLocalError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39119>
_______________________________________

From report at bugs.python.org  Wed Dec 25 08:14:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 25 Dec 2019 13:14:57 +0000
Subject: [issue38902] image/webp support in mimetypes
In-Reply-To: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>
Message-ID: <1577279697.93.0.390306194853.issue38902@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Similar to previous discussions having an IANA registration would improve the acceptance of the patch to add it. It's still not listed at https://www.iana.org/assignments/media-types/media-types.xhtml

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38902>
_______________________________________

From report at bugs.python.org  Wed Dec 25 08:36:44 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 25 Dec 2019 13:36:44 +0000
Subject: [issue33609] Document that dicts preserve insertion order
In-Reply-To: <1527023250.35.0.682650639539.issue33609@psf.upfronthosting.co.za>
Message-ID: <1577281004.63.0.679704675109.issue33609@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

GH-9807 fixed it.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33609>
_______________________________________

From report at bugs.python.org  Wed Dec 25 08:42:25 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 25 Dec 2019 13:42:25 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1577281345.49.0.491999675804.issue10401@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

This is implemented in #26219.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10401>
_______________________________________

From report at bugs.python.org  Wed Dec 25 08:46:21 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 25 Dec 2019 13:46:21 +0000
Subject: [issue28158] Implement LOAD_GLOBAL opcode cache
In-Reply-To: <1473886080.87.0.000411119678127.issue28158@psf.upfronthosting.co.za>
Message-ID: <1577281581.44.0.0580762398379.issue28158@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

This is implemented in #26219.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28158>
_______________________________________

From report at bugs.python.org  Wed Dec 25 09:08:21 2019
From: report at bugs.python.org (hai shi)
Date: Wed, 25 Dec 2019 14:08:21 +0000
Subject: [issue39106] Add suggestions to argparse error message output for
 unrecognized arguments
In-Reply-To: <1576832169.43.0.680374670537.issue39106@roundup.psfhosted.org>
Message-ID: <1577282901.27.0.600420525871.issue39106@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I checked some other common clis and it is show all right available options too. So I thought the argparse's help function is good enough too ;)

```
$ ps -etest
error: TTY could not be found

Usage:
 ps [options]

 Try 'ps --help <simple|list|output|threads|misc|all>'
  or 'ps --help <s|l|o|t|m|a>'
 for additional help text.

For more details see ps(1).
```

```
$ top test
top: unknown option 't'
Usage:
  top -hv | -bcHiOSs -d secs -n max -u|U user -p pid(s) -o field -w [cols]
```

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39106>
_______________________________________

From report at bugs.python.org  Wed Dec 25 10:05:35 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 25 Dec 2019 15:05:35 +0000
Subject: [issue39106] Add suggestions to argparse error message output for
 unrecognized arguments
In-Reply-To: <1576832169.43.0.680374670537.issue39106@roundup.psfhosted.org>
Message-ID: <1577286335.81.0.636618518487.issue39106@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the feedback. Closing it as rejected.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39106>
_______________________________________

From report at bugs.python.org  Wed Dec 25 10:40:39 2019
From: report at bugs.python.org (Batuhan)
Date: Wed, 25 Dec 2019 15:40:39 +0000
Subject: [issue30427] isinstance checks in os.path.normcase redundant with
 os.fspath
In-Reply-To: <1495441077.08.0.893428733741.issue30427@psf.upfronthosting.co.za>
Message-ID: <1577288439.18.0.486796530658.issue30427@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Looks like there is nothing left after PR 1712 if I am not missing something, can this issue be closed?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30427>
_______________________________________

From report at bugs.python.org  Wed Dec 25 10:43:58 2019
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 25 Dec 2019 15:43:58 +0000
Subject: [issue37509] OSError preadv()
In-Reply-To: <1562349039.72.0.211859672318.issue37509@roundup.psfhosted.org>
Message-ID: <1577288638.3.0.196051848488.issue37509@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

I am closing this topic as its right for python to raise OSError as `-errno` must be assigned to e.g. `OSError(-errno, os.strerror(-errno))` to raise appropriate exception.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37509>
_______________________________________

From report at bugs.python.org  Wed Dec 25 11:16:33 2019
From: report at bugs.python.org (Batuhan)
Date: Wed, 25 Dec 2019 16:16:33 +0000
Subject: [issue30364] Outdated function attribute to disable address sanitizer
In-Reply-To: <1494772854.72.0.607120887618.issue30364@psf.upfronthosting.co.za>
Message-ID: <1577290593.3.0.780264966338.issue30364@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17151
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17702

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30364>
_______________________________________

From report at bugs.python.org  Wed Dec 25 12:41:25 2019
From: report at bugs.python.org (Abhijeet)
Date: Wed, 25 Dec 2019 17:41:25 +0000
Subject: [issue39133] threading lib. working improperly on idle window
Message-ID: <1577295685.26.0.995462727475.issue39133@roundup.psfhosted.org>


New submission from Abhijeet <parrotabhijeet at gmail.com>:

Threading library's Thread and start functions not showing predicted result on idle. Especially, newline is not invoked between two threads while sometimes gets invoked in result. Often, running of code stops after thread ends i.e no further execution. Version - 3.8.0 exe installer

----------
assignee: terry.reedy
components: IDLE
messages: 358870
nosy: Pyjeet, terry.reedy
priority: normal
severity: normal
status: open
title: threading lib. working improperly on idle window
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39133>
_______________________________________

From report at bugs.python.org  Wed Dec 25 16:03:02 2019
From: report at bugs.python.org (Roy Smith)
Date: Wed, 25 Dec 2019 21:03:02 +0000
Subject: [issue16399] argparse: append action with default list adds to list
 instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1577307782.22.0.598043107084.issue16399@roundup.psfhosted.org>


Roy Smith <roy at panix.com> added the comment:

I just got bit by this in Python 3.5.3.

I get why it does this.  I also get why it's impractical to change the behavior now.  But, it really isn't the obvious behavior, so it should be documented at https://docs.python.org/3.5/library/argparse.html?highlight=argparse#default.

----------
nosy: +roysmith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16399>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:01:16 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Dec 2019 22:01:16 +0000
Subject: [issue39133] threading lib. working improperly on idle window
In-Reply-To: <1577295685.26.0.995462727475.issue39133@roundup.psfhosted.org>
Message-ID: <1577311276.53.0.653651004582.issue39133@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Give OS.  Provide specific code and describe specific problem.  Run the code directly with python from a command line to determine if IDLE is really involved in the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39133>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:45:42 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 25 Dec 2019 22:45:42 +0000
Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass
 documentation
In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za>
Message-ID: <1577313942.66.0.458975896312.issue33961@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset e28aff54d95236ea1b64b648d89a1516e446e621 by Eric V. Smith (Fabio Sangiovanni) in branch 'master':
bpo-33961: Adjusted dataclasses docs to correct exceptions raised. (GH-7917) (GH-17677)
https://github.com/python/cpython/commit/e28aff54d95236ea1b64b648d89a1516e446e621


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33961>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:45:43 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 25 Dec 2019 22:45:43 +0000
Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass
 documentation
In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za>
Message-ID: <1577313943.02.0.905832450066.issue33961@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17152
pull_request: https://github.com/python/cpython/pull/17705

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33961>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:51:27 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 25 Dec 2019 22:51:27 +0000
Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass
 documentation
In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za>
Message-ID: <1577314287.3.0.823673979527.issue33961@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a5deabd8e43a76bf2d7923342b6c4395c1a5efcd by Miss Islington (bot) in branch '3.8':
bpo-33961: Adjusted dataclasses docs to correct exceptions raised. (GH-7917) (GH-17677)
https://github.com/python/cpython/commit/a5deabd8e43a76bf2d7923342b6c4395c1a5efcd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33961>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:53:17 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 25 Dec 2019 22:53:17 +0000
Subject: [issue33961] Inconsistency in exceptions for dataclasses.dataclass
 documentation
In-Reply-To: <1529963695.74.0.56676864532.issue33961@psf.upfronthosting.co.za>
Message-ID: <1577314397.78.0.784697166042.issue33961@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks, all!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33961>
_______________________________________

From report at bugs.python.org  Wed Dec 25 19:05:40 2019
From: report at bugs.python.org (Alexander Hirner)
Date: Thu, 26 Dec 2019 00:05:40 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
Message-ID: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>


New submission from Alexander Hirner <a.hirner at gmail.com>:

At runtime, we want to check whether objects adhere to a data protocol. This is not possible due to problematic interactions between ABC and @dataclass.

The attached file tests all relevant yet impossible cases. Those are:

1) A(object): Can't check due to "Protocols with non-method members don't support issubclass()" (as outlined in PEP 554)
2) B(ABC): "Can't instantiate abstract class B with abstract methods x, y"
3) C(Protocol): same as A or same as B if @property is @abstractmethod

The problem can be solved in two parts. First allowing to implement @abstractproperty in a dataclass (B). This doesn't involve typing and enables the expected use case of dataclass+ABC. I analysed this problem as follows:
Abstract properties evaluate to a default of property, not to dataclasses.MISSING. Hence, `dataclasses._init_fn` throws TypeError because of deriving from class vars without defaults.

Second, eliding the exception of @runtime_checkable Protocols with non-method members if and only if the the the protocol is in its MRO. I didn't think that through fully, but instantiation could e.g. fail for missing implementations as expected from ABC behaviour (see case D in attached file). I'm not sure about the runtime overhead of this suggestion.

----------
files: dc_repro.py
messages: 358876
nosy: cybertreiber, eric.smith
priority: normal
severity: normal
status: open
title: can't construct dataclass as ABC (or runtime check as data protocol)
type: behavior
versions: Python 3.6, Python 3.8
Added file: https://bugs.python.org/file48802/dc_repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Thu Dec 26 01:09:39 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 26 Dec 2019 06:09:39 +0000
Subject: [issue39132] Adding funcitonality to determine if a constant string
 node is triple quoted
In-Reply-To: <1577201089.29.0.516911847589.issue39132@roundup.psfhosted.org>
Message-ID: <1577340579.66.0.928230995161.issue39132@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I'm not sure the usage should be covered by "Abstract" syntax tree.

Isn't it a "Concrete" syntax tree?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39132>
_______________________________________

From report at bugs.python.org  Thu Dec 26 02:03:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2019 07:03:29 +0000
Subject: [issue39132] Adding funcitonality to determine if a constant string
 node is triple quoted
In-Reply-To: <1577201089.29.0.516911847589.issue39132@roundup.psfhosted.org>
Message-ID: <1577343809.91.0.345595108675.issue39132@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is impossible because of using newline escaping and string literal concatenation. In the following examples 
lineno != end_lineno, but strings use single quotes:

    print('Hello '
          'world!')

    print('Hello\
 world!')

Triple quotes can be also used for strings which occupy a single line of code and do not contain \n:

    print("""exec("print('Hi!')")""")

We cannot also distinguish 1234 from 0x4_d2 and 1234.0 from 1.234e3 at the AST level.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39132>
_______________________________________

From report at bugs.python.org  Thu Dec 26 02:12:12 2019
From: report at bugs.python.org (Michael Wayne Goodman)
Date: Thu, 26 Dec 2019 07:12:12 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
Message-ID: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>


New submission from Michael Wayne Goodman <goodman.m.w at gmail.com>:

The documentation for Python 3.8 and higher still refer to 'clock' as an accepted 'name' argument for time.get_clock_info() that returns a namespace readable by time.clock(), despite time.clock() being removed since Python 3.8.

See the first bullet point in the function documentation: https://docs.python.org/3.8/library/time.html#time.get_clock_info

In Python 3.8, calling time.get_clock_info('clock') raises "ValueError: unknown clock", so it seems the bug is only in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 358879
nosy: docs at python, goodmami
priority: normal
severity: normal
status: open
title: time.get_clock_info() documentation still has 'clock' name
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 02:42:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 26 Dec 2019 07:42:46 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
In-Reply-To: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>
Message-ID: <1577346166.95.0.22507357617.issue39135@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Would you like to propose a PR? The relevant file is at https://github.com/python/cpython/blob/master/Doc/library/time.rst .

----------
keywords: +easy, newcomer friendly
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 03:06:55 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 26 Dec 2019 08:06:55 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577347615.43.0.959596439893.issue39134@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Is dataclasses doing something here that a regular, hand-written class wouldn't do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Thu Dec 26 03:20:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 26 Dec 2019 08:20:03 +0000
Subject: [issue39136] Typos in whatsnew file and docs
Message-ID: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Based on https://github.com/python/cpython/pull/17665#pullrequestreview-335610849 . Grepping for the words might help fix in multiple instances of the typos.

Typos in Whatsnew document

asolute -> absolute
happend -> happened
Excape -> Escape

Doc typos : 

defintitions -> definitions
follwing -> following
necesarily -> necessarily
configuraton -> configuration
focusses -> focuses
funtion -> function

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 358882
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Typos in whatsnew file and docs
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Thu Dec 26 03:45:03 2019
From: report at bugs.python.org (Michael Wayne Goodman)
Date: Thu, 26 Dec 2019 08:45:03 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
In-Reply-To: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>
Message-ID: <1577349903.4.0.278671040179.issue39135@roundup.psfhosted.org>


Michael Wayne Goodman <goodman.m.w at gmail.com> added the comment:

Sure, no problem. I've just signed the CLA and forked the code. I'll wait a day for the CLA check to clear then submit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 05:35:37 2019
From: report at bugs.python.org (Alexander Hirner)
Date: Thu, 26 Dec 2019 10:35:37 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577356537.3.0.222573055351.issue39134@roundup.psfhosted.org>


Alexander Hirner <a.hirner at gmail.com> added the comment:

Here, nothing but less boiler plate. 

Wouldn't it pay off to not rewrite dataclass features like frozen, replace, runtime refelection and the ability to use dataclass aware serialization libraries (e.g. pydantic)? I think @dataclass+ at abstractproperty behaviour is yet to be defined.

The second part about subclass check is not specific to dataclasses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Thu Dec 26 05:54:39 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 26 Dec 2019 10:54:39 +0000
Subject: [issue39137] create_unicode_buffer() gives different results on
 Windows vs Linux
Message-ID: <1577357679.73.0.864612617674.issue39137@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

>>> len(ctypes.create_unicode_buffer("\ud800\udc01", 2)[:])

On Windows: 1
On Linux: 2

Using Python 3.8 on both.

----------
components: ctypes
messages: 358885
nosy: lazka
priority: normal
severity: normal
status: open
title: create_unicode_buffer() gives different results on Windows vs Linux
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39137>
_______________________________________

From report at bugs.python.org  Thu Dec 26 06:14:01 2019
From: report at bugs.python.org (Yorkie Liu)
Date: Thu, 26 Dec 2019 11:14:01 +0000
Subject: [issue39138] import a pycapsule object that's attached on many modules
Message-ID: <1577358841.1.0.469176020389.issue39138@roundup.psfhosted.org>


New submission from Yorkie Liu <yorkiefixer at gmail.com>:

Current PyCapsule's name is corresponding to the `modulename.attrname`, which requires it could be imported in the specified module.

And it's possible to implement a feature which shares the same capsule object between different modules, and supports importing them like this:

```
PyCapsule* cap = PyCapsule_New("foobar");
PyObject_SetAttrString(module1, cap->name);
PyObject_SetAttrString(module2, cap->name);

PyCapsule_Import("module1.foobar", 0);
PyCapsule_Import("module2.foobar", 0);
```

----------
components: C API
messages: 358886
nosy: yorkie
priority: normal
severity: normal
status: open
title: import a pycapsule object that's attached on many modules
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39138>
_______________________________________

From report at bugs.python.org  Thu Dec 26 06:25:05 2019
From: report at bugs.python.org (Yorkie Liu)
Date: Thu, 26 Dec 2019 11:25:05 +0000
Subject: [issue39138] import a pycapsule object that's attached on many modules
In-Reply-To: <1577358841.1.0.469176020389.issue39138@roundup.psfhosted.org>
Message-ID: <1577359505.03.0.0054873610685.issue39138@roundup.psfhosted.org>


Yorkie Liu <yorkiefixer at gmail.com> added the comment:

Update the example:

```
PyCapsule* cap = PyCapsule_New("foobar");
PyObject_SetAttrString(module1, cap->name, cap);
PyObject_SetAttrString(module2, cap->name, cap);

PyCapsule_Import("module1.foobar", 0);
PyCapsule_Import("module2.foobar", 0);
```

----------
resolution:  -> remind

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39138>
_______________________________________

From report at bugs.python.org  Thu Dec 26 10:51:52 2019
From: report at bugs.python.org (Batuhan)
Date: Thu, 26 Dec 2019 15:51:52 +0000
Subject: [issue39132] Adding funcitonality to determine if a constant string
 node is triple quoted
In-Reply-To: <1577201089.29.0.516911847589.issue39132@roundup.psfhosted.org>
Message-ID: <1577375512.75.0.21533983236.issue39132@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@inada.naoki I thought that would be a nice to have feature in certain cases AST used but as @serhiy.storchaka said there is an issue with implicit string concatenation which makes this impossible to expose. Thank you both.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39132>
_______________________________________

From report at bugs.python.org  Thu Dec 26 11:44:22 2019
From: report at bugs.python.org (Khalid Mammadov)
Date: Thu, 26 Dec 2019 16:44:22 +0000
Subject: [issue39139] Reference to depricated collections.abc class in
 collections is unnecessary and confusing
Message-ID: <1577378662.65.0.232984196995.issue39139@roundup.psfhosted.org>


New submission from Khalid Mammadov <khalidmammadov9 at gmail.com>:

"Deprecated since version 3.3, will be removed in version 3.9: Moved Collections Abstract Base Classes to the collections.abc module. For backwards compatibility, they continue to be visible in this module through Python 3.8." on the overview is confusing as it's not listed on that page and explained on the next one.

----------
assignee: docs at python
components: Documentation
messages: 358889
nosy: docs at python, khalidmammadov
priority: normal
severity: normal
status: open
title: Reference to depricated collections.abc class in collections is unnecessary and confusing
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39139>
_______________________________________

From report at bugs.python.org  Thu Dec 26 11:50:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 26 Dec 2019 16:50:00 +0000
Subject: [issue39139] Reference to depricated collections.abc class in
 collections is unnecessary and confusing
In-Reply-To: <1577378662.65.0.232984196995.issue39139@roundup.psfhosted.org>
Message-ID: <1577379000.88.0.627266547457.issue39139@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It can be updated since issue25988 removed the deprecation in Python 3.9.

----------
nosy: +rhettinger, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39139>
_______________________________________

From report at bugs.python.org  Thu Dec 26 15:33:56 2019
From: report at bugs.python.org (Khalid Mammadov)
Date: Thu, 26 Dec 2019 20:33:56 +0000
Subject: [issue39139] Reference to depricated collections.abc class in
 collections is unnecessary and confusing
In-Reply-To: <1577378662.65.0.232984196995.issue39139@roundup.psfhosted.org>
Message-ID: <1577392436.77.0.249428040867.issue39139@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
keywords: +patch
pull_requests: +17153
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17707

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39139>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:55:44 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 26 Dec 2019 21:55:44 +0000
Subject: [issue39102] Increase Enum performance
In-Reply-To: <1576810108.88.0.911071266859.issue39102@roundup.psfhosted.org>
Message-ID: <1577397344.01.0.31712109628.issue39102@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39102>
_______________________________________

From report at bugs.python.org  Thu Dec 26 18:39:08 2019
From: report at bugs.python.org (Luca Paganin)
Date: Thu, 26 Dec 2019 23:39:08 +0000
Subject: [issue39140] shutil.move does not work properly with pathlib.Path
 objects
Message-ID: <1577403548.05.0.784515319719.issue39140@roundup.psfhosted.org>


New submission from Luca Paganin <lucap265 at gmail.com>:

Suppose you have two pathlib objects representing source and destination of a move:

src=pathlib.Path("foo/bar/barbar/myfile.txt")
dst=pathlib.Path("foodst/bardst/")

If you try to do the following

shutil.move(src, dst)

Then an AttributeError will be raised, saying that PosixPath objects do not have an rstrip attribute. The error is the following:

Traceback (most recent call last):
  File "mover.py", line 10, in <module>
    shutil.move(src, dst)
  File "/Users/lucapaganin/opt/anaconda3/lib/python3.7/shutil.py", line 562, in move
    real_dst = os.path.join(dst, _basename(src))
  File "/Users/lucapaganin/opt/anaconda3/lib/python3.7/shutil.py", line 526, in _basename
    return os.path.basename(path.rstrip(sep))
AttributeError: 'PosixPath' object has no attribute 'rstrip'

Looking into shutil code, line 526, I see that the problem happens when you try to strip the trailing slash using rstrip, which is a method for strings, while PosixPath objects do not have it. Moreover, pathlib.Path objects already manage for trailing slashes, correctly getting basenames even when these are present.
The following two workarounds work:

1) Explicit cast both src and dst as string using

shutil.move(str(src), str(dst))

This work for both the cases in which dst contains the destination filename or not.

2) Add the filename to the end of the PosixPath dst object:

dst=pathlib.Path("foodst/bardst/myfile.txt")

Then do 

shutil.move(src, dst)

Surely one could use the method pathlib.Path.replace for PosixPath objects, which does the job without problems, even if it requires for dst to contain the destination filename at the end, and lacks generality, since it bugs when one tries to move files between different filesystems. 
I think that you should account for the possibility for shutil.move to manage pathlib.Path objects even if one does not provide the destination filename, since the source of the bug is due to a safety measure which is not necessary for pathlib.Path objects, i.e. the managing of the trailing slash.
Do you think that is possible? Thank you in advance.

Luca Paganin

P.S.: I attach a tarball with the dirtree I used for the demonstration.

----------
files: mover.tgz
messages: 358891
nosy: Luca Paganin
priority: normal
severity: normal
status: open
title: shutil.move does not work properly with pathlib.Path objects
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48803/mover.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39140>
_______________________________________

From report at bugs.python.org  Thu Dec 26 18:46:13 2019
From: report at bugs.python.org (Sebastien Luttringer)
Date: Thu, 26 Dec 2019 23:46:13 +0000
Subject: [issue29750] smtplib doesn't handle unicode passwords
In-Reply-To: <1488919224.48.0.0966376973087.issue29750@psf.upfronthosting.co.za>
Message-ID: <1577403973.8.0.175944146593.issue29750@roundup.psfhosted.org>


Sebastien Luttringer <seblu+python at seblu.net> added the comment:

Utf8 passwords are still broken on python 3.8.

Patch works great on 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29750>
_______________________________________

From report at bugs.python.org  Thu Dec 26 19:58:53 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 Dec 2019 00:58:53 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577408333.66.0.72509134589.issue39134@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

1. PEP 554 is about multiple interpreters. Which PEP did you mean?

2. The double negative in ?Wouldn't it pay off to not rewrite dataclass features? is confusing. What did you mean?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:13:47 2019
From: report at bugs.python.org (Michael Wayne Goodman)
Date: Fri, 27 Dec 2019 02:13:47 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
In-Reply-To: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>
Message-ID: <1577412827.26.0.528116771255.issue39135@roundup.psfhosted.org>


Change by Michael Wayne Goodman <goodman.m.w at gmail.com>:


----------
keywords: +patch
pull_requests: +17154
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17709

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:14:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 27 Dec 2019 02:14:11 +0000
Subject: [issue39140] shutil.move does not work properly with pathlib.Path
 objects
In-Reply-To: <1577403548.05.0.784515319719.issue39140@roundup.psfhosted.org>
Message-ID: <1577412851.39.0.216304507102.issue39140@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a duplicate of https://bugs.python.org/issue32689 that is fixed in 3.9 . Using os.fspath on path object is more correct here instead of str so that objects with both __str__ and __fspath__ implemented are handled properly.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39140>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:19:03 2019
From: report at bugs.python.org (Noah Massman-Hall)
Date: Fri, 27 Dec 2019 02:19:03 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1577413143.38.0.597197248399.issue22593@roundup.psfhosted.org>


Noah Massman-Hall <noah.massman at gmail.com> added the comment:

I took a crack at the rst side of this, to see if I could reduce it to just one easy to parse for line in each file that needs to be modified.

Yeah, not so easy.

Substituting text in rst isn't hard, you just insert '|ucd_version|' where the version string should go and then include the following line somewhere below.

.. |ucd_version| replace:: 12.1.0

The problem is that I cant find any combination that makes this work for substituting the version string inside of a hyperlink. I've tried multiple combinations and every time the hyperlink gets broken.

So this, inside Doc/library/stdtypes.rst:

See http://www.unicode.org/Public/\ |ucd_version|\ /ucd/extracted/DerivedNumericType.txt

Becomes this in the html:

See <a class="reference external" href="http://www.unicode.org/Public/">http://www.unicode.org/Public/</a>12.1.0/ucd/extracted/DerivedNumericType.txt

It does in fact do the substitution, but the substituted text onward doesn't get included in the hyperlink.

It gets worse if you try to hyperlink text instead of just the url.

In Doc/library/unicodedata.rst I tried this:

compiled from the |ucd_link|_.

.. |ucd_link| replace:: UCD version |ucd_version|
.. _ucd_link: http://www.unicode.org/Public/|ucd_version|/ucd

and got:

compiled from the <a class="reference external" href="http://www.unicode.org/Public/|ucd_version|/ucd">UCD version 12.1.0</a>

The sub inside a sub works fine, but no combination I tried could get it to work in the hyperlink itself.

Near as I can tell, the only way to accomplish this would require adding or possibly creating a plugin for sphinx.

----------
nosy: +nmassman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:24:56 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 27 Dec 2019 02:24:56 +0000
Subject: [issue20066] PyStructSequence_NewType() not setting proper heap
 allocation flag?
In-Reply-To: <1387978399.6.0.58819819413.issue20066@psf.upfronthosting.co.za>
Message-ID: <1577413496.83.0.432653285493.issue20066@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Thanks @nanjekyejoannah for comment.

Yes, I found that the codes are updated.
see https://github.com/python/cpython/blob/bd44a7ead9f7336d7bb45f186b2b6ca0300154f7/Objects/structseq.c#L488

I close this issue.

----------
nosy: +corona10
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20066>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:42:49 2019
From: report at bugs.python.org (Noah Massman-Hall)
Date: Fri, 27 Dec 2019 02:42:49 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1577414569.66.0.905614661564.issue22593@roundup.psfhosted.org>


Change by Noah Massman-Hall <noah.massman at gmail.com>:


----------
keywords: +patch
pull_requests: +17155
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17710

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:48:31 2019
From: report at bugs.python.org (Noah Massman-Hall)
Date: Fri, 27 Dec 2019 02:48:31 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1577414911.54.0.44930329954.issue22593@roundup.psfhosted.org>


Change by Noah Massman-Hall <noah.massman at gmail.com>:


----------
pull_requests:  -17155

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:51:45 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Dec 2019 02:51:45 +0000
Subject: [issue30364] Outdated function attribute to disable address sanitizer
In-Reply-To: <1494772854.72.0.607120887618.issue30364@psf.upfronthosting.co.za>
Message-ID: <1577415105.94.0.149917297195.issue30364@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset c0052f3fe3d19820b2d4f76e383035439affe32c by Benjamin Peterson (Batuhan Ta?kaya) in branch 'master':
closes bpo-30364: Replace deprecated no_address_safety_analysis attribute. (GH-17702)
https://github.com/python/cpython/commit/c0052f3fe3d19820b2d4f76e383035439affe32c


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30364>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:52:01 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 27 Dec 2019 02:52:01 +0000
Subject: [issue30364] Outdated function attribute to disable address sanitizer
In-Reply-To: <1494772854.72.0.607120887618.issue30364@psf.upfronthosting.co.za>
Message-ID: <1577415121.05.0.397608141898.issue30364@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17156
pull_request: https://github.com/python/cpython/pull/17711

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30364>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:52:07 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 27 Dec 2019 02:52:07 +0000
Subject: [issue30364] Outdated function attribute to disable address sanitizer
In-Reply-To: <1494772854.72.0.607120887618.issue30364@psf.upfronthosting.co.za>
Message-ID: <1577415127.04.0.943513196749.issue30364@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17157
pull_request: https://github.com/python/cpython/pull/17712

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30364>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:01:15 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Dec 2019 03:01:15 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
In-Reply-To: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>
Message-ID: <1577415675.32.0.353009817696.issue39135@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 91874bb07161bb481b6f5ea18ffafe69cb8cac30 by Benjamin Peterson (Michael Wayne Goodman) in branch 'master':
closes bpo-39135: Remove 'time.clock()' mention in docs. (GH17709)
https://github.com/python/cpython/commit/91874bb07161bb481b6f5ea18ffafe69cb8cac30


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:02:10 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Dec 2019 03:02:10 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
In-Reply-To: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>
Message-ID: <1577415730.35.0.491712042945.issue39135@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +17158
pull_request: https://github.com/python/cpython/pull/17713

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:07:27 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 Dec 2019 03:07:27 +0000
Subject: [issue39135] time.get_clock_info() documentation still has 'clock'
 name
In-Reply-To: <1577344332.83.0.812432046246.issue39135@roundup.psfhosted.org>
Message-ID: <1577416047.18.0.141717514255.issue39135@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset b9b92d34646d6a1fca120f98476912f5e4ca7f34 by Benjamin Peterson in branch '3.8':
[3.8] closes bpo-39135: Remove 'time.clock()' mention in docs. (GH-17713)
https://github.com/python/cpython/commit/b9b92d34646d6a1fca120f98476912f5e4ca7f34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39135>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:08:34 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 27 Dec 2019 03:08:34 +0000
Subject: [issue30364] Outdated function attribute to disable address sanitizer
In-Reply-To: <1494772854.72.0.607120887618.issue30364@psf.upfronthosting.co.za>
Message-ID: <1577416114.02.0.505471837853.issue30364@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5641b6d3115f1c2700d2f84216710d3778a23d02 by Miss Islington (bot) in branch '3.7':
closes bpo-30364: Replace deprecated no_address_safety_analysis attribute. (GH-17702)
https://github.com/python/cpython/commit/5641b6d3115f1c2700d2f84216710d3778a23d02


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30364>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:10:55 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 27 Dec 2019 03:10:55 +0000
Subject: [issue30364] Outdated function attribute to disable address sanitizer
In-Reply-To: <1494772854.72.0.607120887618.issue30364@psf.upfronthosting.co.za>
Message-ID: <1577416255.81.0.892698044374.issue30364@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5dd1909680a5be76397b19bc235a8205b79787c7 by Miss Islington (bot) in branch '3.8':
closes bpo-30364: Replace deprecated no_address_safety_analysis attribute. (GH-17702)
https://github.com/python/cpython/commit/5dd1909680a5be76397b19bc235a8205b79787c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30364>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:13:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 27 Dec 2019 03:13:08 +0000
Subject: [issue39140] shutil.move does not work properly with pathlib.Path
 objects
In-Reply-To: <1577403548.05.0.784515319719.issue39140@roundup.psfhosted.org>
Message-ID: <1577416388.94.0.283091060568.issue39140@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39140>
_______________________________________

From report at bugs.python.org  Fri Dec 27 02:19:29 2019
From: report at bugs.python.org (Lee Ball)
Date: Fri, 27 Dec 2019 07:19:29 +0000
Subject: [issue38902] image/webp support in mimetypes
In-Reply-To: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>
Message-ID: <1577431169.27.0.0538318495481.issue38902@roundup.psfhosted.org>


Lee Ball <lee.cat.ball at gmail.com> added the comment:

Okay, I've opened a bug with WebP team regarding IANA registration: https://bugs.chromium.org/p/webp/issues/detail?id=448

For what its worth, WebM was added without an IANA registration as a de facto standard. Approval was given in this 2014 comment: https://bugs.python.org/issue16329

To help support the recognition of WebP as a de facto standard, the image format is currently seeing about the same amount of usage on the web as BMP images, and has seen sharp growth this year, approximately tripling in usage. Data from W3: https://w3techs.com/technologies/details/im-webp

Please let me know if there's any data I can provide, or anyone specific I should contact regarding approval.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38902>
_______________________________________

From report at bugs.python.org  Fri Dec 27 02:20:47 2019
From: report at bugs.python.org (Lee Ball)
Date: Fri, 27 Dec 2019 07:20:47 +0000
Subject: [issue38902] image/webp support in mimetypes
In-Reply-To: <1574548382.26.0.67471558876.issue38902@roundup.psfhosted.org>
Message-ID: <1577431247.55.0.0192597418203.issue38902@roundup.psfhosted.org>


Lee Ball <lee.cat.ball at gmail.com> added the comment:

Sorry, amendment to my last comment: the WebM approval without IANA registration was in msg232095 of https://bugs.python.org/issue16329

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38902>
_______________________________________

From report at bugs.python.org  Fri Dec 27 08:31:14 2019
From: report at bugs.python.org (Alexander Hirner)
Date: Fri, 27 Dec 2019 13:31:14 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577453474.23.0.693175836693.issue39134@roundup.psfhosted.org>


Alexander Hirner <a.hirner at gmail.com> added the comment:

Pardon my sloppiness. 

1. That should have been PEP 544. The last point referred to the notion of data protocols [0].

2. I think solving this issue for dataclasses would ensure better composition with modern libraries and other idioms like Protocol and ABC.


[0] https://www.python.org/dev/peps/pep-0544/#runtime-checkable-decorator-and-narrowing-types-by-isinstance

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Fri Dec 27 09:15:12 2019
From: report at bugs.python.org (Evandro Coan)
Date: Fri, 27 Dec 2019 14:15:12 +0000
Subject: [issue33165] Add stacklevel parameter to logging APIs
In-Reply-To: <1522227921.35.0.467229070634.issue33165@psf.upfronthosting.co.za>
Message-ID: <1577456112.2.0.95916120426.issue33165@roundup.psfhosted.org>


Change by Evandro Coan <evandrocoan at hotmail.com>:


----------
pull_requests: +17159
pull_request: https://github.com/python/cpython/pull/17714

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33165>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:24:04 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 16:24:04 +0000
Subject: [issue38131] compile(mode='eval') uninformative error message
In-Reply-To: <1568283719.06.0.851695472479.issue38131@roundup.psfhosted.org>
Message-ID: <1577463844.85.0.596109405516.issue38131@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17160
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17715

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38131>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:24:27 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 16:24:27 +0000
Subject: [issue38131] compile(mode='eval') uninformative error message
In-Reply-To: <1568283719.06.0.851695472479.issue38131@roundup.psfhosted.org>
Message-ID: <1577463867.19.0.728143281008.issue38131@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
components: +Interpreter Core -Library (Lib)
nosy: +BTaskaya
versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38131>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:27:01 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 16:27:01 +0000
Subject: [issue38131] compile(mode='eval') uninformative error message
In-Reply-To: <1568283719.06.0.851695472479.issue38131@roundup.psfhosted.org>
Message-ID: <1577464021.34.0.556039824622.issue38131@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

with PR 17715 

>>> import ast
>>> expr_without_lineno_but_ok = ast.Expression(body=ast.BinOp(left=ast.Num(n=2), right=ast.Num(n=2), op=ast.Add()))
>>> expr_with_lineno_but_with_wrong_body = ast.Expression(body=[ast.BinOp(left=ast.Num(n=2), right=ast.Num(n=2), op=ast.Add())])
>>> ast.fix_missing_locations(expr_with_lineno_but_with_wrong_body)
>>> compile(expr_without_lineno_but_ok, "<temp>", "eval")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: required field "lineno" missing from expr
>>> compile(expr_with_lineno_but_with_wrong_body, "<temp>", "eval")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected some sort of expr, but got [<_ast.BinOp object at 0x7f3f57dc4c80>]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38131>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:49:56 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 Dec 2019 16:49:56 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577465396.73.0.836717906162.issue39134@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks. Can you be specific about ?modern libraries?? Please clarify your use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Fri Dec 27 12:20:17 2019
From: report at bugs.python.org (Antonin Rousset)
Date: Fri, 27 Dec 2019 17:20:17 +0000
Subject: [issue39032] wait_for and Condition.wait still not playing nicely
In-Reply-To: <1576188707.28.0.976402286233.issue39032@roundup.psfhosted.org>
Message-ID: <1577467217.83.0.0253490445392.issue39032@roundup.psfhosted.org>


Change by Antonin Rousset <Antonin at rousset.com>:


----------
nosy: +Antonin Rousset

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39032>
_______________________________________

From report at bugs.python.org  Fri Dec 27 12:55:02 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 17:55:02 +0000
Subject: [issue35143] `from __future__ import annotations` has no effect
 inside `ast.parse`
In-Reply-To: <1541147333.05.0.788709270274.issue35143@psf.upfronthosting.co.za>
Message-ID: <1577469302.77.0.313321109477.issue35143@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> Having a real "ast.unparse" would be better however. It seems that the building blocks are all there, just not in that form.

Now we have that :) https://docs.python.org/3.9/whatsnew/3.9.html#improved-modules

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35143>
_______________________________________

From report at bugs.python.org  Fri Dec 27 13:15:59 2019
From: report at bugs.python.org (David Turner)
Date: Fri, 27 Dec 2019 18:15:59 +0000
Subject: [issue39141] IDLE Clear function returns 256 on Mac OS Catalina
Message-ID: <1577470559.68.0.805755696987.issue39141@roundup.psfhosted.org>


New submission from David Turner <twister68 at gmail.com>:

Trying to set up shortcut function to clear screen but its not working as expected on my Mac OS Catalina -- below is txt from idle



import os
>>> cls= lambda: os.system('clear')
>>> cls()
256

----------
messages: 358908
nosy: twister68 at gmail.com
priority: normal
severity: normal
status: open
title: IDLE Clear function returns 256 on Mac OS Catalina
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39141>
_______________________________________

From report at bugs.python.org  Fri Dec 27 13:23:29 2019
From: report at bugs.python.org (Michel Desmoulin)
Date: Fri, 27 Dec 2019 18:23:29 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1577471009.39.0.983600827864.issue33944@roundup.psfhosted.org>


Michel Desmoulin <desmoulinmichel at gmail.com> added the comment:

Can usercustomize.py be used as an alternative to "*.pth" execution magic ?

----------
nosy: +Michel Desmoulin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Fri Dec 27 13:53:54 2019
From: report at bugs.python.org (Tzu-ping Chung)
Date: Fri, 27 Dec 2019 18:53:54 +0000
Subject: [issue38671] pathlib.Path.resolve(strict=False) returns relative path
 on Windows if the entry does not exist
In-Reply-To: <1572774931.11.0.993470333259.issue38671@roundup.psfhosted.org>
Message-ID: <1577472834.55.0.0376262255381.issue38671@roundup.psfhosted.org>


Change by Tzu-ping Chung <uranusjr at gmail.com>:


----------
keywords: +patch
pull_requests: +17161
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17716

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38671>
_______________________________________

From report at bugs.python.org  Fri Dec 27 14:07:14 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 Dec 2019 19:07:14 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1577473634.43.0.101968393822.issue26219@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/issue26219>
_______________________________________

From report at bugs.python.org  Fri Dec 27 14:47:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 27 Dec 2019 19:47:57 +0000
Subject: [issue39141] IDLE Clear function returns 256 on Mac OS Catalina
In-Reply-To: <1577470559.68.0.805755696987.issue39141@roundup.psfhosted.org>
Message-ID: <1577476077.88.0.39954030098.issue39141@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39141>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:05:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 27 Dec 2019 20:05:11 +0000
Subject: [issue35143] `from __future__ import annotations` has no effect
 inside `ast.parse`
In-Reply-To: <1541147333.05.0.788709270274.issue35143@psf.upfronthosting.co.za>
Message-ID: <1577477111.27.0.841301137307.issue35143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I don't think this is a bug. Technically the 'from __future__ import annotations' is a compiler option, not an AST one. Also, the flag says that "annotations become strings at runtime" and at the point, we have an AST is not still runtime. The CO_FUTURE_ANNOTATIONS only takes place in the compiler that reverses the AST object into a string. If we make the AST aware of CO_FUTURE_ANNOTATIONS, then what the compiler will see in the presence of  'from __future__ import annotations' would be different if you compile a module than if you parse it using ast.parse() and then compile the result (in the second case the compiler will see strings in the annotations, not AST nodes while in the first case it will see nodes). Additionally, doing this will limit tools that want to analyze the contents of those annotations before they get turned into strings (like type checker, linters...etc).

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35143>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:06:13 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 Dec 2019 20:06:13 +0000
Subject: [issue39076] Use types.SimpleNamespace for argparse.Namespace
In-Reply-To: <1576647735.64.0.921659793768.issue39076@roundup.psfhosted.org>
Message-ID: <CALFfu7CYt-xTy1us1BGCnD6s-jB37zGyFbWjaYpHCSOj2QrzcA@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Sorry if there was any confusion.  I didn't mean to suggest we get rid
of argparse.Namespace (in favor of SimpleNamespace).  Rather, the
former would subclass the latter.

> * types.SimpleNamespace() sorts attributes, so this would get in the way of issue #39058.

hence issue 39075

> * argparse.Namespace() supports a __contains__() method that isn't offered by types.SimpleNamespace():

As I suggested originally, there isn't any problem here if
argparse.Namespace subclasses SimpleNamespace.

> * Argparse is sensitive to start-up time so we mostly want to avoid adding new dependencies.

I agree on avoiding extra imports.  The simple solution right now is
to use "type(sys.implementation)", though that isn't the clearest
code.

FWIW, this would also be solved if we added SimpleNamespace to the
builtins, but that is a separate discussion. :)

> * The __repr__ for SimpleNamespace() doesn't round-trip and isn't what we have now with Namespace.

We could certainly fix the repr, but that's kind of irrelevant here if
argparse.Namespace is a subclass.

FWIW, this is also resolved if we add SimpleNamespace to the builtins
(as "namespace").

> * Ironically, the class name "Namespace" is simpler than "SimpleNamespace" ;-)

Agreed. :)  We only used that long name because putting it in the
"types" module mean it needed to have an extra clear name.

That said, it is irrelevant here if argparse.Namespace is a subclass

> * Much of the code in argparse.Namespace() inherits from _AttributeHolder, so switching to types.SimpleNamespace() doesn't really save us much code.

Honestly, _AttributeHolder isn't needed.  The only thing it provides
is a nice repr (like SimpleNamespace does), with some extra
functionality for dynamically sorting/filtering down the attrs shown
in the repr.   There are 3 subclasses and Namespace doesn't even use
the attr filtering.  The implementation doesn't seem to warrant a
dedicated base class and it would be simpler for those 2 subclasses to
each to have a dedicated __repr__ implementation (and for Namespace to
subclass SimpleNamespce), rather than to subclass _AttributeHolder.
Subclassing from _AttributeHolder gives the illusion that there is
something more going on there than there actually is.

Aside from that, there's the weaker argument about consistency and
avoiding duplication (i.e. SimpleNamespace is the canonical "simple"
namespace implementation in Python).  Also, if SimpleNamespace had
existed when argparse was written then I expect it would have been
used instead.

> Are there any upsides to switching?  Attribute lookup is almost equally fast using either approach, so there is no speed benefit:

Yeah, I didn't expect there to much difference in performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39076>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:07:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 Dec 2019 20:07:27 +0000
Subject: [issue39076] Use types.SimpleNamespace for argparse.Namespace
In-Reply-To: <1576600551.73.0.829151608014.issue39076@roundup.psfhosted.org>
Message-ID: <1577477247.42.0.601534852008.issue39076@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Anyway, this probably isn't a discussion worth extending much further.  I don't think it's important enough. :)  So if you have reservations about this then feel free to close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39076>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:15:15 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 Dec 2019 20:15:15 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576991283.04.0.49981225159.issue39075@roundup.psfhosted.org>
Message-ID: <CALFfu7Dn=3FRqxudXbvSCB0GLwMw8EB4ShmhmOER42rfD8RB_Q@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> IMHO, dropping the sort should be a default behavior. If some user need
> this feature, maybe we could supply a param to open the sort function or not?

Consider opening a separate issue (or start a thread on python-ideas)
about adding a more sophisticated implementation to the stdlib's
"reprlib" module.  If you do so then please draw from the
argparse._AttributeHolder implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:31:19 2019
From: report at bugs.python.org (Aniket Panse)
Date: Fri, 27 Dec 2019 20:31:19 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1577478679.47.0.721087728898.issue39082@roundup.psfhosted.org>


Change by Aniket Panse <aniketpanse at gmail.com>:


----------
keywords: +patch
pull_requests: +17162
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17717

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:33:12 2019
From: report at bugs.python.org (Henrique)
Date: Fri, 27 Dec 2019 20:33:12 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
Message-ID: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>


New submission from Henrique <coura.henrique at gmail.com>:

While passing

{
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
        "verbose": {"format": "%(levelname)s %(asctime)s %(module)s %(message)s"}
    },
    "handlers": {
        "stackdriver": {
            "class": "google.cloud.logging.handlers.CloudLoggingHandler",
            "client": client,
            "resource": resource,
        },
    },
    "root": {"level": "INFO", "handlers": ["stackdriver"]},
}

to logging.config.dictConfig it will convert resource, which is a namedtuple to ConvertingTuple, this will make google.cloud.logging.handlers.CloudLoggingHandler break down the line.

I am having to create a wrapper class like 

class Bla:
    resource = logging.resource.Resource(
        type="cloud_run_revision",
        labels={},
    )

    def _to_dict(self):
        return self.resource._to_dict()

to go around this

----------
messages: 358914
nosy: hcoura
priority: normal
severity: normal
status: open
title: logging.config.dictConfig will convert namedtuple to ConvertingTuple
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39142>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:35:52 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 27 Dec 2019 20:35:52 +0000
Subject: [issue39117] Performance regression for making bound methods
In-Reply-To: <1576959181.43.0.150480407259.issue39117@roundup.psfhosted.org>
Message-ID: <1577478952.66.0.0393621082552.issue39117@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39117>
_______________________________________

From report at bugs.python.org  Fri Dec 27 16:18:29 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Fri, 27 Dec 2019 21:18:29 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1577481509.49.0.390479864233.issue33944@roundup.psfhosted.org>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

No. You can't put an usercustomize in a wheel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Fri Dec 27 16:35:04 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 27 Dec 2019 21:35:04 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
Message-ID: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

While I was re-reading The Garbage Collection Handbook [Moss, Hosking, Jones], I have been doing some benchmarks of different aspects of our garbage collection and taking statistics using the pyperformance suite as long as several "production" applications that heavily creates objects. I have observed that our
collector presents a form of "generational nepotism" in some typical scenarios. The most common reason is
that when promotions of the youngest generations happen, some very young objects that just arrived in the generation are promoted because we have reached a threshold, and its death will be delayed. These objects
will likely die immediately if the promotion was delayed a bit (think of a burst of temporary objects being created at once) or if the promotion could distinguish "age" with more granularity. 

The book proposes serval solutions to this problem, and one of the simpler ones taking the
architecture of our collector is to use sub-generation steps: 

> Promotion can be delayed by structuring a generation into two or more aging spaces. This
allows objects to be copied between the fromspace and tospace an arbitrary number of
times within the generation before they are promoted. In Lieberman and Hewitt's original
generational collector [1983], a generation is collected several times before all survivors
are eventually promoted en masse. In terms of the aging semispaces of Figure 9.2b, ei?
ther all live objects in fromspace are evacuated to tospace within this generation or all
are promoted to the next generation, depending on the age of the generation as a whole.

Basically, the differences between steps and generations are that both segregate objects by age,
but different generations are collected at different frequencies whereas all the steps of a
generation are collected at the same time. By using steps in the youngest generation (where
most mutation occurs), and by reducing premature col?lection, the load on the write barrier
can be reduced while also controlling promotion, without need for per-object age records.

--

What do you think about implementing sub-generation steps? Maybe only on the youngest generation?

A "lazy" way of implementing this (although without the semantic of "steps") is adding more intermediate generations with the same threshold (but this likely won't yield the same benefits).

----------
components: Interpreter Core
messages: 358916
nosy: nascheme, pablogsal, tim.peters
priority: normal
severity: normal
status: open
title: Implementing sub-generation steps in the gc
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Fri Dec 27 16:40:45 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 21:40:45 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1577482845.24.0.693466092763.issue38731@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17163
pull_request: https://github.com/python/cpython/pull/17719

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Fri Dec 27 16:56:21 2019
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Dec 2019 21:56:21 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577483781.61.0.896304394082.issue39136@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17164
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17720

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:06:20 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 22:06:20 +0000
Subject: [issue22640] Add silent mode for py_compile
In-Reply-To: <1413361400.01.0.34334853586.issue22640@psf.upfronthosting.co.za>
Message-ID: <1577484380.97.0.95514905554.issue22640@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17165
pull_request: https://github.com/python/cpython/pull/17719

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22640>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:06:55 2019
From: report at bugs.python.org (Batuhan)
Date: Fri, 27 Dec 2019 22:06:55 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1577484415.79.0.904982687753.issue38731@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests:  -17163

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:10:42 2019
From: report at bugs.python.org (anthony shaw)
Date: Fri, 27 Dec 2019 22:10:42 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
Message-ID: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>


New submission from anthony shaw <anthony.p.shaw at gmail.com>:

make tags will include

- Modules/_ctypes/

where as make TAGS will not.

Also, neither include the Python source files for the standard library, which both etags and ctags are capable of handling.

PR to follow

----------
components: Build
messages: 358917
nosy: anthony shaw
priority: normal
severity: normal
status: open
title: Align ctags and etags targets and include Python stdlib
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:13:19 2019
From: report at bugs.python.org (anthony shaw)
Date: Fri, 27 Dec 2019 22:13:19 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577484799.5.0.334240790809.issue39144@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

Also, make tags will reset the "tags" file, whereas, make TAGS will not.
If you ran "make tags" then "make TAGS" you will have a corrupt etags file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:14:59 2019
From: report at bugs.python.org (anthony shaw)
Date: Fri, 27 Dec 2019 22:14:59 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577484899.5.0.555421676826.issue39144@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +17166
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17721

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:17:13 2019
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 27 Dec 2019 22:17:13 +0000
Subject: [issue37542] UDP sendto() sends duplicate packets
In-Reply-To: <1562755863.69.0.759157701288.issue37542@roundup.psfhosted.org>
Message-ID: <1577485033.75.0.741391977283.issue37542@roundup.psfhosted.org>


Alex Gr?nholm <alex.gronholm at nextday.fi> added the comment:

Can you reproduce this on localhost, or over Ethernet while only listening on that specific interface? If not, then likely this is just a Wireshark artifact.

Failing that, you should construct a script that allows others to try to reproduce the effect.

----------
nosy: +alex.gronholm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37542>
_______________________________________

From report at bugs.python.org  Fri Dec 27 20:01:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 28 Dec 2019 01:01:12 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577494872.46.0.255603470972.issue39142@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Can you please attach a sample script with the handler used to illustrate the issue?

----------
nosy: +vinay.sajip, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39142>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:09:25 2019
From: report at bugs.python.org (Josh Holland)
Date: Sat, 28 Dec 2019 02:09:25 +0000
Subject: [issue39090] Document various options for getting the absolute path
 from pathlib.Path objects
In-Reply-To: <1576693250.66.0.453775762211.issue39090@roundup.psfhosted.org>
Message-ID: <1577498965.82.0.288204168618.issue39090@roundup.psfhosted.org>


Change by Josh Holland <anowlcalledjosh at gmail.com>:


----------
nosy: +anowlcalledjosh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:21:57 2019
From: report at bugs.python.org (Cyker Way)
Date: Sat, 28 Dec 2019 02:21:57 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
Message-ID: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>


New submission from Cyker Way <cykerway at gmail.com>:

With an inheritance graph like this:

        A       C
        B       D      (X)      A
                E

Adding or removing class X in E's parents will change the order of A and C in E's MRO: EBDAC vs EBDCXA.

I couldn't imagine what would be the "perfect" MRO. However, given X is completely independent from A and C, this behavior looks strange and problematic.

----------
components: Interpreter Core
files: mro.py
messages: 358921
nosy: cykerway
priority: normal
severity: normal
status: open
title: Innocuous parent class changes multiple inheritance MRO
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48804/mro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:32:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 02:32:57 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577500377.3.0.542264715916.issue39144@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset ef7eaafc9d2e370cf79b3674e56f643bbfe239e2 by Pablo Galindo (Anthony Shaw) in branch 'master':
bpo-39144 Align ctags and etags behaviours in the makefile and include Python stdlib files (GH-17721)
https://github.com/python/cpython/commit/ef7eaafc9d2e370cf79b3674e56f643bbfe239e2


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:33:16 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 28 Dec 2019 02:33:16 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577500396.89.0.149852126824.issue39144@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17167
pull_request: https://github.com/python/cpython/pull/17722

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:33:23 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 28 Dec 2019 02:33:23 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577500403.44.0.828075609024.issue39144@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17168
pull_request: https://github.com/python/cpython/pull/17723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:50:38 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 28 Dec 2019 02:50:38 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577501438.7.0.657428160952.issue39144@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2786fdec79c35b4a68afea2bbbedbba3b6eb2269 by Miss Islington (bot) in branch '3.8':
bpo-39144 Align ctags and etags behaviours in the makefile and include Python stdlib files (GH-17721)
https://github.com/python/cpython/commit/2786fdec79c35b4a68afea2bbbedbba3b6eb2269


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:51:40 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 28 Dec 2019 02:51:40 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577501500.79.0.664968790792.issue39144@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d7aa3d26845be77ebca1b3954830aace6ef31e58 by Miss Islington (bot) in branch '3.7':
bpo-39144 Align ctags and etags behaviours in the makefile and include Python stdlib files (GH-17721)
https://github.com/python/cpython/commit/d7aa3d26845be77ebca1b3954830aace6ef31e58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39144>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:53:14 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 28 Dec 2019 02:53:14 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1577501594.82.0.150207556733.issue38731@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17169
pull_request: https://github.com/python/cpython/pull/17725

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:53:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 02:53:07 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1577501587.09.0.029236792066.issue38731@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 98f0f04b5016e63561d313a3446b7b58f2c12611 by Pablo Galindo (Batuhan Ta?kaya) in branch 'master':
bpo-38731: Fix function signature of quiet in docs (GH-17719)
https://github.com/python/cpython/commit/98f0f04b5016e63561d313a3446b7b58f2c12611


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:56:05 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 28 Dec 2019 02:56:05 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1577501765.12.0.974672955861.issue39145@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Have you read the description of how the MRO is calculated? It's a standard algorithm. So long as the result matches the C3 linearisation algorithm, then it's not a bug.

https://en.wikipedia.org/wiki/C3_linearization

https://www.python.org/download/releases/2.3/mro/

I've gone back to Python 2.4 and tested the MRO. With and without class X, the MRO is:

    E B D C X A object
    E B D A C object

so the result seems to be consistent back to 2.4 if not older. So it's not a change in behaviour in 3.8. It also matches the result of my own implementation of the C3 algorithm that I wrote some time ago to check my understanding of it.

So it looks to me that this is the correct behaviour, going back to 2.3, so I'm closing it as "Not a bug". If you disagree, and can find a bug in Python's C3 linearisation algorithm, please feel free to reopen. If you disagree with the choice of the C3 algorithm, and want to suggest some other algorithm, you'll need to write a PEP setting forth the pros and cons of both, explaining why the alternative is better than the status quo.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:58:52 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 28 Dec 2019 02:58:52 +0000
Subject: [issue38731] bad input crashes py_compile library
In-Reply-To: <1573109618.35.0.267510329775.issue38731@roundup.psfhosted.org>
Message-ID: <1577501932.32.0.804177145685.issue38731@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 04c1efe5acc89b6f3f2c208604a1c35641e8a380 by Miss Islington (bot) in branch '3.8':
bpo-38731: Fix function signature of quiet in docs (GH-17719)
https://github.com/python/cpython/commit/04c1efe5acc89b6f3f2c208604a1c35641e8a380


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38731>
_______________________________________

From report at bugs.python.org  Fri Dec 27 22:46:57 2019
From: report at bugs.python.org (Gurupad Hegde)
Date: Sat, 28 Dec 2019 03:46:57 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577504817.91.0.35074128547.issue39136@roundup.psfhosted.org>


Gurupad Hegde <gurupad93 at gmail.com> added the comment:

Hi, I am a new contributor here. Have created the below pull request.
https://github.com/python/cpython/pull/17720 

Please let me know if i have to do anything else from my end.

----------
nosy: +gurupad93

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sat Dec 28 00:53:09 2019
From: report at bugs.python.org (Cyker Way)
Date: Sat, 28 Dec 2019 05:53:09 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1577512389.43.0.625937573029.issue39145@roundup.psfhosted.org>


Cyker Way <cykerway at gmail.com> added the comment:

Thanks for reply. It's not about the Python's implementation of C3 but C3 itself being used as the MRO algorithm in Python. It bites when you remove an independent interface from your class definition and its method calls become something else.

I think I can propose an easy fix to C3. I would just call it C3.9 if it's going to be merged in Python 3.9. The difference between C3.9 and C3 is: During a merge, put the list of the parents in front of the linearizations of the parents, namely:

Instead of: L[C(B1 ... BN)] = C + merge(L[B1], ..., L[BN], B1 ... BN)

We do: L[C(B1 ... BN)] = C + merge(B1 ... BN, L[B1], ... , L[BN])

This preserves the guarantees of C3 (for example, local precedence ordering, monotonicity), plus another property: When you remove a leaf node in the dependency graph, the MRO of other nodes remain the same. Practically, this means when a developer removes an independent interface from his class, he knows the MRO of the remaining classes keep the same. Here the independent interface can even have its own class hierarchy, and the proof goes by removing each leaf one by one in its hierarchy.

For example, using the same mro.py:

E + [BDA BA DC A]
EB + [DA A DC A]
EBD + [A A C A]
EBDA + [C]
EBDAC

E + [BDXA BA DC X A]
EB + [DXA A DC X A]
EBD + [XA A C X A]
EBDX + [A A C A]
EBDXA + [C]
EBDXAC


You can see EBDAC is a sub-sequence of EBDXAC.

The proof is intuitive. I can give a sketch here. Assume without loss of generality, class E extends A, B, C, D, and we add a new base class X between B and C, now we have:

(f1) E + [ABXCD L(A) L(B) X L(C) L(D)]

Compare this with:

(f0) E + [ABCD L(A) L(B) L(C) L(D)]

We can carry all the computation in f1 just as in f0 until X becomes the head of the first list item:

(f1') E... + [XCD ... X ... ]

(f0') E... + [CD ... ... ]


At this time we know we can extract X in (f1') because X is in any tail. After we extract X, (f1') becomes (f0') and we can carry all the operations just as in (f0'). So the result of (f1) is merely an added X and all other elements keep the same order. Intuitively, the performance of C3.9 should be almost the same as C3. The only drawback I can think of is existing code may have a different MRO, but that happened when Python adopted C3.

Not sure if this is worth a PEP. If anyone is interested feel free to leave a message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Sat Dec 28 00:57:23 2019
From: report at bugs.python.org (Cyker Way)
Date: Sat, 28 Dec 2019 05:57:23 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1577512643.89.0.628885659787.issue39145@roundup.psfhosted.org>


Cyker Way <cykerway at gmail.com> added the comment:

a typo:

...at this time we know we can extract X in (f1') because X is NOT in any tail...

Missed the "NOT" in the previous text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Sat Dec 28 01:46:49 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 28 Dec 2019 06:46:49 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577512389.43.0.625937573029.issue39145@roundup.psfhosted.org>
Message-ID: <20191228064628.GN21130@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Whether this proposed change is worth a PEP is a value judgement, but 
whether it will need a PEP is, I think, a fact. It is a backwards 
incompatible change (it will change the inheritance order of classes) 
potentially breaking people's code. Its not a small change, so it will 
(almost certainly) need a PEP.

The C3 linearisation algoritm has been published in the academic 
literature, where it has been peer-reviewed. It has been in use in 
languages such as Dylan, Python and Perl 6 for at least 16 years. Your 
variant is experimental and untested (unless you can point to languages 
already using it). It won't be easy to convince the core devs to change 
algorithms unless you can point to an actual problem with the status quo 
more serious than "it surprises me".

I don't think the bug tracker is the right place to debate your variant: 
probably not enough eyes on it, and I'm certainly not qualified to pick 
out problems with your design or judge if it is better. If you want to 
take this further, I suggest you try the Python-Ideas or Python-Dev 
mailing lists:

* Python-Ideas is high-volume and plagued by bike-shedding, but is the 
official first step for proposing major changes to the language.

* Python-Dev is lower volume and more likely to catch the eye of senior 
core developers, but they may tell you to take it to Python-Ideas first 
(but not always).

https://www.python.org/community/lists/

If you don't like mailing lists, you could try Discuss:

https://discuss.python.org

Whichever forum you pick, be prepared for serious push-back. The onus 
will be on you to prove that the status quo is not good and your 
alternative solves some real problems. You might want to read these 
first:

https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html

https://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html

I'm telling you this not to discourage you from taking it further, but 
so that you understand that if you want this change you have to be 
prepared to work for it.

Good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Sat Dec 28 01:58:08 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 28 Dec 2019 06:58:08 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1577516288.85.0.0334641525036.issue19083@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17170
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17726

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 01:59:15 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 28 Dec 2019 06:59:15 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1577516355.05.0.70885840389.issue19083@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 02:11:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Dec 2019 07:11:38 +0000
Subject: [issue39111] Misleading documentation for NotImplemented
In-Reply-To: <1576860176.18.0.619926767128.issue39111@roundup.psfhosted.org>
Message-ID: <1577517098.65.0.433194630124.issue39111@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39111>
_______________________________________

From report at bugs.python.org  Sat Dec 28 02:21:22 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Dec 2019 07:21:22 +0000
Subject: [issue39112] Misleading documentation for tuple
In-Reply-To: <1576891699.24.0.656089355811.issue39112@roundup.psfhosted.org>
Message-ID: <1577517682.51.0.841552072603.issue39112@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe that this is a duplicate issue.  As noted before, filter, map, reversed, and zip are classes, but they return iterators and are documented differently.

----------
nosy: +terry.reedy
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39112>
_______________________________________

From report at bugs.python.org  Sat Dec 28 03:09:54 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 28 Dec 2019 08:09:54 +0000
Subject: [issue39112] Misleading documentation for tuple
In-Reply-To: <1576891699.24.0.656089355811.issue39112@roundup.psfhosted.org>
Message-ID: <1577520594.92.0.449456507024.issue39112@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Terry, I guess it's a duplicate of issue34118 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39112>
_______________________________________

From report at bugs.python.org  Sat Dec 28 03:43:06 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 28 Dec 2019 08:43:06 +0000
Subject: [issue32438] PyLong_ API cleanup
In-Reply-To: <1514456365.15.0.213398074469.issue32438@psf.upfronthosting.co.za>
Message-ID: <1577522586.91.0.691010966606.issue32438@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Is this related/resolved with issue 36048?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32438>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:10:19 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 28 Dec 2019 09:10:19 +0000
Subject: [issue37446] Undefined behavior in Python/hamt.c
In-Reply-To: <1561769890.8.0.709429549859.issue37446@roundup.psfhosted.org>
Message-ID: <1577524219.45.0.0124303922084.issue37446@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17171
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17727

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37446>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:11:04 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 28 Dec 2019 09:11:04 +0000
Subject: [issue37446] Undefined behavior in Python/hamt.c
In-Reply-To: <1561769890.8.0.709429549859.issue37446@roundup.psfhosted.org>
Message-ID: <1577524264.36.0.958669837891.issue37446@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> I don't get that output on 3.8.0a4+

I guess it is related with you didn't added -fsanitize=undefined option.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37446>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:20:29 2019
From: report at bugs.python.org (Zhipeng Xie)
Date: Sat, 28 Dec 2019 09:20:29 +0000
Subject: [issue39146] to much memory consumption in re.compile unicode
Message-ID: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>


New submission from Zhipeng Xie <775350901 at qq.com>:

when running the following script, we found python2 comsume a lot memory while python3 does not have the issue.

import re
import time
NON_PRINTABLE = re.compile(u'[^\U00010000-\U0010ffff]')
time.sleep( 30 )

python2:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                            
 6943 root      20   0  109956  93436   3956 S   0.0   1.2   0:00.30 python

python3:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                            
 6952 root      20   0   28032   8880   4868 S   0.0   0.1   0:00.02 python3

----------
components: Library (Lib)
messages: 358936
nosy: Zhipeng Xie
priority: normal
severity: normal
status: open
title: to much memory consumption in re.compile unicode
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:20:49 2019
From: report at bugs.python.org (Zhipeng Xie)
Date: Sat, 28 Dec 2019 09:20:49 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1577524849.5.0.0998876418384.issue39146@roundup.psfhosted.org>


Change by Zhipeng Xie <775350901 at qq.com>:


----------
title: to much memory consumption in re.compile unicode -> too much memory consumption in re.compile unicode

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:29:34 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Dec 2019 09:29:34 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1577525374.55.0.28035754045.issue39146@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17172
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17728

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:56:02 2019
From: report at bugs.python.org (Patrick Liu)
Date: Sat, 28 Dec 2019 09:56:02 +0000
Subject: [issue39147] using zipfile with root privilege shows FileNotFoundError
Message-ID: <1577526962.17.0.0234769232218.issue39147@roundup.psfhosted.org>


New submission from Patrick Liu <liupeifox at gmail.com>:

When I run the python script with root privilege, it can clone the repo successfully but with the error message as follow.
However, it runs correctly with normal user.
Why it cannot find the html file? Thanks.

Python 3.7.4 (default, Aug 13 2019, 20:35:49) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from git_clone import git_clone
>>> git_clone('https://github.com/android9527/android9527.github.io')
13472.0 KB, 13574 KB/s, 0.99 seconds passed         Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/root/anaconda3/lib/python3.7/site-packages/git_clone/git_clone.py", line 53, in git_clone
    f.extractall(path + '/.')
  File "/root/anaconda3/lib/python3.7/zipfile.py", line 1619, in extractall
    self._extract_member(zipinfo, path, pwd)
  File "/root/anaconda3/lib/python3.7/zipfile.py", line 1673, in _extract_member
    open(targetpath, "wb") as target:
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/fit-Knowledgezoo/test/android9527.github.io-master/2019/01/24/2019-01-24-Java ??? synchronized /index.html'
>>> exit()

----------
messages: 358937
nosy: Patrick Liu
priority: normal
severity: normal
status: open
title: using zipfile with root privilege shows FileNotFoundError
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39147>
_______________________________________

From report at bugs.python.org  Sat Dec 28 05:18:50 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 28 Dec 2019 10:18:50 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1577528330.37.0.959095704143.issue38938@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +17174
pull_request: https://github.com/python/cpython/pull/17729

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Dec 28 05:31:44 2019
From: report at bugs.python.org (Cyker Way)
Date: Sat, 28 Dec 2019 10:31:44 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1577529104.8.0.734453868704.issue39145@roundup.psfhosted.org>


Cyker Way <cykerway at gmail.com> added the comment:

Thank you for the links. I doubt this c3 variant could break EPG consistency making it c2. May run some tests later and move on to discussion board. Guess I'm done here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Sat Dec 28 05:50:04 2019
From: report at bugs.python.org (Cyker Way)
Date: Sat, 28 Dec 2019 10:50:04 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1577530204.14.0.0748083854951.issue39145@roundup.psfhosted.org>


Cyker Way <cykerway at gmail.com> added the comment:

Ahhh, 1 second, I haven't really quit from this. I could open another thread but it's highly related to this one.

I just came up with something that looks like a bug not a feature in the original c3.

    #!/usr/bin/env python3

    #        A       C
    #        B       D      X      A
    #                E      F
    #                G

    class A(object): pass
    class B(A): pass
    class C(object): pass
    class D(C): pass
    class X(object): pass
    class E(B, D, A): pass
    class F(B, D, X, A): pass
    class G(E, F): pass
    print(G.mro())

The script fails. It cannot find GEFBDCXA, which looks valid?

You can close again if you feel this isn't a bug. I'm gone for a while.

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Sat Dec 28 05:55:11 2019
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 28 Dec 2019 10:55:11 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
Message-ID: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>


New submission from Alex Gr?nholm <alex.gronholm at nextday.fi>:

Receiving a UDP datagram using DatagramProtocol on the Proactor event loop results in error_received() being called with WinError 87 (Invalid Parameter). The low-level sock_recv() works fine, but naturally loses the sender address information. The attached script works fine as-is on Linux, and on Windows if ::1 is replaced with 127.0.0.1.

There were extensive tests added for UDP support on IOCP, but unfortunately all of them use only IPv4 sockets so they could not catch this problem.

----------
components: Windows
files: udpreceive.py
messages: 358940
nosy: alex.gronholm, asvetlov, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: DatagramProtocol + IPv6 does not work with ProactorEventLoop
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48805/udpreceive.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Sat Dec 28 05:57:07 2019
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Sat, 28 Dec 2019 10:57:07 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1577530627.82.0.85387278589.issue39148@roundup.psfhosted.org>


Change by Alex Gr?nholm <alex.gronholm at nextday.fi>:


----------
components: +asyncio
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Sat Dec 28 06:49:29 2019
From: report at bugs.python.org (Kay Hayen)
Date: Sat, 28 Dec 2019 11:49:29 +0000
Subject: [issue35143] `from __future__ import annotations` has no effect
 inside `ast.parse`
In-Reply-To: <1541147333.05.0.788709270274.issue35143@psf.upfronthosting.co.za>
Message-ID: <1577533769.45.0.0121585103686.issue35143@roundup.psfhosted.org>


Kay Hayen <kay.hayen at gmail.com> added the comment:

Thanks a lot, Batuhan, this will feel a lot more correct, from my point of view, this could be closed unless there would be a backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 07:38:16 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Dec 2019 12:38:16 +0000
Subject: [issue32438] PyLong_ API cleanup
In-Reply-To: <1514456365.15.0.213398074469.issue32438@psf.upfronthosting.co.za>
Message-ID: <1577536696.95.0.614604111871.issue32438@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Batuhan: I think so, yes; at least, the "deprecated" part is done. The "eventually removed" is not, and I don't know whether we have a target version for that removal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32438>
_______________________________________

From report at bugs.python.org  Sat Dec 28 07:42:33 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Dec 2019 12:42:33 +0000
Subject: [issue36048] Deprecate implicit truncating when convert Python
 numbers to C integers: use __index__, not __int__
In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org>
Message-ID: <1577536953.06.0.769475493845.issue36048@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Serhiy: any thoughts about what version should be targeted for eventual removal of the functionality deprecated in this PR? 3.10?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36048>
_______________________________________

From report at bugs.python.org  Sat Dec 28 07:44:53 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 28 Dec 2019 12:44:53 +0000
Subject: [issue32438] PyLong_ API cleanup
In-Reply-To: <1514456365.15.0.213398074469.issue32438@psf.upfronthosting.co.za>
Message-ID: <1577537093.98.0.00524144302676.issue32438@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing as a duplicate of #36048 (which isn't quite right, since this issue came first, but it's probably close enough).

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32438>
_______________________________________

From report at bugs.python.org  Sat Dec 28 09:04:14 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 28 Dec 2019 14:04:14 +0000
Subject: [issue35143] `from __future__ import annotations` has no effect
 inside `ast.parse`
In-Reply-To: <1541147333.05.0.788709270274.issue35143@psf.upfronthosting.co.za>
Message-ID: <1577541854.58.0.579658570795.issue35143@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree with Pablo's analysis. And this can't be backported, since it's a new feature. So I'm closing this issue.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 10:18:15 2019
From: report at bugs.python.org (Alexander Hirner)
Date: Sat, 28 Dec 2019 15:18:15 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577546295.89.0.124690543787.issue39134@roundup.psfhosted.org>


Alexander Hirner <a.hirner at gmail.com> added the comment:

We construct a computational graph and need to validate (or search for possible new) edges at runtime. The data is specific to computer vision. One example is clipping geometry within 2D boundaries. A minimal implementation of this data would be:

@dataclass
class FramedGeometry:
    width: PositiveInt
    height: PositiveInt
    geometry: Geometry

However, different properties are manifest in different encodings. Height, width can be meta data from an image database or inherent to a decoded image (as np.ndarray.shape). The transform will then `dataclasses.replace(geometry=...)` its attribute(s).. If width and height are not implemented, another transition is needed to produce them whilst only looking into the image header, not fully decoding potentially large and many images.

The read-only interface ensures that transitions are generic wrt some forms of inputs. The replace interface preserves runtime types.

Inputs and outputs are annotated with @dataclass or tuples of them. Those dataclasses are a mixin of base dataclasses that declare concrete properties like a URI of an image and ABCs that declare accessors like get_width(self) -> PositiveInt. We use @pydantic.dataclass to parse, validate and deserialize concrete classes to great extent [0]. 

In order to not implement accessors on top of dataclasses, we'd want that abstract properties are compatible with dataclasses and issubclass works with data protocols (given the necessary constraints).

PS:
Polymorphism for computer-vision data is an interesting problem. Other approaches exist, each with their own struggle to model "traits" the right way [1]. E.g., scaling would be valid for `FramedGeometry` since no image data is included but invalid when images are referenced but cannot be resized, like:

class EncodedSizedAnnotatedFrame:
    width: PositiveInt
    height: PositiveInt
    image_bin: bytes
    geometry: Geometry

Thanks!

[0] https://pydantic-docs.helpmanual.io/usage/dataclasses/
[1] https://github.com/pytorch/vision/issues/1406

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Sat Dec 28 10:40:53 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 15:40:53 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577547653.27.0.34113602868.issue39143@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

> The most common reason is that when promotions of the youngest generations happen, 
>some very young objects that just arrived in the generation are >promoted because we have >reached a threshold, and its death will be >delayed.

What threshold is this? Is it based on the number of objects in the young generation in that if the number of objects in the young generation reaches some value, then promotion occurs. If this is the case, we can use another scheme for the start before exploring steps IMHO.

Using Shaw?s Bucket Brigade Scheme  of semi-spaces or generational steps is good but this means a generation with n steps guarantees n scavenges before an object is promoted to the next generation. The surviving objects are copied between these pairs of semispaces b times before they are promoted to the next step. An n-bucket scheme guarantees that objects will be promoted to the old generation If they have survived between nb and nb-1 scavenges. For example, a 2 bucket scheme, objects are copied up to three times before being promoted to the next generation. This method is good but we will still incur the overhead of copying objects between the semi-spaces.

I have looked at a similar problem before for a different runtime and instead think to consider basing promotion on the number of collections survived by objects in the young generation. This requires using five bits from one of two header words of each object to record its age. The objects that reach the collection threshold are promoted to the old generation. This will give the young objects enough time to die thereby reducing how often objects are promoted to the old generation. This in turn reduces the frequency of major collections hence reduced pause times.

I would only consider the generational semi-spaces after we have explored basing promotion on the age of an object in a generation. If this doesn't work, then we can use the bucket brigade scheme.

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 10:48:23 2019
From: report at bugs.python.org (Henrique)
Date: Sat, 28 Dec 2019 15:48:23 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577548103.92.0.392847806756.issue39142@roundup.psfhosted.org>


Henrique <coura.henrique at gmail.com> added the comment:

Sorry for not sending a proper reproducible script when submitting the issue. End of the day and quite frustrated with the bug, anyway, I attached a full script that will show the error.

This is the custom handler I used:

class MyHandler(logging.StreamHandler):
    def __init__(self, resource, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.resource: namedtuple = resource
    
    def emit(self, record):
        record.msg += f" {self.resource.type}"
        return super().emit(record)


self.resource.type will throw and AttributeError when logging, because resource gets converted from a namedtuple to a ConvertingTuple.

----------
Added file: https://bugs.python.org/file48806/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39142>
_______________________________________

From report at bugs.python.org  Sat Dec 28 11:24:35 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 16:24:35 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577550275.24.0.219913312346.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> What threshold is this?

This is the different thresholds for the generations that you can get using gc.get_threshold(). They are in relationship to the number of objects in every generation (there are slightly different rules for the latest generation).

> This method is good but we will still incur the overhead of copying objects between the semi-spaces.

I am not sure what you mean with "copy" here. Moving objects from generations or spaces is just updating the pointers of the linked lists. Objects are not "copied" but "moved". 

> I have looked at a similar problem before for a different runtime and instead think to consider basing promotion on the number of collections survived by objects in the young generation. This requires using five bits from one of two header words of each object to record its age. The objects that reach the collection threshold are promoted to the old generation. This will give the young objects enough time to die thereby reducing how often objects are promoted to the old generation. This in turn reduces the frequency of major collections hence reduced pause times.

The reason I am proposing sub-generation steps is that making the object header bigger is a price too high to pay for this problem. We have recently gone to notable efforts to reduce one word per object by complicating the code substantially using tagged pointers, so recording the age in the object seems the opposite direction. 

> I would only consider the generational semi-spaces after we have explored basing promotion on the age of an object in a generation. If this doesn't work, then we can use the bucket brigade scheme.

As I mentioned before, recording per-object age will be probably a no-go (the solution to this problem will yield memory gains because objects won't suffer "generational nepotism" but making the object header bigger will annihilate those gains) so that is the reason I proposed generational sub-steps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 11:25:22 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 16:25:22 +0000
Subject: [issue39144] Align ctags and etags targets and include Python stdlib
In-Reply-To: <1577484642.78.0.140620689323.issue39144@roundup.psfhosted.org>
Message-ID: <1577550322.15.0.25476977935.issue39144@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/issue39144>
_______________________________________

From report at bugs.python.org  Sat Dec 28 12:14:38 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 17:14:38 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577553278.73.0.68405831288.issue39143@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

> What threshold is this?

> This is the different thresholds for the generations that you can get using gc.get_threshold(). >They are in relationship to the number of objects in every generation (there are slightly different >rules for the latest generation).

I think we are on the same frequency in terms of threshold. Promotion is currently based on number of objects accumulated in the generation if I interpreted your explanation right.


>I am not sure what you mean with "copy" here. Moving objects from generations or spaces is >just updating the pointers of the linked lists. Objects are not "copied" but "moved". 

Yes, in terms of implementation so am thinking there must be a cost in moving these objects. IIRC the GC handbook you referenced may have noted this too..I stand to be corrected though on this.

>The reason I am proposing sub-generation steps is that making the object header bigger is a >price too high to pay for this problem. We have recently gone to notable efforts to reduce one >word per object by complicating the code substantially using tagged pointers, so recording the >age in the object seems the opposite direction. 

I think we only need about 5 bits to store the age of each object ,  do we really need to increase the object back to two word per object ?

>As I mentioned before, recording per-object age will be probably a no-go (the solution to this >problem will yield memory gains because objects won't suffer "generational nepotism" but >making the object header bigger will annihilate those gains) so that is the reason I proposed >generational sub-steps.

Am actually in favour of this Shaw?s steps scheme though it may also mean the more delays we want, the more steps we need to create and manage while changing the age threshold for objects looks simpler than creating and managing steps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 12:33:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 17:33:21 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577554401.12.0.73039193315.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I think we only need about 5 bits to store the age of each object ,  do we really need to increase the object back to two word per object ?

5 bit *per object* is a lot because it scales with the number of objects. It will quickly obliterate any gain that we get from some objects being deallocated sooner (which is what we are trying to achieve). Using inter-generations has a constant cost that is negligible. 

> Am actually in favour of this Shaw?s steps scheme though it may also mean the more delays we want, the more steps we need to create and manage while changing the age threshold for objects looks simpler than creating and managing steps.

I will propose maybe to only do sub-steps for the first generation (as many papers suggest that is where the bigger gains are). I am not sure what you mean with "changing the age threshold for objects looks simpler than creating and managing steps". If you mean changing the generational threshold, I think that does not fix the problem as it only delays or speeds up collections but the problem is scale-invariant with the number of objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 12:41:12 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 28 Dec 2019 17:41:12 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1577554872.81.0.341402865021.issue11105@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

We can probably implement something like this to prevent this happening
diff --git a/Parser/asdl_c.py b/Parser/asdl_c.py
index daac0966f5..f9da52da7f 100755
--- a/Parser/asdl_c.py
+++ b/Parser/asdl_c.py
@@ -559,6 +559,11 @@ class Obj2ModVisitor(PickleVisitor):
             self.emit("asdl_seq_SET(%s, i, val);" % field.name, depth+2)
             self.emit("}", depth+1)
         else:
+            self.emit("if (obj == tmp) {", depth+1)
+            self.emit("PyErr_SetString(PyExc_RuntimeError, \"Recursing fields "
+                      "are not supported for AST nodes.\");", depth+2, reflow=False)
+            self.emit("goto failed;", depth+2)
+            self.emit("}", depth+1)
             self.emit("res = obj2ast_%s(tmp, &%s, arena);" %
                       (field.type, field.name), depth+1)
             self.emit("if (res != 0) goto failed;", depth+1)

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11105>
_______________________________________

From report at bugs.python.org  Sat Dec 28 12:41:29 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 28 Dec 2019 17:41:29 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1577554889.81.0.410965251857.issue11105@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
versions: +Python 3.9 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11105>
_______________________________________

From report at bugs.python.org  Sat Dec 28 12:57:43 2019
From: report at bugs.python.org (Michel Desmoulin)
Date: Sat, 28 Dec 2019 17:57:43 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1577555863.75.0.984431177175.issue33944@roundup.psfhosted.org>


Michel Desmoulin <desmoulinmichel at gmail.com> added the comment:

Just realized it didn't work in venv anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Sat Dec 28 13:22:33 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 18:22:33 +0000
Subject: [issue39123] PyThread_xxx() not available when using limited API
In-Reply-To: <1577111024.93.0.368390768924.issue39123@roundup.psfhosted.org>
Message-ID: <1577557353.14.0.992291438545.issue39123@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39123>
_______________________________________

From report at bugs.python.org  Sat Dec 28 13:23:42 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 18:23:42 +0000
Subject: [issue32599] Add dtrace hook for PyCFunction_Call
In-Reply-To: <1516383576.04.0.467229070634.issue32599@psf.upfronthosting.co.za>
Message-ID: <1577557422.11.0.398610406952.issue32599@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32599>
_______________________________________

From report at bugs.python.org  Sat Dec 28 13:31:50 2019
From: report at bugs.python.org (Leonardo Galani)
Date: Sat, 28 Dec 2019 18:31:50 +0000
Subject: [issue39149] False positive using operator 'AND' while checking keys
 on dict()
Message-ID: <1577557910.45.0.43701821857.issue39149@roundup.psfhosted.org>


New submission from Leonardo Galani <leo at leonardobg.com.br>:

using Python 3.7.6 (default, Dec 27 2019, 09:51:07) @ macOs

dict = { 'a': 1, 'b': 2, 'c': 3 }

if you `if 'a' and 'b' and 'c' in dict: print('ok')` you will get a True, since everything is true.

if you `if 'a' and 'g' and 'c' in dict: print('ok')` you also get a True because the last statement is True but the mid statement is false.

To avoid this false positive, you need to be explicit:
`if 'a' in dict and 'g' in dict and 'c' in dict: print('ok')` you will get a false.

----------
components: macOS
messages: 358954
nosy: leonardogalani, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: False positive using operator 'AND' while checking keys on dict()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39149>
_______________________________________

From report at bugs.python.org  Sat Dec 28 13:40:21 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 18:40:21 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577558421.74.0.267996491707.issue39143@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

>5 bit *per object* is a lot because it scales with the number of objects. It will quickly obliterate >any gain that we get from some objects being deallocated sooner (which is what we are trying >to achieve). Using inter-generations has a constant cost that is negligible. 

I agree but this may not require us falling back to a two word header per object as was the original worry. If it is a worse tradeoff to managing steps then I would suggest to stick to the steps. Again in the end it is about what tradeoffs are willing to work with.

 >I am not sure what you mean with "changing the age >threshold for objects looks simpler than >creating and managing steps". If you mean changing >the generational threshold, I think that >does not fix the problem as it only delays or speeds up >collections but the problem is >scale-invariant with the number of objects.

I meant that for any need for increase in promotion delay, we need to add a step and manage it which is more complex than for example when tracking ages, incase of a change we only change the age threshold which looks simpler to implement.

>I will propose maybe to only do sub-steps for the first generation (as many papers suggest >that is where the bigger gains are).

Correct, since the premise is we just want to delay promotion of young objects to an older generation so that they have enough time to die. The steps should reasonably be in the first generation.

How many semi-spaces do you think of having in this generation? Most systems have and recommend two.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 14:03:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 28 Dec 2019 19:03:25 +0000
Subject: [issue39149] False positive using operator 'AND' while checking keys
 on dict()
In-Reply-To: <1577557910.45.0.43701821857.issue39149@roundup.psfhosted.org>
Message-ID: <1577559805.82.0.753792914498.issue39149@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It's intended as non-empty strings evaluate to True so you with `'a' and 'b' and 'c' in dict` you are essentially evaluating `'a' and 'b' and ('c' in dict)` with brackets precedence i.e. `True and True and True` . On the other hand `'a' and 'g' and 'c' in dict` it's the same with 'g' evaluated to True. I guess you want to check all the keys are present where all is more readable. Some more answers here: https://stackoverflow.com/questions/1285911/how-do-i-check-that-multiple-keys-are-in-a-dict-in-a-single-pass

>>> all(char in dict for char in ['a', 'b', 'c'])
True
>>> all(char in dict for char in ['a', 'b', 'g'])
False

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39149>
_______________________________________

From report at bugs.python.org  Sat Dec 28 14:05:09 2019
From: report at bugs.python.org (Batuhan)
Date: Sat, 28 Dec 2019 19:05:09 +0000
Subject: [issue25087] Type variable substitution in type instances
In-Reply-To: <1442152338.46.0.937548163334.issue25087@psf.upfronthosting.co.za>
Message-ID: <1577559909.42.0.603521176143.issue25087@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

It looks like the issue in typing tracker closed, can we also close this?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25087>
_______________________________________

From report at bugs.python.org  Sat Dec 28 14:38:31 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 19:38:31 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577561911.64.0.981947970193.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> How many semi-spaces do you think of having in this generation? Most systems have and recommend two.

I suppose we would need to experiment, but for what I have seen I think two or three :) What do you think?

> If it is a worse tradeoff to managing steps then I would suggest to stick to the steps.

I think any memory increase that scales with the number of objects will be a big concern.

>  we need to add a step and manage it which is more complex than for example when tracking ages, incase of a change we only change the age threshold which looks simpler to implement.

Exactly, but if with "tracking ages" you mean store per-object ages then the previous concern applies :( Adding sub-generation steps should not be much more complicated IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 14:42:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2019 19:42:13 +0000
Subject: [issue39149] False positive using operator 'AND' while checking keys
 on dict()
In-Reply-To: <1577557910.45.0.43701821857.issue39149@roundup.psfhosted.org>
Message-ID: <1577562133.14.0.50369839535.issue39149@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/issue39149>
_______________________________________

From report at bugs.python.org  Sat Dec 28 14:53:07 2019
From: report at bugs.python.org (Tim Peters)
Date: Sat, 28 Dec 2019 19:53:07 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577562787.84.0.863252165836.issue39143@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Long ago I thought about adding "a buffer in front of" CPython's cyclic gc:  newly tracked items would be added there, and not participate in cyclic gc at all until a collection passed.

For example, break the youngest generation into parts A & B.  Newly tracked items are added to part A.  When a collection occurs, only part B participates from the youngest generation.  When the collection ends, part A is renamed to part B, and part A is marked empty (just a handful of pointer manipulations).

Seems a similar thrust, but a more extreme goal:  trying to maximize the number of new containers that can be reclaimed by refcounting alone without _ever_ being chased by cyclic gc.

Beyond that most objects "die young", which appears overwhelmingly truer than not across almost all Python programs, I'm not sure anything else about lifetime distribution is generally exploitable.

About "5 bits", no, we don't have 'em.  Even the relatively modest ugliness we have now makes it impossible to port Python to a word-addressed machine (I'm not sure any still exist!).  Nothing in C guarantees the last 2 or 3 bits of a pointer "are 0".  We're already using two words to store 2 persistent pointers, one persistent flag, a full-width transient reference count, and two transient flags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 14:59:45 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 19:59:45 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577563185.44.0.0954540991291.issue39143@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

>
I suppose we would need to experiment, but for what I have seen I think two or three :) What do you think?


IMO, I think experimenting with two steps is good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:01:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 28 Dec 2019 20:01:14 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577563274.47.0.885296309061.issue39142@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the details. Attached is a complete script. Looking at the source code, anything that looks like a tuple is converted into a tuple. namedtuple produces factory function that itself is a subclass of tuple. It led me to this interesting issue over detecting if it's a namedtuple issue7796 where detecting _fields in msg134186 is described as a workaround. So logging might detect namedtuple and skip conversion to ConvertingTuple using the workaround but it appears more of the class of special casing it here in logging  that will depend on namedtuple internals. There are no test failures. I will leave it to vinay on this.

>>> import collections
>>> person = collections.namedtuple('Person', 'age')
>>> isinstance(person(age=20), tuple)
True
>>> print(person._source) # works on 3.6 but verbose and _source were removed in 3.7 with 8b57d7363916869357848e666d03fa7614c47897
from builtins import property as _property, tuple as _tuple
from operator import itemgetter as _itemgetter
from collections import OrderedDict

class Person(tuple):
    'Person(age,)'
// snip more source code for person

# Detect namedtuple by checking for _fields attribute

diff --git a/Lib/logging/config.py b/Lib/logging/config.py
index 4a3b8966ed..ba6937e725 100644
--- a/Lib/logging/config.py
+++ b/Lib/logging/config.py
@@ -448,7 +448,8 @@ class BaseConfigurator(object):
             value = ConvertingList(value)
             value.configurator = self
         elif not isinstance(value, ConvertingTuple) and\
-                 isinstance(value, tuple):
+                 isinstance(value, tuple) and\
+                 not hasattr(value, '_fields'):
             value = ConvertingTuple(value)
             value.configurator = self
         elif isinstance(value, str): # str for py3k

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39142>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:04:35 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 28 Dec 2019 20:04:35 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577563475.84.0.956814660515.issue39143@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

> About "5 bits", no, we don't have 'em.  Even the relatively modest > ugliness we have now makes it impossible to port Python to a word->addressed machine (I'm not sure any still exist!).  Nothing in C >guarantees the last 2 or 3 bits of a pointer "are 0".  We're already >using two words to store 2 persistent pointers, one persistent flag, a >full-width transient reference count, and two transient flags.

In view of this, +1 for avoiding the extra bits for age storage. The steps scheme will work best in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:12:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 20:12:34 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577563954.4.0.100821879143.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> For example, break the youngest generation into parts A & B.  Newly tracked items are added to part A.  When a collection occurs, only part B participates from the youngest generation.  When the collection ends, part A is renamed to part B, and part A is marked empty (just a handful of pointer manipulations).

Well, this seems simple enough to fully implement just to try it out to benchmark a bit. I will start doing some experiments with it.

> Beyond that most objects "die young", which appears overwhelmingly truer than not across almost all Python programs, I'm not sure anything else about lifetime distribution is generally exploitable.

In theory, sub-generation steps will make use of "most object die young", specifically it will try to make it happen more often, as this issue can be summarized on "some objects that should die young don't because they were in a collection at the wrong time and now they need to wait even more".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:16:39 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Dec 2019 20:16:39 +0000
Subject: [issue39149] False positive using operator 'AND' while checking keys
 on dict()
In-Reply-To: <1577557910.45.0.43701821857.issue39149@roundup.psfhosted.org>
Message-ID: <1577564199.12.0.265422932325.issue39149@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

P.S. You should also read the "Operator precedence" section for expressions in the Python Language Reference manual which explains that comparison operators bind tighter than Boolean AND operators:

https://docs.python.org/3/reference/expressions.html#operator-precedence

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39149>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:31:46 2019
From: report at bugs.python.org (Leonardo Galani)
Date: Sat, 28 Dec 2019 20:31:46 +0000
Subject: [issue39149] False positive using operator 'AND' while checking keys
 on dict()
In-Reply-To: <1577557910.45.0.43701821857.issue39149@roundup.psfhosted.org>
Message-ID: <1577565106.38.0.186900688784.issue39149@roundup.psfhosted.org>


Leonardo Galani <leo at leonardobg.com.br> added the comment:

I would totally agree if it wasn't for this:

>>> 'a' and 'b' and 'g' in dict
False

The last evaluation is False, making the whole statement False.

but thanks for the documentation link and stackoverflow suggestion.
it sure does make the code more readable.

Happy new year!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39149>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:42:04 2019
From: report at bugs.python.org (xitop)
Date: Sat, 28 Dec 2019 20:42:04 +0000
Subject: [issue38085] Interrupting class creation in __init_subclass__ may
 lead to incorrect isinstance() and issubclass() results
In-Reply-To: <1568106581.16.0.558052842785.issue38085@roundup.psfhosted.org>
Message-ID: <1577565724.01.0.637695452255.issue38085@roundup.psfhosted.org>


xitop <reg.bugs at poti.sk> added the comment:

Please, could some experienced Python developer take a look at this issue reported more than 3 month ago?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38085>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:05:03 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Dec 2019 22:05:03 +0000
Subject: [issue39112] Misleading documentation for tuple
In-Reply-To: <1576891699.24.0.656089355811.issue39112@roundup.psfhosted.org>
Message-ID: <1577570703.65.0.916857546268.issue39112@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fix some class entries in 'Built-in Functions'

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39112>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:09:05 2019
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 28 Dec 2019 22:09:05 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1577570945.73.0.190398328823.issue38938@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

PR 17729 is a C implementation of a non-recursive "flattening" of the the recursive-lazy-mergesort algorithm into a tournament whose state is a tree of losers of comparisons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:10:24 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Dec 2019 22:10:24 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577571024.43.0.114002375665.issue34118@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I closed #39112, about tuple only, as a duplicate of this.

----------
keywords: +patch
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:16:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Dec 2019 22:16:08 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577571368.65.0.170731526693.issue39136@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6c7bb38ff2799ac218e6df598b2b262f89e2bc1e by Terry Jan Reedy (Gurupad Hegde) in branch 'master':
bpo-39136: Fixed typos (GH-17720)
https://github.com/python/cpython/commit/6c7bb38ff2799ac218e6df598b2b262f89e2bc1e


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:23:10 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 28 Dec 2019 22:23:10 +0000
Subject: [issue39148] DatagramProtocol + IPv6 does not work with
 ProactorEventLoop
In-Reply-To: <1577530511.62.0.532247879973.issue39148@roundup.psfhosted.org>
Message-ID: <1577571790.89.0.850539226314.issue39148@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39148>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:57:03 2019
From: report at bugs.python.org (Tim Peters)
Date: Sat, 28 Dec 2019 22:57:03 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577573823.88.0.306965630537.issue39143@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Oh, I don't expect it to help appreciably - which is why I never did it ;-)  It's aimed at something different, I think, than what you're after:  reducing the burden of cyclic gc on objects that would otherwise soon be reclaimed by refcounting anyway.  But such stuff is going to get reclaimed "soon" regardless, and saving it from getting scanned by gc at most once has limited potential.

You seem aimed more at reclaiming _cyclic_ trash sooner.  The hack I sketched would only help with that if a cycle in part B became "theoretically dead" before part A filled up enough to trigger another collection.  But I have no guess as to the distribution of cycle lifetimes, other than that it's bound to vary a lot across programs, and will be multi-modal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:20:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 23:20:24 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577575224.62.0.945493827345.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Oh, I don't expect it to help appreciably - which is why I never did it ;-)  It's aimed at something different, I think, than what you're after:  reducing the burden of cyclic gc on objects that would otherwise soon be reclaimed by refcounting anyway.  But such stuff is going to get reclaimed "soon" regardless, and saving it from getting scanned by gc at most once has limited potential.

What I wanted to say is that this idea is still interesting to benchmark and experiment on its own, especially because is simple enough.

>You seem aimed more at reclaiming _cyclic_ trash sooner.  The hack I sketched would only help with that if a cycle in part B became "theoretically dead" before part A filled up enough to trigger another collection.  But I have no guess as to the distribution of cycle lifetimes, other than that it's bound to vary a lot across programs, and will be multi-modal.

That is right (I was also looking to solve the case in which an object is referred by something in an older generation, then is promoted and almost immediately the referent dies - or it was dead to begin with -).  I think evolving from your proposal into something in which the first generation is split into two "sub-generations" with the same threshold that is collected at the same time should not be very complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:25:03 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Dec 2019 23:25:03 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577575503.8.0.0581246537773.issue39136@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +17176
pull_request: https://github.com/python/cpython/pull/17731

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:33:08 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 23:33:08 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577575988.3.0.620031248528.issue39143@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


Added file: https://bugs.python.org/file48807/vanilla-vs-buffered.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:33:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 23:33:17 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577575997.78.0.250513513474.issue39143@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


Added file: https://bugs.python.org/file48808/diff-vanilla-buffered.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:37:38 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 28 Dec 2019 23:37:38 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577576258.15.0.748300159092.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have attached two files to the issue. One of them (vanilla-vs-buffered) shows the mean memory profile of running test_asyncio 1000 times with the buffered GC and without the buffered GC. The other file shows the difference between both curves.

test_ascyncio is not a "production application" but is the longest and less specific test that we have. I have experimented with some tests in the pyperformance suite and they show some similitudes like some memory spikes seem to be smaller and less memory usage in flat regions after collections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 19:05:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Dec 2019 00:05:21 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577577921.18.0.908542618897.issue39136@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset df647f3340d7a40628ba731f80425cb469e72653 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-39136: Fixed typos (GH-17720)
https://github.com/python/cpython/commit/df647f3340d7a40628ba731f80425cb469e72653


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sat Dec 28 19:28:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Dec 2019 00:28:46 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577579326.28.0.937239543737.issue39136@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +17177
pull_request: https://github.com/python/cpython/pull/17732

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:45:21 2019
From: report at bugs.python.org (Andy Lester)
Date: Sun, 29 Dec 2019 01:45:21 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
Message-ID: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

PyToken_OneChar in Parser/token.c is autogenerated.  I suspect it may be faster and smaller if it were a lookup into a static table of ops rather than a switch statement.  Check to see if it is.

----------
components: Interpreter Core
messages: 358975
nosy: petdance
priority: normal
severity: normal
status: open
title: See if PyToken_OneChar would be faster as a lookup table
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Sat Dec 28 22:42:29 2019
From: report at bugs.python.org (Tim Peters)
Date: Sun, 29 Dec 2019 03:42:29 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577590949.24.0.735693967024.issue39143@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

All right!  So, at a first look, "buffering" isn't an obvious disaster ;-)

I'm afraid nailing anything here is hard.  For example, I don't know what you did to "measure memory", but if you're using stats reported by the OS, that's fraught with dangers too.  Python's small-object allocator makes only weak attempts to return memory "to C", which in turn may or may not return memory to "the system".

One way to do better is to call `sys._debugmallocstats()` and stare at the output.  The "# bytes in allocated blocks" output line is an exact count of the number of bytes pymalloc is currently hanging on to for objects that have been allocated but not yet freed.  The point is that C - and the OS - have nothing to do with this value.  The downside:  objects > 512 bytes aren't included at all in this (pymalloc passes on requests for > 512 bytes to the system malloc(), and doesn't keep track of them).

Anyway, so far, so good!  Looks worth pursuing :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 22:52:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 03:52:57 +0000
Subject: [issue39143] Implementing sub-generation steps in the gc
In-Reply-To: <1577482504.11.0.390249633882.issue39143@roundup.psfhosted.org>
Message-ID: <1577591577.18.0.786882000753.issue39143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I'm afraid nailing anything here is hard.  For example, I don't know what you did to "measure memory", but if you're using stats reported by the OS, that's fraught with dangers too. 

I am interposing a custom allocator to track all the used blocks in all used pools in all arenas and then monitor all the memmap/malloc allocations. I get the same results if I don't use obmalloc (setting the PYTHONMALLOC=malloc) env var, which is more straightforward as I can just interpose a malloc implementation using LD_PRELOAD or a simple custom allocator. I don't claim to be exact but is better than just checking the resident size.

I didn't want to use sys._debugmallocstats() so printing to stdout does not impact performance, as I was also checking that the code does not make the interpreter slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 22:59:28 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 03:59:28 +0000
Subject: [issue39151] Simplify the deep-first-search of the assembler
Message-ID: <1577591968.17.0.626428145875.issue39151@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

I was recently checking the code of the assembler and when looking in detail at the dfs() function I was surprised by this code:

static void
dfs(struct compiler *c, basicblock *b, struct assembler *a, int end)
{
....

    while (j < end) {
        b = a->a_postorder[j++];
        for (i = 0; i < b->b_iused; i++) {
            struct instr *instr = &b->b_instr[i];
            if (instr->i_jrel || instr->i_jabs)
                dfs(c, instr->i_target, a, j);
        }
        assert(a->a_nblocks < j);
        a->a_postorder[a->a_nblocks++] = b;
    }
}

In particular, the recursive call to:

dfs(c, instr->i_target, a, j)

I cannot imagine a situation in which the previous for loop

    for (j = end; b && !b->b_seen; b = b->b_next) {
        b->b_seen = 1;
        assert(a->a_nblocks < j);
        a->a_postorder[--j] = b;
    }

has not visited all blocks (so the b_seen is already set) and in which the recursion will do something meaninfull. Indeed, as a naive check, simplifying the function to (no recursive call):

static void
dfs(struct compiler *c, basicblock *b, struct assembler *a, int end)
{
    int i, j;

    for (j = end; b && !b->b_seen; b = b->b_next) {
        b->b_seen = 1;
        assert(a->a_nblocks < j);
        a->a_postorder[--j] = b;
    }
    while (j < end) {
        b = a->a_postorder[j++];
        assert(a->a_nblocks < j);
        a->a_postorder[a->a_nblocks++] = b;
    }
}

passes the full test suite. I am missing something? Even if I am missing something I think that situation should be added to the test suite so It mativated me to open the issue.

----------
components: Interpreter Core
messages: 358978
nosy: Mark.Shannon, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Simplify the deep-first-search of the assembler
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39151>
_______________________________________

From report at bugs.python.org  Sun Dec 29 00:04:43 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 29 Dec 2019 05:04:43 +0000
Subject: [issue15723] Python breaks OS' append guarantee on file writes
In-Reply-To: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za>
Message-ID: <1577595883.8.0.212431102749.issue15723@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15723>
_______________________________________

From report at bugs.python.org  Sun Dec 29 00:16:12 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 29 Dec 2019 05:16:12 +0000
Subject: [issue25087] Type variable substitution in type instances
In-Reply-To: <1442152338.46.0.937548163334.issue25087@psf.upfronthosting.co.za>
Message-ID: <1577596572.31.0.522559937652.issue25087@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yup, see comment in https://github.com/python/typing/pull/308 regarding #156.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25087>
_______________________________________

From report at bugs.python.org  Sun Dec 29 00:19:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 05:19:11 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1577596751.26.0.481902073431.issue39150@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> PyToken_OneChar in Parser/token.c is autogenerated.  I suspect it may be faster and smaller if it were a lookup into a static table of ops rather than a switch statement.  Check to see if it is.

I suspect that it will be marginally faster (because it won't need to do bound checks to go to the default case) but under PGO it will make almost no difference.

You can try to see if there is any significant improvement using the pyperformance suite (https://pyperformance.readthedocs.io/) with and without your change (with PGO/LTO activated).

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Sun Dec 29 00:21:08 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 29 Dec 2019 05:21:08 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577596868.51.0.750166355395.issue39134@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Have you tried dropping ABCMeta? Mypy checks @abstractmethod regardless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Sun Dec 29 00:52:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 05:52:11 +0000
Subject: [issue39151] Simplify the deep-first-search of the assembler
In-Reply-To: <1577591968.17.0.626428145875.issue39151@roundup.psfhosted.org>
Message-ID: <1577598731.15.0.395636462717.issue39151@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17178
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17733

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39151>
_______________________________________

From report at bugs.python.org  Sun Dec 29 01:19:06 2019
From: report at bugs.python.org (Andy Lester)
Date: Sun, 29 Dec 2019 06:19:06 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1577600346.83.0.85522796277.issue39150@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Thank you. I appreciate the pointer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Sun Dec 29 01:41:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Dec 2019 06:41:13 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577601673.58.0.245557007678.issue39136@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset d7947280a4ba9dc652c3fac22946466338ec6999 by Terry Jan Reedy in branch '3.7':
[3.7] bpo-39136: Fixed typos (GH-17720)
https://github.com/python/cpython/commit/d7947280a4ba9dc652c3fac22946466338ec6999


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sun Dec 29 01:41:58 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Dec 2019 06:41:58 +0000
Subject: [issue39136] Typos in whatsnew file and docs
In-Reply-To: <1577348403.57.0.3073501707.issue39136@roundup.psfhosted.org>
Message-ID: <1577601718.65.0.848165149521.issue39136@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks for the report and patch.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39136>
_______________________________________

From report at bugs.python.org  Sun Dec 29 04:40:00 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 29 Dec 2019 09:40:00 +0000
Subject: [issue5851] Add a stream parameter to gc.set_debug
In-Reply-To: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
Message-ID: <1577612400.16.0.514253969451.issue5851@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@nicdumz are you still interested in this issue?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5851>
_______________________________________

From report at bugs.python.org  Sun Dec 29 05:15:06 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 29 Dec 2019 10:15:06 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577614506.59.0.545714431079.issue38588@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17179
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17734

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Sun Dec 29 06:49:32 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 29 Dec 2019 11:49:32 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1577620172.14.0.736244608474.issue39145@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> You can close again if you feel this isn't a bug.

Yep, it's still not a bug. As Steven said, Python is correctly (modulo undiscovered bugs) implementing the C3 algorithm, and the C3 algorithm does indeed fail in this case.

----------
nosy: +mark.dickinson
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Sun Dec 29 08:05:33 2019
From: report at bugs.python.org (Giovanni Lombardo)
Date: Sun, 29 Dec 2019 13:05:33 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
Message-ID: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>


New submission from Giovanni Lombardo <g.lombardo at protonmail.com>:

The issue arises by simply calling configure on the Scale widget of the themed tk (ttk) widgets set:

```
cursor = scale.configure('cursor')[-1]
```

The above casues the following error:

```
File "C:\Users\Giovanni\Tests\test_scale.py", line 604, in main
    cursor = scale.configure('cursor')[-1]
File "C:\Users\Giovanni\AppData\Local\Programs\Python\Python37\lib\tkinter\ttk.py", line 1090, in configure
    kw.update(cnf)
ValueError: dictionary update sequence element #0 has length 1; 2 is required
```

The interpreter is:

```
Python 3.7.4 (tags/v3.7.4:e09359112e, Jul  8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32```

----------
components: Tkinter
messages: 358987
nosy: glombardo
priority: normal
severity: normal
status: open
title: Faulty override of tkinter.Misc.configure in tkinter.ttk.Scale.configure
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39152>
_______________________________________

From report at bugs.python.org  Sun Dec 29 08:33:59 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Dec 2019 13:33:59 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
Message-ID: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The documentation for PyList_SetItem is explicit that it steals a reference to the passed in value, and drops the reference for any existing entry: https://docs.python.org/3.3/c-api/list.html?highlight=m#PyList_SetItem

The documentation for PyDict_SetItem leaves the semantics unspecified, forcing the reader to either make assumptions, or else go read the source code (as was done for the SO answer at https://stackoverflow.com/questions/40700251/reference-counting-using-pydict-setitemstring)

Since the default assumption is actually correct, I don't think a Sphinx note is warranted, but an extra explicit sentence would be helpful.

PySequence_SetItem has such a sentence already: "This function does *not* steal a reference to v."

My suggestion is that we also add that sentence to the documentation for:

* PyObject_SetItem
* PyMapping_SetItemString
* PyDict_SetItem
* PyDict_SetItemString

----------
messages: 358988
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Clarify refcounting semantics of PyDict_SetItem[String]

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Sun Dec 29 08:34:20 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Dec 2019 13:34:20 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1577626460.47.0.562915842225.issue39153@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Sun Dec 29 08:57:20 2019
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Dec 2019 13:57:20 +0000
Subject: [issue39151] Simplify the deep-first-search of the assembler
In-Reply-To: <1577591968.17.0.626428145875.issue39151@roundup.psfhosted.org>
Message-ID: <1577627840.58.0.916568464492.issue39151@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

This seems correct, but your change assumes that there is no optimisation pass that reorders the blocks.
While the is currently true, it might not be in future.

The code that orders blocks for output should not make assumptions about the shape of the CFG, IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39151>
_______________________________________

From report at bugs.python.org  Sun Dec 29 10:47:12 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 29 Dec 2019 15:47:12 +0000
Subject: [issue24174] Python crash on exit
In-Reply-To: <1431517823.23.0.704050374474.issue24174@psf.upfronthosting.co.za>
Message-ID: <1577634432.44.0.82394679976.issue24174@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

The link you gave is broken, can you give a simple code to reproduce the issue?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24174>
_______________________________________

From report at bugs.python.org  Sun Dec 29 11:42:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 16:42:49 +0000
Subject: [issue39151] Simplify the deep-first-search of the assembler
In-Reply-To: <1577591968.17.0.626428145875.issue39151@roundup.psfhosted.org>
Message-ID: <1577637769.41.0.986426548555.issue39151@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The code that orders blocks for output should not make assumptions about the shape of the CFG, IMO.

I very much agree with this but notice that technically this function is doing it already if I am not mistaken. Following the b_next pointers in the first for loop already relies on the topological order in which they were emitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39151>
_______________________________________

From report at bugs.python.org  Sun Dec 29 11:56:50 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 16:56:50 +0000
Subject: [issue5851] Add a stream parameter to gc.set_debug
In-Reply-To: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
Message-ID: <1577638610.98.0.384424179076.issue5851@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am not convinced about this. One of the problems I dislike is that the gc will take permanent ownership of the file descriptor (so is basically leaked). Is also not clear how this will behave during the delicate stages of finalization (the stream object provided can be anything that we have no control over during finalization) and also, it makes it a bit riskier as this can execute arbitrary python code in the middle of the gc.

On the other hand, is possible to use the gc callbacks to gather similar statistics about collections doing whatever you need there (like writing to file descriptors and the such).

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5851>
_______________________________________

From report at bugs.python.org  Sun Dec 29 11:57:55 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 29 Dec 2019 16:57:55 +0000
Subject: [issue24174] Python crash on exit
In-Reply-To: <1431517823.23.0.704050374474.issue24174@psf.upfronthosting.co.za>
Message-ID: <1577638675.04.0.453716354773.issue24174@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Currently lollypop seems to be residing at https://gitlab.gnome.org/World/lollypop
However, this issue is filled against a no longer supported version which along with many changes in the C code warrants out-of-date closure, I think. C?dric, please re-open this issue if you're still experiencing this crash on a recent Python version.

----------
nosy: +SilentGhost
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24174>
_______________________________________

From report at bugs.python.org  Sun Dec 29 12:42:10 2019
From: report at bugs.python.org (Peter Ludemann)
Date: Sun, 29 Dec 2019 17:42:10 +0000
Subject: [issue39154] "utf8-sig" missing from codecs (inconsistency)
Message-ID: <1577641330.32.0.40121523181.issue39154@roundup.psfhosted.org>


New submission from Peter Ludemann <peter.ludemann at gmail.com>:

In general, 'utf8' and 'utf-8' are interchangeable in the codecs (and in many parts of the Python library). However, 'utf8-sig' is missing ... and it happens to also be generated by lib2to3.tokenize.detect_encoding.

>>> import codecs
>>> codecs.getincrementaldecoder('utf-8-sig')()
<encodings.utf_8_sig.IncrementalDecoder object at 0x7fecbcdbbc10>
>>> codecs.getincrementaldecoder('utf8-sig')()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/codecs.py", line 987, in getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: utf8-sig

----------
components: Unicode
messages: 358994
nosy: Peter Ludemann, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: "utf8-sig" missing from codecs (inconsistency)
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Sun Dec 29 12:48:02 2019
From: report at bugs.python.org (Peter Ludemann)
Date: Sun, 29 Dec 2019 17:48:02 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641330.32.0.40121523181.issue39154@roundup.psfhosted.org>
Message-ID: <1577641682.29.0.16123079146.issue39154@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

lib2to3.tokenize should allow 'utf8' and 'utf-8' interchangeably, to be consistent with the rest of the Python library (I looked through the library source, and there seems to be no consistent preference, and also many (but not all) checks for 'utf-8' also check for 'utf8'). In particular, tokenize.detect_encoding should have code for both forms, as the encoding can be set by the user. Also, code should allow for 'UTF8' and 'UTF-8'.

See also https://bugs.python.org/issue39154

(This is probably a larger issue than just lib2to3, as a quick grep through /usr/lib/python3.7 showed; but not sure how to best address that.)

----------
components: +2to3 (2.x to 3.x conversion tool) -Unicode
title: "utf8-sig" missing from codecs (inconsistency) -> "utf8" not always a synonym for "utf-8" in lib2to3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:14:13 2019
From: report at bugs.python.org (Peter Ludemann)
Date: Sun, 29 Dec 2019 18:14:13 +0000
Subject: [issue39155] "utf8-sig" missing from codecs (inconsistency)
Message-ID: <1577643253.55.0.467066593045.issue39155@roundup.psfhosted.org>


New submission from Peter Ludemann <peter.ludemann at gmail.com>:

In general, 'utf8' and 'utf-8' are interchangeable in the codecs (and in many parts of the Python library). However, 'utf8-sig' is missing ... and it happens to also be generated by lib2to3.tokenize.detect_encoding.

>>> import codecs
>>> codecs.getincrementaldecoder('utf-8-sig')()
<encodings.utf_8_sig.IncrementalDecoder object at 0x7fecbcdbbc10>
>>> codecs.getincrementaldecoder('utf8-sig')()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/codecs.py", line 987, in getincrementaldecoder
    decoder = lookup(encoding).incrementaldecoder
LookupError: unknown encoding: utf8-sig

----------
components: Unicode
messages: 358996
nosy: Peter Ludemann, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: "utf8-sig" missing from codecs (inconsistency)
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39155>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:15:26 2019
From: report at bugs.python.org (Peter Ludemann)
Date: Sun, 29 Dec 2019 18:15:26 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641330.32.0.40121523181.issue39154@roundup.psfhosted.org>
Message-ID: <1577643326.28.0.118604526717.issue39154@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

(oops -- updated this bug instead of submitting a new one)
See also https://bugs.python.org/issue39155

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:40:50 2019
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Dec 2019 18:40:50 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577644850.22.0.619430805702.issue39114@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Exammining the bytecode for:

def finally_return():
    try:
        return 14
    finally:
        a.append(16)

We have:

  2           0 SETUP_FINALLY           16 (to 18)

  3           2 POP_BLOCK

  5           4 LOAD_GLOBAL              0 (a)
              6 LOAD_METHOD              1 (append)
              8 LOAD_CONST               1 (16)
             10 CALL_METHOD              1
             12 POP_TOP

  3          14 LOAD_CONST               2 (14)

  5          16 RETURN_VALUE
        >>   18 LOAD_GLOBAL              0 (a)
             20 LOAD_METHOD              1 (append)
             22 LOAD_CONST               1 (16)
             24 CALL_METHOD              1
             26 POP_TOP
             28 RERAISE
             30 LOAD_CONST               0 (None)
             32 RETURN_VALUE

Which looks correct, except for the line number of the first RETURN_VALUE.

Looking at the compiler it seems that we aren't preserving the original line number when emitting code for the finally block.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:46:26 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 18:46:26 +0000
Subject: [issue5851] Add a stream parameter to gc.set_debug
In-Reply-To: <1240813443.12.0.48308121403.issue5851@psf.upfronthosting.co.za>
Message-ID: <1577645186.33.0.539728279332.issue5851@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am going to close this for now as per my last comment (I think gc callbacks are best suited for custom statistics and custom behaviour when emitting the statistics - and more importantly, safer -) but feel free to re-open if you still think we didn't consider something important.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5851>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:48:04 2019
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Dec 2019 18:48:04 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577645284.42.0.00274250426313.issue39114@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +17180
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17737

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:48:37 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 18:48:37 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577645317.12.0.27286677606.issue38870@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17181
pull_request: https://github.com/python/cpython/pull/17738

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:50:07 2019
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Dec 2019 18:50:07 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577645407.56.0.625673991479.issue39114@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

With PR 17737 the bytecode is:

  2           0 SETUP_FINALLY           16 (to 18)

  3           2 POP_BLOCK

  5           4 LOAD_GLOBAL              0 (a)
              6 LOAD_METHOD              1 (append)
              8 LOAD_CONST               1 (16)
             10 CALL_METHOD              1
             12 POP_TOP

  3          14 LOAD_CONST               2 (14)
             16 RETURN_VALUE

  5     >>   18 LOAD_GLOBAL              0 (a)
             20 LOAD_METHOD              1 (append)
             22 LOAD_CONST               1 (16)
             24 CALL_METHOD              1
             26 POP_TOP
             28 RERAISE
             30 LOAD_CONST               0 (None)
             32 RETURN_VALUE

----------
keywords:  -patch
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Sun Dec 29 14:21:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 19:21:06 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577647266.74.0.287246952758.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 23a226bf3ae7b462084e899d007d12d9fe398ac5 by Pablo Galindo in branch 'master':
bpo-38870: Run always tests that heavily use grammar features in test_unparse (GH-17738)
https://github.com/python/cpython/commit/23a226bf3ae7b462084e899d007d12d9fe398ac5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Sun Dec 29 14:44:42 2019
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 29 Dec 2019 19:44:42 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
Message-ID: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Currently the COMPARE_OP instruction performs one of four different tasks.
We should break it up into four different instructions, that each performs only one of those tasks.

The four tasks are:
  Rich comparison (>, <, ==, !=, >=, <=)
  Identity comparison (is, is not)
  Contains test (in, not in)
  Exception matching

The current implementation involves an unnecessary extra dispatch to determine which task to perform.
Comparisons are common operations, so this extra call and unpredictable branch has a cost.

In addition, testing for exception matching is always followed by a branch, so the test and branch can be combined.

I propose adding three new instructions and changing the meaning of `COMPARE_OP`.

COMPARE_OP should only perform rich comparisons, and should call `PyObject_RichCompare` directly.
IS_OP performs identity tests, performs no calls and cannot fail.
CONTAINS_OP tests for 'in and 'not in' and should call `PySequence_Contains` directly.
JUMP_IF_NOT_EXC_MATCH Tests whether the exception matches and jumps if it does not.

----------
components: Interpreter Core
messages: 359002
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Break up COMPARE_OP into logically distinct operations.
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Sun Dec 29 14:48:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 19:48:20 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577648900.79.0.456412024787.issue38870@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17182
pull_request: https://github.com/python/cpython/pull/17739

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:34:09 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 20:34:09 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577651649.43.0.882713870294.issue39156@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:39:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 20:39:06 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577651946.37.0.416628045822.issue39156@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think is a good idea, being the only problem that I see that as the opcode targets are limited we would be burning 3 more. I specially like the proposal for JUMP_IF_NOT_EXC_MATCH as PyCmp_EXC_MATCH is only used in the code for the try-except and is always followed by a POP_JUMP_IF_FALSE.

As a curiosity, it would be good to have an idea on performance gains of specializing the comparison.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:51:55 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 20:51:55 +0000
Subject: [issue39157] test_pidfd_send_signal can fail on some systems with
 PermissionError: [Errno 1] Operation not permitted
Message-ID: <1577652715.56.0.81838626061.issue39157@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

======================================================================
FAIL: test_pidfd_send_signal (test.test_signal.PidfdSignalTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.pablogsal-arch-x86_64/build/Lib/test/test_signal.py", line 1287, in test_pidfd_send_signal
    self.assertEqual(cm.exception.errno, errno.EBADF)
AssertionError: 1 != 9
---------------------------------------------------------------------

Example failure:

https://buildbot.python.org/all/#/builders/231/builds/1/steps/5/logs/stdio

We should skip the test if the syscall is not permitted

----------
messages: 359004
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_pidfd_send_signal can fail on some systems with PermissionError: [Errno 1] Operation not permitted

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39157>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:54:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 20:54:34 +0000
Subject: [issue39157] test_pidfd_send_signal can fail on some systems with
 PermissionError: [Errno 1] Operation not permitted
In-Reply-To: <1577652715.56.0.81838626061.issue39157@roundup.psfhosted.org>
Message-ID: <1577652874.67.0.765776399214.issue39157@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17183
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17740

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39157>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:32:14 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Dec 2019 21:32:14 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577655134.58.0.353992032274.issue39156@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

When COMPARE_OP occurs in a loop, the dispatch tends to be branch predictable. So there may not be real-world performance benefit to splitting the opcodes.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:36:03 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 21:36:03 +0000
Subject: [issue39157] test_pidfd_send_signal can fail on some systems with
 PermissionError: [Errno 1] Operation not permitted
In-Reply-To: <1577652715.56.0.81838626061.issue39157@roundup.psfhosted.org>
Message-ID: <1577655363.11.0.172162986144.issue39157@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 8f0703ff92ed2d9ccd52d7e083c7bc26e732a428 by Pablo Galindo in branch 'master':
bpo-39157: Skip test_pidfd_send_signal if the system does not have enough privileges to use pidfd (GH-17740)
https://github.com/python/cpython/commit/8f0703ff92ed2d9ccd52d7e083c7bc26e732a428


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39157>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:42:10 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Dec 2019 21:42:10 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
Message-ID: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

We already support sets but not empty sets.  After the PR, this now works:

    >>> from ast import literal_eval
    >>> literal_eval('set()')
    set()

If we wanted, it would be a simple matter to extend it frozensets:

    >>> literal_eval('frozenset({10, 20, 30})')
    frozenset({10, 20, 30})

----------
components: Library (Lib)
messages: 359007
nosy: rhettinger
priority: normal
severity: normal
status: open
title: ast.literal_eval() doesn't support empty sets
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:44:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Dec 2019 21:44:40 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1577655880.52.0.0565051766642.issue39153@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The documentation for PyList_SetItem is explicit because its behavior is an exception from common rule and differs from PyList_SET_ITEM, so both should be documented explicitly.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:48:27 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Dec 2019 21:48:27 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1577656107.0.0.11935256336.issue39158@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +17184
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17742

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:48:23 2019
From: report at bugs.python.org (Batuhan)
Date: Sun, 29 Dec 2019 21:48:23 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1577656103.32.0.609673042268.issue39158@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:54:48 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Dec 2019 21:54:48 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577656488.76.0.0641898178332.issue39156@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Few years ago I experimented with a special opcode for exception matching. It could make the bytecode a tiny bit smaller and faster, but since catching an exception in Python is relatively expensive, it would not have significant performance benefit.

As for splitting COMPARE_OP for comparison, identity and containment tests, all these operations look the same from the compiler side, they correspond the same AST node. Introducing new opcodes will complicate the compiler.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:57:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Dec 2019 21:57:06 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1577656626.18.0.247228499818.issue39158@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

set() is neither literal nor container display.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 29 17:08:41 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 29 Dec 2019 22:08:41 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1577657321.37.0.0670427338444.issue39158@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 29 17:22:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Dec 2019 22:22:50 +0000
Subject: [issue39159] Ideas for making ast.literal_eval() usable
Message-ID: <1577658169.97.0.393062022698.issue39159@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

A primary goal for ast.literal_eval() is to "Safely evaluate an expression node or a string".

In the context of a real application, we need to do several things to make it possible to fulfill its design goal:

1) We should document possible exceptions that need to be caught.  So far, I've found TypeError, MemoryError, SyntaxError, ValueError.

2) Define a size limit guaranteed not to give a MemoryError.  The smallest unsafe size I've found so far is 301 characters:

     s = '(' * 100 + '0' + ',)' * 100
     literal_eval(s)                    # Raises a MemoryError

3) Consider writing a standalone expression compiler that doesn't have the same small limits as our usual compile() function.  This would make literal_eval() usable for evaluating tainted inputs with bigger datasets. (Imagine if the json module could only be safely used with inputs under 301 characters).

4) Perhaps document an example of how we suggest that someone process tainted input:

     expr = input('Enter a dataset in Python format: ')
     if len(expr) > 300:
        error(f'Maximum supported size is 300, not {len(expr)}')
     try:
        data = literal_eval(expr)
     except (TypeError, MemoryError, SyntaxError, ValueError):
        error('Input cannot be evaluated')

----------
messages: 359011
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Ideas for making ast.literal_eval() usable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39159>
_______________________________________

From report at bugs.python.org  Sun Dec 29 17:35:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Dec 2019 22:35:17 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1577658917.09.0.0525662751064.issue39158@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> set() is neither literal nor container display.

Yes, that is obvious.  However, we do support sets and set() is how make an empty set.   

It is weird to support sets but not empty sets, especially when it is so easy to do so safely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 29 17:37:20 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Dec 2019 22:37:20 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577659040.44.0.286393785063.issue39156@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Introducing new opcodes will complicate the compiler.

And it will complicate opcode.py and peephole.c and anything else that touches the word codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Sun Dec 29 22:45:04 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 03:45:04 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
Message-ID: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>


New submission from anthony shaw <anthony.p.shaw at gmail.com>:

I've noticed that ./configure --help is inconsistent.

- The way default values are shared
- The way enumerated 
- The verbs used (e.g. enable, set)
- Some --with-xyx and some --with(out-xyz)
- Some start with capitals, others don't

Also, many of the flags could use additional explanation as to their purpose, or reference the rST file in the doc that explains what they do.

PR to follow

----------
components: Build
messages: 359014
nosy: anthony shaw
priority: normal
severity: normal
status: open
title: ./configure --help has inconsistencies in style

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Sun Dec 29 22:46:15 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 03:46:15 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1577677575.95.0.259205804979.issue39160@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

Current 

 Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --enable-universalsdk[=SDKDIR]
                          Build fat binary against Mac OS X SDK
  --enable-framework[=INSTALLDIR]
                          Build (MacOSX|Darwin) framework
  --enable-shared         disable/enable building shared python library
  --enable-profiling      enable C-level code profiling
  --enable-optimizations  Enable expensive, stable optimizations (PGO, etc).
                          Disabled by default.
  --enable-loadable-sqlite-extensions
                          support loadable extensions in _sqlite module
  --enable-ipv6           Enable ipv6 (with ipv4) support
  --disable-ipv6          Disable ipv6 support
  --enable-big-digits[=BITS]
                          use big digits for Python longs [[BITS=30]]

 Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-universal-archs=ARCH
                          select architectures for universal build ("32-bit",
                          "64-bit", "3-way", "intel", "intel-32", "intel-64",
                          or "all")
  --with-framework-name=FRAMEWORK
                          specify an alternate name of the framework built
                          with --enable-framework
  --with-cxx-main=<compiler>
                          compile main() and link python executable with C++
                          compiler
  --with-suffix=.exe      set executable suffix
  --with-pydebug          build with Py_DEBUG defined
  --with-trace-refs       enable tracing references for debugging purpose
  --with-assertions       build with C assertions enabled
  --with-lto              Enable Link Time Optimization in any build. Disabled
                          by default.
  --with-hash-algorithm=[fnv|siphash24]
                          select hash algorithm
  --with-address-sanitizer
                          enable AddressSanitizer (asan)
  --with-memory-sanitizer enable MemorySanitizer (msan)
  --with-undefined-behavior-sanitizer
                          enable UndefinedBehaviorSanitizer (ubsan)
  --with-libs='lib1 ...'  link against additional libs
  --with-system-expat     build pyexpat module using an installed expat
                          library
  --with-system-ffi       build _ctypes module using an installed ffi library
  --with-system-libmpdec  build _decimal module using an installed libmpdec
                          library
  --with-tcltk-includes='-I...'
                          override search for Tcl and Tk include files
  --with-tcltk-libs='-L...'
                          override search for Tcl and Tk libs
  --with-dbmliborder=db1:db2:...
                          order to check db backends for dbm. Valid value is a
                          colon separated string with the backend names
                          `ndbm', `gdbm' and `bdb'.
  --with(out)-doc-strings disable/enable documentation strings
  --with(out)-pymalloc    disable/enable specialized mallocs
  --with(out)-c-locale-coercion
                          disable/enable C locale coercion to a UTF-8 based
                          locale
  --with-valgrind         Enable Valgrind support
  --with(out)-dtrace      disable/enable DTrace support
  --with-libm=STRING      math library
  --with-libc=STRING      C library
  --with(out)-computed-gotos
                          Use computed gotos in evaluation loop (enabled by
                          default on supported compilers)
  --with(out)-ensurepip=[=upgrade]
                          "install" or "upgrade" using bundled pip
  --with-openssl=DIR      root of the OpenSSL directory
  --with-ssl-default-suites=[python|openssl|STRING]
                          Override default cipher suites string, python: use
                          Python's preferred selection (default), openssl:
                          leave OpenSSL's defaults untouched, STRING: use a
                          custom string, PROTOCOL_SSLv2 ignores the setting

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Sun Dec 29 22:50:08 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 03:50:08 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1577677808.48.0.253570532253.issue39160@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

Updated version based on principles:

- Should not specify --with(out) in help string
- Sentences should start with lowercase (as autoconf generates the builtin string with lower case)
- --with-xyx=VALUE will be described as "overriding"
- --with-xyz will be described as "enabling" said feature
- Mac flags should have the same descriptions as what is in Mac/README.rst
- default value should be in brackets (if known)
- Enumerated options should be shown as =VAL1|VAL2 or [=VAL1|VAL2] if optional

 Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --enable-universalsdk[=SDKDIR]
                          create a universal binary build. SDKDIR specifies
                          which macOS SDK should be used to perform the build,
                          see Mac/README.rst. (default is no)
  --enable-framework[=INSTALLDIR]
                          create a Python.framework rather than a traditional
                          Unix install. optional INSTALLDIR specifies the
                          installation path. see Mac/README.rst (default is
                          no)
  --enable-shared         enable building a shared Python library (default is
                          no)
  --enable-profiling      enable C-level code profiling with gprof (default is
                          no)
  --enable-optimizations  enable expensive, stable optimizations (PGO, etc.)
                          (default is no)
  --enable-loadable-sqlite-extensions
                          support loadable extensions in _sqlite module, see
                          Doc/library/sqlite3.rst (default is no)
  --enable-ipv6           enable ipv6 (with ipv4) support, see
                          Doc/library/socket.rst (default is yes if supported)
  --enable-big-digits[=15|30]
                          use big digits (30 or 15 bits) for Python longs
                          (default is no)]

 Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-universal-archs=ARCH
                          specify the kind of universal binary that should be
                          created. this option is only valid when
                          --enable-universalsdk is set; options are:
                          ("32-bit", "64-bit", "3-way", "intel", "intel-32",
                          "intel-64", or "all") see Mac/README.rst
  --with-framework-name=FRAMEWORK
                          specify the name for the python framework on macOS
                          only valid when --enable-framework is set. see
                          Mac/README.rst (default is 'Python')
  --with-cxx-main[=COMPILER]
                          compile main() and link Python executable with C++
                          compiler specified in COMPILER (default is $CXX)
  --with-suffix=SUFFIX    set executable suffix to SUFFIX (default is '.exe')
  --with-pydebug          build with Py_DEBUG defined (default is no)
  --with-trace-refs       enable tracing references for debugging purpose
                          (default is no)
  --with-assertions       build with C assertions enabled (default is no)
  --with-lto              enable Link-Time-Optimization in any build (default
                          is no)
  --with-hash-algorithm=[fnv|siphash24]
                          select hash algorithm for use in Python/pyhash.c
                          (default is SipHash24)
  --with-address-sanitizer
                          enable AddressSanitizer memory allocation
                          controller, 'asan' (default is no)
  --with-memory-sanitizer enable MemorySanitizer memory allocation controller,
                          'msan' (default is no)
  --with-undefined-behavior-sanitizer
                          enable UndefinedBehaviorSanitizer memory allocation
                          controller, 'ubsan' (default is no)
  --with-libs='lib1 ...'  link against additional libs (default is no)
  --with-system-expat     build pyexpat module using an installed system expat
                          library, see Doc/library/pyexpat.rst (default is no)
  --with-system-ffi       build _ctypes module using an installed ffi library,
                          see Doc/library/ctypes.rst (default is system
                          dependant)
  --with-system-libmpdec  build _decimal module using an installed libmpdec
                          library, see Doc/library/decimal.rst (default is no)
  --with-tcltk-includes='-I...'
                          override search for Tcl and Tk include files
  --with-tcltk-libs='-L...'
                          override search for Tcl and Tk libs
  --with-dbmliborder=db1:db2:...
                          override order to check db backends for dbm. valid
                          value is a colon separated string with the backend
                          names `ndbm', `gdbm' and `bdb'.
  --with-doc-strings      enable documentation strings (default is yes)
  --with-pymalloc         enable specialized mallocs (default is yes)
  --with-c-locale-coercion
                          enable C locale coercion to a UTF-8 based locale
                          (default is yes)
  --with-valgrind         enable Valgrind support (default is no)
  --with-dtrace           enable DTrace support (default is no)
  --with-libm=STRING      override libm math library to STRING (default is
                          system dependant)
  --with-libc=STRING      override libc C library to STRING (default is system
                          dependant)
  --with-computed-gotos   enable computed gotos in evaluation loop (enabled by
                          default on supported compilers)
  --with-ensurepip[=install|upgrade|no]
                          "install" or "upgrade" using bundled pip (default is
                          upgrade)
  --with-openssl=DIR      override root of the OpenSSL directory to DIR
  --with-ssl-default-suites=[python|openssl|STRING]
                          override default cipher suites string, python: use
                          Python's preferred selection (default), openssl:
                          leave OpenSSL's defaults untouched, STRING: use a
                          custom string, PROTOCOL_SSLv2 ignores the setting,
                          see Doc/library/ssl.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Sun Dec 29 22:52:17 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 03:52:17 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1577677937.86.0.319524036253.issue39160@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +17185
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17747

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Sun Dec 29 22:57:24 2019
From: report at bugs.python.org (Noah Massman-Hall)
Date: Mon, 30 Dec 2019 03:57:24 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1577678244.38.0.243834523622.issue22593@roundup.psfhosted.org>


Change by Noah Massman-Hall <noah.massman at gmail.com>:


----------
pull_requests: +17186
pull_request: https://github.com/python/cpython/pull/17748

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Sun Dec 29 23:04:40 2019
From: report at bugs.python.org (Noah Massman-Hall)
Date: Mon, 30 Dec 2019 04:04:40 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1577678680.11.0.747443117292.issue22593@roundup.psfhosted.org>


Noah Massman-Hall <noah.massman at gmail.com> added the comment:

I ended up doing exactly what I said would probably be needed, and wrote a small sphinx extension that handles this. I kept the same reST substitution syntax, but I'm parsing for '|ucd_version|' as the source files are read in and just replacing it with the version number.

Feedback is much appreciated. This is my first really involved PR. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Sun Dec 29 23:15:35 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 04:15:35 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1577679335.49.0.247495179058.issue39160@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
nosy: +anthonypjshaw

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Sun Dec 29 23:18:47 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 04:18:47 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1577679527.33.0.732147988308.issue39160@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Sun Dec 29 23:58:34 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Dec 2019 04:58:34 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1577681914.03.0.607118517152.issue39153@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Right, that's why I don't think the other "*SetItem*" operations should get a Sphinx note - just a sentence, as was already done for PySequence_SetItem.

If it weren't for PyList_SetItem being different, none of the others would need the clarification at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Mon Dec 30 00:18:47 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Dec 2019 05:18:47 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
Message-ID: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

The Py_NewInterpreter docs only cover the behaviour of extension modules that use single-phase initialization: https://docs.python.org/3/c-api/init.html#c.Py_NewInterpreter

Multi-phase initialization allows each subinterpreter to get its own copy of extension modules as well, with only C/C++ level static and global variables being shared.

----------
assignee: docs at python
components: Documentation
messages: 359019
nosy: docs at python, ncoghlan, petr.viktorin
priority: normal
severity: normal
stage: needs patch
status: open
title: Py_NewInterpreter docs need updating for multi-phase initialization
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Mon Dec 30 00:24:57 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Dec 2019 05:24:57 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1577683497.38.0.326857909274.issue39037@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 226e6e7d4326cf91ef37e13528eb1f62de1bb832 by Nick Coghlan (G?ry Ogam) in branch 'master':
bpo-39037: Fix lookup order of magic methods in with statement documentation (GH-17608)
https://github.com/python/cpython/commit/226e6e7d4326cf91ef37e13528eb1f62de1bb832


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Mon Dec 30 00:25:48 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 05:25:48 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1577683548.36.0.257362276073.issue39037@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17187
pull_request: https://github.com/python/cpython/pull/17749

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Mon Dec 30 00:31:22 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 05:31:22 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1577683882.59.0.966716714921.issue39037@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cbfafa3e3625dae96ce392c88c793f8af55167bf by Miss Islington (bot) in branch '3.8':
bpo-39037: Fix lookup order of magic methods in with statement documentation (GH-17608)
https://github.com/python/cpython/commit/cbfafa3e3625dae96ce392c88c793f8af55167bf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:14:48 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 07:14:48 +0000
Subject: [issue39141] IDLE Clear function returns 256 on Mac OS Catalina
In-Reply-To: <1577470559.68.0.805755696987.issue39141@roundup.psfhosted.org>
Message-ID: <1577690088.24.0.94780846315.issue39141@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Unfortunately, this is not going to work as you expect because you are mixing commands for different windowing systems.  The OS-level 'clear' command is used to clear a normal terminal window by issuing special character sequences to standard output that are recognized by the terminal emulator, like for instance Terminal.app on macOS.  When you run commands using os.system() under IDLE on macOS, the standard output descriptor for the subprocess created by os.system is not handled by IDLE.  Currently open Issue11820 describes this problem.  You are apparently running IDLE.app (by launching the app from the Finder) and the command fails because standard output of the subprocess is not associated with a terminal window.  If, instead, you launched IDLE from a terminal window (in Terminal.app):

/usr/local/bin/idle3.8

and ran your test, you would see that the 'clear' clears the Terminal.app window, not the IDLE shell window (and now returns a status of 0), still not what you are looking for.

Even if Issue11820 is implemented such that the standard output from subprocesses are associated with the IDLE shell window, there would still be a problem in that the special character sequences sent by the 'clear' command would most likely not be recognized by the IDLE shell window or its underlying Tk widget, so using the OS 'clear' command still would not work.  A better solution is for IDLE to provide its own 'clear' command and that is the subject of open Issue6143, which this issue should probably be closed as a duplicate of.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39141>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:20:26 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 07:20:26 +0000
Subject: [issue39141] IDLE Clear function returns 256 on Mac OS Catalina
In-Reply-To: <1577470559.68.0.805755696987.issue39141@roundup.psfhosted.org>
Message-ID: <1577690426.94.0.401147378973.issue39141@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39141>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:33:20 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 30 Dec 2019 07:33:20 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577691200.37.0.198564207536.issue38588@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Would you benchmark the performance?

How about calling Py_INCREF and Py_DECREF in PyObject_RichCompare or do_richcompare?

It is safer than checking all caller of the PyObject_RichCompare and PyObject_RichCompareBool.
And it would be faster when PyObject_RichCompareBool is called with v == w and op == Py_EQ.

    /* Quick result when objects are the same.
       Guarantees that identity implies equality. */
    if (v == w) {
        if (op == Py_EQ)
            return 1;
        else if (op == Py_NE)
            return 0;
    }

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:37:27 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 07:37:27 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641682.29.0.16123079146.issue39154@roundup.psfhosted.org>
Message-ID: <1577691447.12.0.997146157222.issue39154@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg358994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:38:47 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 07:38:47 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641682.29.0.16123079146.issue39154@roundup.psfhosted.org>
Message-ID: <1577691527.42.0.167319404611.issue39154@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg358997

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:44:23 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 07:44:23 +0000
Subject: [issue22593] Automate update of doc references to UCD version when it
 changes.
In-Reply-To: <1412903498.5.0.872125887702.issue22593@psf.upfronthosting.co.za>
Message-ID: <1577691863.39.0.851078070421.issue22593@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, mdk
versions: +Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22593>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:46:00 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 07:46:00 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1577691960.97.0.928965504217.issue39160@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Mon Dec 30 02:51:30 2019
From: report at bugs.python.org (Peter Ludemann)
Date: Mon, 30 Dec 2019 07:51:30 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641682.29.0.16123079146.issue39154@roundup.psfhosted.org>
Message-ID: <1577692290.81.0.37124085413.issue39154@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

To clarify and fix a typo ... lib2to3.pgen2.tokenize.detect_encoding checks for 'utf-8'(and 'utf_8') but not 'utf8' in various places. Similarly for 'latin-1' and 'latin1'. (The codecs documentation page allows 'utf8' and 'latin1' as codecs.)

['UTF-8' is taken care of in _get_normal_name] 

See also https://bugs.python.org/issue39155

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Mon Dec 30 03:02:59 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 30 Dec 2019 08:02:59 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577692979.69.0.334507935385.issue38588@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

If we can not add INCREF and DECREF in the PyObject_RichCompare, we can add v == w check in the caller side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 03:35:06 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 08:35:06 +0000
Subject: [issue39162] setup.py not picking up tkinter headers
Message-ID: <1577694906.58.0.783001060452.issue39162@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

./configure && make -j4 is returning:

Failed to build these modules:
_tkinter                                                       

I'm running macOS 10.15.2, with the SDK installed using `xcode-select --install` (no funny business)

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tk.framework/

xcrun --show-sdk-path
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

If I debug setup.py, I can see it's eagerly returning the wrong path (/System)

On a REPL, if I do:
>>> import setup
>>> setup.macosx_sdk_root()
'/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk'

So the path is correct, but I can see in setup.py that detect_tkinter_darwin() will break inside the loop if /System/Library/Frameworks/Tk.framework/Versions/Current  exists (which it does), but it doesn't contain the headers, it contains 3 directories:

Resources      Tk             _CodeSignature

I think detect_tkinter_darwin should be updated so that framework_dirs scans macosx_sdk_root first, but I don't know what other scenarios this might break.

I'd be happy to submit a patch for my scenario but it looks like this whole function needs tests so each platform change and scenario as they come up. There's loads of other issues on BPO related.

----------
components: Build
messages: 359026
nosy: anthonypjshaw
priority: normal
severity: normal
status: open
title: setup.py not picking up tkinter headers
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39162>
_______________________________________

From report at bugs.python.org  Mon Dec 30 03:35:14 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 08:35:14 +0000
Subject: [issue39162] setup.py not picking up tkinter headers
In-Reply-To: <1577694906.58.0.783001060452.issue39162@roundup.psfhosted.org>
Message-ID: <1577694914.57.0.0317571749429.issue39162@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39162>
_______________________________________

From report at bugs.python.org  Mon Dec 30 03:39:04 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 08:39:04 +0000
Subject: [issue39162] setup.py not picking up tkinter headers
In-Reply-To: <1577694906.58.0.783001060452.issue39162@roundup.psfhosted.org>
Message-ID: <1577695144.23.0.406616407794.issue39162@roundup.psfhosted.org>


anthony shaw <anthonyshaw at apache.org> added the comment:

I also can't see how this condition would ever match, since macosx_sdk_root() is not in the list being iterated upon,
https://github.com/python/cpython/blob/master/setup.py#L1774

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39162>
_______________________________________

From report at bugs.python.org  Mon Dec 30 04:04:57 2019
From: report at bugs.python.org (georgepaul bj)
Date: Mon, 30 Dec 2019 09:04:57 +0000
Subject: [issue39163] Perfect Exchange Migration tool
Message-ID: <1577696697.84.0.298684644872.issue39163@roundup.psfhosted.org>


New submission from georgepaul bj <georgepaul123.work at gmail.com>:

EdbMails Exchange Migration tool is the perfect tool which migrates your entire mailbox items  like mails, calendars, contacts etc. without any data loss. and it supports  Exchange versions 2003,  2007, 2010, 2013, 2016 and 2019.  The migration will be incremental .ie. no duplicate items during consecutive migration on the same system.

Exchange Migration


The tool provides risk less migration which helps to migrate direct Exchange to Exchange server and Exchange to Office 365 Migration. It also handles public folders and Archive mailboxes migration.

The software supports cut over , staged and hybrid migration.  It easily performs cross forest and cross domain migration.
To know more : https://www.edbmails.com/pages/exchange-server-migration-tool.html

----------
files: exchange-migration.jpg
messages: 359028
nosy: georgepaul123
priority: normal
severity: normal
status: open
title: Perfect Exchange Migration tool
type: performance
Added file: https://bugs.python.org/file48809/exchange-migration.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39163>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:36:38 2019
From: report at bugs.python.org (Julien Danjou)
Date: Mon, 30 Dec 2019 10:36:38 +0000
Subject: [issue39164] PyErr_GetExcInfo does not allow to retrieve for an
 arbitrary thread
Message-ID: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>


New submission from Julien Danjou <julien at danjou.info>:

PyErr_GetExcInfo does not allow to retrieve exception information for an arbitrary thread. As it calls `_PyThreadState_GET` itself, it's impossible to get exception information for a different thread.

----------
components: C API
messages: 359029
nosy: jd
priority: normal
severity: normal
status: open
title: PyErr_GetExcInfo does not allow to retrieve for an arbitrary thread
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:37:18 2019
From: report at bugs.python.org (Julien Danjou)
Date: Mon, 30 Dec 2019 10:37:18 +0000
Subject: [issue39164] PyErr_GetExcInfo does not allow to retrieve for an
 arbitrary thread
In-Reply-To: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>
Message-ID: <1577702238.39.0.579092808533.issue39164@roundup.psfhosted.org>


Julien Danjou <julien at danjou.info> added the comment:

Relevant python-dev thread: https://mail.python.org/archives/list/python-dev at python.org/thread/QVMFP76R35SXUIM2WPPVPV5XCVMKPDEB/#TLP6MWNML4PRKFFGXHCKNEUMN6UIQ4MT

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:37:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 10:37:46 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1577702266.02.0.697349215158.issue39029@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> Should not parallel tests be ran in different directories?

yes, the test uses support.TESTFN which has the value of "{}_{}_tmp".format(TESTFN, os.getpid()) in the setUp [0] to create tempdir. Under parallel tests the pid value of TESTFN is initialised with a pid once and used always in the setup calls. So setup acts under parallel tests with same test folder. The tempdir can be dynamically generated but I guess this pattern to use support.TESTFN is common and there could be other flaky tests.

# create tempdir at setup each time and clean it up.

diff --git Lib/test/test_mailbox.py Lib/test/test_mailbox.py
index 36a265390e..aa8ae9ae20 100644
--- Lib/test/test_mailbox.py
+++ Lib/test/test_mailbox.py
@@ -51,13 +51,15 @@ class TestMailbox(TestBase):
     _template = 'From: foo\n\n%s\n'

     def setUp(self):
-        self._path = support.TESTFN
+        self._tempdir = tempfile.TemporaryDirectory()
+        self._path = self._tempdir.name
         self._delete_recursively(self._path)
         self._box = self._factory(self._path)

     def tearDown(self):
         self._box.close()
         self._delete_recursively(self._path)
+        self._tempdir.cleanup()

     def test_add(self):
         # Add copies of a sample message

[0] https://github.com/python/cpython/blob/88dce26da6bc4838092128d9a6f1c98bf48b7c90/Lib/test/test_mailbox.py#L54

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:41:00 2019
From: report at bugs.python.org (Julien Danjou)
Date: Mon, 30 Dec 2019 10:41:00 +0000
Subject: [issue39164] PyErr_GetExcInfo does not allow to retrieve for an
 arbitrary thread
In-Reply-To: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>
Message-ID: <1577702460.95.0.391478153928.issue39164@roundup.psfhosted.org>


Change by Julien Danjou <julien at danjou.info>:


----------
keywords: +patch
pull_requests: +17188
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17752

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:42:20 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 30 Dec 2019 10:42:20 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577702540.8.0.835064126959.issue39156@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Moving work from the interpreter to the compiler is always a good idea.

Performance: The compiler is run once per code unit, the interpreter thousands or millions of times.

The compiler is easier to test. Just match the expected bytecode with the actual bytecode. 
The output can be sanity checked by visual inspection.


Although I expect a performance boost, I think this is a worthwhile improvement whether or not it helps 
performance as it makes the instructions better focused.


Pablo, currently there are 117 opcodes, increasing that to 120 is not a problem.
Also there is no reason why we are limited to 256 opcodes in the long term.
Plus, I'm 4 opcodes in credit, thanks to https://bugs.python.org/issue33387 :)

Raymond, regarding the performance of COMPARE_OP, it is not just branch prediction that matters. With this change, the number of (hardware) instructions executed is always reduced, even if branch prediction is no better.

Serhiy, the benefit of having a special opcode for exception matching is not really to speed up exception matching, but to avoid slowing down other tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:44:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 10:44:15 +0000
Subject: [issue38967] Improve error message in enum for member name surrounded
 by underscore.
In-Reply-To: <1575450398.98.0.140033297408.issue38967@roundup.psfhosted.org>
Message-ID: <1577702655.96.0.431150941685.issue38967@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38967>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:50:54 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 10:50:54 +0000
Subject: [issue39162] setup.py not picking up tkinter headers
In-Reply-To: <1577694906.58.0.783001060452.issue39162@roundup.psfhosted.org>
Message-ID: <1577703054.35.0.0317415190309.issue39162@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +17189
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17753

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39162>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:52:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 10:52:22 +0000
Subject: [issue33777] dummy_threading: .is_alive method returns True after
 execution has completed
In-Reply-To: <1528250405.09.0.592728768989.issue33777@psf.upfronthosting.co.za>
Message-ID: <1577703142.13.0.702101887981.issue33777@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

FWIW, dummy_threading and _dummy_thread were removed with 8bf08ee45b7c2341f0d0175b91892843a37c23da in Python 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33777>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:53:22 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 30 Dec 2019 10:53:22 +0000
Subject: [issue39162] setup.py not picking up tkinter headers
In-Reply-To: <1577694906.58.0.783001060452.issue39162@roundup.psfhosted.org>
Message-ID: <1577703202.49.0.662372880941.issue39162@roundup.psfhosted.org>


anthony shaw <anthonyshaw at apache.org> added the comment:

This comes down to a logic bug in detect_tkinter_darwin(), shown in https://github.com/python/cpython/pull/17753/files#r361956102

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39162>
_______________________________________

From report at bugs.python.org  Mon Dec 30 05:54:40 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 30 Dec 2019 10:54:40 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1577703280.11.0.561119005436.issue39156@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +17190
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17754

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:05:21 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 11:05:21 +0000
Subject: [issue39163] Perfect Exchange Migration tool
In-Reply-To: <1577696697.84.0.298684644872.issue39163@roundup.psfhosted.org>
Message-ID: <1577703921.14.0.981359261184.issue39163@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


Removed file: https://bugs.python.org/file48809/exchange-migration.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39163>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:05:36 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 11:05:36 +0000
Subject: [issue39163] Perfect Exchange Migration tool
Message-ID: <1577703936.05.0.216191397921.issue39163@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359028

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39163>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:06:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 11:06:03 +0000
Subject: [issue39163] spam
Message-ID: <1577703963.67.0.174550353418.issue39163@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
title: Perfect Exchange Migration tool -> spam
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39163>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:07:49 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 30 Dec 2019 11:07:49 +0000
Subject: [issue39037] Fix the trial order of the __exit__ and __enter__
 methods in the with statement documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1577704069.34.0.654208286178.issue39037@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:10:32 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 30 Dec 2019 11:10:32 +0000
Subject: [issue33777] dummy_threading: .is_alive method returns True after
 execution has completed
In-Reply-To: <1528250405.09.0.592728768989.issue33777@psf.upfronthosting.co.za>
Message-ID: <1577704232.43.0.088291472414.issue33777@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33777>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:19:02 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 30 Dec 2019 11:19:02 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1577704742.39.0.903519740024.issue33387@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:21:02 2019
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 30 Dec 2019 11:21:02 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577704862.21.0.927035834811.issue39114@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Ned, I think this is fixed. Feel free to re-open if you disagree.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:50:26 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 30 Dec 2019 11:50:26 +0000
Subject: [issue34790] Deprecate passing coroutine objects to asyncio.wait()
In-Reply-To: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>
Message-ID: <1577706626.51.0.300800079815.issue34790@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 89aa7f0ede1a11c020e83f24394593c577a61509 by Andrew Svetlov (Kyle Stanley) in branch 'master':
bpo-34790: Implement deprecation of passing coroutines to asyncio.wait() (GH-16977)
https://github.com/python/cpython/commit/89aa7f0ede1a11c020e83f24394593c577a61509


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34790>
_______________________________________

From report at bugs.python.org  Mon Dec 30 07:12:56 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 12:12:56 +0000
Subject: [issue39162] setup.py not picking up tkinter headers
In-Reply-To: <1577694906.58.0.783001060452.issue39162@roundup.psfhosted.org>
Message-ID: <1577707976.34.0.169238334457.issue39162@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39162>
_______________________________________

From report at bugs.python.org  Mon Dec 30 07:39:54 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 30 Dec 2019 12:39:54 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577709594.35.0.153744629745.issue39114@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Thanks, that fixes the original case in this issue.

Here is another problem which seems related enough to append here instead of opening a new issue:

--- 8< ----------------------------------------------------
import linecache, sys

def trace(frame, event, arg):
    lineno = frame.f_lineno
    print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, lineno).rstrip()))
    return trace

print(sys.version)
sys.settrace(trace)

def b(exc):
    print("exc is {!r}".format(exc))
    try:
        raise Exception(exc)
    except Exception as e:
        if exc != 'expected':
            raise                   # line 17
        q = "removing this line changes the behavior"
        r = "is this executed?"     # line 19
    return

b('expected')
try:
    b('unexpected')
except:
    pass
--- 8< ----------------------------------------------------

With your fix, it reports that the raise on line 17 is followed by line 19, which can't be right:

3.9.0a2+ (heads/pr/17737:f2545467fa, Dec 29 2019, 15:38:57)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 11: def b(exc):
line 12:     print("exc is {!r}".format(exc))
exc is 'expected'
line 13:     try:
line 14:         raise Exception(exc)
exce 14:         raise Exception(exc)
line 15:     except Exception as e:
line 16:         if exc != 'expected':
line 18:         q = "removing this line changes the behavior"
line 19:         r = "is this executed?"
line 20:     return
retu 20:     return
call 11: def b(exc):
line 12:     print("exc is {!r}".format(exc))
exc is 'unexpected'
line 13:     try:
line 14:         raise Exception(exc)
exce 14:         raise Exception(exc)
line 15:     except Exception as e:
line 16:         if exc != 'expected':
line 17:             raise
line 19:         r = "is this executed?"
retu 19:         r = "is this executed?"


Python 3.8 reported this:

3.8.1 (default, Dec 19 2019, 08:38:38)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 11: def b(exc):
line 12:     print("exc is {!r}".format(exc))
exc is 'expected'
line 13:     try:
line 14:         raise Exception(exc)
exce 14:         raise Exception(exc)
line 15:     except Exception as e:
line 16:         if exc != 'expected':
line 18:         q = "removing this line changes the behavior"
line 19:         r = "is this executed?"
line 20:     return
retu 20:     return
call 11: def b(exc):
line 12:     print("exc is {!r}".format(exc))
exc is 'unexpected'
line 13:     try:
line 14:         raise Exception(exc)
exce 14:         raise Exception(exc)
line 15:     except Exception as e:
line 16:         if exc != 'expected':
line 17:             raise
retu 17:             raise

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Mon Dec 30 07:55:04 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 30 Dec 2019 12:55:04 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577710504.29.0.150925845862.issue39114@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

BTW: this is not a regression in your fix. 3.9a2 behaved this way also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Mon Dec 30 08:19:05 2019
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Mon, 30 Dec 2019 13:19:05 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
Message-ID: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>


New submission from Juancarlo A?ez <apalala at gmail.com>:

The problematic `findall(...)[0]` is a common anti-pattern in Python programs. The reason is lack of symmetry and completeness in the `re` module.

The original proposal in `python-ideas` was to add `re.findfirst(pattern, string, flags=0, default=_mark)` with more or less the semantics of `next(findall(pattern, string, flags=flags), default=default)`. 

The referenced PR adds `findalliter(pattern, string, flags=0)` with the value semantics of `findall()` over a generator, implements `findall()` as `return list(findalliter(...))`, and implements `findfirst()`. 

Consistency and correctness are likely because all tests pass with the redefined `findall()`.

----------
components: Library (Lib)
messages: 359039
nosy: apalala
priority: normal
pull_requests: 17191
severity: normal
status: open
title: Completeness and symmetry in RE, avoid `findall(...)[0]`
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Mon Dec 30 08:22:39 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 30 Dec 2019 13:22:39 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
Message-ID: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

3.9.0a2 changed how the final iteration of "async for" is traced.  The body of the loop is traced when the body is not executed.  Standard "for" loops don't show the same effect.

In the output below, notice that 3.9.0a2 and 3.9.0a2+ both show one last execution of line 32, but that line is not actually executed (there is no output).  The standard for loop doesn't show line 27 doing that in any version.

--- 8< ----------------------------------------------------
import linecache, sys

def trace(frame, event, arg):
    # The weird globals here is to avoid a NameError on shutdown...
    if frame.f_code.co_filename == globals().get("__file__"):
        lineno = frame.f_lineno
        print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, lineno).rstrip()))
    return trace

import asyncio

class AsyncIteratorWrapper:
    def __init__(self, obj):
        self._it = iter(obj)

    def __aiter__(self):
        return self

    async def __anext__(self):
        try:
            return next(self._it)
        except StopIteration:
            raise StopAsyncIteration

def doit_sync():
    for letter in "ab":
        print(letter)
    print(".")

async def doit_async():
    async for letter in AsyncIteratorWrapper("ab"):
        print(letter)
    print(".")

print(sys.version)
sys.settrace(trace)

doit_sync()

loop = asyncio.new_event_loop()
loop.run_until_complete(doit_async())
loop.close()
--- 8< ----------------------------------------------------



$ /usr/local/pythonz/pythons/CPython-3.9.0a1/bin/python3.9 /tmp/bpo2.py
3.9.0a1 (default, Nov 20 2019, 18:52:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 25: def doit_sync():
line 26:     for letter in "ab":
line 27:         print(letter)
a
line 26:     for letter in "ab":
line 27:         print(letter)
b
line 26:     for letter in "ab":
line 28:     print(".")
.
retu 28:     print(".")
call 30: async def doit_async():
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 13:     def __init__(self, obj):
line 14:         self._it = iter(obj)
retu 14:         self._it = iter(obj)
call 16:     def __aiter__(self):
line 17:         return self
retu 17:         return self
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
retu 21:             return next(self._it)
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
a
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
retu 21:             return next(self._it)
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
b
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 33:     print(".")
.
retu 33:     print(".")

$ /usr/local/pythonz/pythons/CPython-3.9.0a2/bin/python3.9 /tmp/bpo2.py
3.9.0a2 (default, Dec 19 2019, 08:42:29)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 25: def doit_sync():
line 26:     for letter in "ab":
line 27:         print(letter)
a
line 26:     for letter in "ab":
line 27:         print(letter)
b
line 26:     for letter in "ab":
line 28:     print(".")
.
retu 28:     print(".")
call 30: async def doit_async():
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 13:     def __init__(self, obj):
line 14:         self._it = iter(obj)
retu 14:         self._it = iter(obj)
call 16:     def __aiter__(self):
line 17:         return self
retu 17:         return self
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
retu 21:             return next(self._it)
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
a
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
retu 21:             return next(self._it)
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
b
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
line 33:     print(".")
.
retu 33:     print(".")

$ /usr/local/cpython/bin/python3.9 /tmp/bpo2.py
3.9.0a2+ (heads/master:89aa7f0ede, Dec 30 2019, 07:52:33)
[Clang 10.0.0 (clang-1000.10.44.4)]
call 25: def doit_sync():
line 26:     for letter in "ab":
line 27:         print(letter)
a
line 26:     for letter in "ab":
line 27:         print(letter)
b
line 26:     for letter in "ab":
line 28:     print(".")
.
retu 28:     print(".")
call 30: async def doit_async():
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 13:     def __init__(self, obj):
line 14:         self._it = iter(obj)
retu 14:         self._it = iter(obj)
call 16:     def __aiter__(self):
line 17:         return self
retu 17:         return self
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
retu 21:             return next(self._it)
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
a
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
retu 21:             return next(self._it)
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
b
line 31:     async for letter in AsyncIteratorWrapper("ab"):
call 19:     async def __anext__(self):
line 20:         try:
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
line 33:     print(".")
.
retu 33:     print(".")

$

----------
keywords: 3.9regression
messages: 359040
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Python 3.9.0a2 changed how "async for" traces its final iteration

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39166>
_______________________________________

From report at bugs.python.org  Mon Dec 30 08:29:42 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 13:29:42 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1577712582.35.0.0114939509151.issue39165@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ezio.melotti, mrabarnett, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Mon Dec 30 08:53:39 2019
From: report at bugs.python.org (Callum Ward)
Date: Mon, 30 Dec 2019 13:53:39 +0000
Subject: [issue38314] Implement unix read_pipe.is_reading() method
In-Reply-To: <1569756133.59.0.955288942116.issue38314@roundup.psfhosted.org>
Message-ID: <1577714019.29.0.100810060088.issue38314@roundup.psfhosted.org>


Change by Callum Ward <wards.callum at gmail.com>:


----------
pull_requests: +17192
pull_request: https://github.com/python/cpython/pull/17755

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38314>
_______________________________________

From report at bugs.python.org  Mon Dec 30 09:02:44 2019
From: report at bugs.python.org (=?utf-8?q?Nguy=E1=BB=85n_Gia_Phong?=)
Date: Mon, 30 Dec 2019 14:02:44 +0000
Subject: [issue39125] Type signature of @property not shown in help()
In-Reply-To: <1577115600.68.0.0436692507171.issue39125@roundup.psfhosted.org>
Message-ID: <1577714564.59.0.802871860467.issue39125@roundup.psfhosted.org>


Nguy?n Gia Phong <vn.mcsinyx at gmail.com> added the comment:

Relating to this, should there also be indication about the mode (get, set, del) the property?  Currently there is no way to tell if the *attribute* is read-only, read-write or write-only.

----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39125>
_______________________________________

From report at bugs.python.org  Mon Dec 30 09:04:27 2019
From: report at bugs.python.org (Drew DeVault)
Date: Mon, 30 Dec 2019 14:04:27 +0000
Subject: [issue39119] email/_header_value_parser.py:parse_message_id:
 UnblondLocalError
In-Reply-To: <1577032518.62.0.64044225834.issue39119@roundup.psfhosted.org>
Message-ID: <1577714667.95.0.115509676718.issue39119@roundup.psfhosted.org>


Drew DeVault <sir at cmpwn.com> added the comment:

Sorry for the delay, was travelling for the holidays. I'll check that this is not an issue with 3.8.1. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39119>
_______________________________________

From report at bugs.python.org  Mon Dec 30 10:46:42 2019
From: report at bugs.python.org (Bruce Merry)
Date: Mon, 30 Dec 2019 15:46:42 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577720802.43.0.627560963463.issue36051@roundup.psfhosted.org>


Change by Bruce Merry <bmerry at gmail.com>:


----------
keywords: +patch
pull_requests: +17193
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17757

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:02:20 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 30 Dec 2019 16:02:20 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1577721740.33.0.475968684359.issue39019@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 4dc5a9df59837446ec1dc5b7a0e6ce95ae5b5cec by Ivan Levkivskyi (Batuhan Ta?kaya) in branch 'master':
bpo-39019: Implement missing __class_getitem__ for subprocess classes (GH-17558)
https://github.com/python/cpython/commit/4dc5a9df59837446ec1dc5b7a0e6ce95ae5b5cec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:02:29 2019
From: report at bugs.python.org (Paul Sokolovsky)
Date: Mon, 30 Dec 2019 16:02:29 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL,
 STORE_GLOBAL handle dict subclasses for globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1577721749.25.0.699076442341.issue36220@roundup.psfhosted.org>


Change by Paul Sokolovsky <pfalcon at users.sourceforge.net>:


----------
nosy: +pfalcon
title: LOAD_NAME and LOAD_GLOBAL handle dict subclasses for globals() differently -> LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses for globals() differently

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:08:15 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 30 Dec 2019 16:08:15 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1577722095.32.0.126731614851.issue39019@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:


New changeset 09c482fad11c769be38b2449f1056e264b701bb7 by Ivan Levkivskyi (Batuhan Ta?kaya) in branch 'master':
bpo-39019: Implement missing __class_getitem__ for SpooledTemporaryFile (GH-17560)
https://github.com/python/cpython/commit/09c482fad11c769be38b2449f1056e264b701bb7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:18:30 2019
From: report at bugs.python.org (Trenton Bricken)
Date: Mon, 30 Dec 2019 16:18:30 +0000
Subject: [issue39167] argparse boolean type bug
Message-ID: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>


New submission from Trenton Bricken <brickentrenton at gmail.com>:

This is a bug with argparse. 

Say I have:

parser.add_argument('--verbose', type=bool, action='store', nargs='+',
                        default = [False],
                        help='turns on verbosity')

If in the command line I have "--verbose False' the default will then evaluate to True and return the value "True" rather than the value of "False" that I tried to set it to!

When a developer has lots of arguments to pass in, they may not remember if an argument defaults to False or True. Setting the value to False and having it then return True is very confusing and should not occur. 

Right now I have a work-around where I have a new type=buildBool where:

def buildBool(arg):
   return bool(arg)

and do:

parser.add_argument('--verbose', type=buildBool, action='store', nargs='+',
                        default = ['False'],
                        help='turns on verbosity')

but this means I have to have this type and have my default value be a string which is suboptimal and this bug remains a trap for other developers.

----------
messages: 359045
nosy: Trenton Bricken
priority: normal
severity: normal
status: open
title: argparse boolean type bug
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:18:36 2019
From: report at bugs.python.org (Paul Sokolovsky)
Date: Mon, 30 Dec 2019 16:18:36 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL,
 STORE_GLOBAL handle dict subclasses for globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1577722716.14.0.437059803652.issue36220@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> I wanted to write a sandbox for Python.

Sandbox indeed, it is.

class NS(dict):

    def __setitem__(self, k, v):
        if not isinstance(v, type(lambda: 0)):
            raise RuntimeError("Global variables considered harmful")

globals = NS()

exec("foo = 1", globals)

But then:

exec("""
global foo
foo = "watch me escaping your sandboxes"
""", globals)

This is due to STORE_GLOBAL not handling dict subclasses, unlike STORE_NAME.


While @Kevin Shweh's issue with LOAD_NAME, and @vstinner's concerns of adding yet another branch to LOAD_NAME implementation may be one matter, issue with STORE_GLOBAL is both related and somewhat different. STORE_GLOBAL's should be relatively infrequent, so adding another branch to it unlikely will be quantifiable in performance. But lack of its support disallows to write to tools which police/constrain Python's overdynamicity, which is useful in the age.

Anyway, I decided to not open a separate ticket for this, but add here. Fairly speaking, as long as work to support dict subclasses as globals/locals started, the only reasonable way forward seems to implement it completely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:28:13 2019
From: report at bugs.python.org (Trenton Bricken)
Date: Mon, 30 Dec 2019 16:28:13 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577723293.67.0.230996631828.issue39167@roundup.psfhosted.org>


Trenton Bricken <brickentrenton at gmail.com> added the comment:

Update: 

I was being dumb before, the problem still remains but my work around previously was wrong. This is the new workaround: 

def buildBool(arg):
    if arg == 'False':
        return False
    else:
        return True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:45:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 30 Dec 2019 16:45:43 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577724343.11.0.340347351429.issue39167@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It seems like this is a common problem : https://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse . I guess you want to store verbose=True when --verbose is passed and verbose=False when --verbose is not passed where store_true might help.

----------
nosy: +paul.j3, rhettinger, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 12:17:10 2019
From: report at bugs.python.org (Ruslan Dautkhanov)
Date: Mon, 30 Dec 2019 17:17:10 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
Message-ID: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>


New submission from Ruslan Dautkhanov <dautkhanov at gmail.com>:

Reported originally here - 
https://twitter.com/__zero323__/status/1210911632953692162

See details here
https://asciinema.org/a/290643

In [4]: class Foo: pass
In [5]: %timeit -n1_000_000 Foo()
88.5 ns ? 3.44 ns per loop (mean ? std. dev. of 7 runs, 1000000 loops each)

In [6]: T = TypeVar("T")
In [7]: class Bar(Generic[T]): pass
In [8]: %timeit -n1_000_000 Bar()
883 ns ? 3.46 ns per loop (mean ? std. dev. of 7 runs, 1000000 loops each)

Same effect in Python 3.6 and 3.8

----------
messages: 359049
nosy: Ruslan Dautkhanov
priority: normal
severity: normal
status: open
title: Generic type subscription is a huge toll on Python performance
type: performance
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 12:17:52 2019
From: report at bugs.python.org (Ruslan Dautkhanov)
Date: Mon, 30 Dec 2019 17:17:52 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577726272.79.0.881524796671.issue39168@roundup.psfhosted.org>


Ruslan Dautkhanov <dautkhanov at gmail.com> added the comment:

Python typing gives an order of magnitude slow down in this case

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 12:28:05 2019
From: report at bugs.python.org (Trenton Bricken)
Date: Mon, 30 Dec 2019 17:28:05 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577726885.51.0.798739743461.issue39167@roundup.psfhosted.org>


Trenton Bricken <brickentrenton at gmail.com> added the comment:

Thank you for your quick and helpful reply. 

The problem with your solution is twofold: 
1. it adds some cognitive load in needing to remember whether or not the flag defaults to True or False and thus whether or not you need to add it. It is easier for me to have everything as a flag with a value that follows. 
2. More importantly, I am using argparse for trying lots of different combinations of inputs to a function so I pass them in as a list and then permute the possible values for each input. 

For example: --flag1 a b
--flag2 c d
 
I want to then run a command with the parameter combinations: 
a, c; a, d; b, c; b, d;

And I don't think store_true store_false would allow me to pass in having combinations of True and False like --flag True False would. 

I am fine now with my current work around, but was very confused for some time why my flag would be true when I set it to false. And think this is a counterintuitive pitfall other developers can fall into.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 13:07:03 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Dec 2019 18:07:03 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577729223.25.0.620343971627.issue39168@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 13:51:08 2019
From: report at bugs.python.org (ppperry)
Date: Mon, 30 Dec 2019 18:51:08 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL,
 STORE_GLOBAL handle dict subclasses for globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1577731868.07.0.366623531065.issue36220@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

Duplicate of issue32615

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:18:33 2019
From: report at bugs.python.org (Eitan Adler)
Date: Mon, 30 Dec 2019 19:18:33 +0000
Subject: [issue24955] webbrowser broken on Mac OS X when using the BROWSER
 variable
In-Reply-To: <1440842500.82.0.168118984503.issue24955@psf.upfronthosting.co.za>
Message-ID: <1577733513.74.0.116648769655.issue24955@roundup.psfhosted.org>


Change by Eitan Adler <lists at eitanadler.com>:


----------
nosy: +eitan.adler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24955>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:20:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Dec 2019 19:20:24 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL,
 STORE_GLOBAL handle dict subclasses for globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1577733624.92.0.373736178016.issue36220@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closed as duplicate of issue32615.

----------
nosy: +pablogsal
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:30:54 2019
From: report at bugs.python.org (paul j3)
Date: Mon, 30 Dec 2019 19:30:54 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577734254.45.0.316418112369.issue39167@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

Despite the name, the 'type' parameter specifies a function, not a Python class.  

The only string that produces False is the empty one: bool('').  So 'type=bool' is valid Python, even if it isn't useful.

With `nargs='+'` there's no problem with providing strings like 'False', 'true', 'no', 'oui', 'niet', but if you want to convert those to boolean True/False values, you need to write your own 'type' function.


There was a recent bug/issue that proposed providing such a function (or importing it from another module), and shadowing the existing 'bool' function, but that has been rejected (I think).  It isn't really needed, and the proposed solution was too language specific.

Seems to me that expecting your user to provide an open ended list of 'True False False True' strings would be rather confusing, or at least require a complicated 'help' string.  In any case it's not a common enough case to require any changes to the core argparse functionality.

In sum, it isn't clear what the bug is, or what patch you expect.  This sounds more like a StackOverflow question, than a bug report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:33:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Dec 2019 19:33:06 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1577734386.58.0.20101161566.issue38610@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset d9e561d23d994e3ed15f4fcbd7ee5c8fe50f190b by Pablo Galindo (Zackery Spytz) in branch 'master':
bpo-38610: Fix possible crashes in several list methods (GH-17022)
https://github.com/python/cpython/commit/d9e561d23d994e3ed15f4fcbd7ee5c8fe50f190b


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:33:28 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 19:33:28 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1577734408.0.0.697047693555.issue38610@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17194
pull_request: https://github.com/python/cpython/pull/17758

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:35:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Dec 2019 19:35:36 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1577734536.94.0.692712767805.issue38610@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17195
pull_request: https://github.com/python/cpython/pull/17759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:51:14 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 19:51:14 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1577735474.21.0.150280619892.issue38610@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fcaf14cd9179bb48850f8f81ce8d5cee28129745 by Miss Islington (bot) in branch '3.8':
bpo-38610: Fix possible crashes in several list methods (GH-17022)
https://github.com/python/cpython/commit/fcaf14cd9179bb48850f8f81ce8d5cee28129745


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:58:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Dec 2019 19:58:34 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1577735914.09.0.203237806059.issue38610@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 296d45ec10fb55532bc3fac2311a3f91299ecf59 by Pablo Galindo in branch '3.7':
[3.7] bpo-38610: Fix possible crashes in several list methods (GH-17022) (GH-17759)
https://github.com/python/cpython/commit/296d45ec10fb55532bc3fac2311a3f91299ecf59


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Dec 30 14:58:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Dec 2019 19:58:43 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1577735923.04.0.217458361387.issue38610@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/issue38610>
_______________________________________

From report at bugs.python.org  Mon Dec 30 15:37:27 2019
From: report at bugs.python.org (Batuhan)
Date: Mon, 30 Dec 2019 20:37:27 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577738247.08.0.89501328022.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17196
pull_request: https://github.com/python/cpython/pull/17760

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Mon Dec 30 15:48:14 2019
From: report at bugs.python.org (paul j3)
Date: Mon, 30 Dec 2019 20:48:14 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577738894.05.0.716990479481.issue39167@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

The rejected boolean type proposal:

https://bugs.python.org/issue37564

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 15:56:25 2019
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Dec 2019 20:56:25 +0000
Subject: [issue38967] Improve error message in enum for member name surrounded
 by underscore.
In-Reply-To: <1575450398.98.0.140033297408.issue38967@roundup.psfhosted.org>
Message-ID: <1577739385.4.0.517128091373.issue38967@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Rub?n, good idea.

I wonder, though, if we should say:

  _sunder_ names, such as "%s", are reserved for future Enum use

since `_sunder_` is used in the Enum docs and is unlikely to be confused with one's own variable name.

----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38967>
_______________________________________

From report at bugs.python.org  Mon Dec 30 16:18:35 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Dec 2019 21:18:35 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577740715.56.0.0318652523636.issue39167@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This looks like a duplicate of #37564.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 16:19:32 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Dec 2019 21:19:32 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577740772.84.0.0918560691589.issue39167@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359060

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 16:45:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 Dec 2019 21:45:40 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577742340.36.0.582074955431.issue34118@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +17197
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17761

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 16:53:54 2019
From: report at bugs.python.org (Ruslan Dautkhanov)
Date: Mon, 30 Dec 2019 21:53:54 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577742834.63.0.556900400162.issue39168@roundup.psfhosted.org>


Ruslan Dautkhanov <dautkhanov at gmail.com> added the comment:

In [12]: cProfile.run("for _ in range(100_000): Bar()")                                                                                                                                                            
         200003 function calls in 0.136 seconds                                                                                                                                                                    
                                                                                                                                                                                                                   
   Ordered by: standard name                                                                                                                                                                                       
                                                                                                                                                                                                                   
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)                                                                                                                                            
        1    0.047    0.047    0.136    0.136 <string>:1(<module>)                                                                                                                                                 
   100000    0.079    0.000    0.089    0.000 typing.py:865(__new__)                                                                                                                                               
   100000    0.010    0.000    0.010    0.000 {built-in method __new__ of type object at 0x55ab65861ac0}                                                                                                           
        1    0.000    0.000    0.136    0.136 {built-in method builtins.exec}                                                                                                                                      
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}                                                                                                                     
                                                                                                                                                                                                                   
                                                                                                                                                                                                                   
                                                                                                                                                                                                                   
In [13]: # And typing.py:865 points to                                                                                                                                                                             
                                                                                                                                                                                                                   
In [14]: inspect.getsourcelines(Generic.__new__)                                                                                                                                                                   
Out[14]:                                                                                                                                                                                                           
(['    def __new__(cls, *args, **kwds):\n',                                                                                                                                                                        
  '        if cls in (Generic, Protocol):\n',                                                                                                                                                                      
  '            raise TypeError(f"Type {cls.__name__} cannot be instantiated; "\n',                                                                                                                                 
  '                            "it can be used only as a base class")\n',                                                                                                                                          
  '        if super().__new__ is object.__new__ and cls.__init__ is not object.__init__:\n',                                                                                                                       
  '            obj = super().__new__(cls)\n',                                                                                                                                                                      
  '        else:\n',                                                                                                                                                                                               
  '            obj = super().__new__(cls, *args, **kwds)\n',                                                                                                                                                       
  '        return obj\n'],                                                                                                                                                                                         
 865)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:16:51 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 Dec 2019 22:16:51 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577744211.58.0.368264205754.issue34118@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ee9ff05ec22ecd47dbffdd361967ccd55963dad2 by Terry Jan Reedy in branch 'master':
 bpo-34118: memoryview, range, and tuple are classes  (GH-17761)
https://github.com/python/cpython/commit/ee9ff05ec22ecd47dbffdd361967ccd55963dad2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:16:58 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 22:16:58 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577744218.77.0.46811999731.issue34118@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17198
pull_request: https://github.com/python/cpython/pull/17762

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:17:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 Dec 2019 22:17:43 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577744263.58.0.764530390725.issue34118@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I started with the agreed-on 'function' => 'class' changes and intend to follow with a PR for text changes.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:18:24 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 22:18:24 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577744304.86.0.246513674251.issue34118@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17199
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17763

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:22:27 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 22:22:27 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577744547.33.0.639305265899.issue34118@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c9c17cc933dcffb9ed7f03e3f791d8cfd7acc54a by Miss Islington (bot) in branch '3.7':
bpo-34118: memoryview, range, and tuple are classes  (GH-17761)
https://github.com/python/cpython/commit/c9c17cc933dcffb9ed7f03e3f791d8cfd7acc54a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:24:30 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 30 Dec 2019 22:24:30 +0000
Subject: [issue34118] Fix some class entries in 'Built-in Functions'
In-Reply-To: <1531623878.78.0.56676864532.issue34118@psf.upfronthosting.co.za>
Message-ID: <1577744670.63.0.433543659075.issue34118@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ec941568bdb25e164a87a23cf1b8870ac047b4e3 by Miss Islington (bot) in branch '3.8':
bpo-34118: memoryview, range, and tuple are classes  (GH-17761)
https://github.com/python/cpython/commit/ec941568bdb25e164a87a23cf1b8870ac047b4e3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34118>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:24:43 2019
From: report at bugs.python.org (Paul Sokolovsky)
Date: Mon, 30 Dec 2019 22:24:43 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577744683.18.0.654204793784.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

Some smart maintainer closed https://bugs.python.org/issue36220 as a duplicate of this one. That ticket might have more details of the underlying issues.

----------
nosy: +pfalcon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:40:05 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 Dec 2019 22:40:05 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577745605.04.0.027968137304.issue32615@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Victor, Pablo, I added you two since you commented on the duplicate.

I believe this should be closed as 'not a bug'.  The doc for globals() says is returns a 'dictionary', meaning an instance of dict.  The doc for exec says globals "must be a dictionary (and not a subclass of dictionary)".  (This is mere implied when locals is also given, but it *is* implied.).  The behavior when globals is otherwise is undefined.

----------
nosy: +pablogsal, vstinner
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 18:00:11 2019
From: report at bugs.python.org (Paul Sokolovsky)
Date: Mon, 30 Dec 2019 23:00:11 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577746811.77.0.555053056271.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> The doc for exec says globals "must be a dictionary (and not a subclass of dictionary)"

Docs are full of mistakes and outdated information.

Fixing STORE_GLOBAL case from https://bugs.python.org/issue36220#msg359046 would be trivial and cheap re: overheads. And useful, yeah.

And the gentleman who submitted the other ticket argues that:

> but the inconsistency between LOAD_NAME and LOAD_GLOBAL definitely seems wrong.

Which is easy to agree with, though there're more concerns re: runtime overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 18:17:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 30 Dec 2019 23:17:06 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577747826.71.0.702391102758.issue32615@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The doc for exec says globals "must be a dictionary (and not a subclass of dictionary)"

I agree with Terry, the moment you pass a dict subclass to exec you are out of contract. If any, we may need to sanitize the input to exec, although I don't think is worth paying the performance price for that.

> Some smart maintainer closed https://bugs.python.org/issue36220 as a duplicate of this one.

I closed issue36220 as a duplicate. Paul, I don't know if you are being sarcastic here so I will assume that you are not but in case you are, I suggest you stop as this violates our CoC.

> Docs are full of mistakes and outdated information.

They are also full of contracts and as of today, what the docs document is what is considered the public API. 

In any case, my opinion is that LOAD_NAME and LOAD_GLOBAL should not pay the performance price to handle less-specific APIs just to support a very uncommon case (using dict subclasses as globals) that are also out of contract. For STORE_GLOBAL I feel less strongly about that, but I am still -1 on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 18:37:40 2019
From: report at bugs.python.org (Ashley Whetter)
Date: Mon, 30 Dec 2019 23:37:40 +0000
Subject: [issue34938] Fix mimetype.init() to account for from import
In-Reply-To: <1539036789.21.0.545547206417.issue34938@psf.upfronthosting.co.za>
Message-ID: <1577749060.25.0.918406295756.issue34938@roundup.psfhosted.org>


Ashley Whetter <ashley at awhetter.co.uk> added the comment:

Yes I'm happy to make those changes as part of this.

So clarify what needs to change in PR 16567:

1) Include a note in the docs for `inited` that outlines that if it is imported into the local scope, it will not be updated by calls to `init()`. Only `mimetypes.inited` will.

2) Add a clarification to the `add_type()` docs that changes made with `strict=True` means that they will persist after subsequent calls to `init()`.

3) Remove `_default_mime_types()` in favour of public global constants. The documentation currently refers to these globals as the "official MIME types". Should that wording change to use "default" instead of "official", or maybe should the names of the constants change to `OFFICIAL_SUFFIX_MAP` for example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34938>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:06:25 2019
From: report at bugs.python.org (Ronald Li)
Date: Tue, 31 Dec 2019 00:06:25 +0000
Subject: [issue39169] TypeError: 'int' object is not callable if the signal
 handler is SIG_IGN
Message-ID: <1577750785.74.0.863762449142.issue39169@roundup.psfhosted.org>


New submission from Ronald Li <ronald.ch.li at gmail.com>:

The attached script ign2ndsig.py demonstrates an attempted way to handle signals at most once and ignore any subsequent signals. SIGINT and SIGTERM are used in the demo.


In Python 3.5, the subprocess would go into one of the "except KeyboardInterrupt:" or "except SystemExit:" blocks before doing "finally:" and exiting zero:


# execute the script with no args:
# ./ign2ndsig.py

subproc: sys.version_info(major=3, minor=5, micro=9, releaselevel='final', serial=0)
raising KeyboardInterrupt
handling KeyboardInterrupt
doing finally
rc: 0



In Python 3.6, 3.7 or 3.8, the subprocess would go into neither the "except KeyboardInterrupt:" nor "except SystemExit:" blocks before doing "finally:" and exiting non-zero, with a traceback like this:


subproc: sys.version_info(major=3, minor=6, micro=10, releaselevel='final', serial=0)
raising KeyboardInterrupt
doing finally
Traceback (most recent call last):
  File "./ign2ndsig.py", line 30, in subproc
    input()
  File "./ign2ndsig.py", line 18, in handler
    raise KeyboardInterrupt
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./ign2ndsig.py", line 58, in <module>
    subproc()
  File "./ign2ndsig.py", line 32, in subproc
    printef('handling KeyboardInterrupt')
  File "./ign2ndsig.py", line 10, in printef
    print(*objects, file=sys.stderr, flush=True)
TypeError: 'int' object is not callable
rc: 1



More on the behaviors of ign2ndsig.py :
1. Replacing SIG_IGN at line 14 and 15 with a no-op Python function "fixes" the problem - such that in Python 3.6, 3.7 or 3.8, it'd behave similarly to the Python 3.5 output above.
2. Sending a SIGTERM then a SIGINT (instead of a SIGINT followed by a SIGTERM) (i.e. reversing the order of SIGINT and SIGTERM) at line 49-50 results in a similar behavior (that the TypeError is raised).
3. Sending 2 SIGINTs or 2 SIGTERMs (instead of 1 SIGINT + 1 SIGTERM) (i.e. sending the same signal twice) at line 49-50 does NOT result in the TypeError.


Potentially related issues:

_thread.interrupt_main() errors if SIGINT handler in SIG_DFL, SIG_IGN
https://bugs.python.org/issue23395

Turn SIG_DFL and SIG_IGN into functions
https://bugs.python.org/issue23325

----------
files: ign2ndsig.py
messages: 359071
nosy: Ronald Li
priority: normal
severity: normal
status: open
title: TypeError: 'int' object is not callable if the signal handler is SIG_IGN
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48810/ign2ndsig.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39169>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:10:29 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Dec 2019 00:10:29 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577751029.3.0.27297349083.issue39168@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

What Python version was used for the timings? If not 3.8, please do over in 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:16:04 2019
From: report at bugs.python.org (Paul Sokolovsky)
Date: Tue, 31 Dec 2019 00:16:04 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577751364.36.0.930374949534.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> I agree with Terry, the moment you pass a dict subclass to exec you are out of contract. If any, we may need to sanitize the input to exec, although I don't think is worth paying the performance price for that.

exec() params are already checked, as a seconds param, only dict or dict subclasses are accepted. Seems like good enough contract.

> Paul, I don't know if you are being sarcastic here so I will assume that you are not but in case you are, I suggest you stop as this violates our CoC.

I am not, and please stop your accusations, that violates CoC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:39:23 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Dec 2019 00:39:23 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577752763.37.0.863467492295.issue39168@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Sorry, you already said 3.6 and 3.8 give the same effect. But what if you add a minimal __new__() to Foo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:59:59 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 00:59:59 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577753999.48.0.710999989466.issue32615@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> exec() params are already checked, as a seconds param, only dict or dict subclasses are accepted. Seems like good enough contract.

As I said, the documentation is considered the public API contract and again, the documentation says that dict subclasses are not accepted:

>> it must be a dictionary (and not a subclass of dictionary)

My opinion is that as Terry said, this is a violation of the contract and supporting dict subclasses is a case unusual enough to not sacrifice performance for the general case. 

> I am not, and please stop your accusations, that violates CoC.

A respectful indication to keep the discussion civilized does not violate the CoC. If you are not being sarcastic, then everything is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:04:29 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 01:04:29 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577754269.57.0.422045360597.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 2d5bf568eaa5059402ccce9ba5a366986ba27c8a by Pablo Galindo (Dong-hee Na) in branch 'master':
bpo-38588: Fix possible crashes in dict and list when calling PyObject_RichCompareBool (GH-17734)
https://github.com/python/cpython/commit/2d5bf568eaa5059402ccce9ba5a366986ba27c8a


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:14:32 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 31 Dec 2019 01:14:32 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577754872.4.0.463646705518.issue38588@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17200
pull_request: https://github.com/python/cpython/pull/17764

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:17:48 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 01:17:48 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577755068.66.0.622565701265.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> How about calling Py_INCREF and Py_DECREF in PyObject_RichCompare or do_richcompare?

Apologies, I had missed this suggestion before merging the PR :(

If we decide to add the check to PyObject_RichCompare or do_richcompare we should also adapt the fix for https://bugs.python.org/issue38610

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:18:08 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 31 Dec 2019 01:18:08 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577755088.86.0.0146428152547.issue38588@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17201
pull_request: https://github.com/python/cpython/pull/17765

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:19:09 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 31 Dec 2019 01:19:09 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577755149.49.0.596627069379.issue38588@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

$ ./python -m pyperf timeit -s 'a = ["a"]*100; b = ["a"]*100;' -- 'a == b'

master : Mean +- std dev: 276 ns +- 1 ns
patched: Mean +- std dev: 572 ns +- 3 ns

This makes list comparison 2x slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:21:09 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 01:21:09 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577755269.34.0.525371488629.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> This makes list comparison 2x slower.

Would you like to revert PR 17734? Calling Py_INCREF and Py_DECREF in PyObject_RichCompare or do_richcompare will take the same effect, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:21:33 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 31 Dec 2019 01:21:33 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577755293.79.0.707631012293.issue38588@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> This makes list comparison 2x slower.

This is affected by PR 17734? or PyObject_RichCompare patched?

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:26:28 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 Dec 2019 01:26:28 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577755588.28.0.211371372725.issue39167@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ArgumentParser should support bool type according to truth values

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:31:15 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Dec 2019 01:31:15 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577755875.89.0.318529664307.issue39168@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Hm, here's what I measure in Python 3.8.1. (I don't use IPython or notebooks so this looks a little different.)


>>> timeit.timeit('Foo()', 'class Foo: pass')
0.37630256199999934


>>> timeit.timeit('Foo()', 'class Foo:\n  def __new__(cls): return super().__new__(cls)')
1.5753196039999864


>>> timeit.timeit('Foo()', 'from typing import Generic, TypeVar\nT = TypeVar("T")\nclass Foo(Generic[T]): pass')
3.8748737150000068


>From this I conclude that adding a minimal __new__() method is responsible for about 4x slowdown, and the functionality in typing.py for another factor 2.5.


While this isn't great I don't see an easy way to improve upon this without rewriting the entire typing module in C.  (Some of this may or may not happen for PEP 604.)

PS. I just realized my Python binary was built with debug options, so absolute numbers will look different (better) for you -- but relative numbers will look the same, and I get essentially the same factors with 3.9.0a1+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:31:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 31 Dec 2019 01:31:24 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577755884.26.0.6991551489.issue38588@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17202
pull_request: https://github.com/python/cpython/pull/17766

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:37:29 2019
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 31 Dec 2019 01:37:29 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577756249.74.0.5812691796.issue38588@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Master
Mean +- std dev: 1.08 us +- 0.02 us

Before PR-17734
Mean +- std dev: 584 ns +- 12 ns

New suggested
.....................
Mean +- std dev: 578 ns +- 14 ns

diff --git a/Objects/object.c b/Objects/object.c
index 6fc1146..b42f41a 100644
--- a/Objects/object.c
+++ b/Objects/object.c
@@ -865,6 +865,8 @@ PyObject_RichCompareBool(PyObject *v, PyObject *w, int op)
             return 0;
     }

+    Py_INCREF(v);
+    Py_INCREF(w);
     res = PyObject_RichCompare(v, w, op);
     if (res == NULL)
         return -1;
@@ -873,6 +875,8 @@ PyObject_RichCompareBool(PyObject *v, PyObject *w, int op)
     else
         ok = PyObject_IsTrue(res);
     Py_DECREF(res);
+    Py_DECREF(v);
+    Py_DECREF(w);
     return ok;
 }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:43:00 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 31 Dec 2019 01:43:00 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577756580.92.0.505690531816.issue38588@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

>> This makes list comparison 2x slower.
>
> This is affected by PR 17734? or PyObject_RichCompare patched?

Caused by PR 17734.


> Would you like to revert PR 17734? Calling Py_INCREF and Py_DECREF in PyObject_RichCompare or do_richcompare will take the same effect, no?

Moving INCREF and DECREF is a huge change.  It is just a future idea to prevent same type of bugs.  I think it can not be backported.

To fix this issue with minimum performance regression, I think PR 17766 is the best solution.  So no need to revert PR 17734.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:45:05 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 Dec 2019 01:45:05 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577756705.64.0.715232873709.issue36051@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

This will introduce a risk of data races that didn't previously exist. If you do:

    ba1 = bytearray(b'\x00') * 50000
    ba2 = bytearray(b'\x00') * 50000
    ... pass references to thread that mutates them ...
    ba3 = b''.join((ba1, ba2))

then two things will change from the existing behavior:

1. If the thread in question attempts to write to the bytearrays in place, then it could conceivably write data that is only partially picked up (ba1[0], ba1[40000] = 2, 3 could end up copying the results of the second write without the first; at present, it could only copy the first without the second)

2. If the thread tries to change the size of the bytearrays during the join (ba1 += b'123'), it'll die with a BufferError that wasn't previously possible

#1 isn't terrible (as noted, data races in that case already existed, this just lets them happen in more ways), but #2 is a little unpleasant; code that previously had simple data races (the data might be inconsistent, but the code ran and produced some valid output) can now fail hard, nowhere near the actual call to join that introduced the behavioral change.

I don't think this sinks the patch (loudly breaking code that was silently broken before isn't awful), but I feel like a warning of some kind in the documentation (if only a simple compatibility note in What's New) might be appropriate.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:45:17 2019
From: report at bugs.python.org (Zhipeng Xie)
Date: Tue, 31 Dec 2019 01:45:17 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1577756717.74.0.71823052812.issue39146@roundup.psfhosted.org>


Zhipeng Xie <775350901 at qq.com> added the comment:

Hi, I tracked it down and found that this problem was introduced in python2.7.9 by following commit:

https://hg.python.org/cpython/rev/ebd48b4f650d

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:46:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 Dec 2019 01:46:48 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577756808.18.0.27274696224.issue32615@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Guido, some people would like manipulation and use of globals to work with dict subclasses as well as dicts themselves.  I believe that the current restriction/optimization is at least partly your work.  Do you have any quick opinion, or do you think discussion should go to python-ideas?

----------
nosy: +gvanrossum
stage:  -> test needed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:47:35 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 01:47:35 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577756855.05.0.932033144238.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Moving INCREF and DECREF is a huge change.  It is just a future idea to prevent same type of bugs.  I think it can not be backported.

Now I am wondering how many other APIs are affected by the same pattern other than PyObject_RichCompareBool....

> To fix this issue with minimum performance regression, I think PR 17766 is the best solution.  So no need to revert PR 17734.

Thanks for the quick fix and the analysis. I reviewed PR 17734.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:48:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 01:48:07 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577756887.86.0.119511718262.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Sorry, I meant that I reviewed PR 17766.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:48:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 Dec 2019 01:48:09 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577756889.22.0.239357740607.issue32615@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There are more examples on duplicate #36220.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:58:40 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 31 Dec 2019 01:58:40 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577757520.53.0.398281022533.issue38588@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset dfef986f12dd92bd6434117bba0db3cbb4e65243 by Inada Naoki in branch 'master':
bpo-38588: Optimize list comparison. (GH-17766)
https://github.com/python/cpython/commit/dfef986f12dd92bd6434117bba0db3cbb4e65243


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:17:12 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Dec 2019 02:17:12 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1577758632.81.0.230035436666.issue32615@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This is probably an issue for the new Steering Council.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:31:58 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 31 Dec 2019 02:31:58 +0000
Subject: [issue37446] Undefined behavior in Python/hamt.c
In-Reply-To: <1561769890.8.0.709429549859.issue37446@roundup.psfhosted.org>
Message-ID: <1577759518.68.0.467485421039.issue37446@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset d0c92e81aa2171228a23cb2bed36f7dab975257d by Benjamin Peterson (Batuhan Ta?kaya) in branch 'master':
closes bpo-37446: resolve undefined behavior in Python/hamt.c (GH-17727)
https://github.com/python/cpython/commit/d0c92e81aa2171228a23cb2bed36f7dab975257d


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37446>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:32:05 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 31 Dec 2019 02:32:05 +0000
Subject: [issue37446] Undefined behavior in Python/hamt.c
In-Reply-To: <1561769890.8.0.709429549859.issue37446@roundup.psfhosted.org>
Message-ID: <1577759525.79.0.0429328469217.issue37446@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17203
pull_request: https://github.com/python/cpython/pull/17767

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37446>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:51:25 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 31 Dec 2019 02:51:25 +0000
Subject: [issue37446] Undefined behavior in Python/hamt.c
In-Reply-To: <1561769890.8.0.709429549859.issue37446@roundup.psfhosted.org>
Message-ID: <1577760685.15.0.443664999928.issue37446@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a278ae19b4daa1deb11e2a8eed38838027e90ece by Miss Islington (bot) in branch '3.8':
closes bpo-37446: resolve undefined behavior in Python/hamt.c (GH-17727)
https://github.com/python/cpython/commit/a278ae19b4daa1deb11e2a8eed38838027e90ece


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37446>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:15:13 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 04:15:13 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577765713.99.0.312288379112.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 53f11ba7b1498133ce3ff8173d5ae2e0182a3603 by Pablo Galindo (Dong-hee Na) in branch '3.7':
[3.7] bpo-38588: Fix possible crashes in dict and list when calling P? (GH-17765)
https://github.com/python/cpython/commit/53f11ba7b1498133ce3ff8173d5ae2e0182a3603


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:15:40 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 04:15:40 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577765740.15.0.314025721837.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 2ee87913dde038436a25f1db13ee3fddd2bcc983 by Pablo Galindo (Dong-hee Na) in branch '3.8':
[3.8] bpo-38588: Fix possible crashes in dict and list when calling P? (GH-17764)
https://github.com/python/cpython/commit/2ee87913dde038436a25f1db13ee3fddd2bcc983


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:16:45 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 04:16:45 +0000
Subject: [issue38588] Use-after-free in dict/list
In-Reply-To: <1572009950.92.0.0819194467929.issue38588@roundup.psfhosted.org>
Message-ID: <1577765805.12.0.570324145906.issue38588@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closing this for now, let's open another issue if we plan to discuss calling Py_INCREF and Py_DECREF in PyObject_RichCompare or do_richcompare in the future.

Thanks to everyone involved!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38588>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:42:58 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 31 Dec 2019 04:42:58 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577767378.08.0.809693730747.issue36051@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> 2. If the thread tries to change the size of the bytearrays during the join (ba1 += b'123'), it'll die with a BufferError that wasn't previously possible

Makes sense.  We shouldn't drop GIL while having buffer of arbitrary objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:56:03 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Dec 2019 04:56:03 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1577768163.83.0.603648551269.issue20443@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

With the sys.argv[0] change reverted, I think this overall issue is fixed now - code objects will get absolute paths, while sys.argv[0] will continue to reflect how __main__ was identified.

----------
priority:  -> normal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Tue Dec 31 00:15:00 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 Dec 2019 05:15:00 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577769300.78.0.239440572558.issue27973@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset f82e59ac4020a64c262a925230a8eb190b652e87 by Senthil Kumaran in branch '2.7':
[2.7] bpo-27973 - Fix for urllib.urlretrieve() failing on second ftp transfer (#1040)
https://github.com/python/cpython/commit/f82e59ac4020a64c262a925230a8eb190b652e87


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Tue Dec 31 00:15:00 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 Dec 2019 05:15:00 +0000
Subject: [issue35411] FTP tests of test_urllib2net fail on Travis CI: 425
 Security: Bad IP connecting.
In-Reply-To: <1543961289.76.0.788709270274.issue35411@psf.upfronthosting.co.za>
Message-ID: <1577769300.92.0.848879891937.issue35411@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset f82e59ac4020a64c262a925230a8eb190b652e87 by Senthil Kumaran in branch '2.7':
[2.7] bpo-27973 - Fix for urllib.urlretrieve() failing on second ftp transfer (#1040)
https://github.com/python/cpython/commit/f82e59ac4020a64c262a925230a8eb190b652e87


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35411>
_______________________________________

From report at bugs.python.org  Tue Dec 31 00:50:56 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Dec 2019 05:50:56 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1577771456.75.0.707644904678.issue36476@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Perhaps we need a threading.throw() API, similar to the one we have for generators and coroutines?

If we had that, then Py_FinalizeEx() could gain a few new features:

* throw SystemExit into all daemon threads and then give them a chance to terminate before calling any atexit handlers (printing a warning if some of the threads don't exit)
* throw SystemExit into all daemon and non-daemon threads after running atexit handlers (printing a warning if any such threads exist at all, along with another warning if some of the threads don't exit)

Adding that would require an enhancement to the PendingCall machinery, though, since most pending calls are only processed in the main thread (there's no way to route them to specific child threads).

A simpler alternative would be to have an atomic "terminate_threads" counter in the ceval runtime state that was incremented to 1 to request that SystemExit be raised in daemon threads, and then to 2 to request that SystemExit be raised in all still running threads. When a thread received that request to exit, it would set a new flag in the thread state to indicate it was terminating, and then raise SystemExit. (The thread running Py_FinalizeEx would set that flag in advance so it wasn't affected, and other threads would use it to ensure they only raised SystemExit once). The runtime cost of this would just be another _Py_atomic_load_relaxed call in the eval_breaker branch. (Probably inside `make_pending_calls`, so it gets triggered both by the eval_breaker logic, and by explicit calls to `Py_MakePendingCalls`).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Tue Dec 31 00:54:58 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 Dec 2019 05:54:58 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577771698.4.0.0348220677644.issue27973@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Tue Dec 31 01:02:53 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 06:02:53 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577772173.93.0.88544484093.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

If we want to be conservative, we could only drop the GIL if all the buffers pass the PyBytes_CheckExact test. Presumably that won't encounter any of these problems because bytes objects are immutable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 01:30:46 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 31 Dec 2019 06:30:46 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1577773846.41.0.113509162941.issue36476@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thinking about that idea further, I don't think that change would help much, since the relevant operations should already be checking for thread termination when they attempt to reacquire the GIL.

That means what we're missing is:

1. When daemon threads still exist after the non-daemon threads terminate, deliberately giving them additional time to run (and hence terminate)
2. Explicitly attempting to kick daemon threads out of blocking system calls by sending them signals to provoke EINTR (I have no idea if there's a windows equivalent for this, but we should be able to use pthread_kill on POSIX systems. However, choosing *which* wakeup signal to send could be fraught with compatibility problems)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Tue Dec 31 01:57:54 2019
From: report at bugs.python.org (Clinton James)
Date: Tue, 31 Dec 2019 06:57:54 +0000
Subject: [issue39170] Sqlite3 row_factory for attribute access: NamedRow
Message-ID: <1577775474.34.0.0934062423159.issue39170@roundup.psfhosted.org>


New submission from Clinton James <clinton at jidn.com>:

Currently, sqlite3 returns rows by tuple or sqlite3.Row for dict-style, index access.  I constantly find myself wanting attribute access like namedtuple for rows.  I find attribute access cleaner
without the brackets and quoting field names.  However, unlike previous discussions (https://bugs.python.org/issue13299), I don't want to use the namedtuple object.  I appreciate the simple API and minimal memory consumption of sqlite3.Row and used it as my guide in creating sqlite3.NamedRow to allow access by index and attribute.

A pull request is ready

Why a new object instead of adding attribute access to the existing sqlite3.Row?
There is an existing member method `keys` and any table with the field "keys" would cause a hard to debug, easily avoidable, collision.

Features:

+ Optimized in C, so it will be faster than any python implementation.
+ Access columns by attribute for all valid names and by index for all names.
+ Iterate over fields by name/value pairs.
+ Works with standard functions `len` and `contains`.
+ Identical memory consumption to sqlite3.Row with two references: the data tuple and the cursor description.
+ Identical speed to sqlite3.Row if not faster.  Timing usually has it slightly faster for index by name or attribute, but it is almost identical.

Examples:

    >>> import sqlite3
    >>> c = sqlite3.Connection(":memory:").cursor()
    >>> c.row_factory = sqlite3.NamedRow
    >>> named_row = c.execute("SELECT 'A' AS letter, '.-' AS morse, 65 AS ord").fetchone()

    >>> len(named_row)
    3
    >>> 'letter' in named_row
    true
    >>> named_row == named_row
    true
    >>> hash(named_row)
    5512444875192833987

Index by number and range.
    >>> named_row[0]
    'A'
    >>> named_row[1:]
    ('.-', 65)

Index by column name.
    >>> named_row["ord"]
    65

Access by attribute.
    >>> named_row.morse
    '.-'

Iterate row for name/value pairs.
    >>> dict(named_row)
    {'letter': 'A', 'morse': '.-', 'ord': 65}
    >>> tuple(named_row)
    (('letter', 'A'), ('morse', '.-'), ('ord', 65))


How sqlite3.NamedRow differs from sqlite3.Row
----------------------------------------------

The class only has class dunder methods to allow any valid field name. When the field name would be an invalid attribute name, you have two options: either use the SQL `AS` in the select statement or index by name.
To get the field names use the iterator `[x[0] for x in row]` or do the same from the
`cursor.description`.

```python
    titles = [x[0] for x in row]
    titles = [x[0] for x in cursor.description]
    titles = dict(row).keys()
```

Attribute and dict access are no longer case-insensitive.  There are three reasons for this.
    1. Case-insensitive comparison only works well for ASCII characters.  In a Unicode world, case-insensitive edge cases create unnecessary errors. Looking at a several existing codebases,
       this feature of Row is almost never used and I believe is not needed in NamedRow.
    2. Case-insensitivity is not allowed for attribute access.  This "feature" would treat attribute access differently from the rest of Python and "special cases aren't special enough to break the rules". Where `row.name`, `row.Name`, and `row.NAME` are all the same it gives off the faint code smell of something wrong.  When case-insensitively is needed and the query SELECT can not be modified, sqlite3.Row is still there.
    3. Code is simpler and easier to maintain.
    4. It is faster.

Timing Results
--------------

NamedRow is faster than sqlite3.Row for index-by-name access.
I have published a graph and the methodology of my testing.  In the worst-case scenario, it is just as fast as sqlite3.Row without any extra memory.  In most cases, it is faster.
For more information, see the post at http://jidn.com/2019/10/namedrow-better-python-sqlite3-row-factory/

----------
components: Library (Lib)
messages: 359104
nosy: jidn
priority: normal
severity: normal
status: open
title: Sqlite3 row_factory for attribute access: NamedRow
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39170>
_______________________________________

From report at bugs.python.org  Tue Dec 31 02:17:04 2019
From: report at bugs.python.org (Clinton James)
Date: Tue, 31 Dec 2019 07:17:04 +0000
Subject: [issue39170] Sqlite3 row_factory for attribute access: NamedRow
In-Reply-To: <1577775474.34.0.0934062423159.issue39170@roundup.psfhosted.org>
Message-ID: <1577776624.93.0.126929393929.issue39170@roundup.psfhosted.org>


Change by Clinton James <clinton at jidn.com>:


----------
keywords: +patch
pull_requests: +17204
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17768

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39170>
_______________________________________

From report at bugs.python.org  Tue Dec 31 02:46:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Dec 2019 07:46:15 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577778375.19.0.584882173505.issue36051@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please provide benchmarks that demonstrate the benefit of this change.

We also need to add a test for join() which covers the new code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 03:15:47 2019
From: report at bugs.python.org (Dominic Mayers)
Date: Tue, 31 Dec 2019 08:15:47 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
Message-ID: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>


New submission from Dominic Mayers <dominic_mayers at yahoo.com>:

My first "bug" report here. Not sure I am doing it right. It is just that if I execute the code

    import tkinter
    from tkinter import simpledialog
    tkinter.Tk().withdraw() 
    integer_value = simpledialog.askinteger('Dialog Title', 'What is your age?', minvalue=0, maxvalue=100)

It works. In particular, when the line `parent = tkinter._default_root` is executed in simpledialog.py, `_default_root` is defined.  However, if I execute the code

    import tkinter
    from tkinter import simpledialog
    integer_value = simpledialog.askinteger('Dialog Title', 'What is your age?', minvalue=0, maxvalue=100)

which does not have the line `tkinter.Tk().withdraw()` it does not work. When the line `parent = tkinter._default_root` is executed, `_default_root` is not defined. 

I don't know if it is a bug. I don't understand the remainder of the code enough to say. However, the purpose of this line is to define a parent when none is provided. It seem to me that it should be possible to find a parent window...

----------
components: Tkinter
messages: 359106
nosy: dominic108
priority: normal
severity: normal
status: open
title: Missing default root in tkinter simpledialog.py
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Tue Dec 31 03:53:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 08:53:24 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577782404.15.0.632916197366.issue39114@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17205
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17769

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39114>
_______________________________________

From report at bugs.python.org  Tue Dec 31 03:53:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Dec 2019 08:53:35 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1577782415.62.0.625279373983.issue39146@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

We usually do not backport optimizations to 2.7. It could be backported if a regression was introduced in one of 2.7 bugfixes, but range() was here before ebd48b4f650d.

Also, range(0x10000,0x10ffff+1) takes only 32*2**16 = 2 MiB of memory. It is small in comparison with total memory consumption. Obviously there are other causes of the difference between 2.7 and 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:11:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Dec 2019 09:11:03 +0000
Subject: [issue39169] TypeError: 'int' object is not callable if the signal
 handler is SIG_IGN
In-Reply-To: <1577750785.74.0.863762449142.issue39169@roundup.psfhosted.org>
Message-ID: <1577783463.94.0.46611237746.issue39169@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ethan.furman, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39169>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:13:37 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 09:13:37 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577783617.61.0.824661084569.issue36051@roundup.psfhosted.org>


Change by Bruce Merry <bmerry at gmail.com>:


Added file: https://bugs.python.org/file48811/old.csv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:13:54 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 09:13:54 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577783634.45.0.640903976536.issue36051@roundup.psfhosted.org>


Change by Bruce Merry <bmerry at gmail.com>:


Added file: https://bugs.python.org/file48812/new.csv

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:14:38 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 09:14:38 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577783678.87.0.356908103567.issue36051@roundup.psfhosted.org>


Change by Bruce Merry <bmerry at gmail.com>:


Added file: https://bugs.python.org/file48813/benchjoin.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:24:43 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 09:24:43 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577784283.82.0.408490720069.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

I've attached a benchmark script and CSV results for master (whichever version that was at the point I forked) and with unconditional dropping of the GIL. It shows up to 3x performance improvement when using 4 threads. That's on my home desktop, which is quite old (Sandy Bridge). I'm expecting more significant gains on server CPUs, whose memory systems are optimised for multi-threaded workloads. The columns are chunk size, number of chunks, number of threads, and per-thread throughput.

There are also cases where using multiple threads is a slowdown, but I think that's an artifact of the benchmark. It repeatedly joins the same strings, so performance is higher when they all fit in the cache; when using 4 threads that execute in parallel, the working set is 4x larger and may cease to fit in cache. In real-world usage one is unlikely to be joining the same strings again and again.

In the single-threaded case, the benchmark seems to show that for 64K+, performance is improved by dropping the GIL (which I'm guessing must be statistical noise, since there shouldn't be anything contending for it), which is my reasoning behind the 65536 threshold.

I'll take a look at extra unit tests soon. Do you know off the top of your head where to look for existing `join` tests to add to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:53:35 2019
From: report at bugs.python.org (Zhipeng Xie)
Date: Tue, 31 Dec 2019 09:53:35 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1577786015.9.0.560977365098.issue39146@roundup.psfhosted.org>


Zhipeng Xie <775350901 at qq.com> added the comment:

> but range() was here before ebd48b4f650d.

before ebd48b4f650d, _optimize_unicode use xrange. So python2.7.8 is ok and python2.7.9 consume much memory in my test case.

> Obviously there are other causes of the difference between 2.7 and 3.x.

Maybe it is because my python was compiled with --enable-unicode=ucs4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Tue Dec 31 04:53:48 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 09:53:48 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577786028.75.0.263362036911.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

> I'll take a look at extra unit tests soon. Do you know off the top of your head where to look for existing `join` tests to add to?

Never mind, I found it: https://github.com/python/cpython/blob/92709a263e9cec0bc646ccc1ea051fc528800d8d/Lib/test/test_bytes.py#L535-L559

Do you think it would be sufficient to change the stress test from joining 1000 items to joining 100000 items?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 06:07:34 2019
From: report at bugs.python.org (Bruce Merry)
Date: Tue, 31 Dec 2019 11:07:34 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577790454.09.0.471993287882.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

> Do you think it would be sufficient to change the stress test from joining 1000 items to joining 100000 items?

Actually that won't work, because the existing stress test is using a non-empty separator. I'll add another version of that stress test that uses an empty separator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Tue Dec 31 06:08:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 31 Dec 2019 11:08:14 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>
Message-ID: <1577790494.52.0.484786870713.issue18858@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

dummy_threading was removed in Python 3.9 with issue37312 . I hope this issue can be closed as outdated.

----------
nosy: +inada.naoki, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18858>
_______________________________________

From report at bugs.python.org  Tue Dec 31 06:55:47 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 31 Dec 2019 11:55:47 +0000
Subject: [issue18858] dummy_threading lacks threading.get_ident() equivalent
In-Reply-To: <1377638843.21.0.0472654933915.issue18858@psf.upfronthosting.co.za>
Message-ID: <1577793347.02.0.0361419968149.issue18858@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18858>
_______________________________________

From report at bugs.python.org  Tue Dec 31 07:27:25 2019
From: report at bugs.python.org (Trenton Bricken)
Date: Tue, 31 Dec 2019 12:27:25 +0000
Subject: [issue39167] argparse boolean type bug
In-Reply-To: <1577722710.93.0.00677061008996.issue39167@roundup.psfhosted.org>
Message-ID: <1577795245.3.0.0161809146918.issue39167@roundup.psfhosted.org>


Trenton Bricken <brickentrenton at gmail.com> added the comment:

Thanks for all of these replies. 

The functionality is that the user adds --flag True False and then all of the other parameters are run with True. And then again with False. 

I thought this was a bug because of the confusing type=bool behavior. But it certainly isn't a big deal and it seems like you are already aware of it. 

Thanks for all of your open source contributions and help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39167>
_______________________________________

From report at bugs.python.org  Tue Dec 31 08:04:09 2019
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 31 Dec 2019 13:04:09 +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: <1577797449.46.0.0336943118416.issue24925@roundup.psfhosted.org>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

All is fixed. The PR apparently is correct.
My first dent in the Python universe, however small :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24925>
_______________________________________

From report at bugs.python.org  Tue Dec 31 08:32:58 2019
From: report at bugs.python.org (=?utf-8?b?16DXmdeh158g15HXm9eo?=)
Date: Tue, 31 Dec 2019 13:32:58 +0000
Subject: [issue39172] Translation of "string.find('asd', 'sd')" doesn't work
Message-ID: <1577799178.37.0.470973849561.issue39172@roundup.psfhosted.org>


New submission from ???? ??? <nisan.univ at gmail.com>:

When using the following code to run using python 2.x, it works:

import string
string.find("asd", "sd")

But this method is deprecated in python 3.x

When using "2to3" tool to convert, it doesn't convert it successfully.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 359115
nosy: ???? ???
priority: normal
severity: normal
status: open
title: Translation of "string.find('asd', 'sd')" doesn't work
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39172>
_______________________________________

From report at bugs.python.org  Tue Dec 31 09:09:52 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 31 Dec 2019 14:09:52 +0000
Subject: [issue39172] Transformation of "string.find('asd',
 'sd')" to Python 3 using 2to3
In-Reply-To: <1577799178.37.0.470973849561.issue39172@roundup.psfhosted.org>
Message-ID: <1577801392.54.0.0143708744325.issue39172@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
title: Translation of "string.find('asd', 'sd')" doesn't work -> Transformation of "string.find('asd', 'sd')" to Python 3 using 2to3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39172>
_______________________________________

From report at bugs.python.org  Tue Dec 31 09:12:48 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 31 Dec 2019 14:12:48 +0000
Subject: [issue39172] Transformation of "string.find('asd',
 'sd')" to Python 3 using 2to3
In-Reply-To: <1577799178.37.0.470973849561.issue39172@roundup.psfhosted.org>
Message-ID: <1577801568.12.0.156933927447.issue39172@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems to be a duplicate of issue2899

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39172>
_______________________________________

From report at bugs.python.org  Tue Dec 31 09:44:00 2019
From: report at bugs.python.org (Dominic Mayers)
Date: Tue, 31 Dec 2019 14:44:00 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1577803440.91.0.917127716186.issue39171@roundup.psfhosted.org>


Dominic Mayers <dominic_mayers at yahoo.com> added the comment:

If it's normal, then the error message should perhaps be more informative and user friendly than just a traceback: 

    Traceback (most recent call last):
      File "./dialog.py", line 6, in <module>
        integer_value = simpledialog.askinteger('Dialog Title', 'What is your age?', minvalue=0, maxvalue=100)
      File "/usr/lib/python3.7/tkinter/simpledialog.py", line 341, in askinteger
        d = _QueryInteger(title, prompt, **kw)
      File "/usr/lib/python3.7/tkinter/simpledialog.py", line 271, in __init__
        Dialog.__init__(self, parent, title)
      File "/usr/lib/python3.7/tkinter/simpledialog.py", line 137, in __init__
        if parent.winfo_viewable():
    AttributeError: 'NoneType' object has no attribute 'winfo_viewable'

If it is not too intrusive, it would be even more user friendly if the code found some parent window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Tue Dec 31 10:23:53 2019
From: report at bugs.python.org (hai shi)
Date: Tue, 31 Dec 2019 15:23:53 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
Message-ID: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Currently, many developers discuss the output of attributes of argparse should be sorted or not?

>>> from argparse import ArgumentParser
>>> parser = ArgumentParser()
>>> _ = parser.add_argument('outstream')
>>> _ = parser.add_argument('instream')
>>> args = parser.parse_args(['out.txt', 'in.txt'])

# Keep the original order
>>> vars(args)

{'outstream': 'out.txt', 'instream': 'in.txt'}
# Order is sorted
>>> args
Namespace(instream='in.txt', outstream='out.txt')

IMHO, the attributes order should be keep the original order by default. If user would like use order the attributes order, we should add a param in `_AttributeHolder` to open sorting or not.

such as:
```
class _AttributeHolder(object):
    def __init__(self, sort=false):
        self.sort = sort

    def _get_kwargs(self):
        if sort:
            return sorted(self.__dict__.items())
        else:
            return self.__dict__.items()
```

some other bpos have discussed this topic too: issue39075?issue39058

----------
components: Library (Lib)
messages: 359118
nosy: shihai1991
priority: normal
severity: normal
status: open
title: _AttributeHolder of argparse should support the sort function or not?
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39173>
_______________________________________

From report at bugs.python.org  Tue Dec 31 10:28:00 2019
From: report at bugs.python.org (hai shi)
Date: Tue, 31 Dec 2019 15:28:00 +0000
Subject: [issue39075] types.SimpleNamespace should preserve attribute ordering
 (?)
In-Reply-To: <1576599681.13.0.0769751822925.issue39075@roundup.psfhosted.org>
Message-ID: <1577806080.18.0.630446881654.issue39075@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>Consider opening a separate issue (or start a thread on python-ideas)
>about adding a more sophisticated implementation to the stdlib's
>"reprlib" module.  If you do so then please draw from the
>argparse._AttributeHolder implementation.

FWIW, i created a new bpo: https://bugs.python.org/issue39173

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39075>
_______________________________________

From report at bugs.python.org  Tue Dec 31 11:49:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Dec 2019 16:49:19 +0000
Subject: [issue39172] Transformation of "string.find('asd',
 'sd')" to Python 3 using 2to3
In-Reply-To: <1577799178.37.0.470973849561.issue39172@roundup.psfhosted.org>
Message-ID: <1577810959.92.0.210823427807.issue39172@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Fixers find, rfind, etc in 'string' module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39172>
_______________________________________

From report at bugs.python.org  Tue Dec 31 13:22:32 2019
From: report at bugs.python.org (Lee Collins)
Date: Tue, 31 Dec 2019 18:22:32 +0000
Subject: [issue39174] unicodedata.normalize failing with NFD and NFKD for some
 characters in Python3
Message-ID: <1577816551.99.0.153382211706.issue39174@roundup.psfhosted.org>


New submission from Lee Collins <lcollins at netflix.com>:

A script that works in 2.7.17 is now failing for some Unicode characters in 3.7.5 on MacOS 10.14.6. For example unicodedata.normalize('NFD', '?') used to return the correct decomposition u'a\u0300', but in 3.7 it returns the single composed character U+00E0. This doesn't happen for all composed forms, just some. Other examples: ?, ?

----------
components: Unicode
messages: 359120
nosy: Lee Collins, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: unicodedata.normalize failing with NFD and NFKD for some characters in Python3
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39174>
_______________________________________

From report at bugs.python.org  Tue Dec 31 13:25:39 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 31 Dec 2019 18:25:39 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1577816739.15.0.0173154783273.issue39173@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

What is the use-case for this? Why would anyone care in which order arguments are represented in the object repr?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39173>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:06:17 2019
From: report at bugs.python.org (ppperry)
Date: Tue, 31 Dec 2019 19:06:17 +0000
Subject: [issue11105] Compiling evil ast crashes interpreter
In-Reply-To: <1296709360.51.0.0254918555785.issue11105@psf.upfronthosting.co.za>
Message-ID: <1577819177.13.0.46868972679.issue11105@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

What about indirect cycles like below:

>>> e = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> f = ast.UnaryOp(op=ast.Not(), lineno=0, col_offset=0)
>>> e.operand = f
>>> f.operand = e
>>> compile(ast.Expression(e), "<test>", "eval")

(I tested, this also crashes)

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11105>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:19:25 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 31 Dec 2019 19:19:25 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577819965.35.0.730887453044.issue39142@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
pull_requests: +17206
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17773

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39142>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:23:58 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 31 Dec 2019 19:23:58 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577820238.71.0.666070632497.issue39142@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39142>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:53:15 2019
From: report at bugs.python.org (Lee Collins)
Date: Tue, 31 Dec 2019 19:53:15 +0000
Subject: [issue39174] unicodedata.normalize failing with NFD and NFKD for some
 characters in Python3
In-Reply-To: <1577816551.99.0.153382211706.issue39174@roundup.psfhosted.org>
Message-ID: <1577821995.62.0.7185356182.issue39174@roundup.psfhosted.org>


Lee Collins <lcollins at netflix.com> added the comment:

On further investigation, it appears that the problem is the interaction between Python3 and the MacOS terminal. unicodedata.normalize() produces the correct sequence u'a\u0300' but when printed it comes out as U+00E0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39174>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:56:41 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 31 Dec 2019 19:56:41 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577822201.54.0.866101286494.issue39168@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

This issue came up few times before (although I can't find an issue here on b.p.o., maybe it was on typing-sig list). Although in micro-benchmarks the impact may seem big, in vast majority of applications it is rarely more that a percent or so.

On the other hand, IIRC the only reason `Generic.__new__()` exists is so that one can't write `Generic()` (i.e. instantiate a plain `Generic`). I would be totally fine if we just remove it in 3.9. Hopefully, people already learned what typing is for and don't need so much "protection" against not very meaningful things. Also, the error can be given by static type checkers, there is probably no need for a runtime error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:57:10 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 31 Dec 2019 19:57:10 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577822230.58.0.567695678696.issue27973@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This PR1040 is failing in several 2.7 buildbots:

Tests result: FAILURE then FAILURE
test test_urllibnet failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\test\test_urllibnet.py", line 232, in test_multiple_ftp_retrieves
    "multiple times.\n Error message was : %s" % e)
AssertionError: Failed FTP retrieve while accessing ftp url multiple times.
 Error message was : [Errno 13] Permission denied: 'd:\\temp\\tmpiuquqa'
Example failure:

https://buildbot.python.org/all/#/builders/209/builds/4

----------
nosy: +pablogsal
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:59:02 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Dec 2019 19:59:02 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577822342.89.0.434492140514.issue39168@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

If that solves the perf issue I am fine with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 14:59:12 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 31 Dec 2019 19:59:12 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577822352.32.0.456032552442.issue39168@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

OK, here is the original issue https://github.com/python/typing/issues/681. I asked the author to open an issue here instead, but likely they didn't open one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:09:33 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Dec 2019 21:09:33 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1577826573.67.0.645684969972.issue39173@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39173>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:34:02 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 Dec 2019 21:34:02 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577828042.66.0.243395112621.issue27973@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +17207
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/17774

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:35:14 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 Dec 2019 21:35:14 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577828114.67.0.677511976977.issue27973@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the note, Pablo.
I am going to check if this patch https://github.com/python/cpython/pull/17774 will solve the Windows buildbot issues.

----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:43:08 2019
From: report at bugs.python.org (Ruslan Dautkhanov)
Date: Tue, 31 Dec 2019 21:43:08 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577828588.1.0.795894801787.issue39168@roundup.psfhosted.org>


Ruslan Dautkhanov <dautkhanov at gmail.com> added the comment:

Thank you Guido and Ivan

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:44:56 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Dec 2019 21:44:56 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577828588.1.0.795894801787.issue39168@roundup.psfhosted.org>
Message-ID: <CAP7+vJJoOHD5tju4eRQLWFhKN0BFwPLoK+WCHS7iP66Q5B5fwg@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

OK let?s do it. Clearly for *some* applications the overhead is significant.
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:48:07 2019
From: report at bugs.python.org (Ruslan Dautkhanov)
Date: Tue, 31 Dec 2019 21:48:07 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577828887.46.0.870465648819.issue39168@roundup.psfhosted.org>


Ruslan Dautkhanov <dautkhanov at gmail.com> added the comment:

Perhaps the check should only be done in some sort of Python development mode and off by default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:49:16 2019
From: report at bugs.python.org (Ruslan Dautkhanov)
Date: Tue, 31 Dec 2019 21:49:16 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577828956.36.0.429674072132.issue39168@roundup.psfhosted.org>


Ruslan Dautkhanov <dautkhanov at gmail.com> added the comment:

Didn't see your last response before submitting an update.

That's great you have a plan how to resolve this! 

Thanks again

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Tue Dec 31 17:02:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Dec 2019 22:02:17 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1577829737.64.0.66325022561.issue39165@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1 

I think the module is better-off without this function.  There are already more functions than most people know or remember.  For most cases, re.search() or re.finditer() will suffice.  

Also, I don't recall having seen findall(...)[0].  If it does exist, it is likely an education problem (i.e. something that can be addressed with documentation or a faq).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Tue Dec 31 17:08:04 2019
From: report at bugs.python.org (Dominic Mayers)
Date: Tue, 31 Dec 2019 22:08:04 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1577830084.53.0.762687499501.issue39171@roundup.psfhosted.org>


Dominic Mayers <dominic_mayers at yahoo.com> added the comment:

Again, I just spent a few minutes looking at this, but in the ttk module, in a similar situation, they do:

    if master is None:
        if tkinter._support_default_root:
            master = tkinter._default_root or tkinter.Tk()
        else:
            raise RuntimeError(
                    "No master specified and tkinter is "
                    "configured to not support default root")

Why not do the same for _QueryDialog in simpledialog.py? Actually, I would also withdraw the root that was just created, because the user doesn't expect this extra window. So, I would replace

    if not parent:
         parent = tkinter._default_root
 
with

    if parent is None:
        if tkinter._default_root: 
            parent = tkinter._default_root
        elif tkinter._support_default_root
            parent = tkinter.Tk()
            parent.withdraw()
        else:
            raise RuntimeError(
                    "No parent specified and tkinter is "
                    "configured to not support default root")

This tries to get a parent, if possible, and provides a more useful message when no parent can be found, just as in the ttk module in a similar situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Tue Dec 31 17:42:41 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 Dec 2019 22:42:41 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577832161.04.0.490693513592.issue27973@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Pablo, Is there a way for us to test https://github.com/python/cpython/pull/17774 on a Windows Builder which displayed the post-commit failure?

The CI custom-builders seem to be broken for a different reason: https://buildbot.python.org/all/#/builders/106

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Tue Dec 31 18:12:44 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Dec 2019 23:12:44 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1577833964.09.0.167672454342.issue39171@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17208
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17775

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Tue Dec 31 19:00:46 2019
From: report at bugs.python.org (Anthony Wee)
Date: Wed, 01 Jan 2020 00:00:46 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1577836846.3.0.11804886715.issue29778@roundup.psfhosted.org>


Anthony Wee <antxwee at gmail.com> added the comment:

It looks like there has been a regression in the fix for this issue. 

The commit below introduced a NULL check which causes a call to _PyPathConfig_Init() to be skipped if _Py_dll_path == NULL. It seems like the check should be "if (_Py_dll_path != NULL)"?

https://github.com/python/cpython/commit/c422167749f92d4170203e996a2c619c818335ea#diff-87aed37b4704d4e1513be6378c9c7fe6R169

----------
nosy: +anthonywee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Dec 31 19:51:39 2019
From: report at bugs.python.org (Dominic Mayers)
Date: Wed, 01 Jan 2020 00:51:39 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1577839899.5.0.217438900809.issue39171@roundup.psfhosted.org>


Change by Dominic Mayers <dominic_mayers at yahoo.com>:


----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Tue Dec 31 20:11:33 2019
From: report at bugs.python.org (Justin Hodder)
Date: Wed, 01 Jan 2020 01:11:33 +0000
Subject: [issue39175] Funkness with issubset
Message-ID: <1577841093.35.0.83643957986.issue39175@roundup.psfhosted.org>


New submission from Justin Hodder <draltaicaphone at gmail.com>:

line 59,"print(x2,"avalMana",set(avalMana.keys()))" prints:"{('A', 'B')} avalMana {'A', ('A', 'B'), ('A', 'C')}"

line 60,"        if x2.issubset(set(avalMana.keys())):" is False 
change line 60 to "        if x2.issubset(set(list(avalMana.keys()))):" and it works as expected.

----------
components: Interpreter Core
files: PythonDoesntWorks.py
messages: 359137
nosy: Justin Hodder
priority: normal
severity: normal
status: open
title: Funkness with issubset
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48814/PythonDoesntWorks.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39175>
_______________________________________

From report at bugs.python.org  Tue Dec 31 20:44:07 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 01 Jan 2020 01:44:07 +0000
Subject: [issue39176] Syntax error message uses strange term: "named
 assignment"
Message-ID: <1577843047.69.0.249542272206.issue39176@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

I know this is not allowed:

>>> ((a, b, c) := (1, 2, 3))
  File "<stdin>", line 1
SyntaxError: cannot use named assignment with tuple


But what is "named assignment", and why is this SyntaxError talking about it?  Shouldn't it say "cannot use assignment expressions with tuple" ?

----------
messages: 359138
nosy: nedbat
priority: normal
severity: normal
status: open
title: Syntax error message uses strange term: "named assignment"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39176>
_______________________________________

From report at bugs.python.org  Tue Dec 31 20:47:52 2019
From: report at bugs.python.org (hai shi)
Date: Wed, 01 Jan 2020 01:47:52 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1577843272.93.0.623732545537.issue39173@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Users or developers interact with program by cli(argparse), so attributes' output order affect users' interaction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39173>
_______________________________________

From report at bugs.python.org  Tue Dec 31 20:54:55 2019
From: report at bugs.python.org (Justin Hodder)
Date: Wed, 01 Jan 2020 01:54:55 +0000
Subject: [issue39175] Funkness with issubset
In-Reply-To: <1577841093.35.0.83643957986.issue39175@roundup.psfhosted.org>
Message-ID: <1577843695.28.0.342724259798.issue39175@roundup.psfhosted.org>


Justin Hodder <draltaicaphone at gmail.com> added the comment:

This works:
$ diff PythonDoesntWorks.py HowCanYouPayMana.v3.py
60c60
<         if x2.issubset(set(avalMana.keys())):
---
>         if x2.issubset(set(list(avalMana.keys()))):
62a63
>

this doesn't work:
$ diff PythonDoesntWorks.py HowCanYouPayMana.v3.py
60c60
<         if x2.issubset(set(avalMana.keys())):
---
>         if x2.issubset(set(list(avalMana.keys()))):
62a63
>                 print("cost",cost)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39175>
_______________________________________

From report at bugs.python.org  Tue Dec 31 20:55:01 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 01 Jan 2020 01:55:01 +0000
Subject: [issue37032] Add CodeType.replace() method
In-Reply-To: <1558689955.85.0.932624363868.issue37032@roundup.psfhosted.org>
Message-ID: <1577843701.46.0.588971927257.issue37032@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
pull_requests: +17209
pull_request: https://github.com/python/cpython/pull/17776

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37032>
_______________________________________

From report at bugs.python.org  Tue Dec 31 20:55:31 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 01 Jan 2020 01:55:31 +0000
Subject: [issue39176] Syntax error message uses strange term: "named
 assignment"
In-Reply-To: <1577843047.69.0.249542272206.issue39176@roundup.psfhosted.org>
Message-ID: <1577843731.75.0.108369418632.issue39176@roundup.psfhosted.org>


Change by Ned Batchelder <ned at nedbatchelder.com>:


----------
keywords: +patch
pull_requests: +17210
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17777

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39176>
_______________________________________

From report at bugs.python.org  Tue Dec 31 21:10:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Jan 2020 02:10:44 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1577844644.78.0.137989950883.issue39165@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359133

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Tue Dec 31 21:25:10 2019
From: report at bugs.python.org (Justin Hodder)
Date: Wed, 01 Jan 2020 02:25:10 +0000
Subject: [issue39175] Funkness with issubset
In-Reply-To: <1577841093.35.0.83643957986.issue39175@roundup.psfhosted.org>
Message-ID: <1577845510.43.0.518845049878.issue39175@roundup.psfhosted.org>


Justin Hodder <draltaicaphone at gmail.com> added the comment:

oh I'm using Python 3.8.1 (32-bit)
3.8.1150.0
on win10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39175>
_______________________________________

From report at bugs.python.org  Tue Dec 31 21:38:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Jan 2020 02:38:03 +0000
Subject: [issue39175] Funkness with issubset
In-Reply-To: <1577841093.35.0.83643957986.issue39175@roundup.psfhosted.org>
Message-ID: <1577846283.79.0.814312156294.issue39175@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The error is in line 51 which should be:  x3=tuple(sorted(x))
That will make sure you always get {('A', 'B')} instead of {('B', 'A')}.

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39175>
_______________________________________

From report at bugs.python.org  Tue Dec 31 21:41:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Jan 2020 02:41:05 +0000
Subject: [issue39176] Syntax error message uses strange term: "named
 assignment"
In-Reply-To: <1577843047.69.0.249542272206.issue39176@roundup.psfhosted.org>
Message-ID: <1577846465.87.0.65498037266.issue39176@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 37143a8e3b2e9245d52f4ddebbdd1c6121c96884 by Raymond Hettinger (Ned Batchelder) in branch 'master':
bpo-39176: Improve error message for 'named assignment' (GH-17777)
https://github.com/python/cpython/commit/37143a8e3b2e9245d52f4ddebbdd1c6121c96884


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39176>
_______________________________________

From report at bugs.python.org  Tue Dec 31 21:43:22 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 02:43:22 +0000
Subject: [issue39176] Syntax error message uses strange term: "named
 assignment"
In-Reply-To: <1577843047.69.0.249542272206.issue39176@roundup.psfhosted.org>
Message-ID: <1577846602.11.0.352681849169.issue39176@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17211
pull_request: https://github.com/python/cpython/pull/17778

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39176>
_______________________________________

From report at bugs.python.org  Tue Dec 31 21:45:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Jan 2020 02:45:42 +0000
Subject: [issue39176] Syntax error message uses strange term: "named
 assignment"
In-Reply-To: <1577843047.69.0.249542272206.issue39176@roundup.psfhosted.org>
Message-ID: <1577846742.85.0.517407123845.issue39176@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the patch.

----------
components: +Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39176>
_______________________________________

From report at bugs.python.org  Tue Dec 31 22:28:11 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 01 Jan 2020 03:28:11 +0000
Subject: [issue39176] Syntax error message uses strange term: "named
 assignment"
In-Reply-To: <1577843047.69.0.249542272206.issue39176@roundup.psfhosted.org>
Message-ID: <1577849291.26.0.707018110831.issue39176@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 6c004955aceb8a0cd8e14afbc608ebfdf7c8aa4a by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-39176: Improve error message for 'named assignment' (GH-17777) (GH-17778)
https://github.com/python/cpython/commit/6c004955aceb8a0cd8e14afbc608ebfdf7c8aa4a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39176>
_______________________________________