From report at bugs.python.org  Sat Feb  1 00:50:34 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 01 Feb 2020 05:50:34 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580536234.72.0.0446835949858.issue39496@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

You mean, something like

    while ((row = pysqlite_cursor_iternext(self))) {
            PyList_Append(list, row);
            Py_DECREF(row);
    }

? It's interesting that now we have walrus in Python, we see the opportunities for it in other languages. (In C, it's spelled (=).:)

----------
nosy: +veky

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

From report at bugs.python.org  Sat Feb  1 00:56:44 2020
From: report at bugs.python.org (Peter O.)
Date: Sat, 01 Feb 2020 05:56:44 +0000
Subject: [issue39391] Run-dependent Pydoc output for functions default
 parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1580536604.41.0.0628058898215.issue39391@roundup.psfhosted.org>


Peter O. <poccil14 at gmail.com> added the comment:

Is this bug tracker the correct place to "ask the pydoc developers to add an option to improve [the Pydoc] output", in the sense that the option doesn't write out object IDs?  If not, where is the correct place to do so?

----------

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

From report at bugs.python.org  Sat Feb  1 02:15:11 2020
From: report at bugs.python.org (Alex Henrie)
Date: Sat, 01 Feb 2020 07:15:11 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580541311.43.0.254923053391.issue39496@roundup.psfhosted.org>


Alex Henrie <alexhenrie24 at gmail.com> added the comment:

You're right, that's even better. I forgot that the equals operator also returns the variable's new value. I just updated my pull request :-)

----------

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

From report at bugs.python.org  Sat Feb  1 02:36:55 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 01 Feb 2020 07:36:55 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580542615.05.0.524387080254.issue39496@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

It seems you haven't read carefully what I've written. This way some compilers might emit warnings. Please read https://stackoverflow.com/questions/5476759/compiler-warning-suggest-parentheses-around-assignment-used-as-truth-value

----------

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

From report at bugs.python.org  Sat Feb  1 02:43:27 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 01 Feb 2020 07:43:27 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
 doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1580543007.58.0.715736236948.issue14074@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I am not sure disallowing tuple metavars would break backup compatibility or not~

----------
nosy: +shihai1991
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Feb  1 03:10:48 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 01 Feb 2020 08:10:48 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580544648.85.0.806736070099.issue39467@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

IMHO, cli should only support atomic function.What is atomic functin? (if downstream software's feature can not keep alive without upstream fucntion, it must be an atomic function).

----------
nosy: +shihai1991 -4383

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

From report at bugs.python.org  Sat Feb  1 03:20:45 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 01 Feb 2020 08:20:45 +0000
Subject: [issue39464] Allow translating argparse error messages
In-Reply-To: <1580133337.82.0.00677207154431.issue39464@roundup.psfhosted.org>
Message-ID: <1580545245.8.0.00294577850524.issue39464@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Paste Jos?'s comment from PR17169:

This message isn't used (only?) in exceptions... it's a message that is given to the console, to notify the user when she didn't provide correct parameters. For example:
 
```
$ python3 ./drt.py -l
Uso: ./drt.py [-h] [-l LONG_MIN] [-L LONG_MAX] [-v] [-V]
               entrada.json [salida.tok]
./drt.py: error: argument -l/--min-length: se esperaba un par?metro
```

These are console messages localized into Spanish. The "error:" part is translatable, but it's the same word in Spanish than in English. The "argument" part is what isn't translatable, and it's taken from this "exception".

I confirmed that my proposed patch, translating that particular string, allows giving a fully localized console output to the user in Spanish, such as:

`./drt.py: error: par?metro -l/--min-length: se esperaba un par?metro`

----------
nosy: +shihai1991

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

From report at bugs.python.org  Sat Feb  1 03:37:32 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 01 Feb 2020 08:37:32 +0000
Subject: [issue39464] Allow translating argparse error messages
In-Reply-To: <1580133337.82.0.00677207154431.issue39464@roundup.psfhosted.org>
Message-ID: <1580546252.83.0.00772667616563.issue39464@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Users interact with console's output, so translated the output info is fine to me.
Hi?raymond?paul. What's your opinion?

----------

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

From report at bugs.python.org  Sat Feb  1 03:50:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Feb 2020 08:50:55 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580547055.78.0.127152015157.issue39467@roundup.psfhosted.org>


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

In general I agree with Raymond, although I am warmer to this feature. And I think we should have a mechanism to deprecate not only options, but subcommands.

* The warnings module is used for warning about the use of API. It outputs the file and the line number of the caller to help the developer to fix his code. It allows to hide warnings from non-developers.

But warnings about deprecated CLI options and commands are purposed to be shown to the user of the CLI. They should not contain references to source code, because it is not the cause of the warning. The argparse module should use the same mechanism for warnings and errors: output to stderr.

* I do not understand the purpose of deprecated_pending. The feature is either deprecated or not. If it is deprecated, using it will produce a warning. If it is not deprecated -- no warning. In case of silent deprecation you can manually add a note in the help.

* I am not sure about deprecated_reason. We do not have a way to specify error message for standard errors (such like about missed required argument). If you need a custom warning, do not use the standard deprecation mechanism and emits a warning manually.

* As for moving the output of a warning to post-parsing logic, this is not always convenient and possible.

Let you have options "--verbose" which increments the verbosity level and "--verbosity-level" which sets it directly. One of them is deprecated. We can't easily use a post-parsing logic because they set the same destination. In this case we can workaround this by rewriting the logic to use different destinations, but there this is not always possible. Imagine you have options --add and --append which append the argument to the list and want to deprecate one of them. You can't use different lists and merge them in post-parsing, because the relative order matters.

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

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

From report at bugs.python.org  Sat Feb  1 05:11:08 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Sat, 01 Feb 2020 10:11:08 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1580551868.3.0.813230416582.issue39298@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

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

From report at bugs.python.org  Sat Feb  1 05:48:01 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 01 Feb 2020 10:48:01 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
Message-ID: <1580554081.01.0.712736172146.issue39516@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

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.
>>> 1 ++ 2
3

This is probably because the interpreter reads:

1 + +2

1. ++ could be an operator in future. Probably not. Probably never. But you never know.
2. A space between an unary operator and the object should not be allowed
3. the first expression is clearly unreadable and hard to understand, so completely unpythonic

----------
components: Interpreter Core
messages: 361159
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: ++ does not throw a SyntaxError
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sat Feb  1 06:12:55 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 01 Feb 2020 11:12:55 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>
Message-ID: <1580555575.49.0.599598625484.issue34793@roundup.psfhosted.org>


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


New changeset 90d9ba6ef10af32e8dfe0649789c3a8ccf419e95 by Andrew Svetlov in branch 'master':
bpo-34793: Drop old-style context managers in asyncio.locks (GH-17533)
https://github.com/python/cpython/commit/90d9ba6ef10af32e8dfe0649789c3a8ccf419e95


----------

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

From report at bugs.python.org  Sat Feb  1 06:14:45 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 01 Feb 2020 11:14:45 +0000
Subject: [issue34793] Remove support for "with (await asyncio.lock):"
In-Reply-To: <1537815811.02.0.545547206417.issue34793@psf.upfronthosting.co.za>
Message-ID: <1580555685.42.0.450500512944.issue34793@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/issue34793>
_______________________________________

From report at bugs.python.org  Sat Feb  1 06:23:50 2020
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 01 Feb 2020 11:23:50 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580517057.49.0.13192433757.issue39511@roundup.psfhosted.org>
Message-ID: <CAGvrs3LBh05fyS4ePw0Q99Xk0NC7TWUhfKT3emonFdPJ3FOEQw@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

> The problem is to make Py_INCREF/Py_DECREF efficient.

That is exactly why I didn't propose a change to them.  The singletons
still are refcounted as usual, just that their ob_refcnt is ignored.
If they somehow reach 0, they just "resurrect" themselves and ignore
the regular collection behavior.  In the presence of multiple
DECREF'ers, the ob_refcnt field is garbage, but that is OK as it is
effectively ignored.  Practicality vs Purity and all that.

> Last time someone tried to use an atomic variable for ob_refcnt, it was 20% slower if I recall correctly. If many threads start to update such atomic variable, the CPU cacheline of common singletons like None, True and False can quickly become a performance bottleneck.

Exactly so, hence why I chose the simple solution of effectively
ignoring ob_refcnt.

> On the other side, if each interpreter has its own objects, there is no need to protect ob_refcnt, the interpreter lock protects it.

My solution also does not need any protection around ob_refcnt.

----------
nosy: +jeremy.kloth

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

From report at bugs.python.org  Sat Feb  1 06:35:03 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 11:35:03 +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: <1580556903.91.0.478634760566.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Adding 3.8 before I post a PR - as I think the initial merge that introduced the regression was before master was considered 3.9.

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

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

From report at bugs.python.org  Sat Feb  1 07:10:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 12:10:29 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580559029.67.0.287103794693.issue39511@roundup.psfhosted.org>


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

I vaguely recall discussions about immortal Python objects.

(*) Instagram gc.freeze()

* https://docs.python.org/dev/library/gc.html#gc.freeze
* https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172

(*) Python immortal strings

* PyUnicode_InternImmortal()
* SSTATE_INTERNED_IMMORTAL
* They are only destroyed if Python is compiled with Valgrind or Purify support: unicode_release_interned() function

(*) COUNT_ALLOCS

* When Python is built with COUNT_ALLOCS macro defined, types are immortal
* Many tests have to be skipped if COUNT_ALLOCS is used
* I plan to remove COUNT_ALLOCS feature in bpo-39489 :-)

(*) Static types

* Types which are not allocated on the heap but "static" are immortal
* These types cause various issues and should go away
* For example, they are incompatible with multi-phase initialization module (PEP 489) and stable ABI (PEP 384)

----------

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

From report at bugs.python.org  Sat Feb  1 07:14:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 12:14:15 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580559255.58.0.989554083942.issue39511@roundup.psfhosted.org>


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

Recently, Petr Viktorin proposed immortal singletons in my latest "Pass the Python thread state to internal C functions" thread on python-dev list:
https://mail.python.org/archives/list/python-dev at python.org/message/RAVSH7HYHTROXSTUR3677WGTCTEO6FYF/

In 2004,  Jewett, Jim J proposed:

"What if a few common (constant, singleton) objects (such as None, -1, 0, 1) were declared immortal at compile-time?"

https://mail.python.org/archives/list/python-dev at python.org/thread/XWGRUATMRAVXXZKQ7QA2YX22KI55T7P5/#OQO7DWRVH7IIOE4RUJ2ZR7S5UT6WOCPS

----------

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

From report at bugs.python.org  Sat Feb  1 07:15:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 12:15:00 +0000
Subject: [issue26789] asyncio: Please do not log during shutdown
In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za>
Message-ID: <1580559300.89.0.745732382553.issue26789@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner
title: Please do not log during shutdown -> asyncio: Please do not log during shutdown

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

From report at bugs.python.org  Sat Feb  1 07:21:39 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 01 Feb 2020 12:21:39 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
In-Reply-To: <1580554081.01.0.712736172146.issue39516@roundup.psfhosted.org>
Message-ID: <1580559699.75.0.71703233296.issue39516@roundup.psfhosted.org>


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

This is not a bug, as you have pointed out yourself you are using a binary plus and a unary plus operator in the same expression.

This has been part of Python since version 1, and with operator overloading `obj + +thing` could mean whatever the objects want the two operators to mean. Unary plus is not necessarily a no-op. For example, the Decimal class gives a meaning to unary plus.

`++` should never be an operator in the future, precisely because it already has a meaning today (either two unary pluses, or binary plus followed by unary plus). Even if the compiler could distinguish between the cases, the human reader would not.

The first expression is not "unreadable". The fact that you were able to read it and diagnose it yourself as a binary operator followed by a unary operator proves that you can, in fact, read it. And it probably wasn't that hard to understand. (It wasn't for me.)

It would be easier to read if you used spaces around the binary plus and no space between the unary plus and its operand, but it can still be read and understood even with the unusual spacing.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Feb  1 08:04:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Feb 2020 13:04:45 +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: <1580562285.03.0.72295890491.issue39020@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Feb  1 08:07:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Feb 2020 13:07:19 +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: <1580562439.97.0.0565123512242.issue39020@roundup.psfhosted.org>


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

NetBSD also uses non-ncurses implementation of curses, but it supports ESCDELAY, set_escdelay(), etc. This is not a difference between ncurses and non-ncurse, but a problem specific to the AIX implementation of curses.

Please check that PR 18302 fixes the build.

----------

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

From report at bugs.python.org  Sat Feb  1 08:43:18 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 01 Feb 2020 13:43:18 +0000
Subject: [issue39378] partial of PickleState struct should be traversed.
In-Reply-To: <1579325487.94.0.252462243653.issue39378@roundup.psfhosted.org>
Message-ID: <1580564598.59.0.438175176421.issue39378@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


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

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

From report at bugs.python.org  Sat Feb  1 09:54:26 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 14:54:26 +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: <1580568866.03.0.0518968841393.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

removed 3.8, this is new for 3.9.

Have established that all four functions added in issue38132 do not exist in stock AIX libcurses.a

Was working on my own PR, but shall look at yours first.

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

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

From report at bugs.python.org  Sat Feb  1 09:56:43 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 01 Feb 2020 14:56:43 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
In-Reply-To: <1580554081.01.0.712736172146.issue39516@roundup.psfhosted.org>
Message-ID: <1580569003.41.0.582109148146.issue39516@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> This is not a bug
No one said it's a bug. It's a defect.

> This has been part of Python since version 1
There are many things that was part of Python 1 that was removed.

> `++` should never be an operator in the future, precisely because it already has a meaning today

This is not a "meaning". `++` means nothing. Indeed

>>> 1++
  File "<stdin>", line 1
    1++
      ^
SyntaxError: invalid syntax

> The first expression is not "unreadable". The fact that you were able to read it and diagnose it [...]

The fact I understood it it's because I'm a programmer with more than 10 years of experience, mainly in Python. And I discovered this defect by acccident, because I wanted to write `a += b` and instead I wrote `a ++ b`. And when happened, I didn't realized why it didn't raised a SyntaxError or, at least, a SyntaxWarning. I had to take some minutes to realize the problem. 

So, in my "humble" opinion, it's *highly* unreadable and surprising.

----------

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

From report at bugs.python.org  Sat Feb  1 10:05:10 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 15:05:10 +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: <1580569510.35.0.554487762237.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Have looked at your PR. It will not work on AIX because AIX libcurses is missing all four new functions.

Once I finished my test on AIX - shall I add my patch as a file here, so you can integrate into yours?

I hope that is easier than two PRs.

----------

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

From report at bugs.python.org  Sat Feb  1 10:20:31 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 15:20:31 +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: <1580570431.93.0.977533432791.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Here is the patch I am working on.

I appreciate your example on how to deal with the undefined variables. I had done that incorrectly initially.

----------
Added file: https://bugs.python.org/file48876/bpo-39020-AIX.patch

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

From report at bugs.python.org  Sat Feb  1 10:34:13 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 01 Feb 2020 15:34:13 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
In-Reply-To: <1580569003.41.0.582109148146.issue39516@roundup.psfhosted.org>
Message-ID: <20200201153409.GG6362@ando.pearwood.info>


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

Marco, this is no more of a defect than `x*-y` or `a&~b`. It is a binary 
operator followed by an unary operator, just like `x--y`, `x/-y`, 
`x+-y`, `x**-y` etc. Python has at least three unary operators and at 
least 17 binary operators so in total there are 51 possible legal 
combinations of a binary operator followed by an unary operator.

`++` isn't special, it's not unique, or a defect, or a bug.

>     1++
>       ^
> SyntaxError: invalid syntax

As a programmer with more than 10 years experience, you should know that 
this example is a syntax error because you are missing the right hand 
operand, not because `++` has no meaning. You would get precisely the 
same syntax error with `2*` or `2==`.

----------

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

From report at bugs.python.org  Sat Feb  1 11:14:36 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 16:14:36 +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: <1580573676.13.0.653090659672.issue39020@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +17680
pull_request: https://github.com/python/cpython/pull/18303

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

From report at bugs.python.org  Sat Feb  1 11:16:32 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 16:16:32 +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: <1580573792.88.0.0940742006337.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Thanks again for PR 18202. I followed your lead and made the additional changes and posted as PR 18203.

----------

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

From report at bugs.python.org  Sat Feb  1 11:18:47 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 01 Feb 2020 16:18:47 +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: <1580573927.39.0.84338103746.issue39020@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Blinded - got the numbers wrong!

So, again: Thanks for PR 18302. I followed your lead and made the additional changes and posted as PR 18303 in the hope this is easier for all.

----------

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

From report at bugs.python.org  Sat Feb  1 11:47:40 2020
From: report at bugs.python.org (Alex Henrie)
Date: Sat, 01 Feb 2020 16:47:40 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580575660.22.0.506252086043.issue39496@roundup.psfhosted.org>


Alex Henrie <alexhenrie24 at gmail.com> added the comment:

Sorry about that, I didn't notice that GCC's -Wall option emits a warning about this. I just added the extra sets of parentheses.

----------

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

From report at bugs.python.org  Sat Feb  1 11:59:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Feb 2020 16:59:22 +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: <1580576362.45.0.699229472582.issue39020@roundup.psfhosted.org>


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

Thank you Michael. Sorry, I just missed that you are working on your PR.

----------

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

From report at bugs.python.org  Sat Feb  1 12:02:12 2020
From: report at bugs.python.org (Tomas Ravinskas)
Date: Sat, 01 Feb 2020 17:02:12 +0000
Subject: [issue39517] runpy calls open_code with Path object
Message-ID: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>


New submission from Tomas Ravinskas <tomas.rav at gmail.com>:

runpy accepts Path like objects but open_code seems to only accept strings, so calling open_code with Path object throws TypeError.
I think runpy should call str() on all path passed to open_code.
The relevant line is 232 in runpy.py in function _get_code_from_file.

----------
components: Library (Lib)
messages: 361176
nosy: Tomas Ravinskas
priority: normal
severity: normal
status: open
title: runpy calls open_code with Path object
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Sat Feb  1 12:26:42 2020
From: report at bugs.python.org (Vitaly Zdanevich)
Date: Sat, 01 Feb 2020 17:26:42 +0000
Subject: [issue39518] Dark theme
Message-ID: <1580578002.89.0.0285133557366.issue39518@roundup.psfhosted.org>


New submission from Vitaly Zdanevich <vitaly.zdanevich at gmail.com>:

Please save our eyes. And batteries. Do not ignore this property of useragent https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

----------
assignee: docs at python
components: Documentation
messages: 361177
nosy: Vitaly Zdanevich, docs at python
priority: normal
severity: normal
status: open
title: Dark theme

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

From report at bugs.python.org  Sat Feb  1 12:27:41 2020
From: report at bugs.python.org (Vitaly Zdanevich)
Date: Sat, 01 Feb 2020 17:27:41 +0000
Subject: [issue39518] Dark theme
In-Reply-To: <1580578002.89.0.0285133557366.issue39518@roundup.psfhosted.org>
Message-ID: <1580578061.07.0.784290159611.issue39518@roundup.psfhosted.org>


Change by Vitaly Zdanevich <vitaly.zdanevich at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Sat Feb  1 12:41:28 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 01 Feb 2020 17:41:28 +0000
Subject: [issue39518] Dark theme
In-Reply-To: <1580578002.89.0.0285133557366.issue39518@roundup.psfhosted.org>
Message-ID: <1580578888.46.0.61214680096.issue39518@roundup.psfhosted.org>


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

This seems to be more of an issue relevant to python-docs-theme which is maintained separately : https://github.com/python/python-docs-theme

----------
nosy: +mdk, xtreak

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

From report at bugs.python.org  Sat Feb  1 12:44:37 2020
From: report at bugs.python.org (Mariatta)
Date: Sat, 01 Feb 2020 17:44:37 +0000
Subject: [issue39514] http://sphinx.pocoo.org/
In-Reply-To: <1580506603.75.0.50119765059.issue39514@roundup.psfhosted.org>
Message-ID: <1580579077.96.0.335837537523.issue39514@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Hmm the fix should have been included in release 2020.1, which was release a couple weeks ago.

----------
nosy: +Mariatta

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

From report at bugs.python.org  Sat Feb  1 12:47:50 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 01 Feb 2020 17:47:50 +0000
Subject: [issue39515] pathlib won't strip "\n" in path
In-Reply-To: <1580528708.47.0.815684087896.issue39515@roundup.psfhosted.org>
Message-ID: <1580579270.4.0.898576270968.issue39515@roundup.psfhosted.org>


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

A Windows path reserves the following characters:

* null, as the string terminator
* slash and backslash, as path separators
* colon as the second character in the first component of
  a non-UNC path, since it's a drive path

Additionally, a normalized path reserves trailing dots and spaces on names, since they get stripped from the final component (e.g. "C:\Temp\spam. . ." -> "C:\Temp\spam"). WindowsPath could automatically strip trailing dots and space from normalized paths. This would need to exclude extended paths that begin with the "\\?\" prefix.

Otherwise the set of reserved characters is a function of device and filesystem namespaces, regardless of the recommendations in "Naming Files, Paths, and Namespaces" [1], which are meant to constrain applications to what is generally allowed. I would prefer for WindowsPath to remain generic enough to support all device and filesystem namespaces. 

For example, the VirtualBox shared-folder filesystem (a mini-redirector to the host system) allows colon, pipe, and control characters in file and directory names:

    >>> control = '\a\b\t\n\v\f\r'
    >>> special = ':|'
    >>> dirname = f'//vboxsvr/work/nametest/{control}{special}'
    >>> os.makedirs(dirname, exist_ok=True)
    >>> os.listdir('//vboxsvr/work/nametest')[0]
    '\x07\x08\t\n\x0b\x0c\r:|'

Like most filesystems, it reserves the 5 wildcard characters in base filenames, which includes '*', '?', '<' (DOS_STAR), '>' (DOS_QM), and '"' (DOS_DOT). A filesystem that fails to reserve these wildcard characters cannot properly support WINAPI FindFirstFile[Ex]. The only filesystem I can think of that allows wildcard characters in base names is the named-pipe filesystem. NPFS actually allows any character in a pipe name -- even slash and backslash since it only supports a single directory, the root directory "//./PIPE/".

That said, a path may specify a stream name instead of a base filename. As is documented in [1], and NTFS stream name reserves colon as a delimiter, i.e. "filename:streamname:streamtype", and stream names can include wildcards, pipe, and control characters. For example:

    >>> control = '\a\b\t\n\v\f\r'
    >>> special = '*?<>"|'
    >>> dirname = 'C:\\Temp\\nametest'
    >>> filename = f'{dirname}\\spam'
    >>> streamname = f'{filename}:{control}{special}'
    >>> os.makedirs(dirname, exist_ok=True)
    >>> streamname
    'C:\\Temp\\nametest\\spam:\x07\x08\t\n\x0b\x0c\r*?<>"|'
    >>> open(streamname, 'w').close()

We can use PowerShell (pwsh) to verify the existence of the stream:

    >>> cmd = f'pwsh -c (gi "{filename}" -stream *)[1].Stream'
    >>> subprocess.check_output(cmd, text=True).rstrip()
    '\x07\x08\t\n\x0b\x0c\n*?<>"|'

In terms of device namespaces, a device that is not mounted by a filesystem can implement practically whatever namespace it wants. But considering "//./" device paths are normalized Windows paths, device namespaces should reserve slash, since the system translates slash to backslash.

[1] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

----------
nosy: +eryksun

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

From report at bugs.python.org  Sat Feb  1 12:50:11 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 01 Feb 2020 17:50:11 +0000
Subject: [issue39517] runpy calls open_code with Path object
In-Reply-To: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>
Message-ID: <1580579411.23.0.441236736184.issue39517@roundup.psfhosted.org>


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

Is there documentation in runpy where it's stated that path objects are accepted for the function? If not this seems to be an enhancement.

----------
nosy: +ncoghlan, xtreak

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

From report at bugs.python.org  Sat Feb  1 12:51:37 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 01 Feb 2020 17:51:37 +0000
Subject: [issue39517] runpy calls open_code with Path object
In-Reply-To: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>
Message-ID: <1580579497.69.0.3576059979.issue39517@roundup.psfhosted.org>


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


----------
type: crash -> behavior

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

From report at bugs.python.org  Sat Feb  1 12:53:52 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 01 Feb 2020 17:53:52 +0000
Subject: [issue39515] pathlib won't strip "\n" in path
In-Reply-To: <1580528708.47.0.815684087896.issue39515@roundup.psfhosted.org>
Message-ID: <1580579632.61.0.96644014398.issue39515@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.9

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

From report at bugs.python.org  Sat Feb  1 12:58:26 2020
From: report at bugs.python.org (Tomas Ravinskas)
Date: Sat, 01 Feb 2020 17:58:26 +0000
Subject: [issue39517] runpy calls open_code with Path object
In-Reply-To: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>
Message-ID: <1580579906.98.0.310657479199.issue39517@roundup.psfhosted.org>


Tomas Ravinskas <tomas.rav at gmail.com> added the comment:

Can't see anything about this in the docs, I just noticed that it breaks shiv after upgrade.

----------

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

From report at bugs.python.org  Sat Feb  1 13:59:12 2020
From: report at bugs.python.org (Vitaly Zdanevich)
Date: Sat, 01 Feb 2020 18:59:12 +0000
Subject: [issue39518] Dark theme
In-Reply-To: <1580578002.89.0.0285133557366.issue39518@roundup.psfhosted.org>
Message-ID: <1580583552.81.0.643854003454.issue39518@roundup.psfhosted.org>


Vitaly Zdanevich <vitaly.zdanevich at gmail.com> added the comment:

Added bug report to their repo https://github.com/python/python-docs-theme/issues/43

----------

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

From report at bugs.python.org  Sat Feb  1 14:03:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Feb 2020 19:03:23 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
 doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1580583803.81.0.898840827954.issue14074@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I am not sure disallowing tuple metavars would break backup 
> compatibility or not~

Given that tuple metavars currently doesn't work, there is no backward compatibility issue.  What is being proposed is to give more friendly error messages.

----------

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

From report at bugs.python.org  Sat Feb  1 14:04:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 01 Feb 2020 19:04:09 +0000
Subject: [issue39518] Dark theme property of useragent should be supported for
 docs.python.org
In-Reply-To: <1580578002.89.0.0285133557366.issue39518@roundup.psfhosted.org>
Message-ID: <1580583849.37.0.790021117305.issue39518@roundup.psfhosted.org>


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

Thanks, closing it as third party issue.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed
title: Dark theme -> Dark theme property of useragent should be supported for docs.python.org

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

From report at bugs.python.org  Sat Feb  1 14:15:35 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 01 Feb 2020 19:15:35 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
In-Reply-To: <1580554081.01.0.712736172146.issue39516@roundup.psfhosted.org>
Message-ID: <1580584534.99.0.588140266669.issue39516@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> `++` isn't special

Indeed the problem is that no error or warning is raised if two operators are consecutive, without a space between. All the cases you listed are terribly unreadable and hardly intelligible. 

Anyway I do not agree `++` is not special:

> you should know that this example is a syntax error because you are missing the right hand operand, not because `++` has no meaning

But you should know that in a *lot* of other popular languages, `++` and `--` are unary operators, so it's particularly surprisingly to see that they *seems* to work in Python, even if they *seems* to be a binary operator.

This is completely confusing and messy. Frankly, I'm not a PEP 8 orthodox at all. I think that you can write `a+b`. It's not elegant, it's a bit less readable that `a + b`, but it's not the end of the world. 

But you should *not* be allowed to write `a+-b` without at least a warning, because `+-` seems a binary operator. And you should not be able to write `a+ -b` too, with the interpreter that acts like Ponzio Pilato, because what's this? Is it an unary `+` or an unary `-`? 
We know the unary is the `-`, `a+` has no sense. but for someone that does not know Python, __it's not readable__. So, IMHO, the interpreter should at least raise a warning if the syntax is not: 
`a + -b`
for any combination of binary and unary operators.

----------

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

From report at bugs.python.org  Sat Feb  1 14:38:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Feb 2020 19:38:02 +0000
Subject: [issue39391] Pydoc: add option to remove run-specific ids (addresses)
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1580585882.58.0.713999622097.issue39391@roundup.psfhosted.org>


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

Sorry, I was thinking of something else when I closed this.  What you want is a new -x option, for some 'x'.  The following would help, especially as there is no one who specifically maintains pydoc.

a) a specific proposal or set of proposals as to what letter to use for the option and what the result should be.

b) a currently failing test case (based on the above).

c. a patch for test.test_pydoc adding the test, preferably self-contained (no added file)  -- or does any current test already involve an 'at 0xnnnnnnnn' output?

d. a patch for  pydoc.py making the test pass.

----------
resolution: third party -> 
stage: resolved -> test needed
status: closed -> open
title: Run-dependent Pydoc output for functions default parameters -> Pydoc: add option to remove run-specific ids (addresses)
type: behavior -> enhancement
versions: +Python 3.9

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

From report at bugs.python.org  Sat Feb  1 14:53:10 2020
From: report at bugs.python.org (brasko)
Date: Sat, 01 Feb 2020 19:53:10 +0000
Subject: [issue39519] Can't upgrade pip version 19.3.1 to 20.0.2 on Python
 3.7.4
Message-ID: <1580586790.78.0.0495228970738.issue39519@roundup.psfhosted.org>


New submission from brasko <lamon.joah at jxoo.us>:

Hi when I want to upgrade pip version I get:

Usage:
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip install [options] <requirement specifier> [package-index-options] ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip install [options] -r <requirements file> [package-index-options] ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip install [options] [-e] <vcs project url> ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip install [options] [-e] <local project path> ...
  C:\Users\User\AppData\Local\Programs\Python\Python37\python.exe -m pip install [options] <archive url/path> ...

no such option: -u

----------
components: Windows
messages: 361189
nosy: brasko, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't upgrade pip version 19.3.1 to 20.0.2 on Python 3.7.4
type: security
versions: Python 3.7

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

From report at bugs.python.org  Sat Feb  1 14:54:48 2020
From: report at bugs.python.org (Mariatta)
Date: Sat, 01 Feb 2020 19:54:48 +0000
Subject: [issue39514] http://sphinx.pocoo.org/
In-Reply-To: <1580506603.75.0.50119765059.issue39514@roundup.psfhosted.org>
Message-ID: <1580586888.63.0.865910900056.issue39514@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

I tested locally, if I build the docs using python-docs-theme 2020.1, the link is fixed.

I'm reopening this ticket.

I think it is a matter of making sure docs.p.o is using the right version of python-docs-theme. (v 2020.1)

----------
resolution: out of date -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Sat Feb  1 15:41:34 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Feb 2020 20:41:34 +0000
Subject: [issue39514] http://sphinx.pocoo.org/
In-Reply-To: <1580506603.75.0.50119765059.issue39514@roundup.psfhosted.org>
Message-ID: <1580589694.3.0.561656178305.issue39514@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

https://github.com/python/docsbuild-scripts/pull/83

----------

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

From report at bugs.python.org  Sat Feb  1 15:45:48 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Feb 2020 20:45:48 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580589948.01.0.75681715859.issue39496@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 78c7183f470b60a39ac2dd0ad1a94d49d1e0b062 by Alex Henrie in branch 'master':
bpo-39496: Remove redundant checks from _sqlite/cursor.c (GH-18270)
https://github.com/python/cpython/commit/78c7183f470b60a39ac2dd0ad1a94d49d1e0b062


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

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

From report at bugs.python.org  Sat Feb  1 15:46:08 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Feb 2020 20:46:08 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580589968.27.0.551998566011.issue39496@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Feb  1 16:10:07 2020
From: report at bugs.python.org (Batuhan)
Date: Sat, 01 Feb 2020 21:10:07 +0000
Subject: [issue39520] AST Unparser can't unparse ext slices correctly
Message-ID: <1580591407.68.0.673076668701.issue39520@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

(this issue has already a PR for ast.unparse)

>>> from __future__ import annotations
>>> import ast
>>> x: Tuple[1:2,] = 3
>>> __annotations__["x"]
'Tuple[1:2]'
>>> ast.dump(ast.parse("Tuple[1:2,]"))
"Module(body=[Expr(value=Subscript(value=Name(id='Tuple', ctx=Load()), slice=ExtSlice(dims=[Slice(lower=Constant(value=1, kind=None), upper=Constant(value=2, kind=None), step=None)]), ctx=Load()))], type_ignores=[])"

>>> ast.dump(ast.parse("Tuple[1:2]"))
"Module(body=[Expr(value=Subscript(value=Name(id='Tuple', ctx=Load()), slice=Slice(lower=Constant(value=1, kind=None), upper=Constant(value=2, kind=None), step=None), ctx=Load()))], type_ignores=[])"

----------
components: Interpreter Core
messages: 361193
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: AST Unparser can't unparse ext slices correctly
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Feb  1 16:14:04 2020
From: report at bugs.python.org (Batuhan)
Date: Sat, 01 Feb 2020 21:14:04 +0000
Subject: [issue39520] AST Unparser can't unparse ext slices correctly
In-Reply-To: <1580591407.68.0.673076668701.issue39520@roundup.psfhosted.org>
Message-ID: <1580591644.17.0.884652385792.issue39520@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


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

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

From report at bugs.python.org  Sat Feb  1 16:28:02 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 01 Feb 2020 21:28:02 +0000
Subject: [issue39519] Can't upgrade pip version 19.3.1 to 20.0.2 on Python
 3.7.4
In-Reply-To: <1580586790.78.0.0495228970738.issue39519@roundup.psfhosted.org>
Message-ID: <1580592482.63.0.836519820508.issue39519@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

`pip install --help` provides full list of options, the upgrade option is -U or --upgrade.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: security -> behavior

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

From report at bugs.python.org  Sat Feb  1 16:42:09 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 01 Feb 2020 21:42:09 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8.1 32-bit for
 Windows
Message-ID: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>


New submission from Stefan Pochmann <stefan.pochmann at gmail.com>:

Somehow `reversed` became much slower than `iter` on lists:

List with 1,000 elements:

> python -m timeit -s "a = list(range(1000))" "list(iter(a))"
50000 loops, best of 5: 5.73 usec per loop

> python -m timeit -s "a = list(range(1000))" "list(reversed(a))"
20000 loops, best of 5: 14.2 usec per loop

List with 1,000,000 elements:

> python -m timeit -s "a = list(range(250)) * 4000" "list(iter(a))"
50 loops, best of 5: 7.08 msec per loop

> python -m timeit -s "a = list(range(250)) * 4000" "list(reversed(a))"
20 loops, best of 5: 15.5 msec per loop

On another machine I tried ten different Python versions and found out it's only version 3.8.1 and only the 32-bit version:

                32-bit              64-bit
CPython     iter   reversed     iter   reversed
 3.5.4      19.8     19.9       22.4     22.7
 3.6.8      19.8     19.9       22.3     22.6
 3.7.6      19.9     19.9       22.3     22.5
 3.8.1      19.8     24.9       22.4     22.6

Another time with 3.8.0 instead of 3.8.1:

                32-bit              64-bit
CPython     iter   reversed     iter   reversed
 3.5.4      19.5     19.6       21.9     22.2
 3.6.8      19.5     19.7       21.8     22.1
 3.7.6      19.5     19.6       21.7     22.0
 3.8.0      19.4     24.5       21.7     22.1

I used the "Stable Releases" "executable installer"s from here:
https://www.python.org/downloads/windows/

More details here: https://stackoverflow.com/q/60005302/12671057

----------
components: Build
messages: 361195
nosy: Stefan Pochmann
priority: normal
severity: normal
status: open
title: reversed(mylist) much slower on Python 3.8.1 32-bit for Windows
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Sat Feb  1 16:47:04 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 01 Feb 2020 21:47:04 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8.1 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1580593624.5.0.947518898618.issue39521@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Your 3.8.0 numbers are similar to 3.8.1

----------
components: +Interpreter Core -Build
nosy: +SilentGhost, serhiy.storchaka, vstinner

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

From report at bugs.python.org  Sat Feb  1 16:48:23 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 01 Feb 2020 21:48:23 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1580593703.71.0.51263919425.issue39521@roundup.psfhosted.org>


Change by Stefan Pochmann <stefan.pochmann at gmail.com>:


----------
title: reversed(mylist) much slower on Python 3.8.1 32-bit for Windows -> reversed(mylist) much slower on Python 3.8 32-bit for Windows

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

From report at bugs.python.org  Sat Feb  1 16:51:17 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 01 Feb 2020 21:51:17 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1580593877.31.0.680148695635.issue39521@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

Oh right. The times are correct, I just summarized wrongly there.

----------

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

From report at bugs.python.org  Sat Feb  1 17:13:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Feb 2020 22:13:40 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1580595220.13.0.857817197434.issue39521@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The code for listiter_next() and listreviter_next() is almost the same. 

The main difference that the code for reversed saves the index to Py_ssize_t variable.  Maybe that causes a 32-bit to 64-bit conversion and back.  The change was made on 30 March 2016 in fbb1c5ee068d209e33f6e15ecb4821d5d8b107fa

Another possible cause is that this is just a random build outcome due to PGO or incidental branch mis-prediction from aliasing (as described in https://stackoverflow.com/a/17906589/1001643 ).

On the python.org mac 64-bit build, I'm not seeing any difference, so this is unique to the Windows 32-bit build.

$ python3.7 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(iter(a))"
100 loops, best of 11: 3.08 msec per loop
$ python3.7 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(reversed(a))"
100 loops, best of 11: 3.04 msec per loop
$ python3.8 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(iter(a))"
100 loops, best of 11: 3.07 msec per loop
$ python3.8 -m timeit -r11 -s "a = list(range(250)) * 4000" "list(reversed(a))"
100 loops, best of 11: 3.01 msec per loop

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sat Feb  1 18:35:59 2020
From: report at bugs.python.org (Batuhan)
Date: Sat, 01 Feb 2020 23:35:59 +0000
Subject: [issue39522] AST Unparser with unicode kinded constants
Message-ID: <1580600159.52.0.798208361602.issue39522@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

>>> from __future__ import annotations
>>> import ast
>>> x: u"a" = 3
>>> __annotations__["x"]
"'a'"
>>> ast.dump(ast.parse(__annotations__["x"])) == ast.dump(ast.parse('u"a"'))
False

I guess before touching constant part, we should wait for GH-17426 (afterward I can prepare a patch)

----------
components: Interpreter Core
messages: 361199
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: AST Unparser with unicode kinded constants
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Feb  1 20:36:57 2020
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 02 Feb 2020 01:36:57 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1580607417.13.0.695877753825.issue39010@roundup.psfhosted.org>


Change by Caleb Hattingh <caleb.hattingh at gmail.com>:


----------
nosy: +cjrh

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

From report at bugs.python.org  Sat Feb  1 21:05:21 2020
From: report at bugs.python.org (Alex Henrie)
Date: Sun, 02 Feb 2020 02:05:21 +0000
Subject: [issue39523] Unnecessary variable assignment and initial loop check
 in pysqlite_cursor_executescript
Message-ID: <1580609121.79.0.36186029109.issue39523@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

pysqlite_cursor_executescript currently has the following while loop:

    /* execute statement, and ignore results of SELECT statements */
    rc = SQLITE_ROW;
    while (rc == SQLITE_ROW) {
        rc = pysqlite_step(statement, self->connection);
        if (PyErr_Occurred()) {
            (void)sqlite3_finalize(statement);
            goto error;
        }
    }

This can and should be rewritten as a do-while loop to avoid having to initialize rc to SQLITE_ROW and then check its value knowing that the value check will succeed.

----------
components: Library (Lib)
messages: 361200
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Unnecessary variable assignment and initial loop check in pysqlite_cursor_executescript
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Sat Feb  1 21:06:58 2020
From: report at bugs.python.org (Alex Henrie)
Date: Sun, 02 Feb 2020 02:06:58 +0000
Subject: [issue39523] Unnecessary variable assignment and initial loop check
 in pysqlite_cursor_executescript
In-Reply-To: <1580609121.79.0.36186029109.issue39523@roundup.psfhosted.org>
Message-ID: <1580609218.7.0.642613690778.issue39523@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


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

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

From report at bugs.python.org  Sat Feb  1 21:50:32 2020
From: report at bugs.python.org (Daniel Hillier)
Date: Sun, 02 Feb 2020 02:50:32 +0000
Subject: [issue39294] zipfile.ZipInfo objects contain invalid 'extra' fields.
In-Reply-To: <1578693479.87.0.550823648689.issue39294@roundup.psfhosted.org>
Message-ID: <1580611832.18.0.516258753442.issue39294@roundup.psfhosted.org>


Daniel Hillier <daniel.hillier at gmail.com> added the comment:

This looks to be expected behaviour for the zip64 extension in the zip spec (for handling large files or large archives).

Section 4.4.1.4 of the zip spec outlines when the zip64 extra fields are used (https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT). In short, when the file offset header (number of bytes to the start of the file in the archive) exceeds the size allotted in the header in the original spec (0xFFFFFFFF or just under 2Gb).

Let me know if what you're observing is unrelated to this.

----------
nosy: +dhillier

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

From report at bugs.python.org  Sat Feb  1 22:51:40 2020
From: report at bugs.python.org (William Chargin)
Date: Sun, 02 Feb 2020 03:51:40 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1580615500.08.0.719761009096.issue18819@roundup.psfhosted.org>


William Chargin <wchargin at gmail.com> added the comment:

My pleasure. Is there anything else that you need from me to close this
out? It looks like the PR is approved and in an ?awaiting merge? state,
but I don?t have access to merge it.

----------

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

From report at bugs.python.org  Sat Feb  1 23:09:48 2020
From: report at bugs.python.org (mpheath)
Date: Sun, 02 Feb 2020 04:09:48 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
Message-ID: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>


New submission from mpheath <mpheath at tpg.com.au>:

In the ast module, a function named _pad_whitespace has a doc string with escape sequences of \f and \t.

The current doc string from Lib/ast.py:305 is:

    """Replace all chars except '\f\t' in a line with spaces."""

Example of doc string output in a REPL:

    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.
    >>> import ast
    >>> import inspect
    >>> inspect.getdoc(ast._pad_whitespace)
    "Replace all chars except '\x0c     ' in a line with spaces."
    >>>

The \x0c is the formfeed and the '     ' (5 spaces) was the tab.

It is my understanding that the output should be:

    "Replace all chars except '\f\t' in a line with spaces."

I would expect the source to be:

    """Replace all chars except '\\f\\t' in a line with spaces."""

or perhaps a raw string:

    r"""Replace all chars except '\f\t' in a line with spaces."""

The current Lib/ast.py:305 is Python 3.9.0 alpha 3 though the issue is also in Python 3.8.0 and 3.8.1 with 3.8/Lib/ast.py:227 .
Python 3.7.4 3.7/Lib/ast.py does not have the function _pad_whitespace as it appears major code changes occurred in the ast module with Python 3.8.0.

----------
messages: 361203
nosy: mpheath
priority: normal
severity: normal
status: open
title: Escape sequences in doc string of ast._pad_whitespace
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Feb  1 23:21:08 2020
From: report at bugs.python.org (mpheath)
Date: Sun, 02 Feb 2020 04:21:08 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580617268.26.0.929243194799.issue39524@roundup.psfhosted.org>


mpheath <mpheath at tpg.com.au> added the comment:

Correction: Python 3.8.0 and 3.8.1 with Lib/ast.py:277

Line 227 is invalid and 277 is correct.

----------

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

From report at bugs.python.org  Sat Feb  1 23:23:37 2020
From: report at bugs.python.org (mpheath)
Date: Sun, 02 Feb 2020 04:23:37 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580617417.03.0.506903344019.issue39524@roundup.psfhosted.org>


mpheath <mpheath at tpg.com.au> added the comment:

Correction: Python 3.8.0 and 3.8.1 with 3.8/Lib/ast.py:277

Line 227 is invalid and 277 is correct and forgot to add 3.8 prefix. Sorry.

----------

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

From report at bugs.python.org  Sat Feb  1 23:30:07 2020
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 02 Feb 2020 04:30:07 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580617807.18.0.558516140084.issue39483@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

@heckad You should instead ask the maintainers of teleton how to use their library with asyncio.run, not the other way round.

----------
nosy: +cjrh

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

From report at bugs.python.org  Sat Feb  1 23:35:04 2020
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 02 Feb 2020 04:35:04 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580618104.54.0.235033650179.issue39483@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

Hmm, my recent comment looks rude but I didn't intend it to be that way. What I mean is: there are many, many more users of asyncio.run than there are of teleton, so any change made to asyncio.run is going to affect more people than the other way round. So before we regard this as something that will be generally useful (run() taking a loop parameter), it will be faster to check if the 3rd party library provides a way to work with the std library.  FWIW I have an alternative run() implementation, with the PYPI package "aiorun" in which I do allow a loop parameter to be passed in. So far, it's only caused headaches for me as the maintainer :)

----------

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

From report at bugs.python.org  Sat Feb  1 23:43:00 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 02 Feb 2020 04:43:00 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580618580.82.0.130829069088.issue39524@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/issue39524>
_______________________________________

From report at bugs.python.org  Sat Feb  1 23:46:38 2020
From: report at bugs.python.org (Richard Bruskiewich)
Date: Sun, 02 Feb 2020 04:46:38 +0000
Subject: [issue35108] inspect.getmembers passes exceptions from object's
 properties through
In-Reply-To: <1540887635.53.0.788709270274.issue35108@psf.upfronthosting.co.za>
Message-ID: <1580618798.2.0.964140668609.issue35108@roundup.psfhosted.org>


Richard Bruskiewich <richard.bruskiewich at delphinai.com> added the comment:

This "bug" is buzzing around my project head right now, interfering with the operation of the Python Fire CLI library when it attempts to interrogate the Python Pandas DataFrame using the inspect.getmembers() call. See https://github.com/pandas-dev/pandas/issues/31474 and https://github.com/pandas-dev/pandas/pull/31549.

I have code that uses Fire and Pandas, but have to "dumb it down" to use Pandas 0.24.3 rather than the latest 0.25.1 which raises a "NotImplementedError" which leaks out of the getmembers() call.  The Pandas people are passing the buck to you folks in the Python community.

This is terribly frustrating for we minions in the real work trying to implementing real working software systems leveraging all these wonderful libraries (and the Python language).

When is this "bug" going to be fixed? Help!

----------
nosy: +richardbruskiewich

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

From report at bugs.python.org  Sat Feb  1 23:54:57 2020
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 02 Feb 2020 04:54:57 +0000
Subject: [issue38988] Killing asyncio subprocesses on timeout?
In-Reply-To: <1575654060.86.0.979877919031.issue38988@roundup.psfhosted.org>
Message-ID: <1580619297.09.0.268203779711.issue38988@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

@dontbugme This is a very old problem with threads and sub-processes.  In the general case (cross-platform, etc) it is difficult to kill threads and sub-processes from the outside. The traditional solution is to somehow send a message to the thread or subprocess to tell it to finish up. Then, you have to write the code running the thread or subprocess to notice such a message, and then shut itself down. With threads, the usual solution is to pass `None` on a queue, and have the thread pull data off that queue. When it receives a `None` it knows that it's time to shut down, and the thread terminates itself. This model can also be used with the multiprocessing module because there is a Queue instance provided there that works across the inter-process boundary.  Unfortunately, we don't have that feature in the asyncio subprocess machinery yet. For subprocesses, there are three options available:

1) Send a "shutdown" sentinal via STDIN (asyncio.subprocess.Process.communicate)
2) Send a process signal (via asyncio.subprocess.Process.send_signal)
3) Pass messages between main process and child process via socket connections

My experience has been that (3) is the most practical, esp. in a cross-platform sense. The added benefit of (3) is that this also works, unchanged, if the "worker" process is running on a different machine. There are probably things we can do to make (3) easier. Not sure.

I don't know if my comment helps, but I feel your pain. You are correct that `wait_for` is not an alternative to `timeout` because there is no actual cancellation that happen.

----------
nosy: +cjrh

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

From report at bugs.python.org  Sat Feb  1 23:58:36 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 02 Feb 2020 04:58:36 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580619516.65.0.333580964876.issue39479@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'd have to hear back from Raymond more on what he had in mind - I may well have been reading far too much in the specific name he suggested.

Don't much care about API, etc - pick something reasonable and go with it.  I'm not overly ;-) concerned with being "newbie friendly".  If someone is in a context where they need to use probabilistic solutions, there is no substitute for them learning something non-trivial about them.  The usual API for a Miller-Rabin tester supports passing in the number of bases to try, and it's as clear as anything of this kind _can_ be then that the probability of getting back True when the argument is actually composite is no higher than 1 over 4 to the power of the number of bases tried.  Which is also the way they'll find it explained in every reference.  It's doing nobody a real favor to make up our own explanations for a novel UI ;-)

BTW, purely by coincidence, I faced a small puzzle today, as part of a larger problem:

Given that 25 is congruent to 55 mod 10, and also mod 15, what's the largest modulus we can be certain of that the congruence still holds?  IOW, given

    x = y (mod A), and
    x = y (mod B)

what's the largest C such that we can be certain

    x = y (mod C)

too?  And the answer is C = lcm(A, B) (which is 30 in the example).

----------

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

From report at bugs.python.org  Sun Feb  2 00:10:48 2020
From: report at bugs.python.org (David Hwang)
Date: Sun, 02 Feb 2020 05:10:48 +0000
Subject: [issue39525] math.remainder() give wrong answer on large integer
Message-ID: <1580620248.23.0.0499654222962.issue39525@roundup.psfhosted.org>


New submission from David Hwang <hungry4grace at gmail.com>:

These two numbers are off by 1, and so should give different answer to
>>> math.remainder(12345678901234567890,3)
1.0
>>> math.remainder(12345678901234567891,3)
1.0

----------
components: Library (Lib)
messages: 361211
nosy: David Hwang
priority: normal
severity: normal
status: open
title: math.remainder() give wrong answer on large integer
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Feb  2 00:22:38 2020
From: report at bugs.python.org (mlwtc)
Date: Sun, 02 Feb 2020 05:22:38 +0000
Subject: [issue39526] print(text1.get(1.2,1.5))
Message-ID: <1580620958.57.0.556548292097.issue39526@roundup.psfhosted.org>


New submission from mlwtc <meistudent at 163.com>:

>>> from tkinter import *
>>> root = Tk()
>>> text1 = Text(root,width=30,height=3)
>>> text1.insert(INSERT,'abcdefghijklmnopqrstuvwxyz123456789123456789')
>>> print(text1.get(1.0,1.30))
abc
>>> print(text1.get(1.0,1.31))
abcdefghijklmnopqrstuvwxyz12345
>>> print(text1.get(1.0,1.20))
ab
>>> print(text1.get(1.0,1.21))
abcdefghijklmnopqrstu
>>> print(text1.get(1.0,1.10))
a
>>> print(text1.get(1.0,1.11))
abcdefghijk
>>> print(text1.get(1.0,1.9))
abcdefghi
  

   Is there a bug here?

----------
components: Build
messages: 361212
nosy: mlwtc
priority: normal
severity: normal
status: open
title: print(text1.get(1.2,1.5))
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Sun Feb  2 00:29:55 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 02 Feb 2020 05:29:55 +0000
Subject: [issue39527] Update doc of argparse.rst
Message-ID: <1580621395.73.0.298845669728.issue39527@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

1. examples don't need import argparse much times(IMHO, it should be a default behavior);
2. argparse have no doctest, it's not a good behavior;

----------
assignee: docs at python
components: Documentation
messages: 361213
nosy: docs at python, mdk, rhettinger, shihai1991
priority: normal
severity: normal
status: open
title: Update doc of argparse.rst
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun Feb  2 00:33:33 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 02 Feb 2020 05:33:33 +0000
Subject: [issue39527] Update doc of argparse.rst
In-Reply-To: <1580621395.73.0.298845669728.issue39527@roundup.psfhosted.org>
Message-ID: <1580621613.58.0.27851536937.issue39527@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


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

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

From report at bugs.python.org  Sun Feb  2 00:42:11 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 02 Feb 2020 05:42:11 +0000
Subject: [issue39525] math.remainder() give wrong answer on large integer
In-Reply-To: <1580620248.23.0.0499654222962.issue39525@roundup.psfhosted.org>
Message-ID: <1580622131.77.0.341253326354.issue39525@roundup.psfhosted.org>


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

math.remainder performs *floating point* remainder. That means it has to convert the arguments to floats first, and there is no float capable of representing either of those two numbers exactly:

    py> '%f' % float(12345678901234567890)
    '12345678901234567168.000000'
    py> '%f' % float(12345678901234567891)
    '12345678901234567168.000000'

That's just the way floats work. They don't have infinite precision, so sometimes they have rounding error.

If you want exact integer remainder, use the `%` operator:

    py> 12345678901234567890 % 3
    0
    py> 12345678901234567891 % 3
    1

See the tutorial and the FAQs

https://docs.python.org/3/tutorial/floatingpoint.html

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Feb  2 00:44:04 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 02 Feb 2020 05:44:04 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
 doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1580622244.14.0.551518836561.issue14074@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Given that tuple metavars currently doesn't work, there is no backward compatibility issue.  What is being proposed is to give more friendly error messages.

Got it, thanks.

> Paul suggested that it may be a better plan to just disallow tuple metavars and to give a better error message as the OP suggested.  That makes sense to me.

+1

----------

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

From report at bugs.python.org  Sun Feb  2 00:44:51 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 02 Feb 2020 05:44:51 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
 doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1580622291.75.0.641386333019.issue14074@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


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

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

From report at bugs.python.org  Sun Feb  2 00:45:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 02 Feb 2020 05:45:26 +0000
Subject: [issue39526] print(text1.get(1.2,1.5))
In-Reply-To: <1580620958.57.0.556548292097.issue39526@roundup.psfhosted.org>
Message-ID: <1580622326.28.0.651221766748.issue39526@roundup.psfhosted.org>


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

> Is there a bug here?

How about if you tell us what behaviour you expected, why you expected it, and what you got instead, then we can tell you if your expectation was correct and whether or not there is a bug.

You have seven results printed. I have no idea which ones you think are wrong.

----------
components: +Tkinter -Build
nosy: +steven.daprano
type: compile error -> behavior

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

From report at bugs.python.org  Sun Feb  2 00:54:12 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 02 Feb 2020 05:54:12 +0000
Subject: [issue39525] math.remainder() give wrong answer on large integer
In-Reply-To: <1580620248.23.0.0499654222962.issue39525@roundup.psfhosted.org>
Message-ID: <1580622852.64.0.660150619429.issue39525@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Arguments to `remainder()` are converted to floats, and the returned value is also a float.  These specific arguments convert to the same float:

>>> a = 12345678901234567890
>>> b = 12345678901234567891
>>> float(a) == float(b)
True

And the float they convert _to_ retains only the 53 most-significant bits of the inputs:

>>> int(float(b))
12345678901234567168
>>> c = _
>>> c.bit_length()
64
>>> bin(c)
'0b1010101101010100101010011000110011101011000111110000100000000000'

Note that the last 11 bits are zeroes, and 64 - 11 = 53.

So this is all doing what it's intended to do, and won't be changed.

I'm leaving this open, though, in case someone thinks the docs should be clarified.  But the same things apply to _many_ functions in the `math` module:  unless the docs specifically say they work with integer arguments, integer arguments are converted to float.

Oops!  Someone else already closed this while I was typing.  That's fine by me too ;-)

----------
nosy: +tim.peters

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

From report at bugs.python.org  Sun Feb  2 00:56:30 2020
From: report at bugs.python.org (Dan Snider)
Date: Sun, 02 Feb 2020 05:56:30 +0000
Subject: [issue39528] add "
Message-ID: <1580622990.14.0.618721528246.issue39528@roundup.psfhosted.org>


Change by Dan Snider <mr.assume.away at gmail.com>:


----------
nosy: bup
priority: normal
severity: normal
status: open
title: add "

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

From report at bugs.python.org  Sun Feb  2 01:02:25 2020
From: report at bugs.python.org (mlwtc)
Date: Sun, 02 Feb 2020 06:02:25 +0000
Subject: [issue39526] print(text1.get(1.2,1.5))
In-Reply-To: <1580620958.57.0.556548292097.issue39526@roundup.psfhosted.org>
Message-ID: <1580623345.43.0.982814738381.issue39526@roundup.psfhosted.org>


mlwtc <meistudent at 163.com> added the comment:

Look at line 5:print(text1.get(1.0,1.30))
I think the result should be "abcdefghijklmnopqrstuvwxyz1234"

print(text1.get(1.0,1.20))
I think the result should be "abcdefghijklmnopqrst"

print(text1.get(1.0,1.10))
I think the result should be "abcdefghij"

     Others are correct,So I don't know why these results are not my expected.

----------

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

From report at bugs.python.org  Sun Feb  2 01:37:09 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 02 Feb 2020 06:37:09 +0000
Subject: [issue39513] NameError: name 'open' is not defined
In-Reply-To: <1580498337.58.0.0606728460892.issue39513@roundup.psfhosted.org>
Message-ID: <1580625429.74.0.598474367133.issue39513@roundup.psfhosted.org>


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

Please attach a small script which allows reproduction of this issue - otherwise, it's unlikely we'll be able to make much progress, and I'll probably close it in a week or so if you haven't been able to do this. Thanks!

----------

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

From report at bugs.python.org  Sun Feb  2 01:43:46 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 02 Feb 2020 06:43:46 +0000
Subject: [issue38506] Launcher for Windows (py.exe) may rank Python 3.xx (in
 the future) after 3.x
In-Reply-To: <1571322664.68.0.257867788049.issue38506@roundup.psfhosted.org>
Message-ID: <1580625826.86.0.599215357161.issue38506@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17684
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18307

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

From report at bugs.python.org  Sun Feb  2 02:02:51 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 02 Feb 2020 07:02:51 +0000
Subject: [issue39528] add "
Message-ID: <1580626971.76.0.561762685962.issue39528@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Feb  2 02:30:48 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 02 Feb 2020 07:30:48 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580472937.77.0.880294060551.issue39479@roundup.psfhosted.org>
Message-ID: <20200202073043.GH6362@ando.pearwood.info>


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

On Fri, Jan 31, 2020 at 12:15:37PM +0000, Vedran ?a?i? wrote:
> 
> Vedran ?a?i? <vedgar at gmail.com> added the comment:
> 
> is_prime that's always correct is probably not the right thing to go into math. Besides, now we have isqrt, it's just
> 
>     n>1 and n&1 and all(n%d for d in range(3,isqrt(n)+1,2))
> 
> -- yes, it's damn slow, but so is everything else you want to be absolutely correct. :-]

Lots of things are fast and still absolutely correct.

And I think that you probably are underestimating just how slow trial 
division is for testing primes. I can imagine you've probably tested it 
on "large numbers" like a trillion-trillion (1e18) and thought that's 
acceptably fast. Try it on numbers like this:

P = int('29674495668685510550154174642905332730771991'
        '79985304335099507553127683875317177019959423'
        '8596428121188033664754218345562493168782883')
Q = P*(313*(P-1)+1)*(353*(P-1)+1)

Q is a 397 digit Carmichael Number. Its smallest factor is P, which has 
131 digits. If your computer is fast enough to perform a thousand 
trillion (1e15) divisions per second, your trial division will take more 
than 3e107 years to complete. That's 10 million trillion trillion 
trillion trillion trillion trillion trillion trillion trillion times 
longer than the universe has existed.

In a practical sense, your algorithm is never going to terminate. The 
sun will burn out and die first.

Upgrading your CPU is not going to help.

My old and slow PC can prove that Q is a composite number, using pure 
Python, in less than six seconds. And I'm sure that a better programmer 
than me would be able to shave off some of that time.

> is_probable_prime is another matter, but there is an enormous amount 
> of bikeshedding about the API of that one.

What is there to bikeshed about the API?

The API should be a function that takes a single integer, and returns 
False if that number is certainly composite[1] otherwise True.

I will argue that any other details -- including whether it is 
probabilistic or not -- are *quality of implementation* issues and not 
part of the API.

For the same reason, the name should be just "is_prime" (or "isprime") 
and not disturb naive users by calling it "probably prime".

Experts will read the documentation and/or the source code, and everyone 
else can happily ignore the microscopic[2] chance of a false positive 
with really huge numbers. (Sometimes ignorance really is bliss.)

We can argue on technical grounds just what the implementation should 
be, but that's not part of the API, and the implementation could change:

- Miller-Rabin, or Baillie?PSW, or AKS, or something else;
- whether probabilistic or deterministic;
- what error rate (if any) we are willing to accept;

etc.

If we choose the fast, simple Miller-Rabin test, with just 30 random 
iterations the error rate is less than approximately one in a trillion 
trillion. If we tested a million numbers ever second, it would take over 
18,000 years (on average) to find one false positive.

If that isn't good enough, increase the number of iterations to 50, in 
which case you would expect one false positive every 20,000 trillion 
years.

In comparison, it is estimated that cosmic rays cause memory bit 
flips as often one error per 4GB of RAM per day. This probabilistic 
algorithm is more reliable than your determinstic computer.

https://blogs.oracle.com/linux/attack-of-the-cosmic-rays-v2

https://www.johndcook.com/blog/2019/05/20/cosmic-rays-flipping-bits/

I don't have much time for worries about Miller-Rabin being 
"probabilistic". When I was young and naive I worried about it a lot, 
and maybe that was a legitimate worry for a naive Miller-Rabin 
implementation that did, say, five iterations (probability of a false 
positive about 0.1%).

But with 30 or 50 rounds, I am confident that nobody will ever 
experience such a false positive, not if they spend their entire 
lifetime doing nothing but calling `is_prime`.

Let's be real: if the banks are willing to trust the transfer of 
billions of dollars to probabilistic primality testing, why are we 
worring about this?

(By the way: for smallish numbers, under 2**64, no more than twelve 
rounds of Miller-Rabin are sufficient to deterministically decide 
whether a number is prime or not. Likewise for Baillie?PSW, which is 
also completely deterministic for numbers up to 2**64.)

[1] For ease of discussion, we'll count zero and one as composite.

[2] More like nanoscopic or picoscopic.

----------

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

From report at bugs.python.org  Sun Feb  2 02:52:28 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 02 Feb 2020 07:52:28 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580629948.16.0.268853784976.issue39479@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Tim: Considering that congruence is _defined_ as x=y(mod m) :<=> m|y-x, it's really not so surprising. :-)

Steven: It seems that we completely agree about inclusion of is_probabilistic_prime in stdlib. And we agree that it should be called isprime (or is_prime if Raymond names it;). About the bikeshedding, see Tim's comment. :-P

About absolutely correct algorithms: first, what exactly is your claim? If it's "I can write an algorithm in pure Python that can for every number of 397 digits mathematically exactly determine whether it is prime in under 6 seconds", I'd very much like to see that algorithm. (I guess it must be publicly available, since we're speaking about inclusion in Python stdlib.) I really don't have much expertise in number theory that I can be convinced it doesn't exist, but I very much doubt it.

----------

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

From report at bugs.python.org  Sun Feb  2 02:53:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Feb 2020 07:53:27 +0000
Subject: [issue39513] NameError: name 'open' is not defined
In-Reply-To: <1580498337.58.0.0606728460892.issue39513@roundup.psfhosted.org>
Message-ID: <1580630007.29.0.165868892237.issue39513@roundup.psfhosted.org>


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

Symptoms as when try to log very late at shutdown stage, when the content of the builtin module is restored to its original value which does not include open imported from io.

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

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

From report at bugs.python.org  Sun Feb  2 03:00:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Feb 2020 08:00:12 +0000
Subject: [issue39526] print(text1.get(1.2,1.5))
In-Reply-To: <1580620958.57.0.556548292097.issue39526@roundup.psfhosted.org>
Message-ID: <1580630412.11.0.431850707408.issue39526@roundup.psfhosted.org>


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

1.30 is the same as 1.3 in Python.

You perhaps want to use '1.30'.

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

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

From report at bugs.python.org  Sun Feb  2 03:28:51 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 02 Feb 2020 08:28:51 +0000
Subject: [issue39513] NameError: name 'open' is not defined
In-Reply-To: <1580498337.58.0.0606728460892.issue39513@roundup.psfhosted.org>
Message-ID: <1580632131.79.0.875588971116.issue39513@roundup.psfhosted.org>


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

Well, my comment/request was prompted by whether this issue is a duplicate of bpo-26789, because it's not clear from the OP. If it is, then it can be closed as such. I don't think this is specifically a logging problem, more a case of how things become inaccessible as the interpreter shuts down. Any code which calls "open" (or some other builtins) would run into this problem, not just and not specifically logging. I'm not sure, but I don't believe we have a good answer to this problem in general.

----------

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

From report at bugs.python.org  Sun Feb  2 05:06:39 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Feb 2020 10:06:39 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580637999.49.0.818433519191.issue39350@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Feb  2 05:08:55 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Feb 2020 10:08:55 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580638135.18.0.275443382899.issue39350@roundup.psfhosted.org>


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

Apologies, I think I moved the discussion off-track. The first order of business should be to fix the regression. We can discuss behaviour changes after that.

I've opened GH-18309 as a quick fix for the regression.

----------

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

From report at bugs.python.org  Sun Feb  2 05:13:41 2020
From: report at bugs.python.org (mlwtc)
Date: Sun, 02 Feb 2020 10:13:41 +0000
Subject: [issue39526] print(text1.get(1.2,1.5))
In-Reply-To: <1580620958.57.0.556548292097.issue39526@roundup.psfhosted.org>
Message-ID: <1580638421.64.0.764555420384.issue39526@roundup.psfhosted.org>


mlwtc <meistudent at 163.com> added the comment:

ok, I see, Thank U.

----------

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

From report at bugs.python.org  Sun Feb  2 05:19:53 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 02 Feb 2020 10:19:53 +0000
Subject: [issue39526] print(text1.get(1.2,1.5))
In-Reply-To: <1580620958.57.0.556548292097.issue39526@roundup.psfhosted.org>
Message-ID: <1580638793.37.0.512907207958.issue39526@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Feb  2 05:46:34 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 02 Feb 2020 10:46:34 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1580640394.97.0.456643374227.issue12915@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +17686
pull_request: https://github.com/python/cpython/pull/18310

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

From report at bugs.python.org  Sun Feb  2 05:53:17 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 02 Feb 2020 10:53:17 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580640797.62.0.589393719196.issue39434@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Small style question: using 5 spaces in https://github.com/python/cpython/blob/master/Objects/floatobject.c#L655-L664 after PR 18147 merged.
Due to bpo don't receive style quesiton, I commented here.

----------
nosy: +shihai1991

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

From report at bugs.python.org  Sun Feb  2 05:57:13 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 Feb 2020 10:57:13 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580641033.77.0.835093571749.issue39483@roundup.psfhosted.org>


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


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Feb  2 06:05:06 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 02 Feb 2020 11:05:06 +0000
Subject: [issue28276] test_loading.py - false positive result for "def
 test_find" when find_library() is not functional or the (shared) library does
 not exist
In-Reply-To: <1474887883.6.0.275550575314.issue28276@psf.upfronthosting.co.za>
Message-ID: <1580641506.16.0.134442503269.issue28276@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

This is something from long long ago - time to get it completed.

The (remaining) issue is: "c" and "m" may not be shared libraries - so nothing is ever found and the test is "skipped" but reports itself as PASSED.

The original issue (fixed for AIX in Python3.7) would be if find_library itself is broken and always returns NULL/None.

Again, the tests says "PASSED" when actually it was skipped.

Following this - Martin's suggestion seems a viable solution.

----------
type:  -> behavior

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

From report at bugs.python.org  Sun Feb  2 06:11:37 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 Feb 2020 11:11:37 +0000
Subject: [issue39529] Deprecate get_event_loop()
Message-ID: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>


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

Yuri proposed it for Python 3.8 but at that time the change was premature.
Now we can reconsider it for 3.9

The problem is that asyncio.get_event_loop() not only returns a loop but also creates it on-demand if the thread is main and the loop doesn't exist.  

It leads to weird errors when get_event_loop() is called at import-time and asyncio.run() is used for asyncio code execution.

get_running_loop() is a much better alternative when used *inside* a running loop, run() should be preferred for calling async code at top-level. Low-level new_event_loop()/loop.run_until_complete() are still present to run async code if top-level run() is not suitable for any reason.

asyncio.run() was introduced in 3.7, deprecation on get_event_loop() in 3.8 was able to complicate support of 3.5/3.6 by third-party libraries.
3.5 now reached EOL, 3.6 is in the security-fix mode and going close to EOL. Most people are migrated to newer versions already if they care.
The maintenance burden of the introduced deprecation should be pretty low.

----------
messages: 361229
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Deprecate get_event_loop()

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

From report at bugs.python.org  Sun Feb  2 06:14:56 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Feb 2020 11:14:56 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580642096.64.0.784259936005.issue39434@roundup.psfhosted.org>


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


----------
pull_requests: +17687
pull_request: https://github.com/python/cpython/pull/18311

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

From report at bugs.python.org  Sun Feb  2 06:37:37 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Feb 2020 11:37:37 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580643457.9.0.646292444616.issue39434@roundup.psfhosted.org>


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

@shihai1991 Good catch! Now fixed.

----------

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

From report at bugs.python.org  Sun Feb  2 07:23:50 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 02 Feb 2020 12:23:50 +0000
Subject: [issue28276] test_loading.py - false positive result for "def
 test_find" when find_library() is not functional or the (shared) library does
 not exist
In-Reply-To: <1474887883.6.0.275550575314.issue28276@psf.upfronthosting.co.za>
Message-ID: <1580646230.26.0.382239752722.issue28276@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


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

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

From report at bugs.python.org  Sun Feb  2 07:24:19 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 02 Feb 2020 12:24:19 +0000
Subject: [issue28276] test_loading.py - false positive result for "def
 test_find" when find_library() is not functional or the (shared) library does
 not exist
In-Reply-To: <1474887883.6.0.275550575314.issue28276@psf.upfronthosting.co.za>
Message-ID: <1580646259.08.0.45611511397.issue28276@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


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

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

From report at bugs.python.org  Sun Feb  2 07:49:04 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Feb 2020 12:49:04 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1580647744.29.0.0787688245945.issue39349@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 339fd46cb764277cbbdc3e78dcc5b45b156bb6ae by Kyle Stanley in branch 'master':
bpo-39349: Add *cancel_futures* to Executor.shutdown() (GH-18057)
https://github.com/python/cpython/commit/339fd46cb764277cbbdc3e78dcc5b45b156bb6ae


----------

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

From report at bugs.python.org  Sun Feb  2 07:50:29 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Feb 2020 12:50:29 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1580647829.58.0.587837450612.issue39349@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you very muck, Kyle!

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

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

From report at bugs.python.org  Sun Feb  2 07:59:02 2020
From: report at bugs.python.org (Michael Felt)
Date: Sun, 02 Feb 2020 12:59:02 +0000
Subject: [issue28312] Minor change - more direct hint re: multiple machine
 sizes and LONG_BIT conflicts
In-Reply-To: <1475143958.19.0.0194605363834.issue28312@psf.upfronthosting.co.za>
Message-ID: <1580648342.66.0.975283232776.issue28312@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


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

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

From report at bugs.python.org  Sun Feb  2 08:47:12 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 02 Feb 2020 13:47:12 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580651232.86.0.717216569383.issue39434@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Thanks good catch :)

----------

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

From report at bugs.python.org  Sun Feb  2 09:17:34 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Feb 2020 14:17:34 +0000
Subject: [issue39530] Documentation about comparisons between numeric types is
 misleading
Message-ID: <1580653054.78.0.127921454413.issue39530@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The documentation[1] for comparisons between mixed types says:

> [...] when a binary arithmetic operator has operands of different
> numeric types, the operand with the "narrower" type is widened to
> that of the other, where integer is narrower than floating point,
> which is narrower than complex. Comparisons between numbers of
> mixed type use the same rule.

That "use the same rule" part of the last sentence is misleading: it suggests that (for example) when an int is compared with a float, the int is first converted to a float, and then the two floats are compared. But that's not what actually happens: instead, the exact values of the int and float are compared. (And it's essential that equality comparisons happen that way, else equality becomes intransitive and dictionaries with numeric keys get very confused as a result.)

I suggest dropping the last sentence and adding a new paragraph about comparisons between numbers of mixed type.




[1] https://github.com/python/cpython/blob/master/Doc/library/stdtypes.rst#numeric-types-----classint-classfloat-classcomplex

----------
assignee: docs at python
components: Documentation
messages: 361234
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Documentation about comparisons between numeric types is misleading
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Feb  2 09:21:06 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Feb 2020 14:21:06 +0000
Subject: [issue39530] Documentation about comparisons between numeric types is
 misleading
In-Reply-To: <1580653054.78.0.127921454413.issue39530@roundup.psfhosted.org>
Message-ID: <1580653266.48.0.702940273219.issue39530@roundup.psfhosted.org>


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

Related SO question: https://stackoverflow.com/questions/60005876/how-does-python-compare-int-to-float-objects

----------

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

From report at bugs.python.org  Sun Feb  2 09:21:34 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 14:21:34 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1580653294.78.0.261250719011.issue37404@roundup.psfhosted.org>


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

Sorry it broke the version, what could I have done to avoid this?
Also can we close this issue?

----------

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

From report at bugs.python.org  Sun Feb  2 09:31:35 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 14:31:35 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1580653895.82.0.140965230657.issue39274@roundup.psfhosted.org>


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

Hi all,

I think this issue can be closed right?
Saw a successful PR.

----------
nosy: +Ido Michael

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

From report at bugs.python.org  Sun Feb  2 09:37:51 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 02 Feb 2020 14:37:51 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1580654271.22.0.573091509904.issue39274@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

"Successful" PR would be merged into master. This issue is still in "patch review" stage.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Feb  2 09:44:12 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 14:44:12 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1580654652.34.0.477434559438.issue38691@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Feb  2 09:45:47 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 14:45:47 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1580654747.95.0.301704009263.issue38691@roundup.psfhosted.org>


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

Created this PR: GH-18314

----------
nosy: +Ido Michael

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

From report at bugs.python.org  Sun Feb  2 09:54:54 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 14:54:54 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1580655294.87.0.55921462068.issue10572@roundup.psfhosted.org>


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

Are there any conclusions? what needs to be done?

----------
nosy: +Ido Michael

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

From report at bugs.python.org  Sun Feb  2 10:08:15 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 15:08:15 +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: <1580656095.09.0.870963408879.issue39128@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Feb  2 10:09:00 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 15:09:00 +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: <1580656140.43.0.648457408676.issue39128@roundup.psfhosted.org>


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

Created PR added arguments to method signature in doc.
GH-18315

----------
nosy: +Ido Michael

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

From report at bugs.python.org  Sun Feb  2 10:36:08 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 15:36:08 +0000
Subject: [issue38101] Update devguide triaging keywords
In-Reply-To: <1568194769.69.0.909868564617.issue38101@roundup.psfhosted.org>
Message-ID: <1580657768.81.0.357709598255.issue38101@roundup.psfhosted.org>


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

Added a PR: GH-570

----------

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

From report at bugs.python.org  Sun Feb  2 10:39:18 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 15:39:18 +0000
Subject: [issue38101] Update devguide triaging keywords
In-Reply-To: <1568194769.69.0.909868564617.issue38101@roundup.psfhosted.org>
Message-ID: <1580657958.59.0.356007623272.issue38101@roundup.psfhosted.org>


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

It treats the PR as a cpython while it's on the devguide repo, here is the link:
https://github.com/python/devguide/pull/570

----------

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

From report at bugs.python.org  Sun Feb  2 10:42:59 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 02 Feb 2020 15:42:59 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1580658179.46.0.176883718793.issue35885@roundup.psfhosted.org>


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

Can I take this?
What needs to be done? adding an indent flag and if it's passed indent the keys?

----------
nosy: +Ido Michael

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

From report at bugs.python.org  Sun Feb  2 11:11:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Feb 2020 16:11:17 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1580659877.72.0.275914109482.issue39529@roundup.psfhosted.org>


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

Will asyncio.get_event_loop() be removed or made an alias of asyncio.get_running_loop()? The latter could minimize the disruption of the existing code.

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

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

From report at bugs.python.org  Sun Feb  2 11:18:20 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 02 Feb 2020 16:18:20 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580660300.17.0.39412935594.issue39524@roundup.psfhosted.org>


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

I think this would be an improvement, and an good issue for a newcomer.

I'd vote for the r-string, but it doesn't really matter.

----------
keywords: +easy, newcomer friendly
nosy: +eric.smith
stage:  -> needs patch

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

From report at bugs.python.org  Sun Feb  2 11:44:08 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 Feb 2020 16:44:08 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1580661848.02.0.433733147942.issue39529@roundup.psfhosted.org>


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

Currently, I'm talking about adding a deprecation only.
The asyncio.get_event_loop() function will stay in Python for a while in deprecated status. I don't know the exact period but it should be 3 releases at least I guess, with possibly extending to 5 releases if needed.

----------

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

From report at bugs.python.org  Sun Feb  2 11:49:58 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 Feb 2020 16:49:58 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1580662198.25.0.732879940346.issue39529@roundup.psfhosted.org>


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

Serhiy, maybe I had not understood your proposal properly.

If you are asking about deprecating get_event_loop() call from outside of async code but implicit call get_running_loop() without a warning if called from async function -- it sounds like a brilliant idea.

Something like:

def get_event_loop():
    current_loop = _get_running_loop()
    if current_loop is not None:
        return current_loop
    warnings.warn("...", DeprecationWarning)  
    return get_event_loop_policy().get_event_loop()

----------

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

From report at bugs.python.org  Sun Feb  2 11:50:06 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 02 Feb 2020 16:50:06 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1580662206.5.0.328304098843.issue39529@roundup.psfhosted.org>


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


----------
components: +asyncio
nosy: +yselivanov

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

From report at bugs.python.org  Sun Feb  2 12:12:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Feb 2020 17:12:56 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1580663576.97.0.776068438323.issue39529@roundup.psfhosted.org>


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

Yes, it is what I meant.

Many code written before 3.7 use get_event_loop() because there was no get_running_loop() yet. Now, to avoid deprecation (and making the code more robust) it should be rewritten with using get_running_loop() or get_event_loop() depending on Python version. It is cumbersome, and causes a code churn.

----------

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

From report at bugs.python.org  Sun Feb  2 12:31:12 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 02 Feb 2020 17:31:12 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1580664672.44.0.690317461535.issue35885@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

I would suggest adding indent parameter to the write method, it would default to an empty string and could be used directly in the formatting operation.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Feb  2 13:26:45 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 02 Feb 2020 18:26:45 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580668005.33.0.405916279908.issue39479@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

[Steven]
> ... Try it on numbers like this:
> ...
> Q = P*(313*(P-1)+1)*(353*(P-1)+1)
>
> Q is a 397 digit Carmichael Number. Its smallest factor is P,
> which has 131 digits.
> ...
> My old and slow PC can prove that Q is a composite number,
> using pure Python, in less than six seconds.
>
> And I'm sure that a better programmer than me would be
> able to shave off some of that time.

The pure-Python Miller-Rabin code i posted in the aforementioned thread is typically at least 100 times faster than that.  But it's not deterministic.  Because it tries (pseudo)random bases, it all depends on how many it needs to try on each run before finding a witness to that Q is composite.  It usually (at least 75% of runs) finds one on the first try.

BTW, it doesn't much matter that this is "pure Python" - for ints of this size the bulk of the time regardless is spent in CPython's C-coded bigint arithmetic.  I expect that your code must be doing more than _just_ Miller-Rabin, and in the Q case is paying through the nose for "optimizations" that all fail before getting to Miller-Rabin.

About the API, I can't agree to the one you propose.  Different applications have different appropriate tradeoffs between degree of certainty and time consumed - "one size fits all" doesn't fly here.

    def probably_prime(n, maxsteps=20)

supplies a _default_ instead.  I don't want an API that's useful _only_ to people who don't know what they're doing ;-)
 

> (By the way: for smallish numbers, under 2**64, no more than
> twelve rounds of Miller-Rabin are sufficient to
> deterministically decide whether a number is prime or not.

But only if you use a fixed set of 12 specific bases for which the claim has been proved.  "Real" Miller-Rabin picks bases at random, relying only on properties that have been proved independent of the argument size.

[Vedran]
> Tim: Considering that congruence is _defined_ as
> x=y(mod m) :<=> m|y-x, it's
> really not so surprising. :-)

Didn't say it was ;-)  Was just noting the odd coincidence that I just happened to stumble into a real use for lcm(), not previously mentioned in this report, while doing something else.

----------

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

From report at bugs.python.org  Sun Feb  2 13:55:26 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 02 Feb 2020 18:55:26 +0000
Subject: [issue39492] reference cycle affecting Pickler instances (Python3.8+)
In-Reply-To: <1580341168.06.0.481762102037.issue39492@roundup.psfhosted.org>
Message-ID: <1580669726.01.0.317354301812.issue39492@roundup.psfhosted.org>


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


New changeset 0f2f35e15f9fbee44ce042b724348419d8136bc5 by Pierre Glaser in branch 'master':
bpo-39492: Fix a reference cycle between reducer_override and a Pickler instance (GH-18266)
https://github.com/python/cpython/commit/0f2f35e15f9fbee44ce042b724348419d8136bc5


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

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

From report at bugs.python.org  Sun Feb  2 14:19:26 2020
From: report at bugs.python.org (EMO)
Date: Sun, 02 Feb 2020 19:19:26 +0000
Subject: [issue39531] Memory Leak in multiprocessing.Pool()
Message-ID: <1580671166.84.0.839644381298.issue39531@roundup.psfhosted.org>


New submission from EMO <akash.dave at valensdatalabs.com>:

After even deleting all variables it still reserves memory of around a GB.

----------
components: Library (Lib)
files: User's.py
messages: 361253
nosy: EMO
priority: normal
severity: normal
status: open
title: Memory Leak in multiprocessing.Pool()
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48877/User's.py

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

From report at bugs.python.org  Sun Feb  2 14:47:53 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Feb 2020 19:47:53 +0000
Subject: [issue39492] reference cycle affecting Pickler instances (Python3.8+)
In-Reply-To: <1580341168.06.0.481762102037.issue39492@roundup.psfhosted.org>
Message-ID: <1580672873.09.0.605386668824.issue39492@roundup.psfhosted.org>


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


----------
pull_requests: +17692
pull_request: https://github.com/python/cpython/pull/18316

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

From report at bugs.python.org  Sun Feb  2 15:23:04 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Feb 2020 20:23:04 +0000
Subject: [issue39492] reference cycle affecting Pickler instances (Python3.8+)
In-Reply-To: <1580341168.06.0.481762102037.issue39492@roundup.psfhosted.org>
Message-ID: <1580674984.22.0.0606588778256.issue39492@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 17236873392533ce0c5d7bbf52cbd61bca171c59 by Antoine Pitrou in branch '3.8':
[3.8] bpo-39492: Fix a reference cycle between reducer_override and a Pickler instance (GH-18266) (#18316)
https://github.com/python/cpython/commit/17236873392533ce0c5d7bbf52cbd61bca171c59


----------

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

From report at bugs.python.org  Sun Feb  2 15:23:21 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Feb 2020 20:23:21 +0000
Subject: [issue39492] reference cycle affecting Pickler instances (Python3.8+)
In-Reply-To: <1580341168.06.0.481762102037.issue39492@roundup.psfhosted.org>
Message-ID: <1580675001.92.0.518430870763.issue39492@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you for the PR!

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

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

From report at bugs.python.org  Sun Feb  2 16:53:01 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Feb 2020 21:53:01 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580680381.65.0.617291134859.issue39511@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Is the sub-interpreter PEP approved?   If not, I had thought the plan was to only implement PRs that made clean-ups that would have been necessary anyway.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sun Feb  2 17:32:13 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Feb 2020 22:32:13 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580682733.44.0.917064169701.issue39511@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Random idea (not carefully thought-out):  Would it be simpler to have these objects just ignore their refcount by having dealloc() be a null operation or having it set the refcount back to a positive number).  That would let sub-interpreters share the objects without worrying about race-conditions on incref/decref operations.  To make this work, the objects can register themselves as permanent, shared, objects; then, during shutdown, we could explicitly call a hard dealloc on those objects.

----------

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

From report at bugs.python.org  Sun Feb  2 17:57:45 2020
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 02 Feb 2020 22:57:45 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580684265.72.0.750722564721.issue39511@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

+1, obviously, as I came to the same conclusion above (see msg361122)

----------

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

From report at bugs.python.org  Sun Feb  2 18:45:17 2020
From: report at bugs.python.org (Isaac Muse)
Date: Sun, 02 Feb 2020 23:45:17 +0000
Subject: [issue39532] Pathlib: handling of `.` in paths and patterns creates
 unmatchable paths
Message-ID: <1580687117.16.0.54415875836.issue39532@roundup.psfhosted.org>


New submission from Isaac Muse <faceless.server1 at gmail.com>:

It appears that the pathlib library strips out `.` in glob paths when they represent a directory. This is kind of a naive approach in my opinion, but I understand what was trying to be achieved.

When a path is given to pathlib, it normalizes it by stripping out non-essential things like `.` that represent directories, and strips out trailing `/` to give a path without unnecessary parts (the stripping of trailing `/` is another discussion).

But there is a small twist, when given an empty string or just a dot, you need to have something as the directory, so it allows a `.`.

So, it appears the idea was since this normalization is applied to paths, why not apply it to the glob patterns as well, so it does. But the special logic that ensures you don't have an empty string to match does not get applied to the glob patterns. This creates unmatchable paths:

>>> import pathlib
>>> str(pathlib.Path('.'))
'.'
>>> pathlib.Path('.').match('.')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python36\lib\pathlib.py", line 939, in match
    raise ValueError("empty pattern")
ValueError: empty pattern

I wonder if it is appropriate to apply this `.` stripping to glob patterns. Personally, I think the glob pattern, except for slash normalization, should remain unchanged, but if it is to be normalized above and beyond this, at the very least should use the exact same logic that is applied to the paths.

----------
components: Library (Lib)
messages: 361259
nosy: Isaac Muse
priority: normal
severity: normal
status: open
title: Pathlib: handling of `.` in paths and patterns creates unmatchable paths
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Feb  2 19:01:22 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 03 Feb 2020 00:01:22 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1580688082.52.0.469103030871.issue39349@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Thank you very muck, Kyle!

No problem. Thanks for reviewing and merging the PR, Antoine!

----------

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

From report at bugs.python.org  Sun Feb  2 19:15:33 2020
From: report at bugs.python.org (Isaac Muse)
Date: Mon, 03 Feb 2020 00:15:33 +0000
Subject: [issue39532] Pathlib: handling of `.` in paths and patterns creates
 unmatchable paths
In-Reply-To: <1580687117.16.0.54415875836.issue39532@roundup.psfhosted.org>
Message-ID: <1580688933.77.0.936038690429.issue39532@roundup.psfhosted.org>


Isaac Muse <faceless.server1 at gmail.com> added the comment:

The more I think about this, I think the normalization of paths is actually fine, it is the normalization of the patterns that is problematic, or more the difference in normalization. I could live with the pattern normalization of `.` and trailing `/` if it was at least consistent with what happens in paths. I still find the modification of the glob pattern in this manner surprising, but at least it wouldn't' cause cases like this to fail.

----------

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

From report at bugs.python.org  Sun Feb  2 20:28:08 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 03 Feb 2020 01:28:08 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580668005.33.0.405916279908.issue39479@roundup.psfhosted.org>
Message-ID: <20200203012802.GJ6362@ando.pearwood.info>


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

> [Steven]
> > ... Try it on numbers like this:
> > ...
> > Q = P*(313*(P-1)+1)*(353*(P-1)+1)
> >
> > Q is a 397 digit Carmichael Number. Its smallest factor is P,
> > which has 131 digits.

[Tim]
> The pure-Python Miller-Rabin code i posted in the aforementioned 
> thread is typically at least 100 times faster than that.

This is exactly the sort of argument about quality of implementation 
which isn't, or shouldn't be, part of the argument about the API, IMO. 
Just as the choice of Timsort over Quicksort or Bubblesort *wink* isn't 
part of the list.sort() API, let alone the implementation choices in 
Timsort such as MIN_GALLOP.

I'm happy to have a discussion about implementation, here or off-list, 
I'm sure I will learn a lot. But briefly, the Q I quoted above was 
carefully designed (not by me, I hasten to add!) to be a preudoprime to 
the first 307 prime bases, so it's something of a worst-case scenario 
for my version.

> BTW, it doesn't much matter that this is "pure Python" - for ints of 
> this size the bulk of the time regardless is spent in CPython's 
> C-coded bigint arithmetic.

A fair point, thank you.

> About the API, I can't agree to the one you propose.  Different 
> applications have different appropriate tradeoffs between degree of 
> certainty and time consumed - "one size fits all" doesn't fly here.
> 
>     def probably_prime(n, maxsteps=20)
> 
> supplies a _default_ instead.  I don't want an API that's useful 
> _only_ to people who don't know what they're doing ;-)

It's not just for people who don't know what they're doing. It is for 
people who don't want to sweat the small details, they just want an 
answer True or False and are prepared to trust that the function author 
knows what they are doing.

If someone cares about the small details like how many bases to 
try, they might also care about details like:

- which specific bases are used;
- whether to use Miller-Rabin at all;
- how many trial divisions to do first;
- which specific primality test to use;

etc. What if the implementation shifts away from Miller-Rabin to (say) 
Baillie-PSW? Then your maxsteps parameter becomes meaningless. Do we 
deprecate it or leave it there in case the implementation changes again 
to something that has a concept of number of steps?

I think that if someone cares sufficiently about the details, then they 
probably won't be satisfied with a single isprime function, but may want 
is_fermat_prime, is_miller_rabin_prime, is_lucas_prime etc.

> > (By the way: for smallish numbers, under 2**64, no more than
> > twelve rounds of Miller-Rabin are sufficient to
> > deterministically decide whether a number is prime or not.
> 
> But only if you use a fixed set of 12 specific bases for which the 
> claim has been proved.

Correct. The first twelve primes make up such a minimal set.

http://oeis.org/A014233

----------

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

From report at bugs.python.org  Sun Feb  2 22:10:05 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 03 Feb 2020 03:10:05 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580699405.15.0.279873378259.issue39479@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

[Tim]
>> The pure-Python Miller-Rabin code i posted in the
>> aforementioned thread is typically at least 100
>> times faster than that.

[Steven]
> This is exactly the sort of argument about quality of
> implementation which isn't, or shouldn't be, part of
> the argument about the API, IMO.

I wasn't at all talking about API at that point.  I was backing the argument _you_ were making, that trial division is a hopelessly inefficient implementation, compared to what's possible with probabilistic methods, regardless of API.  You were in fact underselling that argument, because it's straightforward to get an order or two of magnitude faster than you demonstrated.


> the Q I quoted above was carefully designed (not by me, I hasten
> to add!)

I know the paper it came from.

> to be a preudoprime to the first 307 prime bases, so it's
> something of a worst-case scenario for my version.

Which is why I have no problem picturing how this "should be" approached:  the original Miller-Rabin (which uses random bases, not succumbing to the "premature optimization" catastrophe magnet) has no problem with Q (or with anything else!), and hasn't really been improved on for general-purpose use since it was published.  It's a darned-near perfect mix of simplicity, brevity, clarity, robustness, generality, and speed.  "Good enough" by a long shot on all counts.

>>    def probably_prime(n, maxsteps=20)
>>
>> supplies a _default_ instead.  I don't want an API that's useful
>> _only_ to people who don't know what they're doing ;-)

> It's not just for people who don't know what they're doing. It
> is for people who don't want to sweat the small details,

Then they can accept the default.  In what conceivable sense is that a burden?

> they just want an nswer True or False and are prepared
> to trust that the function author knows what they are
> doing.

But the function author can't possibly know what the _user_ needs this for.  In some apps degree of certainty is far more important than speed, while in other apps it's the opposite.  Be realistic here?  Your argument here makes sense for always-right functions, but you're not willing to accept one of those for this specific purpose (& neither am I).

> If someone cares about the small details like how
> many bases to try,

It's not a "small detail" where it matters:  it is THE way to trade off computation time against confidence in the results.  It's a _fundamental_ aspect of how Miller-Rabin works.

> they might also care about details like:
>
> - which specific bases are used;
> - whether to use Miller-Rabin at all;
> - how many trial divisions to do first;
> - which specific primality test to use;

Then they should go use a special-purpose library ;-)  Letting them fiddle the single most important parameter isn't down in the weeds, it's a top-level control knob.

My answers to all the above:

- bases are picked via randrange(2, n-1)
- yes, because no better general-purpose algorithm is known
- none - although I'll allow that there may be a
  speed advantage in some apps if a gcd is done with a
  relatively small primorial first (more efficient than
  one-at-a-time trial divisions by small primes)
- Miller-Rabin

> What if the implementation shifts away from Miller-Rabin
> to (say) Baillie-PSW?

It can't ;-)  I would absolutely document that Miller-Rabin _is_ the algorithm being used, with the random-bases implementation choice.  Then the curious can search the web for a mountain of good information about it.

> Then your maxsteps parameter becomes meaningless. Do we
> deprecate it or leave it there in case the implementation
> changes again to something that has a concept of number
> of steps?

All moot, given that I have no interest in hiding the specific algorithm in use.  YAGNI.

> I think that if someone cares sufficiently about the details,
> then they probably won't be satisfied with a single isprime
> function, but may want is_fermat_prime, is_miller_rabin_prime,
> is_lucas_prime etc.

Again, go to a special-purpose library if that's what they want.  And, again, I don't agree with your characterization of the Miller-Rabin maxsteps parameter as a "detail".  It's a fundamental aspect of what the algorithm does.  Which casual users can certainly ignore, but at their own risk.

> ...
> Correct. The first twelve primes make up such a minimal set.

And if you don't care about picking the fixed bases from a prefix of the primes, you only need 7 bases for a 100% reliable test through 2**64:  2, 325, 9375, 28178, 450775, 9780504, and 1795265022.  Or so this table claims:

https://miller-rabin.appspot.com/

But I don't care here.  Using a fixed set of bases is begging for embarrassment (for every fixed finite set of bases, there are an infinite number of composites they'll _claim_ are prime).  There are no systemic failure modes when using random bases.

----------

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

From report at bugs.python.org  Sun Feb  2 23:09:34 2020
From: report at bugs.python.org (=?utf-8?b?5b6Q5b27?=)
Date: Mon, 03 Feb 2020 04:09:34 +0000
Subject: [issue39515] pathlib won't strip "\n" in path
In-Reply-To: <1580528708.47.0.815684087896.issue39515@roundup.psfhosted.org>
Message-ID: <1580702974.72.0.615453867424.issue39515@roundup.psfhosted.org>


?? <chrisxuche at gmail.com> added the comment:

Thank you for your explanation.

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

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

From report at bugs.python.org  Sun Feb  2 23:26:02 2020
From: report at bugs.python.org (ntninja)
Date: Mon, 03 Feb 2020 04:26:02 +0000
Subject: [issue39533] Use `statx(2)` system call on Linux for extended
 `os.stat` information
Message-ID: <1580703962.85.0.294314145935.issue39533@roundup.psfhosted.org>


New submission from ntninja <alexander-pbt at ninetailed.ninja>:

Background: For a long time several Linux filesystems have been tracking two extra bits of information. The file attributes bits[1] and the file creation time (aka crtime aka btime aka birthtime)[2]. Before Linux 4.11 accessing these required secret knowledge (ioctl numbers) or access to unstable interfaces (debugfs). However since that version the statx(2) system call[3] has finally been added (it has a long history), which exposes these two fields adds (struct) space for potentially more.

Since CPython already exposes `st_birthtime` on FreeBSD and friends, I think it would be fair to also expose this field on Linux. As the timestamp value is only available on some file systems and configurations it is not guaranteed that the system call will return a value for btime at all. I suppose the field should be set to `None` in that case. In my opinion it should also become a regular field (available on all platforms) since, with this addition, we now have a suitable value to return on every major platform CPython targets: `stx_btime` on Linux, `st_birthtime` on macOS/FreeBSD and `st_ctime` on Windows.

`stx_attributes` could be exposed as a new `st_attributes` flag specific to Linux as there is no equivalent on other platforms to my knowledge (Window's `st_file_attributes` is similar in some aspects but has a completely different format and content).

There is a Python script I created, that calls statx(2) using ctypes here: https://github.com/ipfs/py-datastore/blob/e566d40a8ca81d8628147e255fe7830b5f928a43/datastore/filesystem/util/statx.py
It may be useful as a reference when implementing this in C.

  [1]: https://man.cx/chattr(1)
  [2]: https://unix.stackexchange.com/a/50184/47938
  [3]: https://man.cx/statx(2)

----------
messages: 361265
nosy: ntninja
priority: normal
severity: normal
status: open
title: Use `statx(2)` system call on Linux for extended `os.stat` information
type: enhancement

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

From report at bugs.python.org  Mon Feb  3 01:00:52 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Feb 2020 06:00:52 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1580709652.7.0.56268336808.issue37224@roundup.psfhosted.org>


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


----------
pull_requests: +17693
pull_request: https://github.com/python/cpython/pull/18318

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

From report at bugs.python.org  Mon Feb  3 02:06:57 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 03 Feb 2020 07:06:57 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1580713617.45.0.787342655703.issue39450@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 032de7324e30c6b44ef272cea3be205a3d768759 by Steve Cirelli in branch 'master':
bpo-39450 Stripped whitespace before parsing the docstring in TestCase.shortDescription (GH-18175)
https://github.com/python/cpython/commit/032de7324e30c6b44ef272cea3be205a3d768759


----------
nosy: +cjw296

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

From report at bugs.python.org  Mon Feb  3 02:07:21 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Feb 2020 07:07:21 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1580713641.49.0.0353567198715.issue39450@roundup.psfhosted.org>


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


----------
pull_requests: +17694
pull_request: https://github.com/python/cpython/pull/18321

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

From report at bugs.python.org  Mon Feb  3 02:07:29 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Feb 2020 07:07:29 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1580713649.89.0.36864460457.issue39450@roundup.psfhosted.org>


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


----------
pull_requests: +17695
pull_request: https://github.com/python/cpython/pull/18322

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

From report at bugs.python.org  Mon Feb  3 02:25:23 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 03 Feb 2020 07:25:23 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1580714723.35.0.0385008254462.issue39450@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 7561e7a83ccccf5118fda6c62fe9c8c3458f8cfd by Miss Islington (bot) in branch '3.7':
bpo-39450 Stripped whitespace before parsing the docstring in TestCase.shortDescription (GH-18321)
https://github.com/python/cpython/commit/7561e7a83ccccf5118fda6c62fe9c8c3458f8cfd


----------

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

From report at bugs.python.org  Mon Feb  3 03:03:02 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Feb 2020 08:03:02 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1580716982.87.0.234394111887.issue39450@roundup.psfhosted.org>


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


----------
pull_requests: +17696
pull_request: https://github.com/python/cpython/pull/18323

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

From report at bugs.python.org  Mon Feb  3 03:20:48 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 03 Feb 2020 08:20:48 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1580718048.13.0.72914207977.issue39450@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 02395fad8e3a35ef00fa31c308693844013a1dd4 by Miss Islington (bot) in branch '3.8':
bpo-39450 Stripped whitespace before parsing the docstring in TestCase.shortDescription (GH-18175) (#18323)
https://github.com/python/cpython/commit/02395fad8e3a35ef00fa31c308693844013a1dd4


----------

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

From report at bugs.python.org  Mon Feb  3 03:21:12 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 03 Feb 2020 08:21:12 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
Message-ID: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

According to [1][2] the documentation about return in finally statement is missleading in [3].

It currently states:

> If a finally clause includes a return statement, the finally clause?s return statement will execute before, and instead of, the return statement in a try clause.

I would prefer speaking about returned values instead of statements executed, I think it would clarify the point.


[1]: https://mail.python.org/archives/list/docs at python.org/message/LBMO47JSDPKFKLYR25HAKD7A76D5IHWI/
[2]: https://stackoverflow.com/questions/59639733/python-docs-have-misleading-explanation-of-return-in-finally
[3]: https://docs.python.org/3.7/tutorial/errors.html#defining-clean-up-actions

----------
assignee: mdk
components: Documentation
messages: 361269
nosy: mdk
priority: normal
severity: normal
status: open
title: Clarify tutorial on return statement in finally clause.
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Feb  3 03:22:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 08:22:08 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1580718128.2.0.713287874955.issue39534@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Mon Feb  3 03:23:07 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 03 Feb 2020 08:23:07 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1580718187.9.0.424879870464.issue39534@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


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

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

From report at bugs.python.org  Mon Feb  3 03:29:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 08:29:00 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580718540.41.0.777665697012.issue39479@roundup.psfhosted.org>


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

If someone wants to continue the discussion on is_prime(), I suggest to open a separated issue.

----------

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

From report at bugs.python.org  Mon Feb  3 03:31:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 08:31:04 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1580718664.74.0.478100369758.issue39280@roundup.psfhosted.org>


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

> Hi guys,

sidenote: please avoid "hi guys" which is not inclusive, see https://heyguys.cc/ Thanks ;-)

----------

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

From report at bugs.python.org  Mon Feb  3 03:34:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 08:34:10 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
 violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1580718850.03.0.591800884618.issue12731@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

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

From report at bugs.python.org  Mon Feb  3 03:40:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 08:40:07 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580719207.62.0.51133653757.issue39502@roundup.psfhosted.org>


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

> test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000'

AIX kernel seems to have a bug. You should report it to AIX.

>>> time.localtime(91301504)
time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=18, tm_min=31, tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0)

----------

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

From report at bugs.python.org  Mon Feb  3 04:21:12 2020
From: report at bugs.python.org (Robert Pierce)
Date: Mon, 03 Feb 2020 09:21:12 +0000
Subject: [issue39535] multiprocessing.Process file descriptor resource leak
Message-ID: <1580721672.06.0.925204130251.issue39535@roundup.psfhosted.org>


New submission from Robert Pierce <robert.pierce at decisionnext.com>:

multiprocessing.Process opens a FIFO to the child. This FIFO is not documented the the Process class API and it's purpose is not clear from the documentation. It is a minor documentation bug that the class creates non-transparent resource utilization.

The primary behavioral bug is that incorrect handling of this FIFO creates a resource leak, since the file descriptor is not closed on join(), or even when the parent Process object goes out of scope.

The effect of this bug is that programs generating large numbers of Process objects will hit system resource limits of open file descriptors.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: proc_test.py
messages: 361273
nosy: Robert Pierce, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.Process file descriptor resource leak
type: resource usage
versions: Python 3.6
Added file: https://bugs.python.org/file48878/proc_test.py

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

From report at bugs.python.org  Mon Feb  3 04:31:44 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 09:31:44 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1580722304.76.0.584531925988.issue36051@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Mon Feb  3 04:46:56 2020
From: report at bugs.python.org (Jairo Vadillo)
Date: Mon, 03 Feb 2020 09:46:56 +0000
Subject: [issue39536] Datetime strftime: %Y exports years < 1000 with 3 digits
 instead of 4 on Linux
Message-ID: <1580723216.73.0.692049460733.issue39536@roundup.psfhosted.org>


New submission from Jairo Vadillo <jairo at 21buttons.com>:

This two examples are pretty simple.

On MacOS stftime %Y works as expected, retrieving 4 digits:

Python 3.7.6 (default, Dec 30 2019, 19:38:26)
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
> datetime.strftime(datetime.now().replace(year=100), "%Y-%m-%d")
'0100-02-03'

But on Linux...:

Python 3.7.6 (default, Jan  3 2020, 23:35:31)
[GCC 8.3.0] on linux
> datetime.strftime(datetime.now().replace(year=100), "%Y-%m-%d")
'100-02-03'


This causes a lot of trouble when storing and then retrieving string dates from any string based storage.

----------
components: Library (Lib)
messages: 361274
nosy: Jairo Vadillo
priority: normal
severity: normal
status: open
title: Datetime strftime: %Y exports years < 1000 with 3 digits instead of 4 on Linux
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Feb  3 04:52:00 2020
From: report at bugs.python.org (pmp-p)
Date: Mon, 03 Feb 2020 09:52:00 +0000
Subject: [issue39536] Datetime strftime: %Y exports years < 1000 with 3 digits
 instead of 4 on Linux
In-Reply-To: <1580723216.73.0.692049460733.issue39536@roundup.psfhosted.org>
Message-ID: <1580723520.29.0.899152985222.issue39536@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

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

From report at bugs.python.org  Mon Feb  3 04:56:03 2020
From: report at bugs.python.org (Robert Pierce)
Date: Mon, 03 Feb 2020 09:56:03 +0000
Subject: [issue39535] multiprocessing.Process file descriptor resource leak
In-Reply-To: <1580721672.06.0.925204130251.issue39535@roundup.psfhosted.org>
Message-ID: <1580723763.77.0.53461889844.issue39535@roundup.psfhosted.org>


Robert Pierce <robert.pierce at decisionnext.com> added the comment:

It appears as if the problem is the sentinel FIFO opened by (for example) multiprocessing.popen_fork.Popen._launch(). It registers a finalization class to close the sentinel on garbage collection. Instead, it should be closed in poll() or wait() when the child process is reaped and known to be dead. The sentinel serves no purpose after the child is reaped, and waiting till garbage collection means that programs forking large numbers of processes cannot control file descriptor utilization.

----------

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

From report at bugs.python.org  Mon Feb  3 05:03:42 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 10:03: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: <1580724222.99.0.213712685426.issue36051@roundup.psfhosted.org>


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


New changeset 869c0c99b94ff9527acc1ca060164ab3d1bdcc53 by Inada Naoki in branch 'master':
bpo-36051: Fix compiler warning. (GH-18325)
https://github.com/python/cpython/commit/869c0c99b94ff9527acc1ca060164ab3d1bdcc53


----------

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

From report at bugs.python.org  Mon Feb  3 05:04:15 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 10:04: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: <1580724255.03.0.699556961966.issue36051@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Mon Feb  3 05:06:34 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 03 Feb 2020 10:06:34 +0000
Subject: [issue39537] Change line number table format
Message-ID: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>


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

The current line number table format has two issues that need to be addressed.

1. There is no way to express that a bytecode does not have have a line number. The `END_ASYNC_FOR` bytecode, bytecodes for cleaning up the variable used to store exceptions in exception handles, and a few other cases, are all artificial and should have no line number.

2. It is inefficient to find a line number when tracing.
Currently, whenever the line number changes, the line number table must be re-scanned from the the start.


I propose to fix this by implementing a new line number table. 
Each instruction (currently pair of bytes) would have a one byte line-offset value. An offset of 0 indicates that the instruction has no line number.

In addition to the offset table there would be a table of bytecode-offset, base-line pairs. Following the pairs is the instruction count.
Adding the instruction count at the end means that the table is not just a table of start, line pairs, but also a table of (inclusive) start, line, (exclusive) end triples. This format makes it very easy to scan forwards and backwards.
Because each entry covers up to 255 lines, the table is very small.

The line of the bytecode at `n*2` (instruction `n`) is calculated as:

offset = lnotab[n]
if offset == 0:
    line = -1 # artificial
else:
    line_base = scan_table_to_find(n)
    line = offset + line_base


The new format fixes the two issues listed above.
1. Having no line number is expressed by a 0 in the offset table.
2. Since the offset-base table is made up of absolute values, not relative ones, it can be reliably scanned backwards. It is even possible to use a binary search, although a linear scan will be faster in almost all cases. 


The number format would be larger than the old one. 
However, the code object is composed not only of code, but several tuples of names and constants as well, so increasing the size of the line number has a small effect overall.

----------
components: Interpreter Core
messages: 361277
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Change line number table format
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Mon Feb  3 05:07:05 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 03 Feb 2020 10:07:05 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1580724425.23.0.239298647581.issue39537@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
nosy: +nedbat, pablogsal, skip.montanaro -Mark.Shannon

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

From report at bugs.python.org  Mon Feb  3 05:08:42 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 03 Feb 2020 10:08:42 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1580724522.35.0.387980444594.issue38691@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@Ido Michael
I left review comments for you :)
Thanks for the contribution.

----------
nosy: +corona10

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

From report at bugs.python.org  Mon Feb  3 05:16:45 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 03 Feb 2020 10:16:45 +0000
Subject: [issue37404] asyncio sock_recv blocks on ssl sockets.
In-Reply-To: <1561491381.97.0.0488150062245.issue37404@roundup.psfhosted.org>
Message-ID: <1580725005.85.0.596022612998.issue37404@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/issue37404>
_______________________________________

From report at bugs.python.org  Mon Feb  3 05:19:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Feb 2020 10:19:15 +0000
Subject: [issue39538] SystemError when set Element.attrib to non-dict
Message-ID: <1580725155.12.0.53190069949.issue39538@roundup.psfhosted.org>


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

The C implementation raises a SystemError after setting Element.attrib to non-dict.

>>> from xml.etree import ElementTree as ET
>>> e = ET.Element('a')
>>> e.attrib = 1
>>> e.get('x')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/dictobject.c:1438: bad argument to internal function
>>> e.items()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/dictobject.c:2732: bad argument to internal function
>>> e.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: Objects/dictobject.c:2712: bad argument to internal function

The only valid non-dict value is None (although it is an implementation detail).

>>> e.attrib = None
>>> e.get('x')
>>> e.items()
[]
>>> e.keys()
[]

The Python implementation raises an AttributeError (even for None).

>>> import sys
>>> sys.modules['_elementtree'] = None
>>> from xml.etree import ElementTree as ET
>>> e = ET.Element('a')
>>> e.attrib = 1
>>> e.get('x')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementTree.py", line 358, in get
    return self.attrib.get(key, default)
AttributeError: 'int' object has no attribute 'get'
>>> e.items()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementTree.py", line 388, in items
    return self.attrib.items()
AttributeError: 'int' object has no attribute 'items'
>>> e.keys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.8/Lib/xml/etree/ElementTree.py", line 377, in keys
    return self.attrib.keys()
AttributeError: 'int' object has no attribute 'keys'

Other way to trigger an error is via __setstate__().

----------
components: Extension Modules, XML
messages: 361279
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: SystemError when set Element.attrib to non-dict
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Feb  3 05:25:05 2020
From: report at bugs.python.org (Gilles Van Assche)
Date: Mon, 03 Feb 2020 10:25:05 +0000
Subject: [issue39539] Improve Keccak support in hashlib including
 KangarooTwelve
Message-ID: <1580725505.22.0.0334645206917.issue39539@roundup.psfhosted.org>


New submission from Gilles Van Assche <gilles-python at noekeon.org>:

Dear all,

I think it would be nice if hashlib would include the support of Keccak with a chosen suffix, as well as the fast instance KangarooTwelve (K12).

1) Currently, hashlib's interface for Keccak only supports the 6 instances of FIPS 202 (SHA3-* and SHAKE*). However, the instances in NIST SP 800-185 (cSHAKE, KMAC, ?) use a different suffix and therefore cannot be instantiated on top of the aforementioned 6 instances. Instead, simply adding the suffix as an argument to the constructor would enable a user to instantiate plain Keccak (as in Ethereum) or the SP 800-185 instances.

2) K12 is an alternative hash function (and XOF) in the Keccak family. It is fast, parallelizable and it benefits directly from the cryptanalysis on the (unchanged) underlying permutation since 2008. This would be IMHO a valuable addition to hashlib. Among others, implementations of K12 can be found in the XKCP on GitHub.

Kind regards,
Gilles (co-designer of Keccak and K12)

----------
components: Library (Lib)
messages: 361280
nosy: gvanas
priority: normal
severity: normal
status: open
title: Improve Keccak support in hashlib including KangarooTwelve
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Feb  3 05:38:00 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 03 Feb 2020 10:38:00 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1580726280.28.0.41164560133.issue39537@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


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

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

From report at bugs.python.org  Mon Feb  3 05:56:35 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 10:56:35 +0000
Subject: [issue17659] no way to determine First weekday (based on locale)
In-Reply-To: <1365410883.64.0.172005963141.issue17659@psf.upfronthosting.co.za>
Message-ID: <1580727395.71.0.98627499788.issue17659@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17700
pull_request: https://github.com/python/cpython/pull/18327

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

From report at bugs.python.org  Mon Feb  3 05:57:31 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 10:57: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: <1580727451.09.0.849608767562.issue39087@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17701
pull_request: https://github.com/python/cpython/pull/18327

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

From report at bugs.python.org  Mon Feb  3 06:36:14 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 11:36:14 +0000
Subject: [issue39536] Datetime strftime: %Y exports years < 1000 with 3 digits
 instead of 4 on Linux
In-Reply-To: <1580723216.73.0.692049460733.issue39536@roundup.psfhosted.org>
Message-ID: <1580729774.68.0.478777758584.issue39536@roundup.psfhosted.org>


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

Closing as a duplicate of #13305. Feel free to add to the discussion there if you disagree with the resolution of that issue.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  3 06:37:17 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 11:37:17 +0000
Subject: [issue39536] Datetime strftime: %Y exports years < 1000 with 3 digits
 instead of 4 on Linux
In-Reply-To: <1580723216.73.0.692049460733.issue39536@roundup.psfhosted.org>
Message-ID: <1580729837.22.0.194525969036.issue39536@roundup.psfhosted.org>


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

> if you disagree with the resolution of that issue

Sorry, my mistake. That issue is still open.

----------

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

From report at bugs.python.org  Mon Feb  3 06:38:20 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 11:38:20 +0000
Subject: [issue39536] Datetime strftime: %Y exports years < 1000 with 3 digits
 instead of 4 on Linux
In-Reply-To: <1580723216.73.0.692049460733.issue39536@roundup.psfhosted.org>
Message-ID: <1580729900.61.0.927843015325.issue39536@roundup.psfhosted.org>


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


----------
superseder:  -> datetime.strftime("%Y") not consistent for years < 1000

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

From report at bugs.python.org  Mon Feb  3 06:39:09 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 11:39:09 +0000
Subject: [issue19237] Proposal : LCM function to complement GCD
In-Reply-To: <1381613985.13.0.579421159234.issue19237@psf.upfronthosting.co.za>
Message-ID: <1580729949.86.0.958536704994.issue19237@roundup.psfhosted.org>


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

See renewed discussion in #39479, which may lead to math.lcm being added in 3.9.

----------

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

From report at bugs.python.org  Mon Feb  3 07:10:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 12:10:03 +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: <1580731803.25.0.179853581899.issue39087@roundup.psfhosted.org>


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

I am still not sure about we should add new API only for avoiding cache.

* PyUnicode_AsUTF8String : When we need bytes or want to avoid cache.
* PyUnicode_AsUTF8AndSize : When we need C string, and cache is acceptable.


With PR-18327, PyUnicode_AsUTF8AndSize become 10+% faster than master branch, and same speed to PyUnicode_AsUTF8String.


## vs master

$ ./python -m pyperf timeit --compare-to=../cpython/python --python-names master:patched -s 'from _testcapi import unicode_bench_asutf8 as b' -- 'b(1000, "hello", "?????")'
master: ..................... 96.6 us +- 3.3 us
patched: ..................... 83.3 us +- 0.3 us

Mean +- std dev: [master] 96.6 us +- 3.3 us -> [patched] 83.3 us +- 0.3 us: 1.16x faster (-14%)


## vs AsUTF8String

$ ./python -m pyperf timeit -s 'from _testcapi import unicode_bench_asutf8 as b' -- 'b(1000, "hello", "?????")'
.....................
Mean +- std dev: 83.2 us +- 0.2 us

$ ./python -m pyperf timeit -s 'from _testcapi import unicode_bench_asutf8string as b' -- 'b(1000, "hello", "?????")'
.....................
Mean +- std dev: 81.9 us +- 2.1 us


## vs AsUTF8String (ASCII)

If we can not accept cache, PyUnicode_AsUTF8String is slower than PyUnicode_AsUTF8 when the unicode is ASCII string.  PyUnicode_GetUTF8Buffer helps only this case.

$ ./python -m pyperf timeit -s 'from _testcapi import unicode_bench_asutf8 as b' -- 'b(1000, "hello", "world")'
.....................
Mean +- std dev: 37.5 us +- 1.7 us

$ ./python -m pyperf timeit -s 'from _testcapi import unicode_bench_asutf8string as b' -- 'b(1000, "hello", "world")'
.....................
Mean +- std dev: 46.4 us +- 1.6 us

----------

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

From report at bugs.python.org  Mon Feb  3 07:14:13 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 03 Feb 2020 12:14: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: <1580732053.56.0.223019637747.issue39087@roundup.psfhosted.org>


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

Attached patch is the benchmark function I used in previous post.

----------
Added file: https://bugs.python.org/file48879/bench-asutf8.patch

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

From report at bugs.python.org  Mon Feb  3 07:21:32 2020
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 03 Feb 2020 12:21:32 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580732492.65.0.652696691825.issue39484@roundup.psfhosted.org>


Vincent Michel <vxgmichel at gmail.com> added the comment:

Thanks for your answers, that was very informative!

> >>> a/10**9
> 1580301619.9061854
> >>> a/1e9
> 1580301619.9061852
>
> I'm not sure which one is "correct".


Originally, I thought `a/10**9` was more precise because I ran into the following case while working with hundreds of nanoseconds (because windows):

```
r = 1580301619906185900
print("Ref   :", r)
print("10**7 :", int(r // 100 / 10**7 * 10 ** 7) * 100)
print("1e7   :", int(r // 100 / 1e7 * 10 ** 7) * 100)
print("10**9 :", int(r / 10**9 * 10**9))
print("1e9   :", int(r / 1e9 * 10**9))
[...]
Ref   : 1580301619906185900
10**7 : 1580301619906185800
1e7   : 1580301619906186200
10**9 : 1580301619906185984
1e9   : 1580301619906185984
```

I decided to plot the conversion errors for different division methods over a short period of time. It turns out that:
- `/1e9` is equally or more precise than `/10**9` when working with nanoseconds
- `/10**7` is equally or more precise than `/1e7` when working with hundreds nanoseconds

This result really surprised me, I have no idea what is the reason behind this.

See the plots and code attached for more information.

In any case, this means there is no reason to change the division in `_PyTime_AsSecondsDouble`, closing this issue as wontfix sounds fine :)

---

As a side note, the only place I could find something similar mentioned in the docs is in the `os.stat_result.st_ctime_ns` documentation: 

https://docs.python.org/3.8/library/os.html#os.stat_result.st_ctime_ns

> Similarly, although st_atime_ns, st_mtime_ns, and st_ctime_ns are 
> always expressed in nanoseconds, many systems do not provide 
> nanosecond precision. On systems that do provide nanosecond precision,
> 1the floating-point object used to store st_atime, st_mtime, and 
> st_ctime cannot preserve all of it, and as such will be slightly 
> inexact. If you need the exact timestamps you should always use 
> st_atime_ns, st_mtime_ns, and st_ctime_ns.

Maybe this kind of limitation should also be mentioned in the documentation of `time.time_ns()`?

----------
Added file: https://bugs.python.org/file48880/Comparing_division_errors_over_10_us.png

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

From report at bugs.python.org  Mon Feb  3 07:22:21 2020
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 03 Feb 2020 12:22:21 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580732541.43.0.549927240981.issue39484@roundup.psfhosted.org>


Change by Vincent Michel <vxgmichel at gmail.com>:


Added file: https://bugs.python.org/file48881/comparing_errors.py

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

From report at bugs.python.org  Mon Feb  3 07:29:54 2020
From: report at bugs.python.org (Alexander McFarlane)
Date: Mon, 03 Feb 2020 12:29:54 +0000
Subject: [issue39540] Logging docs don't address the creation of multiple
 loggers when a hierarchy is provided
Message-ID: <1580732994.06.0.683672257184.issue39540@roundup.psfhosted.org>


New submission from Alexander McFarlane <alexander.mcfarlane at nomura.com>:

If `logger_name` is a hierarchy format (e.g. `logger_name = 'parent.child'`) and the logger name `'parent'` has not been created, the function call `logging.getLogger(logger_name)` will create all loggers in the hierarchy (in this instance two loggers, `'parent'` and `'parent.child'` will be created)

This is not documented anywhere in the logging documentation. Suggest that this is detailed under `logging.getLogger`

More info...
https://stackoverflow.com/q/59990300/4013571

----------
assignee: docs at python
components: Documentation
messages: 361287
nosy: docs at python, flipdazed
priority: normal
severity: normal
status: open
title: Logging docs don't address the creation of multiple loggers when a hierarchy is provided
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Feb  3 07:54:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 12:54:58 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580734498.41.0.970805386459.issue39484@roundup.psfhosted.org>


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

Yeah, time.time(), time.monotonic() and time.perf_counter() can benefit of a note suggestion to use time.time_ns(), time.monotonic_ns() or time.perf_counter_ns() to better precision.

----------

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

From report at bugs.python.org  Mon Feb  3 08:11:06 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 03 Feb 2020 13:11:06 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
Message-ID: <1580735466.88.0.173305606254.issue39491@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


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

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

From report at bugs.python.org  Mon Feb  3 08:11:42 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 03 Feb 2020 13:11:42 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
Message-ID: <1580735502.9.0.605744961616.issue39491@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


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

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

From report at bugs.python.org  Mon Feb  3 08:16:22 2020
From: report at bugs.python.org (Amir Mohamadi)
Date: Mon, 03 Feb 2020 13:16:22 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580735782.06.0.212236101466.issue39524@roundup.psfhosted.org>


Amir Mohamadi <amiremohamadi at yahoo.com> added the comment:

But in both cases the 'Output' will contain '\\':
"Replace all chars except '\\f\\t' in a line with spaces."

----------
nosy: +Amir

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

From report at bugs.python.org  Mon Feb  3 08:19:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 13:19:57 +0000
Subject: [issue39541] distutils: Remove bdist_wininst (Windows .exe
 installers) in favor of bdist_wheel (.whl)
Message-ID: <1580735997.04.0.997914254478.issue39541@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The distutils bdist_wininst has been deprecated in Python 3.8 by bpo-37481 in favor of bdist_wheel.

See "Deprecate bdist_wininst" discussion:
https://discuss.python.org/t/deprecate-bdist-wininst/1929

I now propose to remove it from the Python code base to ease the Python maintenance.

One of the project project which used .exe Windows installer was Pillow, but this project doesn't publish .exe installers since Pillow 6.2.0 (October 2019):

* "No more deprecated bdist_wininst .exe installers #4029 [hugovk]"
* https://github.com/python-pillow/Pillow/pull/4029

Attached PR removes bdist_wininst: use bdist_whell instead.

----------
components: Library (Lib)
messages: 361290
nosy: vstinner
priority: normal
severity: normal
status: open
title: distutils: Remove bdist_wininst (Windows .exe installers) in favor of bdist_wheel (.whl)
versions: Python 3.9

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

From report at bugs.python.org  Mon Feb  3 08:25:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 13:25:42 +0000
Subject: [issue39541] distutils: Remove bdist_wininst (Windows .exe
 installers) in favor of bdist_wheel (.whl)
In-Reply-To: <1580735997.04.0.997914254478.issue39541@roundup.psfhosted.org>
Message-ID: <1580736342.08.0.808959950409.issue39541@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Mon Feb  3 08:32:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 13:32:50 +0000
Subject: [issue39541] distutils: Remove bdist_wininst (Windows .exe
 installers) in favor of bdist_wheel (.whl)
In-Reply-To: <1580735997.04.0.997914254478.issue39541@roundup.psfhosted.org>
Message-ID: <1580736770.92.0.47002369971.issue39541@roundup.psfhosted.org>


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

I created a topic in the Packaging discourse to announce this removal:
https://discuss.python.org/t/remove-distutils-bdist-wininst-command/3115

I plan to merge my PR at the end of the week, except if someone speaks out to request to keep the deprecated command.

----------

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

From report at bugs.python.org  Mon Feb  3 08:37:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Feb 2020 13:37:38 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580737058.56.0.496289773255.issue39484@roundup.psfhosted.org>


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

The problem is that there is a double rounding in

    time = float(time_ns) / 1e9

1. When convert time_ns to float.
2. When divide it by 1e9.

The formula

    time = time_ns / 10**9

may be more accurate.

----------
nosy: +lemburg, mark.dickinson, rhettinger, stutzbach

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

From report at bugs.python.org  Mon Feb  3 09:02:18 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 03 Feb 2020 14:02:18 +0000
Subject: [issue28290] BETA report: Python-3.6 build messages to stderr: AIX
 and "not GCC"
In-Reply-To: <1475001330.34.0.107474417097.issue28290@psf.upfronthosting.co.za>
Message-ID: <1580738538.39.0.146473631209.issue28290@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Closing, as not longer relevant.

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

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

From report at bugs.python.org  Mon Feb  3 09:17:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 14:17:22 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580739442.4.0.220251254937.issue39489@roundup.psfhosted.org>


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


New changeset c6e5c1123bac6cbb4c85265155af5349dcea522e by Victor Stinner in branch 'master':
bpo-39489: Remove COUNT_ALLOCS special build (GH-18259)
https://github.com/python/cpython/commit/c6e5c1123bac6cbb4c85265155af5349dcea522e


----------

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

From report at bugs.python.org  Mon Feb  3 09:19:10 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 03 Feb 2020 14:19:10 +0000
Subject: [issue32542] memory not freed, aka memory leak continues...
In-Reply-To: <1515783394.33.0.467229070634.issue32542@psf.upfronthosting.co.za>
Message-ID: <1580739550.93.0.58800399794.issue32542@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Not an issue in 3.9, so, closing: "not relevant"

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

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

From report at bugs.python.org  Mon Feb  3 09:19:38 2020
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 03 Feb 2020 14:19:38 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580739578.23.0.57688715998.issue39484@roundup.psfhosted.org>


Vincent Michel <vxgmichel at gmail.com> added the comment:

> The problem is that there is a double rounding in [...]

Actually `float(x) / 1e9` and `x / 1e9` seems to produce the same results:

```
import time
import itertools
now = time.time_ns()                                                                          
for x in itertools.count(now):
    assert float(x) / 1e9 == x / 1e9
```

> The formula `time = time_ns / 10**9` may be more accurate.

Well that seems to not be the case, see the plots and the corresponding code. I might have made a mistake though, please let me know if I got something wrong :)

----------

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

From report at bugs.python.org  Mon Feb  3 09:21:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 14:21:24 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580739684.63.0.382194932418.issue39489@roundup.psfhosted.org>


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

Done, I remove COUNT_ALLOCS macro and all associated code.

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

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

From report at bugs.python.org  Mon Feb  3 09:23:23 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 03 Feb 2020 14:23:23 +0000
Subject: [issue36034] Suprise halt caused by
 -Werror=implicit-function-declaration in ./Modules/posixmodule.c
In-Reply-To: <1550577361.99.0.890870320024.issue36034@roundup.psfhosted.org>
Message-ID: <1580739803.2.0.183042738825.issue36034@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

closing. Will open a new issue with a correct description of the issue at hand. The problem is related to 64-bit mode (which was not mentioned before) and minor() major() macro definitions.

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

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

From report at bugs.python.org  Mon Feb  3 09:24:21 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 03 Feb 2020 14:24:21 +0000
Subject: [issue39541] distutils: Remove bdist_wininst (Windows .exe
 installers) in favor of bdist_wheel (.whl)
In-Reply-To: <1580735997.04.0.997914254478.issue39541@roundup.psfhosted.org>
Message-ID: <1580739861.57.0.419398903855.issue39541@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Per my reasoning in the discourse thread, I disagree with this move. I think that this should be handled in setuptools, which is where we tend to handle breaking changes or even enhancements to distutils.

If we do this in setuptools, we'll get a backport of the deprecation and removal back to 3.5, and it will make it easier to maintain setuptools.

The deprecation of bdist_wininst in Python 3.8 already made it harder to maintain setuptools with no real benefit to the CPython project, I would prefer to not repeat this mistake.

----------
nosy: +p-ganssle

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

From report at bugs.python.org  Mon Feb  3 09:28:55 2020
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 03 Feb 2020 14:28:55 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580740135.77.0.94263928641.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

> The problem is that there is a double rounding in
>     time = float(time_ns) / 1e9
> 1. When convert time_ns to float.
> 2. When divide it by 1e9.

I'm pretty sure that in Python 3, if you say
   c = a / b
and a and b are both "single-digit" integers, it first converts them both into doubles and then performs the divide.  See long_true_divide() in Objects/longobject.c, starting (currently) at line 3938.

----------

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

From report at bugs.python.org  Mon Feb  3 09:36:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Feb 2020 14:36:56 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580740616.15.0.438199299514.issue39484@roundup.psfhosted.org>


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

But they are not single-digit integers. And more, int(float(a)) != a.

----------

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

From report at bugs.python.org  Mon Feb  3 09:42:30 2020
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 03 Feb 2020 14:42:30 +0000
Subject: [issue34972] json dump silently converts int keys to string
In-Reply-To: <1539426263.62.0.788709270274.issue34972@psf.upfronthosting.co.za>
Message-ID: <1580740950.94.0.751182315779.issue34972@roundup.psfhosted.org>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I understand (and agree with) the merits of automatically converting the int to str when dumping to a string.

However, this result really surprised me:

>>> json.dumps({1:2, "1":3})
'{"1": 2, "1": 3}'

Is it a valid JSON?

----------
nosy: +facundobatista

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

From report at bugs.python.org  Mon Feb  3 09:45:15 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 03 Feb 2020 14:45:15 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580719207.62.0.51133653757.issue39502@roundup.psfhosted.org>
Message-ID: <302d3256-bfd2-0931-0390-24b8bac52c05@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Not sure I understand what bug I am supposed to report. I apologize if 
my message https://bugs.python.org/issue39502#msg361116.

I assume your comment re: time.localtime(91301504) comes from this bit 
of the test message (mtime_ns=91301504000000000).

Assuming our TZ used are different I am verifying AIX works correctly 
for the constant 91301504

root at x065:[/data/prj/python/python3-3.9]./python
Python 3.9.0a3+ (heads/master-dirty:78c7183f47, Feb  3 2020, 14:10:40) [C] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import time

>>> time.gmtime(91301504)
time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=17, tm_min=31, tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0)
>>> time.localtime(91301504)
time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=17, tm_min=31, tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0)

root at x065:[/data/prj/python/python3-3.9]set | grep TZ
TZ=UTC0

Again, my apologies for the confusion: the message
"skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000" only occurs when the test is run on a NFS
mount hosted by a SAN based on a Linux kernel.

When I specify --tempdir=/tmp (i.e., using jfs2 as filesystem) the test passes normally.

On 03/02/2020 09:40, STINNER Victor wrote:
> STINNER Victor <vstinner at python.org> added the comment:
>
>> test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000'
> AIX kernel seems to have a bug. You should report it to AIX.
>
>>>> time.localtime(91301504)
> time.struct_time(tm_year=1972, tm_mon=11, tm_mday=22, tm_hour=18, tm_min=31, tm_sec=44, tm_wday=2, tm_yday=327, tm_isdst=0)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39502>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Feb  3 09:47:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 14:47:56 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580741276.57.0.650220493874.issue39484@roundup.psfhosted.org>


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

I'm not sure which kind of problem you are trying to solve here. time.time() does lose precision because it uses the float type. Comparing time.time() and time.time_ns() tricky because of that. If you care of nanosecond precision, avoid float whenever possible and only store time as integer.

I'm not sure how to compat time.time() float with time.time_ns(). Maybe math.isclose() can help.

I don't think that Python is wrong here, time.time() and time.time_ns() work are expected, and I don't think that time.time() result can be magically more accurate: 1580301619906185300 nanoseconds (int) cannot be stored exactly as floating point number of seconds.

I suggest to only document in time.time() is less accurate than time.time_ns().

----------

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

From report at bugs.python.org  Mon Feb  3 10:16:22 2020
From: report at bugs.python.org (Philipp Rehs)
Date: Mon, 03 Feb 2020 15:16:22 +0000
Subject: [issue30256] Adding a SyncManager Queue proxy to a SyncManager dict
 or Namespace proxy raises an exception
In-Reply-To: <1493812414.86.0.361870744934.issue30256@psf.upfronthosting.co.za>
Message-ID: <1580742982.19.0.475030024032.issue30256@roundup.psfhosted.org>


Change by Philipp Rehs <phhere at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Mon Feb  3 10:21:31 2020
From: report at bugs.python.org (Tom Augspurger)
Date: Mon, 03 Feb 2020 15:21:31 +0000
Subject: [issue35108] inspect.getmembers passes exceptions from object's
 properties through
In-Reply-To: <1540887635.53.0.788709270274.issue35108@psf.upfronthosting.co.za>
Message-ID: <1580743291.22.0.95885008482.issue35108@roundup.psfhosted.org>


Change by Tom Augspurger <tom.augspurger88 at gmail.com>:


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

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

From report at bugs.python.org  Mon Feb  3 10:42:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 15:42:01 +0000
Subject: [issue39542] Cleanup object.h header
Message-ID: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In bpo-39489, I removed the COUNT_ALLOCS special build. The object.h header can now be cleaned up to simplify the code.

----------
components: C API
messages: 361305
nosy: vstinner
priority: normal
severity: normal
status: open
title: Cleanup object.h header
versions: Python 3.9

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

From report at bugs.python.org  Mon Feb  3 10:44:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 Feb 2020 15:44:29 +0000
Subject: [issue39540] Logging docs don't address the creation of multiple
 loggers when a hierarchy is provided
In-Reply-To: <1580732994.06.0.683672257184.issue39540@roundup.psfhosted.org>
Message-ID: <1580744669.32.0.0252233703575.issue39540@roundup.psfhosted.org>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Mon Feb  3 10:45:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 15:45:50 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580744750.25.0.0708281069252.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Mon Feb  3 11:04:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Feb 2020 16:04:09 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580745849.29.0.322834871599.issue39484@roundup.psfhosted.org>


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

>>> 1580301619906185300/10**9
1580301619.9061854
>>> 1580301619906185300/1e9
1580301619.9061852
>>> float(F(1580301619906185300/10**9) * 10**9 - 1580301619906185300)
88.5650634765625
>>> float(F(1580301619906185300/1e9) * 10**9 - 1580301619906185300)
-149.853515625

1580301619906185300/10**9 is more accurate than 1580301619906185300/1e9.

----------

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

From report at bugs.python.org  Mon Feb  3 11:28:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 16:28:38 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580747318.52.0.0295543391043.issue39542@roundup.psfhosted.org>


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


New changeset 4b524161a0f9d50d782e739a3708434ffd4e94a5 by Victor Stinner in branch 'master':
bpo-39542: Move object.h debug functions to internal C API (GH-18331)
https://github.com/python/cpython/commit/4b524161a0f9d50d782e739a3708434ffd4e94a5


----------

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

From report at bugs.python.org  Mon Feb  3 11:35:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 16:35:03 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580747703.34.0.817466788127.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17705
pull_request: https://github.com/python/cpython/pull/18332

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

From report at bugs.python.org  Mon Feb  3 11:35:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 16:35:12 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580747712.0.0.1275697553.issue39484@roundup.psfhosted.org>


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

I compare nanoseconds (int):

>>> t=1580301619906185300

# int/int: int.__truediv__(int)
>>> abs(t - int(t/10**9 * 1e9))
172

# int/float: float.__rtruediv__(int)
>>> abs(t - int(t/1e9 * 1e9))
84

# float/int: float.__truediv__(int)
>>> abs(t - int(float(t)/10**9 * 1e9))
84

# float/float: float.__truediv__(float)
>>> abs(t - int(float(t)/1e9 * 1e9))
84

=> int/int is less accurate than float/float for t=1580301619906185300


You compare seconds (float/Fraction):

>>> from fractions import Fraction as F
>>> t=1580301619906185300

# int / int
>>> float(F(t/10**9) * 10**9 - t)
88.5650634765625

# int / float
>>> float(F(t/1e9) * 10**9 - t)
-149.853515625

=> here int/int looks more accurate than int/float


And we get different conclusion :-)

----------

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

From report at bugs.python.org  Mon Feb  3 11:35:22 2020
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 03 Feb 2020 16:35:22 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580747722.97.0.264642746212.issue39484@roundup.psfhosted.org>


Vincent Michel <vxgmichel at gmail.com> added the comment:

@serhiy.storchaka
> 1580301619906185300/10**9 is more accurate than 1580301619906185300/1e9.

I don't know exactly what `F` represents in your example but here is what I get:

>>> r = 1580301619906185300                                                              
>>> int(r / 10**9 * 10**9) - r                                                           
172
>>> int(r / 1e9 * 10**9) - r                                                             
-84

@vstinner
> I suggest to only document in time.time() is less accurate than time.time_ns().

Sounds good!

----------

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

From report at bugs.python.org  Mon Feb  3 11:53:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 16:53:48 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
Message-ID: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In bpo-35059, I converted Py_DECREF() macro to a static inline function (commit 2aaf0c12041bcaadd7f2cc5a54450eefd7a6ff12).

Then in bpo-35134, I moved _Py_Dealloc() macro to the newly created Include/cpython/object.h header file (commit 6eb996685e25c09499858bee4be258776e603c6f).

The problem is that when Py_DECREF() was converted to a static inline function, it stopped to use the *redefine* _Py_Dealloc() fast macro, but instead use the slow regular function call:

PyAPI_FUNC(void) _Py_Dealloc(PyObject *);

Py_DECREF() performance is critical for overall Python performance.

I will work on a PR to fix this issue.


See also bpo-39542 which updates object.h and cpython/object.h.

----------
components: C API
messages: 361310
nosy: vstinner
priority: normal
severity: normal
status: open
title: Py_DECREF(): use inlined _Py_Dealloc()
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Feb  3 11:55:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Feb 2020 16:55:08 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580748908.94.0.563105061907.issue39542@roundup.psfhosted.org>


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


New changeset 49932fec62c616ec88da52642339d83ae719e924 by Victor Stinner in branch 'master':
bpo-39542: Simplify _Py_NewReference() (GH-18332)
https://github.com/python/cpython/commit/49932fec62c616ec88da52642339d83ae719e924


----------

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

From report at bugs.python.org  Mon Feb  3 12:04:13 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 03 Feb 2020 17:04:13 +0000
Subject: [issue29988] with statements are not ensuring that __exit__ is called
 if __enter__ succeeds
In-Reply-To: <1491349378.03.0.0671954460373.issue29988@psf.upfronthosting.co.za>
Message-ID: <1580749453.98.0.705761131046.issue29988@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +17706
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18334

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

From report at bugs.python.org  Mon Feb  3 12:11:23 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 03 Feb 2020 17:11:23 +0000
Subject: [issue38558] Data Structures documentation out of sync with new
 Walrus operator
In-Reply-To: <1571776032.37.0.709698360286.issue38558@roundup.psfhosted.org>
Message-ID: <1580749883.23.0.144705208968.issue38558@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 5807efd4c396d5718325e21f5a14e324a77ff77c by Adorilson Bezerra in branch 'master':
bpo-38558: Link to further docs from walrus operator mention in tutorial (GH-16973)
https://github.com/python/cpython/commit/5807efd4c396d5718325e21f5a14e324a77ff77c


----------
nosy: +mdk

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

From report at bugs.python.org  Mon Feb  3 12:11:34 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Feb 2020 17:11:34 +0000
Subject: [issue38558] Data Structures documentation out of sync with new
 Walrus operator
In-Reply-To: <1571776032.37.0.709698360286.issue38558@roundup.psfhosted.org>
Message-ID: <1580749894.54.0.325180358195.issue38558@roundup.psfhosted.org>


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


----------
pull_requests: +17707
pull_request: https://github.com/python/cpython/pull/18335

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

From report at bugs.python.org  Mon Feb  3 12:17:24 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Feb 2020 17:17:24 +0000
Subject: [issue38558] Data Structures documentation out of sync with new
 Walrus operator
In-Reply-To: <1571776032.37.0.709698360286.issue38558@roundup.psfhosted.org>
Message-ID: <1580750244.51.0.519233208705.issue38558@roundup.psfhosted.org>


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


New changeset d01ae1b22330992eadc7b2a0842ead544f7e507d by Miss Islington (bot) in branch '3.8':
bpo-38558: Link to further docs from walrus operator mention in tutorial (GH-16973)
https://github.com/python/cpython/commit/d01ae1b22330992eadc7b2a0842ead544f7e507d


----------

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

From report at bugs.python.org  Mon Feb  3 12:51:23 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 17:51:23 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580752283.97.0.331263318845.issue39484@roundup.psfhosted.org>


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

> int/int is less accurate than float/float for t=1580301619906185300

No, int/int is more accurate here. If a and b are ints, a / b is always correctly rounded on an IEEE 754 system, while float(a) / float(b) will not necessarily give a correctly rounded result. So for an integer a, `a / 10**9` will _always_ be at least as accurate as `a / 1e9`.

----------

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

From report at bugs.python.org  Mon Feb  3 12:53:35 2020
From: report at bugs.python.org (tegavu)
Date: Mon, 03 Feb 2020 17:53:35 +0000
Subject: [issue39544] Pathlib PureWindowsPath sorting incorrect (is not
 natural sort)
Message-ID: <1580752415.37.0.934686672002.issue39544@roundup.psfhosted.org>


New submission from tegavu <tegavu83ag at sogetthis.com>:

Wrong behavior in pathlib.PureWindowsPath - sorting does not use natural sort.

Everything below was written based on W7x64 & Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32.

The documentation (https://docs.python.org/3/library/pathlib.html#general-properties) states: "Paths of a same flavour are comparable and orderable."

This can be done like this:

from pathlib import *
print( PureWindowsPath('C:\\1') < PureWindowsPath('C:\\a') )

This returns True. This is expected because 1 is sorted before a on Windows.

This sorting also works well for harder cases where other sorting functions fail: !1 should be before 1 and !a should be before a.

But it fails with natural sorting:

from pathlib import *
print( PureWindowsPath('C:\\15') < PureWindowsPath('C:\\100') )

This returns False.

This is a bug in my opinion, since PureWindowsPath should sort like Windows(Explorer) would sort. 

Right now PureWindowsPath does probably something like NTFS sorting, but NTFS is not Windows and from a function called 'WindowsPath' I expect a path that would be given in Windows Explorer.

In case a simple `dir` on Windows sorts by NTFS names (I am not sure!), PureWindowsPath also fails, since (for example) "[" < "a" should be False.

See this image for comparison:
https://i.imgur.com/GjBhWsS.png

Here is a string that can be used directly as a list to check sorting:

test_list = ['15', '100', '11111', '!', '#', '$', '%', '&', "'", '(', ')', '+', '+11111', '+aaaaa', ',', '-', ';', '=', '@', '[', ']', '^', '_', '`', 'aaaaa', 'foo0', 'foo_0', '{', '}', '~', '?', '?', '?', '?', '?']

----------
messages: 361315
nosy: tegavu
priority: normal
severity: normal
status: open
title: Pathlib PureWindowsPath sorting incorrect (is not natural sort)
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Feb  3 12:57:54 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 17:57:54 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580752674.72.0.755478183049.issue39484@roundup.psfhosted.org>


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

To be clear: the following is flawed as an accuracy test, because the *multiplication* by 1e9 introduces additional error.

# int/int: int.__truediv__(int)
>>> abs(t - int(t/10**9 * 1e9))
172

Try this instead, which uses the Fractions module to get the exact error. (The error is converted to a float before printing, for convenience, to show the approximate size of the errors.)

>>> from fractions import Fraction as F
>>> exact = F(t, 10**9)
>>> int_int = t / 10**9
>>> float_float = t / 1e9
>>> int_int_error = F(int_int) - exact
>>> float_float_error = F(float_float) - exact
>>> print(float(int_int_error))
8.85650634765625e-08
>>> print(float(float_float_error))
-1.49853515625e-07

----------

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

From report at bugs.python.org  Mon Feb  3 13:26:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Feb 2020 18:26:38 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
Message-ID: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>


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

The following code is compiled in 3.7, but is a syntax error in 3.6.

async def f(x):
    f"{await x}"

I have not found mentioning this change in What's New, and it looks grammatically correct. It looks as a bug in 3.6.

It may be too later to fix it in 3.6, but at least it should be documented.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 361317
nosy: docs at python, eric.smith, serhiy.storchaka
priority: normal
severity: normal
status: open
title: await is not supported in f-string in 3.6
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Feb  3 13:27:33 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 03 Feb 2020 18:27:33 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580754453.05.0.0943242860098.issue39480@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Mon Feb  3 13:34:42 2020
From: report at bugs.python.org (Ronan Pigott)
Date: Mon, 03 Feb 2020 18:34:42 +0000
Subject: [issue39400] pydoc: Use of MANPAGER variable is incorrect
In-Reply-To: <1579554143.61.0.454786328579.issue39400@roundup.psfhosted.org>
Message-ID: <1580754882.44.0.177773814476.issue39400@roundup.psfhosted.org>


Ronan Pigott <rpigott at berkeley.edu> added the comment:

Any reason a change like this could not be added to a 3.8.x release?

Like I pointed out in the PR, pydoc's use of MANPAGER is undocumented and, as far as I'm concerned, incorrect.

A lot of software references idiosyncratic <PROGRAM>_PAGER vars, but pydoc reuses MANPAGER instead of something like PYDOC_PAGER. I don't think it's such a bad idea to reuse MANPAGER considering the two programs serve a similar function, but I think matching man's interpretation of MANPAGER is then the only reasonable behavior pydoc can take. If it does not, pydoc is by-default broken on plenty of otherwise fine setups.

As it stands, pydoc is broken _because_ of undocumented behavior. A user reading the docs carefully still might not recognize that pydoc is preferring their MANPAGER value over PAGER. For that reason, I'd call this a bugfix. The bug here could be considered that pydoc references MANPAGER _at all_. However, given what I think is the intent of the original code - to allow pydoc to benefit from a user's MANPAGER customization - I've tried to update pydoc to reflect that intent in the PR, rather than remove the feature.

I think this change could be eligible for 3.8.x. Thoughts?

----------

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

From report at bugs.python.org  Mon Feb  3 13:40:47 2020
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 03 Feb 2020 18:40:47 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580755247.09.0.523899281959.issue39484@roundup.psfhosted.org>


Vincent Michel <vxgmichel at gmail.com> added the comment:

@mark.dickinson
> To be clear: the following is flawed as an accuracy test, because the *multiplication* by 1e9 introduces additional error.

Interesting, I completely missed that! 

But did you notice that the full conversion might still perform better when using only floats?

```
>>> from fractions import Fraction as F                                                   
>>> r = 1580301619906185300                                                              
>>> abs(int(r / 1e9 * 1e9) - r)                                                          
84
>>> abs(round(F(r / 10**9) * 10**9) - r)                                               
89
```

I wanted to figure out how often that happens so I updated my plotting, you can find the code and plot attached.

Notice how both methods seems to perform equally good (the difference of the absolute errors seems to average to zero). I have no idea about why that happens though.

----------
Added file: https://bugs.python.org/file48882/Comparing_conversions_over_5_us.png

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

From report at bugs.python.org  Mon Feb  3 13:43:25 2020
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 03 Feb 2020 18:43:25 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580755405.82.0.222125698697.issue39484@roundup.psfhosted.org>


Change by Vincent Michel <vxgmichel at gmail.com>:


Added file: https://bugs.python.org/file48883/comparing_conversions.py

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

From report at bugs.python.org  Mon Feb  3 13:45:19 2020
From: report at bugs.python.org (Max Vorobev)
Date: Mon, 03 Feb 2020 18:45:19 +0000
Subject: [issue30825] csv.Sniffer does not detect lineterminator
In-Reply-To: <1498944224.71.0.636990812421.issue30825@psf.upfronthosting.co.za>
Message-ID: <1580755519.2.0.308904555497.issue30825@roundup.psfhosted.org>


Change by Max Vorobev <vmax0770 at gmail.com>:


----------
keywords: +patch
pull_requests: +17708
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18336

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

From report at bugs.python.org  Mon Feb  3 13:45:11 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 03 Feb 2020 18:45:11 +0000
Subject: [issue39544] Pathlib PureWindowsPath sorting incorrect (is not
 natural sort)
In-Reply-To: <1580752415.37.0.934686672002.issue39544@roundup.psfhosted.org>
Message-ID: <1580755511.99.0.769708128328.issue39544@roundup.psfhosted.org>


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

> Right now PureWindowsPath does probably something like NTFS sorting, 
> but NTFS is not Windows and from a function called 'WindowsPath' I 
> expect a path that would be given in Windows Explorer.

NTFS stores the names in a directory as a btree that's sorted case-insensitively according to the filesystem's casing table. Other filesystems such as FAT32 store names in arbitrary order, maybe FIFO order with reuse of slot indexes when files are deleted, or maybe based on hashing the filename.

The Windows file API does not sort the results of a directory listing. It's up to applications to decide how a listing will be presented. You cite what Explorer does as a standard for "Windows", but there is no such standard that I know of. Maybe implementing a natural sort for Path instances is desirable, but I disagree that appealing to what Explorer does should be the sole basis for this decision. Anyway, it would be a breaking change, which certainly cannot be implemented in 3.8.

Currently sorting is based on the case-folded parts:

     def casefold_parts(self, parts):
        return [p.lower() for p in parts]

----------
nosy: +eryksun
versions: +Python 3.9 -Python 3.8

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

From report at bugs.python.org  Mon Feb  3 13:45:29 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 03 Feb 2020 18:45:29 +0000
Subject: [issue39544] Pathlib PureWindowsPath sorting incorrect (is not
 natural sort)
In-Reply-To: <1580752415.37.0.934686672002.issue39544@roundup.psfhosted.org>
Message-ID: <1580755529.33.0.762643682457.issue39544@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components: +Library (Lib), Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Mon Feb  3 13:58:56 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 18:58:56 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580756336.32.0.566549665001.issue39480@roundup.psfhosted.org>


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

Speaking as a British, UK-based Python contributor who's unhappy with recent political developments in the UK, I say let's close this.

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

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

From report at bugs.python.org  Mon Feb  3 14:00:06 2020
From: report at bugs.python.org (Mariatta)
Date: Mon, 03 Feb 2020 19:00:06 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1580756406.28.0.203964703125.issue39545@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

The answer I got from Yury before was: "Before 3.7 async and await were not proper keywords, so the interpreter did not recognize them in some contexts."

----------
nosy: +Mariatta

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

From report at bugs.python.org  Mon Feb  3 14:30:11 2020
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 03 Feb 2020 19:30:11 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580758211.96.0.0588236834659.issue39502@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

I think that Victor means AIX kernel and filesystems are not prepared for Y2038.

----------
nosy: +David.Edelsohn

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

From report at bugs.python.org  Mon Feb  3 14:43:36 2020
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 03 Feb 2020 19:43:36 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1580759016.66.0.209774947061.issue38628@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

How was Python compiled?  With GCC? Which version of GCC?
I assume that Python was built as a 64 bit application based on libc loading the 64 bit member shr_64.o.

Does the testcase work in 32 bit mode?
Does the testcase work if Python is compiled by XLC?

This likely is an incompatibility in libffi with libffi loading the registers incorrectly for the call into libc.a(shr_64.o).

It seems rather fragile to pass a struct that is supposed to have the same parameter layout as the function signature.

----------

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

From report at bugs.python.org  Mon Feb  3 14:46:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Feb 2020 19:46:48 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580759208.6.0.171898068429.issue39480@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Feb  3 14:50:35 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Feb 2020 19:50:35 +0000
Subject: [issue39527] Update doc of argparse.rst
In-Reply-To: <1580621395.73.0.298845669728.issue39527@roundup.psfhosted.org>
Message-ID: <1580759435.84.0.945265578707.issue39527@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Feb  3 15:09:35 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 03 Feb 2020 20:09:35 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1580760575.94.0.339084603269.issue10572@roundup.psfhosted.org>


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

Someone probably needs to go through the stdlib to find which modules have tests outside of Lib/test/, and then figure out if there is still any justification for that. If there isn't then they should be moved to Lib/test.

----------

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

From report at bugs.python.org  Mon Feb  3 15:11:28 2020
From: report at bugs.python.org (Kyle Meyer)
Date: Mon, 03 Feb 2020 20:11:28 +0000
Subject: [issue39546] argparse: allow_abbrev=False is ignored for alternative
 prefix characters
Message-ID: <1580760688.73.0.980793532046.issue39546@roundup.psfhosted.org>


New submission from Kyle Meyer <kyle at kyleam.com>:

As of Python v3.8.0 (specifically commit b1e4d1b603), specifying
`allow_abbrev=False` does not disable abbreviation for prefix
characters other than '-'.

--8<---------------cut here---------------start------------->8---
import argparse

parser = argparse.ArgumentParser(prefix_chars='+', allow_abbrev=False)
parser.add_argument('++long')
print(parser.parse_args(['++lo=val']))
--8<---------------cut here---------------end--------------->8---

Observed output (with b1e4d1b603 and current master):

    Namespace(long='val')

Expected (and observed with b1e4d1b603^ and 3.7.3):

    usage: scratch.py [+h] [++long LONG]
    scratch.py: error: unrecognized arguments: ++lo=val


I will follow up with a PR to propose a fix.

----------
components: Library (Lib)
messages: 361326
nosy: kyleam
priority: normal
severity: normal
status: open
title: argparse: allow_abbrev=False is ignored for alternative prefix characters
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Feb  3 15:18:15 2020
From: report at bugs.python.org (Kyle Meyer)
Date: Mon, 03 Feb 2020 20:18:15 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1580761095.24.0.856202224032.issue26967@roundup.psfhosted.org>


Change by Kyle Meyer <kyle at kyleam.com>:


----------
pull_requests: +17710
pull_request: https://github.com/python/cpython/pull/18337

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

From report at bugs.python.org  Mon Feb  3 15:18:15 2020
From: report at bugs.python.org (Kyle Meyer)
Date: Mon, 03 Feb 2020 20:18:15 +0000
Subject: [issue39546] argparse: allow_abbrev=False is ignored for alternative
 prefix characters
In-Reply-To: <1580760688.73.0.980793532046.issue39546@roundup.psfhosted.org>
Message-ID: <1580761095.17.0.569238285356.issue39546@roundup.psfhosted.org>


Change by Kyle Meyer <kyle at kyleam.com>:


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

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

From report at bugs.python.org  Mon Feb  3 15:27:51 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 03 Feb 2020 20:27:51 +0000
Subject: [issue39088] test_concurrent_futures crashed with python.core core
 dump on AMD64 FreeBSD Shared 3.x
In-Reply-To: <1576690668.17.0.971544115619.issue39088@roundup.psfhosted.org>
Message-ID: <1580761671.59.0.631085994488.issue39088@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

In GH-18228, an unrelated failure in test_concurrent_futures occurred (same as the one above):


Ran 354 tests in 496.802s
OK (skipped=35)
Warning -- files was modified by test_multiprocessing_spawn
  Before: []
  After:  ['python.core']


Full test logs: https://buildbot.python.org/all/#/builders/152/builds/259/steps/5/logs/stdio

----------
nosy: +aeros

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

From report at bugs.python.org  Mon Feb  3 16:28:50 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 21:28:50 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
 Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1580765330.56.0.776578204111.issue8627@roundup.psfhosted.org>


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

Let's close. This was only ever an issue in Python 2.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Feb  3 16:30:07 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 21:30:07 +0000
Subject: [issue39108] random needs doc for "gauss" versus "normalvariate"
In-Reply-To: <1576842313.59.0.109867222427.issue39108@roundup.psfhosted.org>
Message-ID: <1580765407.75.0.530870293402.issue39108@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/issue39108>
_______________________________________

From report at bugs.python.org  Mon Feb  3 16:37:42 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 21:37:42 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1580765862.67.0.791855552848.issue19683@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/issue19683>
_______________________________________

From report at bugs.python.org  Mon Feb  3 16:38:44 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 21:38:44 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
 files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1580765924.05.0.305405556722.issue8912@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/issue8912>
_______________________________________

From report at bugs.python.org  Mon Feb  3 16:40:21 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Feb 2020 21:40:21 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1580766021.7.0.976510324844.issue39280@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/issue39280>
_______________________________________

From report at bugs.python.org  Mon Feb  3 17:59:34 2020
From: report at bugs.python.org (Will Bond)
Date: Mon, 03 Feb 2020 22:59:34 +0000
Subject: [issue39547] hmac.new() default parameter change not mentioned in
 changelog
Message-ID: <1580770774.29.0.234296121178.issue39547@roundup.psfhosted.org>


New submission from Will Bond <will at wbond.net>:

When running code on Python 3.8 that previous was running 3.3, I ran into the issue that the default value for the digestmod parameter of hmac.new() has been changed to backwards-incompatible value.

I generally would have expected such a break to show up in https://docs.python.org/3/whatsnew/3.8.html#api-and-feature-removals. If not there, somewhere on the 3.8 changelog page.

----------
assignee: docs at python
components: Documentation
messages: 361329
nosy: docs at python, wbond
priority: normal
severity: normal
status: open
title: hmac.new() default parameter change not mentioned in changelog
versions: Python 3.8

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

From report at bugs.python.org  Mon Feb  3 18:31:29 2020
From: report at bugs.python.org (Stephen Balousek)
Date: Mon, 03 Feb 2020 23:31:29 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
Message-ID: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>


New submission from Stephen Balousek <stephen at balousek.net>:

When making an HTTP request using an opener with an attached HTTPDigestAuthHandler, the request causes a crash when the returned 'WWW-Authenticate' header for the 'Digest' domain does not return the optional 'qop' value.

Response headers:
=================
Content-Type: application/json
Content-Security-Policy: default-src 'self' 'unsafe-eval' 'unsafe-inline';img-src 'self' data:
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 600
WWW-Authenticate: Digest realm="ServiceManager", nonce="1580815098100956"
WWW-Authenticate: Basic realm="ServiceManager", charset="UTF-8"
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Expires: 0
Pragma: no-cache

Crash:
======
Error:   Exception: 'NoneType' object has no attribute 'split'
Traceback (most recent call last):
...
  File "/home/sbalousek/bin/restap.py", line 1317, in RunTest
    status, payload, contentType = ExecuteRequest(baseUrl, test, tap);
  File "/home/sbalousek/bin/restap.py", line 1398, in ExecuteRequest
    response    = opener.open(request, payload, timeout);
  File "/usr/lib/python3.8/urllib/request.py", line 523, in open
    response = meth(req, response)
  File "/home/sbalousek/bin/restap.py", line 1065, in http_response
    return self.process_response(request, response, HTTPErrorProcessor.http_response);
  File "/home/sbalousek/bin/restap.py", line 1056, in process_response
    return handler(self, request, response);
  File "/usr/lib/python3.8/urllib/request.py", line 632, in http_response
    response = self.parent.error(
  File "/usr/lib/python3.8/urllib/request.py", line 555, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 494, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.8/urllib/request.py", line 1203, in http_error_401
    retry = self.http_error_auth_reqed('www-authenticate',
  File "/usr/lib/python3.8/urllib/request.py", line 1082, in http_error_auth_reqed
    return self.retry_http_digest_auth(req, authreq)
  File "/usr/lib/python3.8/urllib/request.py", line 1090, in retry_http_digest_auth
    auth = self.get_authorization(req, chal)
  File "/usr/lib/python3.8/urllib/request.py", line 1143, in get_authorization
    if 'auth' in qop.split(','):
AttributeError: 'NoneType' object has no attribute 'split'

Diagnosis:
==========
The crash is a result of an optional 'qop' value missing from the 'WWW-Authenticate' header.

This bug was introduced in changes for issue 38686.

----------
components: Library (Lib)
messages: 361330
nosy: Stephen Balousek
priority: normal
severity: normal
status: open
title: Request fails when 'WWW-Authenticate' header for Digest Authentication does not contain 'qop'
type: crash
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Feb  3 18:50:43 2020
From: report at bugs.python.org (Stephen Balousek)
Date: Mon, 03 Feb 2020 23:50:43 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1580773843.11.0.012814493079.issue39548@roundup.psfhosted.org>


Change by Stephen Balousek <stephen at balousek.net>:


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

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

From report at bugs.python.org  Mon Feb  3 19:32:22 2020
From: report at bugs.python.org (mpheath)
Date: Tue, 04 Feb 2020 00:32:22 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580776342.34.0.0323925778055.issue39524@roundup.psfhosted.org>


Change by mpheath <mpheath at tpg.com.au>:


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

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

From report at bugs.python.org  Mon Feb  3 19:44:04 2020
From: report at bugs.python.org (Mariatta)
Date: Tue, 04 Feb 2020 00:44:04 +0000
Subject: [issue39539] Improve Keccak support in hashlib including
 KangarooTwelve
In-Reply-To: <1580725505.22.0.0334645206917.issue39539@roundup.psfhosted.org>
Message-ID: <1580777044.38.0.584019270333.issue39539@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Added hashlib module experts.

----------
nosy: +Mariatta, christian.heimes, gregory.p.smith

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

From report at bugs.python.org  Mon Feb  3 19:45:35 2020
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 04 Feb 2020 00:45:35 +0000
Subject: [issue39514] http://sphinx.pocoo.org/
In-Reply-To: <1580506603.75.0.50119765059.issue39514@roundup.psfhosted.org>
Message-ID: <1580777135.37.0.145314887237.issue39514@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

My PR has been merged and I've verified that the link is now point to https://www.sphinx-doc.org/. Closing this as 'fixed'.

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

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

From report at bugs.python.org  Mon Feb  3 19:58:43 2020
From: report at bugs.python.org (mpheath)
Date: Tue, 04 Feb 2020 00:58:43 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580777923.86.0.254769517073.issue39524@roundup.psfhosted.org>


Change by mpheath <mpheath at tpg.com.au>:


----------
pull_requests: +17713
pull_request: https://github.com/python/cpython/pull/18341

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

From report at bugs.python.org  Mon Feb  3 20:00:29 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 04 Feb 2020 01:00:29 +0000
Subject: [issue39539] Improve Keccak support in hashlib including
 KangarooTwelve
In-Reply-To: <1580725505.22.0.0334645206917.issue39539@roundup.psfhosted.org>
Message-ID: <1580778029.15.0.501803358141.issue39539@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Christian added the SHA3 support so is probably best to comment on this. The way our hashlib code is structured we always use the https://github.com/python/cpython/tree/master/Modules/_sha3 implementation rather than OpenSSL for these algorithms due to the better functionality of that Keccak code.  So at first glance it should be reasonably straightforward to update it to accept an optional suffix constructor argument.

PR welcome.

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

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

From report at bugs.python.org  Mon Feb  3 20:07:30 2020
From: report at bugs.python.org (=?utf-8?q?Alexander_B=C3=B6hn?=)
Date: Tue, 04 Feb 2020 01:07:30 +0000
Subject: =?utf-8?q?=5Bissue39549=5D_The_reprlib=2ERepr_type_should_permit_the_?=
 =?utf-8?q?=E2=80=9Cfillvalue=E2=80=9D_to_be_set_by_the_user?=
Message-ID: <1580778450.13.0.746492669497.issue39549@roundup.psfhosted.org>


New submission from Alexander B?hn <fish2000 at gmail.com>:

Currently, the `reprlib.recursive_repr(?)` decorator allows a ?fillvalue? parameter to be specified by the user. This is a string value that is used as a placeholder when calculating an objects? repr ? in the case of `recursive_repr(?)` the ?fillvalue? defaults to '...' and may be set by the user to a string of any length.

There is no such user-defined ?fillvalue? on the `reprlib.Repr` type, although the '...' string is hardcoded in its implementation and used throughout.

I propose that the hardcoded use of the '...' string in the code for the `reprlib.Repr` implementation should be replaced by a ?fillvalue? attribute, set on the class in its `__init__(?)` method ? and therefore overridable in subclasses, like the existing myriad ?max*? instance attributes. 

PR to follow in short order.

----------
components: Library (Lib)
messages: 361334
nosy: fish2000
priority: normal
severity: normal
status: open
title: The reprlib.Repr type should permit the ?fillvalue? to be set by the user
type: behavior
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/issue39549>
_______________________________________

From report at bugs.python.org  Mon Feb  3 20:14:39 2020
From: report at bugs.python.org (mpheath)
Date: Tue, 04 Feb 2020 01:14:39 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580778879.03.0.432669671781.issue39524@roundup.psfhosted.org>


mpheath <mpheath at tpg.com.au> added the comment:

I have submitted 2 Pull Requests. One for 3.9 and the other for 3.8. Only way I knew was to create 2 separate branches to checkout, linked to version tags to get the correct patches for ast.py. Hope is OK.

----------

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

From report at bugs.python.org  Mon Feb  3 20:44:33 2020
From: report at bugs.python.org (mpheath)
Date: Tue, 04 Feb 2020 01:44:33 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1580780673.93.0.25323715291.issue39524@roundup.psfhosted.org>


Change by mpheath <mpheath at tpg.com.au>:


----------
pull_requests: +17714
pull_request: https://github.com/python/cpython/pull/18342

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

From report at bugs.python.org  Mon Feb  3 21:16:25 2020
From: report at bugs.python.org (=?utf-8?q?Alexander_B=C3=B6hn?=)
Date: Tue, 04 Feb 2020 02:16:25 +0000
Subject: =?utf-8?q?=5Bissue39549=5D_The_reprlib=2ERepr_type_should_permit_the_?=
 =?utf-8?q?=E2=80=9Cfillvalue=E2=80=9D_to_be_set_by_the_user?=
In-Reply-To: <1580778450.13.0.746492669497.issue39549@roundup.psfhosted.org>
Message-ID: <1580782585.21.0.787535216082.issue39549@roundup.psfhosted.org>


Change by Alexander B?hn <fish2000 at gmail.com>:


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

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

From report at bugs.python.org  Mon Feb  3 21:53:59 2020
From: report at bugs.python.org (Cyker Way)
Date: Tue, 04 Feb 2020 02:53:59 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
 doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1580784839.1.0.4241060592.issue14074@roundup.psfhosted.org>


Cyker Way <cykerway at gmail.com> added the comment:

Tuple support is documented:

https://github.com/python/cpython/commit/98047eb806227f11212f6a42c242030a51964e30#diff-9c4a053d29149ba40370fbdddd3e34faR1059

https://docs.python.org/3/library/argparse.html#metavar

>   Providing a tuple to ``metavar`` specifies a different display for each of the arguments:

>From his word here I feel like our professor meant to support tuple metavar but the implementation was not careful. He called for a patch eight years ago. Let's summon him and see if he has changed his mind?

----------

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

From report at bugs.python.org  Tue Feb  4 02:19:18 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 04 Feb 2020 07:19:18 +0000
Subject: [issue39540] Logging docs don't address the creation of multiple
 loggers when a hierarchy is provided
In-Reply-To: <1580732994.06.0.683672257184.issue39540@roundup.psfhosted.org>
Message-ID: <1580800758.73.0.876277057767.issue39540@roundup.psfhosted.org>


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

That's an internal detail. In fact loggers aren't created for all loggers in the hierarchy - PlaceHolder objects are created internally for hierarchy ancestors, and converted to loggers if needed. The printout from your linked Stack Overflow question shows this.

This is not documented because it's internal implementation detail. How the dotted-name hierarchy works is documented.

----------

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

From report at bugs.python.org  Tue Feb  4 02:27:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Feb 2020 07:27:40 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1580801260.11.0.871767440739.issue39545@roundup.psfhosted.org>


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

Yes, await was recognized only in asynchronous functions. f-strings involve a separate parsing step for subexpressions, and it is not aware that it is in an asynchronous function. Seems the fix was unintentional, but it should documented in any case.

----------

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

From report at bugs.python.org  Tue Feb  4 03:13:06 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 04 Feb 2020 08:13:06 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1580803986.41.0.154616212456.issue10572@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/issue10572>
_______________________________________

From report at bugs.python.org  Tue Feb  4 03:33:52 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Feb 2020 08:33:52 +0000
Subject: [issue37336] os.sendfile() support missing for AIX platform
In-Reply-To: <1560933369.42.0.72033951597.issue37336@roundup.psfhosted.org>
Message-ID: <1580805232.19.0.290303328682.issue37336@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

OK. Couple of months later.

Would appreciate guidance before submitting a patch.

In advance: Thank you for your time and consideration.

Short: socket.sendfile() and AIX send_file() are very close in terms of functionality - especially the requirement that "out_fd" is a non-blocking socket.
os.sendfile() and AIX send_file(), imho, do not match because it appears that os.sendfile(in_fd, out_fd, ...) will work with any kind of open file descriptor.

Longer:
.. method:: socket.sendfile(file, offset=0, count=None)

   Send a file until EOF is reached by using high-performance
   :mod:`os.sendfile` and return the total number of bytes which were sent.
   *file* must be a regular file object opened in binary mode. If
   :mod:`os.sendfile` is not available (e.g. Windows) or *file* is not a
   regular file :meth:`send` will be used instead. 
...
 The socket must be of :const:`SOCK_STREAM` type.
   Non-blocking sockets are not supported.

   .. versionadded:: 3.5

AIX

#include < sys/socket.h >

ssize_t send_file(Socket_p, sf_iobuf, flags)

int * Socket_p;
struct sf_parms * sf_iobuf;
uint_t  flags;
Description

The send_file subroutine sends data from the opened file specified in the sf_iobuf parameter, over the connected socket pointed to by the Socket_p parameter.

Note Currently, the send_file only supports the TCP/IP protocol (SOCK_STREAM socket in AF_INET). An error will be returned when this function is used on any other types of sockets.

**** These match in terms of goals. ****

Considering the requirements of AIX send_file() os.sendfile() does not seem to fit. I read (Doc/library/os.rst) os.sendfile to imply that any
open file descriptors will be "sent" whereas with socket.sendfile - in_fd is binary file, out_fd is a SOCK_STREAM socket descriptor.

So, would like some feedback on how to proceed:

e.g., 
A. a new os.send_file - only available for AIX (and only accessible to socket.sendfile(),
B. os.sendfile  "returns" one of the following when the input parameters are not appropriate:
EBADF 	        Either the socket or the file descriptor parameter is not valid.
ENOTSOCK 	The socket parameter refers to a file, not a socket.

(There are other errno results, not important for the discussion atm).

Again, thank you for your time!

----------

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

From report at bugs.python.org  Tue Feb  4 04:27:07 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 04 Feb 2020 09:27:07 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1580808427.86.0.473262957955.issue31826@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

PR for removing __version__ from mock: https://github.com/python/cpython/pull/17977

----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Tue Feb  4 04:27:22 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 04 Feb 2020 09:27:22 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1580808442.13.0.623061498083.issue31826@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


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

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

From report at bugs.python.org  Tue Feb  4 04:32:47 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 04 Feb 2020 09:32:47 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1580808767.96.0.159407274577.issue31826@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  4 04:42:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 09:42:29 +0000
Subject: [issue2534] Restore isinstance and issubclass speed in 2.6
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1580809349.13.0.456432000728.issue2534@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +barry
nosy_count: 8.0 -> 9.0
pull_requests: +17718
pull_request: https://github.com/python/cpython/pull/18345

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

From report at bugs.python.org  Tue Feb  4 05:08:00 2020
From: report at bugs.python.org (=?utf-8?q?Alexander_B=C3=B6hn?=)
Date: Tue, 04 Feb 2020 10:08:00 +0000
Subject: =?utf-8?q?=5Bissue39549=5D_The_reprlib=2ERepr_type_should_permit_the_?=
 =?utf-8?q?=E2=80=9Cfillvalue=E2=80=9D_to_be_set_by_the_user?=
In-Reply-To: <1580778450.13.0.746492669497.issue39549@roundup.psfhosted.org>
Message-ID: <1580810880.25.0.228697129972.issue39549@roundup.psfhosted.org>


Change by Alexander B?hn <fish2000 at gmail.com>:


----------
components: +Tests

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

From report at bugs.python.org  Tue Feb  4 05:26:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 10:26:35 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580811995.2.0.32857559105.issue39543@roundup.psfhosted.org>


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

There are different problems.

_Py_Dealloc() calls _Py_ForgetReference() and requires access to PyTypeObjects structure fields to call Py_TYPE(op)->tp_dealloc().

_Py_ForgetReference() is a function and so has no issuse with the limited API (it's not a macro nor an inline function).

_Py_NewReference():

* _Py_NewReference() access _Py_tracemalloc_config, _Py_RefTotal and calls _Py_AddToAllObjects()
* PyObject_INIT() and PyObject_INIT_VAR() inline functions call _Py_NewReference()

I'm not sure that it's really more efficient than _Py_NewReference() and _Py_Dealloc() are macros/inline functions. Moreover, it causes issues with the limited API and it leaks many implementation details in the API.

I may be better to convert PyObject_INIT() and PyObject_INIT_VAR() to aliases to public opaque PyObject_Init() and PyObject_InitVar(), and convert _Py_NewReference() and _Py_Dealloc() to opaque functions (from the API point of view).

----------

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

From report at bugs.python.org  Tue Feb  4 05:29:49 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 10:29:49 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1580812189.57.0.277275180571.issue38076@roundup.psfhosted.org>


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


New changeset 4590f72259ecbcea66e12a28af14d867255d2e66 by Eddie Elizondo in branch 'master':
bpo-38076 Clear the interpreter state only after clearing module globals (GH-18039)
https://github.com/python/cpython/commit/4590f72259ecbcea66e12a28af14d867255d2e66


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

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

From report at bugs.python.org  Tue Feb  4 05:53:53 2020
From: report at bugs.python.org (Ben Caller)
Date: Tue, 04 Feb 2020 10:53:53 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1580813633.24.0.415198780191.issue39503@roundup.psfhosted.org>


Ben Caller <bcaller at gmail.com> added the comment:

Isn't this a duplicate of bpo-38826 ?

----------
nosy: +bc

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

From report at bugs.python.org  Tue Feb  4 05:54:36 2020
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Tue, 04 Feb 2020 10:54:36 +0000
Subject: [issue31826] Misleading __version__ attribute of modules in standard
 library
In-Reply-To: <1508505664.08.0.213398074469.issue31826@psf.upfronthosting.co.za>
Message-ID: <1580813676.77.0.454440700569.issue31826@roundup.psfhosted.org>


Change by Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com>:


----------
nosy: +Henk-Jaap Wagenaar

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

From report at bugs.python.org  Tue Feb  4 05:57:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Feb 2020 10:57:15 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1580813835.12.0.580742074498.issue39537@roundup.psfhosted.org>


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

I planned to add a table for end line numbers, so every instruction will be associated with a range of lines.

For example, in

  x = {
    a,
    b
  }

the BUILD_SET instruction will be associated with lines 1-4. Currently it is associated only with line 1, and was associated with line 3 in 3.7.

In

  x = (
    a
    +
    b
  )

the BINARY_ADD instruction will be associated with lines 2-4. Currently it is associated with line 2, and was associated with line 4 in 3.7. The proposition about associating it with line 3 (containing the "+" operator) was rejected before.

In

  x = (
    a
    .
    b
  )

the LOAD_ATTR instruction will be associated with lines 2-4. Currently it is associated with line 2. The AST does not contain information about lines of "." and "b" tokens, but it contains information about the start and the end positions of "a.b".

This will help tools like coverage.py which are confused be executing the same line several times and may allow to generate more informative tracebacks.

As for END_ASYNC_FOR, it will be associated with the range of the "async for" statement.

Maybe we could use more efficient format for encoding start and end line numbers.

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

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

From report at bugs.python.org  Tue Feb  4 06:55:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 04 Feb 2020 11:55:45 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1580817345.32.0.279809823493.issue39545@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  4 07:06:25 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 04 Feb 2020 12:06:25 +0000
Subject: [issue39546] argparse: allow_abbrev=False is ignored for alternative
 prefix characters
In-Reply-To: <1580760688.73.0.980793532046.issue39546@roundup.psfhosted.org>
Message-ID: <1580817985.49.0.693157539842.issue39546@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Good catch, it apprears in my python env(master base) too.

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

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

From report at bugs.python.org  Tue Feb  4 07:15:53 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 04 Feb 2020 12:15:53 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1580818553.22.0.527259178639.issue17239@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  4 07:59:12 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 04 Feb 2020 12:59:12 +0000
Subject: [issue16776] Document PyCFunction_New and PyCFunction_NewEx functions
In-Reply-To: <1356434154.16.0.0981038830976.issue16776@psf.upfronthosting.co.za>
Message-ID: <1580821152.47.0.768313897624.issue16776@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

IMO, PyCFunction* should be a CPython-specific implementation detail: alternate implementations of the C-API don't need to support them, and extension authors should be fine without using them. (And if not, more efforts like PEP 590 Vectorcall should make it so.)

The functions are public in the sense that they don't have underscored names, but I wouldn't rush to make them documented.

----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Tue Feb  4 08:38:11 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 04 Feb 2020 13:38:11 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580823491.37.0.579511884786.issue39479@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  4 09:45:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 14:45:29 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580827529.65.0.584617481347.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17720
pull_request: https://github.com/python/cpython/pull/18346

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

From report at bugs.python.org  Tue Feb  4 09:45:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 14:45:57 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580827557.65.0.358497900619.issue39543@roundup.psfhosted.org>


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

For _Py_NewReference(), I proposed PR 18346 to make it opaque (hide implementation details).

----------

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

From report at bugs.python.org  Tue Feb  4 09:49:45 2020
From: report at bugs.python.org (Rohit Sanjay)
Date: Tue, 04 Feb 2020 14:49:45 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1580827785.42.0.491031625152.issue39545@roundup.psfhosted.org>


Rohit Sanjay <sanjay.rohit2 at gmail.com> added the comment:

Hey, I'd like to work on this issue. Seems like an easy fix. Can you please help me out with where I will need to add the documentation for this?

----------
nosy: +rohitsanjay

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

From report at bugs.python.org  Tue Feb  4 10:00:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 15:00:36 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580828436.53.0.797292041107.issue39543@roundup.psfhosted.org>


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

To declare _Py_Dealloc() as a static inline function in Include/object.h, we need to define the PyTypeObject in object.h which requires tons on other type definitions: PyNumberMethods, PySequenceMethods, etc.

If possible, I would prefer to not move back CPython specific definitions from cpython/object.h to object.h. It would mean to keep the Python 3.8 state: leave _Py_Dealloc() defined as a regular function and close this issue as "won't fix".

----------

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

From report at bugs.python.org  Tue Feb  4 10:04:37 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Feb 2020 15:04:37 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
In-Reply-To: <1580554081.01.0.712736172146.issue39516@roundup.psfhosted.org>
Message-ID: <1580828677.67.0.05101133609.issue39516@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FWIW, this is the sort of thing that is usually best suited to be reported by linters, not the Python runtime.

----------
nosy: +eric.snow

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

From report at bugs.python.org  Tue Feb  4 10:19:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 15:19:11 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580829551.34.0.290243693838.issue39484@roundup.psfhosted.org>


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

> No, int/int is more accurate here.

Should _PyFloat_FromPyTime() implementation be modified to reuse long_true_divide()?

----------

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

From report at bugs.python.org  Tue Feb  4 10:24:38 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 15:24:38 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580829878.32.0.47653934968.issue39432@roundup.psfhosted.org>


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


New changeset 9538bc9185e934bee2bd5ae2cda2b2e92a61906d by Stefan Behnel in branch 'master':
bpo-39432: Implement PEP-489 algorithm for non-ascii "PyInit_*" symbol names in distutils (GH-18150)
https://github.com/python/cpython/commit/9538bc9185e934bee2bd5ae2cda2b2e92a61906d


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

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

From report at bugs.python.org  Tue Feb  4 10:31:25 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 15:31:25 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1580830285.2.0.691646244422.issue37224@roundup.psfhosted.org>


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


New changeset 9a740b6c7e7a88185d79128b8a1993ac387d5091 by Miss Islington (bot) in branch '3.8':
bpo-37224: Improve test__xxsubinterpreters.DestroyTests (GH-18058)
https://github.com/python/cpython/commit/9a740b6c7e7a88185d79128b8a1993ac387d5091


----------

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

From report at bugs.python.org  Tue Feb  4 10:32:52 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Feb 2020 15:32:52 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1580830372.95.0.0436189708142.issue37224@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, Kyle.  That helps at least a little. :)

----------

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

From report at bugs.python.org  Tue Feb  4 10:55:41 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Feb 2020 15:55:41 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580680381.65.0.617291134859.issue39511@roundup.psfhosted.org>
Message-ID: <CALFfu7ABKdc2NBqsMR9GMbiwKO7pHmcZFq=8gOaRiLjEW-fODg@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Sun, Feb 2, 2020 at 2:53 PM Raymond Hettinger <report at bugs.python.org> wrote:
> Is the sub-interpreter PEP approved?

PEP 554 is not approved yet (and certainly is not guaranteed, though
I'm hopeful).  However, that PEP is exclusively about exposing
subinterpreters in the stdlib.

There is no PEP for the effort to isolate subinterpreters and stop
sharing the GIL between them.  We are not planning on having such a
PEP since the actual proposal is so basic ("make the GIL
per-interpreter") and there has been no controversy.

I need to do a better job about communicating the difference, as folks
keep conflating PEP 554 with the effort to stop sharing the GIL
between subinterpreters.  Note that both are part of my "multi-core
Python" project. [1]

> If not, I had thought the plan was to only
> implement PRs that made clean-ups that would have been necessary anyway.

Right.  In this case the "cleanup" is how singletons are finalized
when the runtime shuts down.  This has a material impact on projects
that embed the CPython runtime.  Currently runtime finalization is a
mess.

That said, making the singletons per-interpreter isn't a prerequisite
of that cleanup.  For specific case of the per-interpreter GIL world,
we just need an approach that addresses their life cycle in a
thread-safe way.

[1] https://github.com/ericsnowcurrently/multi-core-python

----------

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

From report at bugs.python.org  Tue Feb  4 11:24:50 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Feb 2020 16:24:50 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580682733.44.0.917064169701.issue39511@roundup.psfhosted.org>
Message-ID: <CALFfu7AJ9sdX1YcEVL6BO7NGgS9u87cfy-rEK+s0PsLR4AR1Jg@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Sun, Feb 2, 2020 at 3:32 PM Raymond Hettinger <report at bugs.python.org> wrote:
> Random idea (not carefully thought-out):  Would it be simpler to have these objects just
> ignore their refcount by having dealloc() be a null operation or having it set the refcount
> back to a positive number).  That would let sub-interpreters share the objects without
> worrying about race-conditions on incref/decref operations.

This is pretty much one of the two approaches I have been considering. :)

Just to be clear, singletons normally won't end up with a refcount of
0, by design.  However, if there's a incref race between two
interpreters (that don't share a GIL) then you *can* end up triggering
dealloc (via Py_DECREF) and even get negative refcounts (which cause
Py_FatalError() on debug builds).  Here are some mitigations:

* (as noted above) make dealloc() for singletons a noop
* (as noted above) in dealloc() set the refcount back to some positive value
* make the initial refcount sufficiently large such that it is
unlikely to reach 0 even with races
* incref each singleton once during each interpreter initiialization
(and decref once during interp. finalization)

We would have to special-case refleak checks for singletons, to avoid
false positives.

Also note that currently extension authors (and CPython contributors)
can rely on the runtime to identify when then accidentally
incref/decref a singleton too much (or forget to do so).  So it may
make sense to do something in the "singleton dealloc()" in debug
builds to provide similar checks.

>  To make this work, the objects can register themselves as permanent, shared, objects;
> then, during shutdown, we could explicitly call a hard dealloc on those objects.

great point

----------

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

From report at bugs.python.org  Tue Feb  4 11:27:22 2020
From: report at bugs.python.org (Eric Snow)
Date: Tue, 04 Feb 2020 16:27:22 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <CALFfu7AJ9sdX1YcEVL6BO7NGgS9u87cfy-rEK+s0PsLR4AR1Jg@mail.gmail.com>
Message-ID: <CALFfu7CjuV64rbjkX=bRoJga_kgjoJGFA9GWhageWAgdRjZJLg@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> This is pretty much one of the two approaches I have been considering.

The other approach is to leave the current static singletons alone and
only use them for the main interpreter.  Each subinterpreter would get
its own copy, created when that interpreter is initialized.

----------

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

From report at bugs.python.org  Tue Feb  4 11:34:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 04 Feb 2020 16:34:02 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1580834042.11.0.257247533203.issue34788@roundup.psfhosted.org>


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

Nick, can you comment on this and review the revised PR?

----------
nosy: +ncoghlan
versions:  -Python 2.7

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

From report at bugs.python.org  Tue Feb  4 12:06:33 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Tue, 04 Feb 2020 17:06:33 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1580835993.42.0.51774565087.issue39384@roundup.psfhosted.org>


Mark Sapiro <mark at msapiro.net> added the comment:

Other Mailman3 installations are also encountering this issue. See https://lists.mailman3.org/archives/list/mailman-users at mailman3.org/message/VQZORIDL5PNQ4W33KIMVTFTANSGZD46S/

----------

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

From report at bugs.python.org  Tue Feb  4 12:58:59 2020
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Feb 2020 17:58:59 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1580839139.35.0.218054051677.issue39384@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

If we can get an actual reproducer using message_as_bytes I'd feel more comfortable with the fix.  I worry that there is some other bug this is exposing that should be fixed instead.

----------

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

From report at bugs.python.org  Tue Feb  4 12:59:26 2020
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Feb 2020 17:59:26 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1580839166.17.0.87819399195.issue39384@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

message_from_bytes

----------

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

From report at bugs.python.org  Tue Feb  4 13:30:00 2020
From: report at bugs.python.org (Joachim Jablon)
Date: Tue, 04 Feb 2020 18:30:00 +0000
Subject: [issue39550] isinstance accepts subtypes of tuples as second argument
Message-ID: <1580841000.84.0.0928756449377.issue39550@roundup.psfhosted.org>


New submission from Joachim Jablon <ewjoachim at gmail.com>:

(Not really sure it is a bug, but better informed people might find it worthy still)

isinstance can accept, as second argument, a type or a potentially nested tuple of types. Only tuples are accepted, as opposed to generic iterables. The reasoning behind using a tuple was recently added through a small refactoring from Victor Stinner:
https://github.com/python/cpython/commit/850a4bd839ca11b59439e21dda2a3ebe917a9a16
The idea being that it's impossible to make a self referencing tuple nest, and thus the function, which is recursive, doesn't have to deal with infinite recursion.

It's possible to use a tuple subclass, though, and while it doesn't break the function because it reads , the tuple is not explored through the __iter__ interface:

>>> class T(tuple):
...     def __iter__(self):
...             yield self
... 
>>> isinstance(3, T())
False

This is the expected result if checking what the tuple contains, but not if iterating the tuple. For me, there's nothing absolutely wrong with the current behaviour, but it feels like we're walking on a fine line, and if for any reason, the isinstance tuple iteration were to start using __iter__ in the future, this example may crash. Solutions could be handling any iterable but explicitely checking for recursion or, as suggested by Victor Stinner, forbidding subclasses of tuple.

Guido van Rossum suggested opening an issue so here it is.

A link to the discussion that prompted this:
https://twitter.com/VictorStinner/status/1224744606421655554

----------
messages: 361362
nosy: ewjoachim
priority: normal
severity: normal
status: open
title: isinstance accepts subtypes of tuples as second argument
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Feb  4 13:41:33 2020
From: report at bugs.python.org (Anselmo Melo)
Date: Tue, 04 Feb 2020 18:41:33 +0000
Subject: [issue38826] Regular Expression Denial of Service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1573955142.95.0.285133152076.issue38826@roundup.psfhosted.org>
Message-ID: <1580841693.86.0.866180186156.issue38826@roundup.psfhosted.org>


Change by Anselmo Melo <anselmo.melo at intel.com>:


----------
nosy: +Anselmo Melo

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

From report at bugs.python.org  Tue Feb  4 13:59:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 04 Feb 2020 18:59:21 +0000
Subject: [issue39550] isinstance accepts subtypes of tuples as second argument
In-Reply-To: <1580841000.84.0.0928756449377.issue39550@roundup.psfhosted.org>
Message-ID: <1580842761.74.0.96448535404.issue39550@roundup.psfhosted.org>


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

I do not understand what the problem is.

If the isinstance tuple iteration were to start using __iter__ in the future, it should start to handle all corner cases. But what is wrong now?

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

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

From report at bugs.python.org  Tue Feb  4 14:49:31 2020
From: report at bugs.python.org (Marco Sulla)
Date: Tue, 04 Feb 2020 19:49:31 +0000
Subject: [issue39516] ++ does not throw a SyntaxError
In-Reply-To: <1580554081.01.0.712736172146.issue39516@roundup.psfhosted.org>
Message-ID: <1580845771.03.0.800905781638.issue39516@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> this is the sort of thing that is usually best suited to be reported by linters, not the Python runtime.

TL;DR: if you write something like `a -- b`, it's quite extraordinary that you really wanted to write this. You probably wanted to write `a - -b` or, more probably, `a -= b`. So the parser is **masking a potential subtle bug**, that can cause hours of stressing debugging, because probably the program will run without problem but gives you a wrong result, or will throw an exception but in a completely different point.

Long version:

Normally I agree, but not in this case.

PEP 8 defines line guides for writing a more readable code. They are not mandatory because:

1. there are cases in which is more readable if you not follow PEP 8 (for example, using `\` with long `with` statements)
2. there are cases in which the rule is not followed because of using it in fast tests (as for from module import *)
3. sometimes is simply not possible to follow PEP 8 (for example, many classes can easily implement __eq__, but implementing all the other comparison operators many times is simply not possible)
4. sometimes the recommendation can't be followed, because it's not what you want to achive (for example, sometimes you need to check the exact class of an object and use `type(a) == SomeClass` instead of `isinstance(a, SomeClass)`)
5. there are cases that PEP 8 does not work. For example, bool(numpy.ndarray) does not work, you must do len(numpy.ndarray)
6. sometimes, it's simply a matter of style. One prefers a style, another one prefer another style

That said, none of these valid border cases can be applied to this case:

1. `a+-b` can be NEVER more readable than `a + -b`
2. `a++b` is clearly faster because you have to write... 2 spaces less. Well, I think that you'll never write a ton of binary operators followed by a unary one, so I suppose two little blank spaces does not slow down you too much :-D
3. it's always possible to separate `a * -b`, for example
4. if you write something like `a -- b`, it's quite extraordinary that you really wanted to write this. You probably wanted to write `a - -b` or, more probably, `a -= b`. So the parser is **masking a potential subtle bug**, that can cause hours of stressing debugging, because probably the program will run without problem but gives you a wrong result, or will throw an exception but in a completely different point.
5. See 3
6. this is IMHO not a matter of style. Writing `a ++ b` is simply ugly, **much** unreadable and prone to errors.

----------

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

From report at bugs.python.org  Tue Feb  4 14:49:31 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 04 Feb 2020 19:49:31 +0000
Subject: [issue39550] isinstance accepts subtypes of tuples as second argument
In-Reply-To: <1580841000.84.0.0928756449377.issue39550@roundup.psfhosted.org>
Message-ID: <1580845771.64.0.511087474562.issue39550@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Serhiy: I think at least a test for this particular corner case should be added, so that no implementations of `isinstance` that use the CPython test suite hit an infinite recursion in that event, I guess?

Though I think it's maybe an open question as to what the correct behavior is. Should we throw on any tuple subclass because there's no reason to support tuple subclasses? Should we switch to using __iter__ when it's defined because there are other cases where the custom behavior of the subclass is defined by its __iter__? Should we make it a guarantee that __iter__ is *never* called?

I can't really think of a reason why defining __iter__ on a tuple subclass would be anything other than a weird hack, so I would probably say either ban tuple subclasses or add a test like so:

def testIsinstanceIterNeverCalled(self):
    """Guarantee that __iter__ is never called when isinstance is invoked"""
    class NoIterTuple(tuple):
        def __iter__(self):  # pragma: nocover
            raise NotImplemented("Cannot call __iter__ on this.")

    self.assertTrue(isinstance(1, NoIterTuple((int,))))

----------
nosy: +p-ganssle

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

From report at bugs.python.org  Tue Feb  4 15:27:49 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 04 Feb 2020 20:27:49 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
Message-ID: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>


New submission from Dino Viehland <dinoviehland at gmail.com>:

The fix for bpo-17636 added support for falling back to sys.modules when a module isn't directly present on the module.  But mock doesn't have the same behavior - it'll try the import, and then try to get the value off the object.  If it's not there it just errors out.

Instead it should also consult sys.modules to be consistent with import semantics.

----------
assignee: dino.viehland
components: Tests
messages: 361366
nosy: dino.viehland
priority: normal
severity: normal
stage: needs patch
status: open
title: mock patch should match behavior of import from when module isn't present in sys.modules
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Feb  4 15:36:01 2020
From: report at bugs.python.org (Mikko Korkalo)
Date: Tue, 04 Feb 2020 20:36:01 +0000
Subject: [issue29707] os.path.ismount() always returns false for mount --bind
 on same filesystem
In-Reply-To: <1488524974.65.0.103028894103.issue29707@psf.upfronthosting.co.za>
Message-ID: <1580848561.14.0.609247194731.issue29707@roundup.psfhosted.org>


Mikko Korkalo <mikko.korkalo at gmail.com> added the comment:

I disagree about whether this should be fixed or not.
It's definitely a bug. If you ask whether a bind mount destination is a mount, it should return true.

I wrote a logic that does bind mounting. The logic cannot use ismount() because it does not work for me, it would keep remounting the same bind mount.

Not fixing this just causes people to write even less portable hackery on their own. I have to parse /proc/mounts or something manually, which obviously should be the job of ismount().
Python has a lot of platform-specific underlying implementations anyway.

----------
nosy: +Mikko Korkalo

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

From report at bugs.python.org  Tue Feb  4 15:36:51 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 04 Feb 2020 20:36:51 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1580848611.83.0.119571935811.issue39551@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  4 15:36:51 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 04 Feb 2020 20:36:51 +0000
Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules
In-Reply-To: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za>
Message-ID: <1580848611.97.0.0840486464002.issue17636@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
pull_requests: +17722
pull_request: https://github.com/python/cpython/pull/18347

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

From report at bugs.python.org  Tue Feb  4 16:15:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 21:15:35 +0000
Subject: [issue39550] isinstance accepts subtypes of tuples as second argument
In-Reply-To: <1580841000.84.0.0928756449377.issue39550@roundup.psfhosted.org>
Message-ID: <1580850935.27.0.538154146967.issue39550@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Tue Feb  4 16:16:29 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 04 Feb 2020 21:16:29 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1580850989.47.0.320884476676.issue39551@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

What's the real world use case for this?

----------
nosy: +cjw296

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

From report at bugs.python.org  Tue Feb  4 16:25:25 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 04 Feb 2020 21:25:25 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580851525.48.0.775787668243.issue39510@roundup.psfhosted.org>


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


New changeset cb1c0746f277052e45a60d6c436a765e34722821 by Philipp Gesang in branch 'master':
closes bpo-39510: Fix use-after-free in BufferedReader.readinto() (GH-18295)
https://github.com/python/cpython/commit/cb1c0746f277052e45a60d6c436a765e34722821


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

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

From report at bugs.python.org  Tue Feb  4 16:25:42 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 21:25:42 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580851542.69.0.0870903286175.issue39510@roundup.psfhosted.org>


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


----------
pull_requests: +17723
pull_request: https://github.com/python/cpython/pull/18348

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

From report at bugs.python.org  Tue Feb  4 16:25:49 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 21:25:49 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580851549.84.0.695409851458.issue39510@roundup.psfhosted.org>


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


----------
pull_requests: +17724
pull_request: https://github.com/python/cpython/pull/18349

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

From report at bugs.python.org  Tue Feb  4 16:25:57 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 21:25:57 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580851557.28.0.282201444845.issue39510@roundup.psfhosted.org>


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


----------
pull_requests: +17725
pull_request: https://github.com/python/cpython/pull/18350

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

From report at bugs.python.org  Tue Feb  4 16:31:16 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 04 Feb 2020 21:31:16 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1580851876.0.0.537173384826.issue39551@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

It's related to bpo-39336.  If you have an immutable package which doesn't allow it's children to be published on it when following the chain of packages it ends up not arriving at the final module.

But you can also hit it if you end up doing the patch during a relative import, although that seems much less likely.  But it generally seems matching the behavior of imports would be good to me.

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

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

From report at bugs.python.org  Tue Feb  4 16:31:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 21:31:43 +0000
Subject: [issue39550] isinstance accepts subtypes of tuples as second argument
In-Reply-To: <1580841000.84.0.0928756449377.issue39550@roundup.psfhosted.org>
Message-ID: <1580851903.5.0.923043006119.issue39550@roundup.psfhosted.org>


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

Joachim:
> It's possible to use a tuple subclass, though, and while it doesn't break the function because it reads , the tuple is not explored through the __iter__ interface: (...)

I don't think that the example from the first message is an issue in isinstance(). Defining __iter__() does not override __getitem__() nor __len__():
---
class T(tuple):
    def __iter__(self):
        print("__iter__")
        yield self

inst = T(("a", "b"))
print(len(inst))
print(inst[0])
print(inst[1])
---

Output:
---
2
a
b
---

But isinstance() doesn't call overriden __getitem__() and __len__() methods, only tuple.__getitem__() and tuple.__len__() original methods.


Joachim:
>  Solutions could be handling any iterable but explicitely checking for recursion or, as suggested by Victor Stinner, forbidding subclasses of tuple.

isinstance() should use PyTuple_CheckExact(): only accept the exact tuple type, and reject any other type.

We can start by deprecating tuple subclasses in Python 3.9.


Paul:
> Should we switch to using __iter__ when it's defined because there are other cases where the custom behavior of the subclass is defined by its __iter__?

I just restored an old comment from Guido van Rossum which was lost in a previous refactoring, commit 850a4bd839ca11b59439e21dda2a3ebe917a9a16:

    if (PyTuple_Check(cls)) {
        /* Not a general sequence -- that opens up the road to
           recursion and stack overflow. */
       ...
    }

--

By the way, nested tuples are accepted:

>>> isinstance(1, ((((int,),),),))
True

I am -0 on nested tuples. The implementation is not so crazy (simple recursive code), so it is maybe ok to keep it.

----------
Added file: https://bugs.python.org/file48884/isinstance_iter.py

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

From report at bugs.python.org  Tue Feb  4 16:42:01 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 21:42:01 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580852521.99.0.889860187124.issue39510@roundup.psfhosted.org>


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


New changeset 30e769382dfb67a68fe8e6bfe8509addb4aa9514 by Miss Islington (bot) in branch '3.8':
closes bpo-39510: Fix use-after-free in BufferedReader.readinto() (GH-18295)
https://github.com/python/cpython/commit/30e769382dfb67a68fe8e6bfe8509addb4aa9514


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

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

From report at bugs.python.org  Tue Feb  4 16:43:11 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Feb 2020 21:43:11 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580852591.43.0.921947590614.issue39510@roundup.psfhosted.org>


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


New changeset 97d2a9832494e4c85da124ceab18802eed9a4ab1 by Miss Islington (bot) in branch '3.7':
closes bpo-39510: Fix use-after-free in BufferedReader.readinto() (GH-18295)
https://github.com/python/cpython/commit/97d2a9832494e4c85da124ceab18802eed9a4ab1


----------

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

From report at bugs.python.org  Tue Feb  4 16:44:44 2020
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 04 Feb 2020 21:44:44 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1580852684.57.0.154536466096.issue38628@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Is this a legal use of Python ctypes?  I don't see anything in the Python documentation that one can call a ctypes function with an argument list that does not match the function signature and expect it to work.  Maybe this works on x86 by accident, but that doesn't mean that it is guaranteed to work everywhere and is permitted.

----------

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

From report at bugs.python.org  Tue Feb  4 16:49:06 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 04 Feb 2020 21:49:06 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1580852946.83.0.300442248692.issue39551@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/issue39551>
_______________________________________

From report at bugs.python.org  Tue Feb  4 17:06:49 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 04 Feb 2020 22:06:49 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580854009.86.0.913830477287.issue39510@roundup.psfhosted.org>


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


New changeset c352e6c7446c894b13643f538db312092b351789 by Miss Islington (bot) in branch '3.6':
closes bpo-39510: Fix use-after-free in BufferedReader.readinto() (GH-18350)
https://github.com/python/cpython/commit/c352e6c7446c894b13643f538db312092b351789


----------

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

From report at bugs.python.org  Tue Feb  4 17:12:03 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 04 Feb 2020 22:12:03 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1580854323.92.0.0897649818459.issue39551@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

I'm afraid I don't understand "immutable package which doesn't allow it's children to be published on it", can you give an example?

----------

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

From report at bugs.python.org  Tue Feb  4 17:42:23 2020
From: report at bugs.python.org (Frazer Clews)
Date: Tue, 04 Feb 2020 22:42:23 +0000
Subject: [issue39552] shell scripts use legacy
Message-ID: <1580856143.95.0.631656009872.issue39552@roundup.psfhosted.org>


Change by Frazer Clews <frazerleslieclews at gmail.com>:


----------
components: Installation
nosy: frazerclews
priority: normal
severity: normal
status: open
title: shell scripts use legacy
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Feb  4 18:01:15 2020
From: report at bugs.python.org (Frazer Clews)
Date: Tue, 04 Feb 2020 23:01:15 +0000
Subject: [issue39552] shell scripts use legacy
Message-ID: <1580857275.67.0.229500293766.issue39552@roundup.psfhosted.org>


Change by Frazer Clews <frazerleslieclews at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  4 18:10:23 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 04 Feb 2020 23:10:23 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1580857823.02.0.691386806641.issue39551@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

My actual scenario involves a custom module loader where the modules are published are completely immutable (it ends up publishing an object which isn't a subtype of module).  It can still have normal Python modules as a child which aren't immutable, so they could still be patched by Mock (or it could have immutable sub-packages which Mock wouldn't be able to patch).  

So imagine something like this:

immutable_package\__init__.py
__immutable__ = True
x = 2

immutable_package\x.py
y = 2


Doing a "from immutable_package import x" would normally publish "x" as a child onto the package.  But because the package is immutable, this is impossible, and the assignment is ignored with a warning.  

When Mock gets a call to patch on something like "immutable_package.x.y", it's not going to find x, even though if I were to write "from immutable_package.x import y" or "from immutable_package import x" it would succeed.

Cases can be contrived without all of this though where the child isn't published on it's parent, but it requires 

x/__init__.py
from x.pkg import child

x/pkg/__init__.py:
x = 1


x/pkg/child.py:
from unittest.mock import patch
y = 42

@patch('x.pkg.child.y', 100)
def f():
    print(y)

f()

"python -m x" will fail without the patch but succeed with it.

----------

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

From report at bugs.python.org  Tue Feb  4 18:32:21 2020
From: report at bugs.python.org (Sam Clegg)
Date: Tue, 04 Feb 2020 23:32:21 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1580859141.53.0.951327365639.issue34841@roundup.psfhosted.org>


Sam Clegg <sbc at chromium.org> added the comment:

We just ran into the same issue trying to use this zip as part of the emscripten SDK (https://github.com/emscripten-core/emsdk/pull/349).  Seems like a fairly fundamental problem with the windows embeddable zip file.

Is there any downside to simply removing the .pth file?  It seems to have the desired effect.

----------
nosy: +Sam Clegg

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

From report at bugs.python.org  Tue Feb  4 18:35:39 2020
From: report at bugs.python.org (Sam Clegg)
Date: Tue, 04 Feb 2020 23:35:39 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1580859339.57.0.564101472801.issue34841@roundup.psfhosted.org>


Change by Sam Clegg <sbc at chromium.org>:


----------
components: +Installation

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

From report at bugs.python.org  Tue Feb  4 18:49:08 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 04 Feb 2020 23:49:08 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1580860148.8.0.484378952556.issue34841@roundup.psfhosted.org>


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

This is intentional. When embedding the Python runtime, you should limit the import directories to those you want to allow - we do not infer *any* from how it is started, due to the security risks.

Modifying the ._pth file after you extract the distro and before you redistribute your own installer is encouraged, especially if you aren't using an "everything in one directory" layout for your application.

If that statement doesn't sound like it applies to you, then you probably want the regular installer and not the embeddable package. It is *not* meant to be a "portable" distribution.

----------
nosy: +steve.dower
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  4 18:59:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Feb 2020 23:59:24 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580860764.33.0.449692974696.issue39511@roundup.psfhosted.org>


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

> The other approach is to leave the current static singletons alone and
> only use them for the main interpreter.  Each subinterpreter would get
> its own copy, created when that interpreter is initialized.

Which API should be used in C extensions to be "subinterpreter-safe"? Currently, Py_None is a singleton shared by multiple interpreters. Should suddenly all C extensions use a new Py_GetNone() function which returns the per-interpreter singleton? If yes, that's basically what my PR 18301 does:

   #define Py_None Py_GetNone()

----------

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

From report at bugs.python.org  Tue Feb  4 19:00:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:00:03 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1580860803.37.0.0950579923668.issue8901@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/issue8901>
_______________________________________

From report at bugs.python.org  Tue Feb  4 19:04:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:04:34 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1580861074.78.0.703087548905.issue39279@roundup.psfhosted.org>


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

Without a source stating that version numbers will only ever contain ASCII digits (or a real-world counterexample), I see no reason to make a change here.

Thanks for working on this, Ram!

----------
nosy: +steve.dower
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Feb  4 19:08:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 00:08:01 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580861281.94.0.530200047971.issue39511@roundup.psfhosted.org>


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

> (as noted above) make dealloc() for singletons a noop

I expect issues with negative reference count value. As you wrote, it triggers a fatal error when Python is built in release mode.


> make the initial refcount sufficiently large such that it is
unlikely to reach 0 even with races

Py_None is heavily used. If the reference count is updated by multiple threads with no lock to protect it, there is a significant risk that value zero will be reached soon or later.

--

In the Linux kernel, they started to special type for reference counters, to reduce the risk of vulnerability on reference counter underflow or overflow:

* "reference-count protection" for kernel hardening: refcount_t type
* https://lwn.net/Articles/728675/
* https://lwn.net/Articles/706498/

The kernel already used atomic_t type. But the issue here is about bugs, since no program is perfect, even the Linux kernel.

----------

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

From report at bugs.python.org  Tue Feb  4 19:08:07 2020
From: report at bugs.python.org (Sam Clegg)
Date: Wed, 05 Feb 2020 00:08:07 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1580861287.71.0.443453397987.issue34841@roundup.psfhosted.org>


Sam Clegg <sbc at chromium.org> added the comment:

In our case we ended up stripping the .pth file and distributing that modified .zip files.

I guess the main problem here is that its really not clear that this version of python doesn't work like the others, or needs to be modified before use.   It can be very confusing to try to debug the resulting error message which for me was:

```
C:\Users\circleci\project\python\3.7.4_64bit\python.exe
Traceback (most recent call last):
  File "C:\Users\circleci\project\upstream\emscripten\\emcc", line 6, in <module>
    from tools import python_selector
ModuleNotFoundError: No module named 'tools'
```

For us we really want a non-interactive installation so a zip file made sense.   We are embeddeding python within another SDK so it sounds like it is applicable.

Maybe this is documented somewhere and I just missed it, but its certainly was a confusing difference from other distributions of python.   

What about adding some kind of startup message such as "This version of python requires local modification before using"?

Also, I'm curious about the kind of security risk there is in including the script directory in sys.path?   If an attacker had access to the script directory couldn't they just modify the script directly?

----------

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

From report at bugs.python.org  Tue Feb  4 19:08:02 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:08:02 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580158688.69.0.521881077968.issue39469@roundup.psfhosted.org>
Message-ID: <1580861282.19.0.463352908384.issue39469@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/issue39469>
_______________________________________

From report at bugs.python.org  Tue Feb  4 19:11:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 00:11:14 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580861474.12.0.964239576276.issue39542@roundup.psfhosted.org>


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


New changeset 40e547dfbb9052ca0c667b242f6825ed1c23c195 by Victor Stinner in branch 'master':
bpo-39542: Make _Py_NewReference() opaque in C API (GH-18346)
https://github.com/python/cpython/commit/40e547dfbb9052ca0c667b242f6825ed1c23c195


----------

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

From report at bugs.python.org  Tue Feb  4 19:15:09 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:15:09 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1580861709.72.0.639218829511.issue39184@roundup.psfhosted.org>


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


New changeset 95f60010219e142a436fae18e1695cbc45407afe by Saiyang Gou in branch 'master':
bpo-39184: Add audit events to command execution functions in os and pty modules (GH-17824)
https://github.com/python/cpython/commit/95f60010219e142a436fae18e1695cbc45407afe


----------

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

From report at bugs.python.org  Tue Feb  4 19:15:39 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 00:15:39 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1580861739.5.0.439286266855.issue39184@roundup.psfhosted.org>


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


----------
pull_requests: +17728
pull_request: https://github.com/python/cpython/pull/18353

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

From report at bugs.python.org  Tue Feb  4 19:18:19 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:18:19 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1580861899.64.0.814719009284.issue39184@roundup.psfhosted.org>


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

Thanks for the spawn patch, I've merged it.

On the second list, I'd say go for it. The only one I'd skip are the stat() calls (and those that just do a stat call, such as exists/isfile, etc.), and getcwd() (which has many other ways to implicitly use the information). Maybe skip getenv as well, but modifying the environment is worth collecting.

----------

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

From report at bugs.python.org  Tue Feb  4 19:20:20 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 05 Feb 2020 00:20:20 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1580862020.96.0.0349402737371.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Thanks, Kyle.  That helps at least a little. :)

No problem. (:

I'll certainly spend some additional time investigating the main issue when I have the chance to, but in the meantime that test change should make it slightly easier to determine the point of failure.

----------

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

From report at bugs.python.org  Tue Feb  4 19:26:05 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:26:05 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1580862365.03.0.910358978777.issue34841@roundup.psfhosted.org>


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

The install page (https://docs.python.org/3/using/windows.html - linked from the download page) covers non-interactive installs, as well as describing the embeddable distro in detail (https://docs.python.org/3/using/windows.html#windows-embeddable). It sounds like you may be in the right category, but you may also prefer the nuget.org package (https://docs.python.org/3/using/windows.html#windows-nuget), which is intended for arbitrary execution on CI systems rather than constrained execution within another application.

The security concerns are an attacker gaining access to a new machine that they know very little about and searching for a "python.exe" they can use to run their tools. Sure, they can modify their initial script to modify sys.path before trying to import anything, but that's not always possible, so we cut off a number of easy-moderate attacks (and many trivial attacks) by not allowing unanticipated script bundles to be executed.

----------

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

From report at bugs.python.org  Tue Feb  4 19:30:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:30:24 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1580862624.52.0.314526542821.issue39185@roundup.psfhosted.org>


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


New changeset 89ae20b30e4543f379ee647c965eb46200556496 by Anthony Shaw in branch 'master':
bpo-39185 Add the d[etailed] and q[uiet] verbosity levels for msbuild (GH-17791)
https://github.com/python/cpython/commit/89ae20b30e4543f379ee647c965eb46200556496


----------

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

From report at bugs.python.org  Tue Feb  4 19:30:33 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 00:30:33 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1580862633.9.0.448213741837.issue39185@roundup.psfhosted.org>


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


----------
pull_requests: +17729
pull_request: https://github.com/python/cpython/pull/18354

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

From report at bugs.python.org  Tue Feb  4 19:30:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 00:30:53 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1580862653.59.0.566966527392.issue39185@roundup.psfhosted.org>


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


----------
pull_requests: +17730
pull_request: https://github.com/python/cpython/pull/18355

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

From report at bugs.python.org  Tue Feb  4 19:31:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:31:34 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1580862694.36.0.464071686464.issue39185@roundup.psfhosted.org>


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

Thanks! Nice change

----------
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/issue39185>
_______________________________________

From report at bugs.python.org  Tue Feb  4 19:32:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 00:32:36 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1580862756.64.0.363359415213.issue39184@roundup.psfhosted.org>


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


New changeset 3498ac55bcfc18d698ea605424ec65a6e1457a39 by Miss Islington (bot) in branch '3.8':
bpo-39184: Add audit events to command execution functions in os and pty modules (GH-17824)
https://github.com/python/cpython/commit/3498ac55bcfc18d698ea605424ec65a6e1457a39


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

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

From report at bugs.python.org  Tue Feb  4 19:41:19 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:41:19 +0000
Subject: [issue38439] Python needs higher resolution app/menu icons
In-Reply-To: <1570749295.67.0.980962290264.issue38439@roundup.psfhosted.org>
Message-ID: <1580863279.63.0.918280356344.issue38439@roundup.psfhosted.org>


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

Copying my comment from the PR:

Could someone with the SVG also create 44x44 and 150x150 sized versions? (Like the pythonx44.png and pythonx150.png files in PC/icons.)

These are the sizes used for the tiles created by the Microsoft Store installer, and referenced from PC\layout\support\appxmanifest.py (search for pythonwx to find the current IDLE and pythonw references).

----------
nosy: +steve.dower

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

From report at bugs.python.org  Tue Feb  4 19:45:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:45:13 +0000
Subject: [issue39553] Delete HAVE_SXS protected code
Message-ID: <1580863513.73.0.140072621675.issue39553@roundup.psfhosted.org>


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

We no longer support SXS manifests, so rather than fixing issue37025 in master, let's just delete the code covered by HAVE_SXS completely.

----------
components: Windows
keywords: easy (C)
messages: 361393
nosy: ZackerySpytz, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Delete HAVE_SXS protected code
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue Feb  4 19:45:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 00:45:34 +0000
Subject: [issue37025] Misleading error message "Python failed to load the
 default activation context"
In-Reply-To: <1558646019.4.0.18611977167.issue37025@roundup.psfhosted.org>
Message-ID: <1580863534.07.0.594449254411.issue37025@roundup.psfhosted.org>


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

Fixed in 2.7 - using issue39553 for removing the code in master.

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

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

From report at bugs.python.org  Tue Feb  4 19:47:22 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 00:47:22 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1580863642.38.0.316457861433.issue39185@roundup.psfhosted.org>


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


New changeset 6ba8dc6aae6fa0a7e29ba4ac18227beb38872392 by Miss Islington (bot) in branch '3.7':
bpo-39185 Add the d[etailed] and q[uiet] verbosity levels for msbuild (GH-17791)
https://github.com/python/cpython/commit/6ba8dc6aae6fa0a7e29ba4ac18227beb38872392


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

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

From report at bugs.python.org  Tue Feb  4 19:48:05 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 00:48:05 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1580863685.61.0.940751742037.issue39185@roundup.psfhosted.org>


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


New changeset 6470a7643018b357adcd88f77ae2a196f41cb351 by Miss Islington (bot) in branch '3.8':
bpo-39185 Add the d[etailed] and q[uiet] verbosity levels for msbuild (GH-17791)
https://github.com/python/cpython/commit/6470a7643018b357adcd88f77ae2a196f41cb351


----------

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

From report at bugs.python.org  Tue Feb  4 19:59:18 2020
From: report at bugs.python.org (Sam Clegg)
Date: Wed, 05 Feb 2020 00:59:18 +0000
Subject: =?utf-8?q?=5Bissue34841=5D_Script=E2=80=99s_directory_not_in_sys=2Epath_w?=
 =?utf-8?q?ith_embeddable_Windows_distribution?=
In-Reply-To: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>
Message-ID: <1580864358.87.0.0665180774268.issue34841@roundup.psfhosted.org>


Sam Clegg <sbc at chromium.org> added the comment:

Thanks for the info.  If we run into any more difficulties I'll look into nuget.  I should indeed have read the docs more closely.  Apologies.

----------

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

From report at bugs.python.org  Tue Feb  4 20:10:31 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Feb 2020 01:10:31 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
Message-ID: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>


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


New changeset cf5b109dbb39bcff1bc5b5d22036866d11de971b by Jakub Stasiak in branch 'master':
bpo-39491: Merge PEP 593 (typing.Annotated) support (#18260)
https://github.com/python/cpython/commit/cf5b109dbb39bcff1bc5b5d22036866d11de971b


----------

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

From report at bugs.python.org  Tue Feb  4 21:52:29 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 05 Feb 2020 02:52:29 +0000
Subject: [issue39553] Delete HAVE_SXS protected code
In-Reply-To: <1580863513.73.0.140072621675.issue39553@roundup.psfhosted.org>
Message-ID: <1580871149.92.0.785887786726.issue39553@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  4 21:53:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 02:53:11 +0000
Subject: [issue33698] `._pth` does not allow to populate `sys.path` with empty
 entry
In-Reply-To: <1527700361.05.0.682650639539.issue33698@psf.upfronthosting.co.za>
Message-ID: <1580871191.26.0.230084728008.issue33698@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  4 21:53:55 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 02:53:55 +0000
Subject: [issue28901] Windows: document that site is not imported by default
 by embeddable distribution
In-Reply-To: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>
Message-ID: <1580871235.86.0.987780432372.issue28901@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Feb  4 21:55:59 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 05 Feb 2020 02:55:59 +0000
Subject: [issue39553] Delete HAVE_SXS protected code
In-Reply-To: <1580863513.73.0.140072621675.issue39553@roundup.psfhosted.org>
Message-ID: <1580871359.77.0.219670911138.issue39553@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I had worked on bpo-37025, so I have submitted a patch for this issue.  Please consider taking a look.

----------

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

From report at bugs.python.org  Tue Feb  4 21:58:15 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 05 Feb 2020 02:58:15 +0000
Subject: [issue38506] Launcher for Windows (py.exe) may rank Python 3.xx (in
 the future) after 3.x
In-Reply-To: <1571322664.68.0.257867788049.issue38506@roundup.psfhosted.org>
Message-ID: <1580871495.69.0.77692044682.issue38506@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

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

From report at bugs.python.org  Tue Feb  4 21:59:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 02:59:20 +0000
Subject: [issue36136] Windows: python._pth sets isolated mode late during
 Python initialization
In-Reply-To: <1551277286.04.0.945215476701.issue36136@roundup.psfhosted.org>
Message-ID: <1580871560.46.0.412212361444.issue36136@roundup.psfhosted.org>


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

Sorry I missed seeing this - I rarely browse new issues unless they're "Windows" tagged.

Reading what's in master, I don't *think* there's any regression in the main case, since the values from pathconfig override config and AFAICT they aren't used in between:

    if (pathconfig.isolated != -1) {
        config->isolated = pathconfig.isolated;
    }

Haven't looked back at 3.7, but I haven't heard of any issues coming up here from people I know who have shipped this (though they might have been using SetPath to override it all anyway).

All of this could become irrelevant though if we add support to other platforms for ._pth files :) (yes, it has been requested)

----------
nosy: +steve.dower

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

From report at bugs.python.org  Tue Feb  4 21:59:21 2020
From: report at bugs.python.org (Ido Michael)
Date: Wed, 05 Feb 2020 02:59:21 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1580871561.01.0.999868290037.issue10572@roundup.psfhosted.org>


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

Thanks Brett,

I'll check this out over the week.
Let's take this module for instance: Lib/distutils.

I looked on this one test file by now, it looks decoupled (test_bdist.py), 

1.What to look for
2.Once decided it's not the right path, just migrate to Lib/tests/"module" and make sure it runs fine?

----------

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

From report at bugs.python.org  Tue Feb  4 22:13:07 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 03:13:07 +0000
Subject: [issue39553] Delete HAVE_SXS protected code
In-Reply-To: <1580863513.73.0.140072621675.issue39553@roundup.psfhosted.org>
Message-ID: <1580872387.59.0.807930672436.issue39553@roundup.psfhosted.org>


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


New changeset b439a715cb75e2663df32588fd004c7528b9f83b by Zackery Spytz in branch 'master':
bpo-39553: Delete HAVE_SXS protected code (GH-18356)
https://github.com/python/cpython/commit/b439a715cb75e2663df32588fd004c7528b9f83b


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

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

From report at bugs.python.org  Tue Feb  4 22:17:10 2020
From: report at bugs.python.org (Gustavo)
Date: Wed, 05 Feb 2020 03:17:10 +0000
Subject: [issue36199] libzmq.dll causes uncontrollable screen flickering when
 accessing windows 2012 R2 server through remote desktop
In-Reply-To: <1551804211.97.0.598936212645.issue36199@roundup.psfhosted.org>
Message-ID: <1580872630.82.0.854145260375.issue36199@roundup.psfhosted.org>


Gustavo <augussee at yahoo.com> added the comment:

Hi! I want to help you, leaving a useful guide about <a="https://remotedesktopwindows10.net">how to use remote desktop to connect to a Windows PC</a>.

----------
nosy: +gustavoxo

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

From report at bugs.python.org  Tue Feb  4 22:47:25 2020
From: report at bugs.python.org (Benoit B)
Date: Wed, 05 Feb 2020 03:47:25 +0000
Subject: [issue39554] @functools.lru_cache() not respecting typed=False
Message-ID: <1580874445.88.0.596584453725.issue39554@roundup.psfhosted.org>


New submission from Benoit B <hi at benbernardblog.com>:

I don't know if I'm missing something, but there's a behavior of functools.lru_cache() that I currently don't understand.

As the documentation states:

"If typed is set to true, function arguments of different types will be cached separately. For example, f(3) and f(3.0) will be treated as distinct calls with distinct results."

For a function accepting only positional arguments, using typed=False doesn't seem to be working in all cases.

>>> import functools
>>> 
>>> @functools.lru_cache()      # Implicitly uses typed=False
>>> def func(a):
...     return a
>>> 
>>> func(1)
>>> func(1.0)
>>> 
>>> print(func.cache_info())
CacheInfo(hits=0, misses=2, maxsize=128, currsize=2)

Instead, I would have expected: CacheInfo(hits=1, misses=1, maxsize=128, currsize=2)

So it looks like 1 and 1.0 were stored as different values even though typed=False was used.

After analyzing the source code of _functoolsmodule.c::lru_cache_make_key(), I found what follows:

    if (!typed && !kwds_size) {
        if (PyTuple_GET_SIZE(args) == 1) {
            key = PyTuple_GET_ITEM(args, 0);
            if (PyUnicode_CheckExact(key) || PyLong_CheckExact(key)) {      <<< it appears that a 'float' would cause 'args' (a tuple) to be returned as the key, whereas an 'int' would cause 'key'
                /* For common scalar keys, save space by                        (an int) to be returned as the key. So 1 and 1.0 generate different hashes and are stored as different items.
                   dropping the enclosing args tuple  */
                Py_INCREF(key);
                return key;
            }
        }
        Py_INCREF(args);
        return args;
    }

At some point in the past, the above code section looked like this:

    if (!typed && !kwds) {
        Py_INCREF(args);
        return args;
    }
    
So no matter what the type of the argument was, it was working.
    
Am I somehow mistaken in my analysis or is this a bug?

----------
components: Library (Lib)
messages: 361404
nosy: bbernard
priority: normal
severity: normal
status: open
title: @functools.lru_cache() not respecting typed=False
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Feb  4 23:18:33 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Feb 2020 04:18:33 +0000
Subject: [issue39554] @functools.lru_cache() not respecting typed=False
In-Reply-To: <1580874445.88.0.596584453725.issue39554@roundup.psfhosted.org>
Message-ID: <1580876313.01.0.705734513446.issue39554@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I understand the confusion, but this isn't a bug.

Specifying "typed=True" means that the cache is required to treat the calls f(1) and f(1.0) as distinct.

However, specifying or defaulting to "typed=False" means that the cache isn't required to do so, but it is still allowed to.

This flexibility allowed the tool to add a space saving path for *int*.  It comes at the expense of leaving equivalent int/float calls as distinct.  Most apps win here because it is typical to keep the type the same across calls.  Also, the saved space may allow users to choose a larger value for *maxsize*.

Note, similar liberties were taken with keyword argument ordering.  Formerly, f(a=1, b=2) was considered equivalent to f(b=1, a=1).  Now, they are treated as distinct.  The downside is a potential extra call.  The upside is that we save the huge overhead of sorting the keyword arguments.  Mostly, this is a net win, despite the visible change in cache utilization statistics.

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

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

From report at bugs.python.org  Tue Feb  4 23:57:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 04:57:38 +0000
Subject: [issue39553] Delete HAVE_SXS protected code
In-Reply-To: <1580863513.73.0.140072621675.issue39553@roundup.psfhosted.org>
Message-ID: <1580878658.52.0.29916462896.issue39553@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/issue39553>
_______________________________________

From report at bugs.python.org  Tue Feb  4 23:59:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 04:59:17 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
Message-ID: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>


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

>From https://buildbot.python.org/all/#/builders/129/builds/306

======================================================================
FAIL: test_unicode_module_names (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\distutils\tests\test_build_ext.py", line 315, in test_unicode_module_names
    self.assertRegex(cmd.get_ext_filename(modules[0].name), r'foo\..*')
AssertionError: Regex didn't match: 'foo\\..*' not found in 'foo_d.cp39-win_amd64.pyd'
======================================================================
FAIL: test_unicode_module_names (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\distutils\tests\test_build_ext.py", line 315, in test_unicode_module_names
    self.assertRegex(cmd.get_ext_filename(modules[0].name), r'foo\..*')
AssertionError: Regex didn't match: 'foo\\..*' not found in 'foo_d.cp39-win_amd64.pyd'

----------
components: Distutils, Windows
messages: 361406
nosy: dstufft, eric.araujo, pablogsal, paul.moore, scoder, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_distutils fails for Windows debug build
type: behavior

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

From report at bugs.python.org  Wed Feb  5 00:04:46 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 05:04:46 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1580879086.0.0.303337989823.issue39555@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Feb  5 01:35:54 2020
From: report at bugs.python.org (Kevin Young)
Date: Wed, 05 Feb 2020 06:35:54 +0000
Subject: [issue39556] Different objects of the same class references the same
 dictionary
Message-ID: <1580884554.4.0.0450040370405.issue39556@roundup.psfhosted.org>


New submission from Kevin Young <kings988 at gmail.com>:

Test code:

class Test(object):
    def __init__(self, a={}):
        self._a = a
    
    def put(self, k, v):
        self._a[k] = v

if __name__ == '__main__':
    t1 = Test()
    t1.put('aa', '11')
    t1.put('bb', '22')
    
    t2 = Test()
    t2.put('cc', '33')
    for k, v in t2._a.items():
        print(k, '=', v)

Output:
aa = 11
bb = 22
cc = 33

The expected output should be:
cc = 33

My workaround:
self._a = dict(a)

I have tested on both Python 3.7.3 and 3.8.1, they share the same results.
I'm not sure if this is a bug or on-purpose feature of python. Could someone provide some guidance for me? Thank you.

----------
components: Interpreter Core
messages: 361407
nosy: Kevin Young
priority: normal
severity: normal
status: open
title: Different objects of the same class references the same dictionary
versions: Python 3.7

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

From report at bugs.python.org  Wed Feb  5 01:55:56 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 05 Feb 2020 06:55:56 +0000
Subject: [issue39556] Different objects of the same class references the same
 dictionary
In-Reply-To: <1580884554.4.0.0450040370405.issue39556@roundup.psfhosted.org>
Message-ID: <1580885756.84.0.32893266394.issue39556@roundup.psfhosted.org>


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

This is a common mistake, you'll find the FAQ entry for it here: https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects

It's not necessarily a "feature" but default values in functions are only created once, when the function is defined. Subsequent calls will refer to that same initially created object.

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

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

From report at bugs.python.org  Wed Feb  5 02:16:06 2020
From: report at bugs.python.org (Kevin Young)
Date: Wed, 05 Feb 2020 07:16:06 +0000
Subject: [issue39556] Different objects of the same class references the same
 dictionary
In-Reply-To: <1580884554.4.0.0450040370405.issue39556@roundup.psfhosted.org>
Message-ID: <1580886966.51.0.358842226041.issue39556@roundup.psfhosted.org>


Kevin Young <kings988 at gmail.com> added the comment:

Thank you, Ammar!
I thought the default values were locally scoped under the __init__() function.

----------

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

From report at bugs.python.org  Wed Feb  5 02:38:19 2020
From: report at bugs.python.org (Avraham Mahfuda)
Date: Wed, 05 Feb 2020 07:38:19 +0000
Subject: [issue39557] ThreadPoolExecutor is busy-waiting when idle.
Message-ID: <1580888299.0.0.965711454165.issue39557@roundup.psfhosted.org>


New submission from Avraham Mahfuda <avraham.mahfuda at bloxroute.com>:

In concurrent.futures.thread line 78 is busy-waiting if the queue is empty, which may cause the CPU to spin to 100% when idle.

----------
messages: 361410
nosy: Avraham Mahfuda
priority: normal
severity: normal
status: open
title: ThreadPoolExecutor is busy-waiting when idle.
type: resource usage
versions: Python 3.7

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

From report at bugs.python.org  Wed Feb  5 02:54:13 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 05 Feb 2020 07:54:13 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1580889253.95.0.894654519157.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17733
pull_request: https://github.com/python/cpython/pull/18358

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

From report at bugs.python.org  Wed Feb  5 03:00:49 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Feb 2020 08:00:49 +0000
Subject: [issue39557] ThreadPoolExecutor is busy-waiting when idle.
In-Reply-To: <1580888299.0.0.965711454165.issue39557@roundup.psfhosted.org>
Message-ID: <1580889649.07.0.832304117933.issue39557@roundup.psfhosted.org>


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

On the HEAD of the current 3.7 branch, the file you refer to has the following code starting at line 37:

        while True:
            work_item = work_queue.get(block=True)
            if work_item is not None:
                work_item.run()
                ...

Code link: https://github.com/python/cpython/blob/6ba8dc6aae6fa0a7e29ba4ac18227beb38872392/Lib/concurrent/futures/thread.py#L77-L80

Is that the code you're referring to?

If that's not the code you mean, please could you say exactly which version of Python you're looking at? (Code gets added and removed over time, so a line number isn't all that helpful without additional information).

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

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

From report at bugs.python.org  Wed Feb  5 03:04:17 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Feb 2020 08:04:17 +0000
Subject: [issue39557] ThreadPoolExecutor is busy-waiting when idle.
In-Reply-To: <1580888299.0.0.965711454165.issue39557@roundup.psfhosted.org>
Message-ID: <1580889857.51.0.885819719458.issue39557@roundup.psfhosted.org>


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

It would also be helpful to know which platform you're observing the 100% CPU usage on, so that we can try to reproduce.

----------

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

From report at bugs.python.org  Wed Feb  5 03:14:14 2020
From: report at bugs.python.org (Avraham Mahfuda)
Date: Wed, 05 Feb 2020 08:14:14 +0000
Subject: [issue39557] ThreadPoolExecutor is busy-waiting when idle.
In-Reply-To: <1580888299.0.0.965711454165.issue39557@roundup.psfhosted.org>
Message-ID: <1580890454.26.0.83244042708.issue39557@roundup.psfhosted.org>


Avraham Mahfuda <avraham.mahfuda at bloxroute.com> added the comment:

1. I can confirm that the posted code above is the correct one.
2. The 100% CPU was observed in a docker instance using python:3.7.0-alpine3.8 image.
3. The docker image was running on a 2 cores VM.

----------

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

From report at bugs.python.org  Wed Feb  5 03:17:06 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 05 Feb 2020 08:17:06 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
In-Reply-To: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>
Message-ID: <1580890626.8.0.73313266271.issue39505@roundup.psfhosted.org>


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


New changeset 787b6d548c250f36df6d3f3179f60d754c8aa5e3 by schwarzichet in branch 'master':
bpo-39505: delete the redundant '/' in $env:VIRTUAL_ENV (GH-18290)
https://github.com/python/cpython/commit/787b6d548c250f36df6d3f3179f60d754c8aa5e3


----------

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

From report at bugs.python.org  Wed Feb  5 03:17:24 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Feb 2020 08:17:24 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
In-Reply-To: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>
Message-ID: <1580890644.57.0.390781494744.issue39505@roundup.psfhosted.org>


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


----------
pull_requests: +17734
pull_request: https://github.com/python/cpython/pull/18359

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

From report at bugs.python.org  Wed Feb  5 03:23:03 2020
From: report at bugs.python.org (Avraham Mahfuda)
Date: Wed, 05 Feb 2020 08:23:03 +0000
Subject: [issue39557] ThreadPoolExecutor is busy-waiting when idle.
In-Reply-To: <1580888299.0.0.965711454165.issue39557@roundup.psfhosted.org>
Message-ID: <1580890983.05.0.210881930803.issue39557@roundup.psfhosted.org>


Avraham Mahfuda <avraham.mahfuda at bloxroute.com> added the comment:

If I understand the following code correctly, there seems to be a busy loop waiting for the SimpleQueue.put to signal that an item was entered to queue.
https://github.com/python/cpython/blob/3.7/Modules/_queuemodule.c#L217

----------

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

From report at bugs.python.org  Wed Feb  5 03:39:04 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 05 Feb 2020 08:39:04 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580891944.42.0.745371265913.issue39432@roundup.psfhosted.org>


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

Ok, this is merged into 3.9. To which versions should we backport it?
Definitely 3.8, definitely not 3.5, probably not 3.6 (since it's not a security issue). Ned, what about 3.7?

----------
nosy: +ned.deily
stage: patch review -> backport needed

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

From report at bugs.python.org  Wed Feb  5 03:39:40 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 05 Feb 2020 08:39:40 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
In-Reply-To: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>
Message-ID: <1580891980.62.0.30733878697.issue39505@roundup.psfhosted.org>


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


New changeset 927d3aab1c7874b5705fcc8269ea608315434e66 by Miss Islington (bot) in branch '3.8':
bpo-39505: delete the redundant '/' in $env:VIRTUAL_ENV (GH-18290) (GH-18359)
https://github.com/python/cpython/commit/927d3aab1c7874b5705fcc8269ea608315434e66


----------

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

From report at bugs.python.org  Wed Feb  5 03:40:11 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 05 Feb 2020 08:40:11 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
In-Reply-To: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>
Message-ID: <1580892011.26.0.84663014788.issue39505@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

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

From report at bugs.python.org  Wed Feb  5 03:53:11 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 05 Feb 2020 08:53:11 +0000
Subject: [issue39538] SystemError when set Element.attrib to non-dict
In-Reply-To: <1580725155.12.0.53190069949.issue39538@roundup.psfhosted.org>
Message-ID: <1580892791.13.0.0132102576205.issue39538@roundup.psfhosted.org>


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

I agree that SystemError is the wrong response. Whether it needs to be AttributeError ? probably fine to consider this an implementation detail. TypeError also seems ok in at least some of the cases. I think we should widen the code to expect some kind of Mapping (instead of strictly a dict), and if we don't find that on access, a TypeError seems just as good as an AttributeError from Python.

I'm unsure if we should restrict assignments to ".attrib". It's probably enough to allow "None" assignments to say "no attributes allowed", Everything else can be handled by some kind of Mapping object. But then, why not just use the Mapping protocol on access and leave errors to that stage?

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

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

From report at bugs.python.org  Wed Feb  5 04:26:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Feb 2020 09:26:32 +0000
Subject: [issue38149] sys.audit() is called multiple times for glob.glob()
In-Reply-To: <1568365671.05.0.0499818085141.issue38149@roundup.psfhosted.org>
Message-ID: <1580894792.39.0.520692778064.issue38149@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Feb  5 05:45:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 10:45:37 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580899537.72.0.569081861092.issue39543@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Wed Feb  5 05:51:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 10:51:32 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580899892.23.0.136566154569.issue39543@roundup.psfhosted.org>


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

I wrote a quick & dirty local patch to define again _Py_NewReference() and _Py_Dealloc() as inline function in object.h before Py_DECREF(). I failed to see a clear win in term of performance.

Microbenchmark:

./python -m pyperf timeit --duplicate=4096 'o=object(); o=None' -l 512

Result if _Py_Dealloc() is inlined again:

Mean +- std dev: [opaque] 69.3 ns +- 1.5 ns -> [dealloc] 67.5 ns +- 1.5 ns: 1.03x faster (-3%)

Result if _Py_Dealloc() and _Py_NewReference() are inlined again:

Mean +- std dev: [opaque] 69.3 ns +- 1.5 ns -> [dealloc_newref] 66.1 ns +- 1.3 ns: 1.05x faster (-5%)

It's a matter of 3.2 nanoseconds. Honestly, I don't think that it's worth it to bother with that. I expect way more siginificant speedup with more advanced optimizations like using a tracing GC or tagged pointers, and these optimizations require to better hide implementation details.

_Py_Dealloc() was converted to a regular function was mistake when I moved code to cpython/object.h and nobody noticed.

For all these reasons, I wrote PR 18361 to remove the unused _Py_Dealloc() macro, rather than trying to inline it again.

----------

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

From report at bugs.python.org  Wed Feb  5 06:02:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 11:02:20 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580900540.57.0.59242800734.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17737
pull_request: https://github.com/python/cpython/pull/18362

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

From report at bugs.python.org  Wed Feb  5 06:04:44 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 05 Feb 2020 11:04:44 +0000
Subject: [issue39127] _Py_HashPointer's void * argument should be const
In-Reply-To: <1577162580.85.0.922460323342.issue39127@roundup.psfhosted.org>
Message-ID: <1580900684.89.0.812234815306.issue39127@roundup.psfhosted.org>


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


----------
type:  -> enhancement
versions: +Python 3.9

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

From report at bugs.python.org  Wed Feb  5 06:09:20 2020
From: report at bugs.python.org (Carl Harris)
Date: Wed, 05 Feb 2020 11:09:20 +0000
Subject: [issue35799] fix or remove smtpd.PureProxy
In-Reply-To: <1548091515.27.0.738178577175.issue35799@roundup.psfhosted.org>
Message-ID: <1580900960.63.0.895195916194.issue35799@roundup.psfhosted.org>


Change by Carl Harris <elgoogemail2007 at gmail.com>:


----------
nosy: +hitbox

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

From report at bugs.python.org  Wed Feb  5 06:18:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 11:18:59 +0000
Subject: [issue39543] Py_DECREF(): use inlined _Py_Dealloc()
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580901539.4.0.86987847698.issue39543@roundup.psfhosted.org>


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


New changeset f16433a73138f279642e581074135694ddcfe965 by Victor Stinner in branch 'master':
bpo-39543: Remove unused _Py_Dealloc() macro (GH-18361)
https://github.com/python/cpython/commit/f16433a73138f279642e581074135694ddcfe965


----------

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

From report at bugs.python.org  Wed Feb  5 06:19:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 11:19:38 +0000
Subject: [issue39543] Remove unused _Py_Dealloc() macro
In-Reply-To: <1580748828.27.0.856458139281.issue39543@roundup.psfhosted.org>
Message-ID: <1580901578.97.0.07186292253.issue39543@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Py_DECREF(): use inlined _Py_Dealloc() -> Remove unused _Py_Dealloc() macro
versions:  -Python 3.8

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

From report at bugs.python.org  Wed Feb  5 06:20:39 2020
From: report at bugs.python.org (=?utf-8?b?0JHQvtGA0LjRgSDQktC10YDRhdC+0LLRgdC60LjQuQ==?=)
Date: Wed, 05 Feb 2020 11:20:39 +0000
Subject: [issue39558] Implement __len__() for itertools.combinations
Message-ID: <1580901639.1.0.0844849880483.issue39558@roundup.psfhosted.org>


New submission from ????? ?????????? <boris.verk at gmail.com>:

and the other objects that have a straightforward formula for the number of elements they will generate.

----------
components: Library (Lib)
messages: 361421
nosy: boris
priority: normal
severity: normal
status: open
title: Implement __len__() for itertools.combinations
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Feb  5 06:23:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 11:23:32 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580901812.05.0.395192896863.issue39542@roundup.psfhosted.org>


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


New changeset 0fa4f43db086ac3459811cca4ec5201ffbee694a by Victor Stinner in branch 'master':
bpo-39542: Exclude trashcan from the limited C API (GH-18362)
https://github.com/python/cpython/commit/0fa4f43db086ac3459811cca4ec5201ffbee694a


----------

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

From report at bugs.python.org  Wed Feb  5 06:48:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 11:48:41 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580903321.64.0.960553935757.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17738
pull_request: https://github.com/python/cpython/pull/18363

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

From report at bugs.python.org  Wed Feb  5 07:02:55 2020
From: report at bugs.python.org (Sebastian Rittau)
Date: Wed, 05 Feb 2020 12:02:55 +0000
Subject: [issue39559] uuid.getnode() has unused argument
Message-ID: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>


New submission from Sebastian Rittau <srittau at rittau.biz>:

uuid.getnode() has an undocumented, keyword-only "getters" argument that gets discarded immediately. This is confusing when using code inspection tools and can give the wrong impression that you can somehow override the node getters when you can't. I recommend removing this argument.

----------
components: Library (Lib)
messages: 361423
nosy: srittau
priority: normal
severity: normal
status: open
title: uuid.getnode() has unused argument
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Feb  5 07:05:35 2020
From: report at bugs.python.org (Sebastian Rittau)
Date: Wed, 05 Feb 2020 12:05:35 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580904335.63.0.229411945276.issue39559@roundup.psfhosted.org>


Sebastian Rittau <srittau at rittau.biz> added the comment:

Shantanu points out in https://github.com/python/typeshed/pull/3715 that the argument was made useless due to bpo-28009.

----------

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

From report at bugs.python.org  Wed Feb  5 07:12:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 12:12:26 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580904746.97.0.244337592028.issue39542@roundup.psfhosted.org>


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


New changeset f58bd7c1693fe041f7296a5778d0a11287895648 by Victor Stinner in branch 'master':
bpo-39542: Make PyObject_INIT() opaque in limited C API (GH-18363)
https://github.com/python/cpython/commit/f58bd7c1693fe041f7296a5778d0a11287895648


----------

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

From report at bugs.python.org  Wed Feb  5 07:15:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 12:15:57 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580904957.59.0.209488588304.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17739
pull_request: https://github.com/python/cpython/pull/18364

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

From report at bugs.python.org  Wed Feb  5 07:50:11 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 05 Feb 2020 12:50:11 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1580907011.73.0.106970428532.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17740
pull_request: https://github.com/python/cpython/pull/18365

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

From report at bugs.python.org  Wed Feb  5 07:52:13 2020
From: report at bugs.python.org (Santiago M. Mola)
Date: Wed, 05 Feb 2020 12:52:13 +0000
Subject: [issue39560] PyUnicode_FromKindAndData kind transformation is not
 documented
Message-ID: <1580907133.21.0.114993814029.issue39560@roundup.psfhosted.org>


New submission from Santiago M. Mola <santi at mola.io>:

PyUnicode_FromKindAndData copies input data and transforms it to the most compact representation. This behavior is not documented.

Proposed wording:

> The input buffer is copied and transformed into the canonical representation, if necessary. For example, if the buffer is a UCS4 string (PyUnicode_4BYTE_KIND) and it consists only of codepoints in the UCS1 range, it will be transformed into UCS1 (PyUnicode_1BYTE_KIND).

----------
assignee: docs at python
components: Documentation
messages: 361426
nosy: docs at python, smola
priority: normal
severity: normal
status: open
title: PyUnicode_FromKindAndData kind transformation is not documented
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/issue39560>
_______________________________________

From report at bugs.python.org  Wed Feb  5 08:14:03 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Feb 2020 13:14:03 +0000
Subject: [issue39558] Implement __len__() for itertools.combinations
In-Reply-To: <1580901639.1.0.0844849880483.issue39558@roundup.psfhosted.org>
Message-ID: <1580908443.21.0.643384387913.issue39558@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/issue39558>
_______________________________________

From report at bugs.python.org  Wed Feb  5 08:15:21 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 05 Feb 2020 13:15:21 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1580908521.1.0.781678859773.issue1635741@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

i thinkt that not checking `PyModule_AddObject()`'s result may cause this probleam too.

1) python-ast.c have one question, i fix it in PR18358.
2) most of the questions in extension module, for example: https://github.com/python/cpython/blob/master/Modules/gcmodule.c#L2019-L2022

----------

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

From report at bugs.python.org  Wed Feb  5 08:17:36 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 05 Feb 2020 13:17:36 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1580908656.4.0.807344764071.issue1635741@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

update the above info:
1) python-ast.c have one question, i fix it in PR18365.

----------

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

From report at bugs.python.org  Wed Feb  5 08:22:59 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 05 Feb 2020 13:22:59 +0000
Subject: [issue39558] Implement __len__() for itertools.combinations
In-Reply-To: <1580901639.1.0.0844849880483.issue39558@roundup.psfhosted.org>
Message-ID: <1580908979.63.0.343013648462.issue39558@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

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

From report at bugs.python.org  Wed Feb  5 08:24:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 13:24:46 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580909086.48.0.322595724614.issue39542@roundup.psfhosted.org>


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


New changeset 509dd90f4684e40af3105dd3e754fa4b9c1530c1 by Victor Stinner in branch 'master':
bpo-39542: Convert PyType_Check() to static inline function (GH-18364)
https://github.com/python/cpython/commit/509dd90f4684e40af3105dd3e754fa4b9c1530c1


----------

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

From report at bugs.python.org  Wed Feb  5 08:35:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 13:35:40 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580909740.84.0.175357353517.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17741
pull_request: https://github.com/python/cpython/pull/18366

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

From report at bugs.python.org  Wed Feb  5 08:56:12 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Feb 2020 13:56:12 +0000
Subject: [issue39558] Implement __len__() for itertools.combinations
In-Reply-To: <1580901639.1.0.0844849880483.issue39558@roundup.psfhosted.org>
Message-ID: <1580910972.51.0.106674770506.issue39558@roundup.psfhosted.org>


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

This is essentially a duplicate of #27678 and #24849 (and there may be others).

Note that the math module now has `prod`, `comb` and `perm`, which match the lengths of the full `product`, `combinations` and `permutations` itertools functions.

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

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

From report at bugs.python.org  Wed Feb  5 09:10:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 14:10:56 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580911856.05.0.270548335318.issue39542@roundup.psfhosted.org>


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


New changeset 0e4e735d06967145b49fd00693627f3624991dbc by Victor Stinner in branch 'master':
bpo-39542: Define PyTypeObject earlier in object.h (GH-18366)
https://github.com/python/cpython/commit/0e4e735d06967145b49fd00693627f3624991dbc


----------

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

From report at bugs.python.org  Wed Feb  5 09:11:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 14:11:11 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580911871.52.0.880534943813.issue39542@roundup.psfhosted.org>


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

Ok, object.h looks much better now! I close the issue.

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

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

From report at bugs.python.org  Wed Feb  5 09:53:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Feb 2020 14:53:44 +0000
Subject: [issue39558] Implement __len__() for itertools.combinations
In-Reply-To: <1580901639.1.0.0844849880483.issue39558@roundup.psfhosted.org>
Message-ID: <1580914424.31.0.360124319968.issue39558@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/issue39558>
_______________________________________

From report at bugs.python.org  Wed Feb  5 09:58:40 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 05 Feb 2020 14:58:40 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1580914720.62.0.203336402105.issue38628@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

The bug report implies a different bug than what is being reported.  The bug is not related to calling a LIBC function with an argument list that does not match the function signature.

The true issue is that a Python ctypes structure definition on AIX that contains an array as in the example does not create an argument list that matches the AIX ABI for argument passing.  An example that directly uses libffi seems to work, but invoking libffi via Python ctypes does not.

In other words, Python ctypes structures created with _fields_ equivalent to

struct {
  const char *s;
  unsigned long d;
  size_t n;
}

should produce the same argument list as

struct {
  const char *s;
  unsigned long c_n[2];
}

but the version with the array does not.

libffi passes arrays as pointers, so Python ctypes converts arrays passed by value as libffi structs.  This occurs in cpython/Modules/_ctypes/stgdict.c .  It is likely that ctypes is not generating the correct libffi descriptor.

The memchr example visually demonstrates the incorrect argument list, but is not intended to be correct, safe use of ctypes.

----------

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

From report at bugs.python.org  Wed Feb  5 11:49:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 16:49:46 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580921386.1.0.81643434075.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17742
pull_request: https://github.com/python/cpython/pull/18368

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

From report at bugs.python.org  Wed Feb  5 11:52:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 16:52:10 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580921530.65.0.372146380355.issue39432@roundup.psfhosted.org>


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

The test fails on Windows. Example on AMD64 Windows8.1 Refleaks 3.x:
https://buildbot.python.org/all/#/builders/157/builds/76

======================================================================
FAIL: test_unicode_module_names (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\distutils\tests\test_build_ext.py", line 315, in test_unicode_module_names
    self.assertRegex(cmd.get_ext_filename(modules[0].name), r'foo\..*')
AssertionError: Regex didn't match: 'foo\\..*' not found in 'foo_d.cp39-win_amd64.pyd'

======================================================================
FAIL: test_unicode_module_names (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\distutils\tests\test_build_ext.py", line 315, in test_unicode_module_names
    self.assertRegex(cmd.get_ext_filename(modules[0].name), r'foo\..*')
AssertionError: Regex didn't match: 'foo\\..*' not found in 'foo_d.cp39-win_amd64.pyd'

----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Feb  5 11:52:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 16:52:49 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580921569.95.0.333217126264.issue39432@roundup.psfhosted.org>


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

Python 3.6 doesn't accept bugfixes anymore:
https://devguide.python.org/#status-of-python-branches

The bugfix can go into 3.7 and 3.8.

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

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

From report at bugs.python.org  Wed Feb  5 11:55:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 16:55:34 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580921734.82.0.650467166837.issue39432@roundup.psfhosted.org>


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

I put a breakpoint before the error:

test_unicode_module_names (distutils.tests.test_build_ext.BuildExtTestCase) ... > c:\vstinner\python\master\lib\distutils\tests
\test_build_ext.py(316)test_unicode_module_names()
-> self.assertRegex(cmd.get_ext_filename(modules[0].name), r'foo\..*')
(Pdb) p modules
[<distutils.extension.Extension('foo') at 0x274003035f0>, <distutils.extension.Extension('f??') at 0x27400303730>]
(Pdb) p modules[0].name
'foo'
(Pdb) p modules[1].name 
'f??'

----------

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

From report at bugs.python.org  Wed Feb  5 11:57:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 16:57:18 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580921838.54.0.147808607355.issue39432@roundup.psfhosted.org>


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

On Windows, names get a "_d" suffix for debug. Extract of build_ext.py:

    def get_libraries(self, ext):
        """Return the list of libraries to link against when building a
        shared extension.  On most platforms, this is just 'ext.libraries';
        on Windows, we add the Python library (eg. python20.dll).
        """
        # The python library is always needed on Windows.  For MSVC, this
        # is redundant, since the library is mentioned in a pragma in
        # pyconfig.h that MSVC groks.  The other Windows compilers all seem
        # to need it mentioned explicitly, though, so that's what we do.
        # Append '_d' to the python import library on debug builds.
        if sys.platform == "win32":
            from distutils._msvccompiler import MSVCCompiler
            if not isinstance(self.compiler, MSVCCompiler):
                template = "python%d%d"
                if self.debug:
                    template = template + '_d'
(...)

----------

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

From report at bugs.python.org  Wed Feb  5 12:03:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 17:03:41 +0000
Subject: [issue39561] AMD64 Fedora Rawhide LTO + PGO 3.x: "checking for
 getaddrinfo... no"
Message-ID: <1580922221.51.0.460186713117.issue39561@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

On AMD64 Fedora Rawhide LTO + PGO 3.x buildbot, "checking for getaddrinfo... no" failed:

https://buildbot.python.org/all/#/builders/154/builds/243

checking for getaddrinfo... no
Fatal: You must get working getaddrinfo() function.
       or you can specify "--disable-ipv6".

It sounds like a regression in Fedora Rawhide libc.

----------
components: Build
messages: 361438
nosy: vstinner
priority: normal
severity: normal
status: open
title: AMD64 Fedora Rawhide LTO + PGO 3.x: "checking for getaddrinfo... no"
versions: Python 3.9

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

From report at bugs.python.org  Wed Feb  5 12:09:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 17:09:06 +0000
Subject: [issue39561] AMD64 Fedora Rawhide LTO + PGO 3.x: "checking for
 getaddrinfo... no"
In-Reply-To: <1580922221.51.0.460186713117.issue39561@roundup.psfhosted.org>
Message-ID: <1580922546.72.0.759186676131.issue39561@roundup.psfhosted.org>


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

Oh strange, it's back to green on the follow build:
https://buildbot.python.org/all/#/builders/154/builds/244

I close the issue.

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

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

From report at bugs.python.org  Wed Feb  5 12:21:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 17:21:00 +0000
Subject: [issue39488] test_largefile: TestSocketSendfile.test_it() uses too
 much disk space
In-Reply-To: <1580318049.66.0.254124049267.issue39488@roundup.psfhosted.org>
Message-ID: <1580923260.83.0.600890469193.issue39488@roundup.psfhosted.org>


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


New changeset b39fb8e847ac59b539ad7e93df91c1709815180e by Giampaolo Rodola in branch 'master':
bpo-39488: Skip test_largefile tests if not enough disk space (GH-18261)
https://github.com/python/cpython/commit/b39fb8e847ac59b539ad7e93df91c1709815180e


----------

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

From report at bugs.python.org  Wed Feb  5 12:23:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 17:23:24 +0000
Subject: [issue39488] test_largefile: TestSocketSendfile.test_it() uses too
 much disk space
In-Reply-To: <1580318049.66.0.254124049267.issue39488@roundup.psfhosted.org>
Message-ID: <1580923404.07.0.148341306589.issue39488@roundup.psfhosted.org>


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

Giampaolo Rodola modified the tests to skip them if there is not enough disk space. Let's see if it's enough to fix these buildbots. Since the issue was random, I close the issue and just hope that it's now fixed :-)

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

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

From report at bugs.python.org  Wed Feb  5 12:24:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Feb 2020 17:24:41 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1580923481.1.0.0197499103317.issue39542@roundup.psfhosted.org>


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


New changeset 58f4e1a6ee4c6ea82f3f5075d9d9d344ce6b8a56 by Victor Stinner in branch 'master':
bpo-39542: Declare _Py_AddToAllObjects() in pycore_object.h (GH-18368)
https://github.com/python/cpython/commit/58f4e1a6ee4c6ea82f3f5075d9d9d344ce6b8a56


----------

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

From report at bugs.python.org  Wed Feb  5 12:28:25 2020
From: report at bugs.python.org (jack1142)
Date: Wed, 05 Feb 2020 17:28:25 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
Message-ID: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>


New submission from jack1142 <kuba.kuczys at gmail.com>:

asyncio REPL doesn't allow using asynchronous comprehensions outside of async func. Same behavior can also be observed when using `ast.PyCF_ALLOW_TOP_LEVEL_AWAIT` flag in `compile()`

Example with `async for`:
>>> async def async_gen():
...     for x in range(5):
...         yield await asyncio.sleep(1, x)
... 
>>> [x async for x in async_gen()]
  File "<console>", line 0
SyntaxError: asynchronous comprehension outside of an asynchronous function


Example with `await`:
>>> [await asyncio.sleep(1, x) for x in range(5)]
  File "<console>", line 0
SyntaxError: asynchronous comprehension outside of an asynchronous function

----------
components: asyncio
messages: 361443
nosy: asvetlov, jack1142, yselivanov
priority: normal
severity: normal
status: open
title: Asynchronous comprehensions don't work in asyncio REPL
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Feb  5 12:31:11 2020
From: report at bugs.python.org (Hector E. Socarras)
Date: Wed, 05 Feb 2020 17:31:11 +0000
Subject: [issue39563] asyncio.Protocol on windows 10 x64
Message-ID: <1580923871.37.0.213869641033.issue39563@roundup.psfhosted.org>


New submission from Hector E. Socarras <hsocarras1987 at gmail.com>:

I test de sample Echo Tcp Server on https://docs.python.org/3.8/library/asyncio-protocol.html. When I run de server i got the following error from python interpreter
Traceback (most recent call last):
  File "server_test.py", line 1, in <module>
    import asyncio
  File "C:\Users\Hector\AppData\Local\Programs\Python\Python37\lib\asyncio\__init__.py", line 8, in <module>
    from .base_events import *
  File "C:\Users\Hector\AppData\Local\Programs\Python\Python37\lib\asyncio\base_events.py", line 23, in <module>
    import socket
  File "C:\Users\Hector\pynode\net\socket.py", line 7, in <module>
    class NetBaseProtocol(asyncio.Protocol, EventEmitter):
AttributeError: module 'asyncio' has no attribute 'Protocol'

the problem was that i have a module named socket in the same folder. But I think that base_events.py should import the apropiate socket module using relative import or supplying full path for his socket import.

----------
components: asyncio
messages: 361444
nosy: asvetlov, hsocarras, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Protocol on windows 10 x64
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Wed Feb  5 12:33:21 2020
From: report at bugs.python.org (jack1142)
Date: Wed, 05 Feb 2020 17:33:21 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1580924001.3.0.107287581478.issue39562@roundup.psfhosted.org>


jack1142 <kuba.kuczys at gmail.com> added the comment:

I also noticed that putting `await` before the async comprehension will make the code inside the comprehension run (though after it runs, it will fail on awaiting list):

>>> await [await asyncio.sleep(1, print(x)) for x in range(5)] 
0
1
2
3
4
Traceback (most recent call last):
  File "C:\Python38\lib\concurrent\futures\_base.py", line 439, in result
    return self.__get_result()
  File "C:\Python38\lib\concurrent\futures\_base.py", line 388, in __get_result
    raise self._exception
  File "<console>", line 1, in <module>
TypeError: object list can't be used in 'await' expression

----------

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

From report at bugs.python.org  Wed Feb  5 12:38:58 2020
From: report at bugs.python.org (Hector E. Socarras)
Date: Wed, 05 Feb 2020 17:38:58 +0000
Subject: [issue39563] asyncio.Protocol on windows 10 x64
In-Reply-To: <1580923871.37.0.213869641033.issue39563@roundup.psfhosted.org>
Message-ID: <1580924338.96.0.49551427885.issue39563@roundup.psfhosted.org>


Change by Hector E. Socarras <hsocarras1987 at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  5 12:43:26 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 05 Feb 2020 17:43:26 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1580924606.69.0.794263266419.issue10572@roundup.psfhosted.org>


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

distutils might get pulled out at some point to it's at the bottom of the priority list for now.

Basically move the tests for a package to under Lib/test under the proper subpackage name and make sure the tests didn't break due to the move. That's pretty much the extent of this work.

----------

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

From report at bugs.python.org  Wed Feb  5 13:26:40 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 05 Feb 2020 18:26:40 +0000
Subject: [issue28009] Fix uuid.uuid1() core logic of uuid.getnode() needs
 refresh
In-Reply-To: <1473290315.48.0.840701308825.issue28009@psf.upfronthosting.co.za>
Message-ID: <1580927200.84.0.467724639979.issue28009@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
pull_requests: +17744
pull_request: https://github.com/python/cpython/pull/18369

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

From report at bugs.python.org  Wed Feb  5 13:26:40 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 05 Feb 2020 18:26:40 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580927200.76.0.0372495639695.issue39559@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  5 13:31:43 2020
From: report at bugs.python.org (Tal Einat)
Date: Wed, 05 Feb 2020 18:31:43 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580927503.05.0.707274400159.issue39559@roundup.psfhosted.org>


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

Simply removing the argument would be backwards-incompatible.

Unless someone can show via a code search that this is never used in practice, we may want to consider deprecating this argument before removing it.

----------
nosy: +taleinat
versions: +Python 3.9 -Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Feb  5 13:56:46 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 05 Feb 2020 18:56:46 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1580929006.39.0.167399206354.issue38823@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17745
pull_request: https://github.com/python/cpython/pull/18365

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

From report at bugs.python.org  Wed Feb  5 14:07:35 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 05 Feb 2020 19:07:35 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580929655.29.0.125043921768.issue39559@roundup.psfhosted.org>


Shantanu <hauntsaninja at gmail.com> added the comment:

Github code search isn't great, but I was unable to find any usage of `uuid.getnode(getters=`, whereas I was able to find usage of `uuid.uuid1(node=` (even though `node` is optional and can be passed positionally). I'd be surprised if it was used in practice, given that it's undocumented and only present on 3.7+ (I discovered it while running `inspect.signature` on large parts of stdlib). I think that, and the fact that this never did anything (even before bpo-28009 it looks like `getters` gets immediately overwritten), mitigate the risk here.

Let me know what you think should be done; happy to submit a PR that issues a deprecation warning.

----------
nosy: +hauntsaninja

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

From report at bugs.python.org  Wed Feb  5 15:00:11 2020
From: report at bugs.python.org (Sebastian Rittau)
Date: Wed, 05 Feb 2020 20:00:11 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580932811.99.0.268980748376.issue39559@roundup.psfhosted.org>


Sebastian Rittau <srittau at rittau.biz> added the comment:

Code using this argument is in all likelihood already subtly broken, because it depends on non-existing functionality. I believe that a "hard" break would be better (for Python 3.9).

----------

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

From report at bugs.python.org  Wed Feb  5 15:20:05 2020
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 05 Feb 2020 20:20:05 +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: <1580934005.71.0.641063340134.issue39026@roundup.psfhosted.org>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy: +mcepl

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

From report at bugs.python.org  Wed Feb  5 15:22:46 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 05 Feb 2020 20:22:46 +0000
Subject: [issue39558] Implement __len__() for itertools.combinations
In-Reply-To: <1580901639.1.0.0844849880483.issue39558@roundup.psfhosted.org>
Message-ID: <1580934166.91.0.602113711676.issue39558@roundup.psfhosted.org>


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


----------
superseder:  -> Add __len__ to map, everything in itertools

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

From report at bugs.python.org  Wed Feb  5 15:23:46 2020
From: report at bugs.python.org (Dan Arad)
Date: Wed, 05 Feb 2020 20:23:46 +0000
Subject: [issue14149] argparse: Document how to use argument names that are
 not Python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1580934226.82.0.151628726426.issue14149@roundup.psfhosted.org>


Dan Arad <dan1994 at gmail.com> added the comment:

Hi everyone!

I thought to take this issue up by updating the documentation. Is this still relevant?

If so I think the best place to add the documentation is in the "name or flags" section, where people will go looking first. I think to add both the metavar and the vars solutions discussed below.

----------
nosy: +Dan Arad

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

From report at bugs.python.org  Wed Feb  5 15:41:36 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 05 Feb 2020 20:41:36 +0000
Subject: [issue39556] Different objects of the same class references the same
 dictionary
In-Reply-To: <1580884554.4.0.0450040370405.issue39556@roundup.psfhosted.org>
Message-ID: <1580935296.44.0.663157657214.issue39556@roundup.psfhosted.org>


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

Ammar: it is definitely a feature that default values are created only once, when the function is created, not over and over again every time the function is called. (These are sometimes called "early binding" and "late binding" respectively.)

With early binding, you know what the default value is: it is the object at the time the function was created.

(But note that *mutable* objects may be mutated from one call to the next: they are not "reset" to their initial value each time. This is occasionally useful, to implement static storage across function calls, but also often a Gotcha that trips people up.)

With late binding, a default value like this:

    def function(value=a+b+c):

could change from one call to the next, if the values a, b or c change.

Both early and late binding have advantages and disadvantages, but if a language only has one, it is better to have early binding (as Python has) and let the coder do the late binding inside the function:

    def function(value=None):
        if value is None:
            value = a+b+c

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

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

From report at bugs.python.org  Wed Feb  5 15:43:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Feb 2020 20:43:18 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580935398.69.0.15317395659.issue39559@roundup.psfhosted.org>


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


New changeset 8b6f6526f857bb7523b0fcff09b45bc6471289e9 by Shantanu in branch 'master':
bpo-39559: Remove unused, undocumented argument from uuid.getnode (GH-18369)
https://github.com/python/cpython/commit/8b6f6526f857bb7523b0fcff09b45bc6471289e9


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

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

From report at bugs.python.org  Wed Feb  5 15:45:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Feb 2020 20:45:34 +0000
Subject: [issue39559] uuid.getnode() has unused argument
In-Reply-To: <1580904175.73.0.59628160229.issue39559@roundup.psfhosted.org>
Message-ID: <1580935534.9.0.483992053239.issue39559@roundup.psfhosted.org>


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

I agree. It was added in issue32502, but was never documented and used.

Thank you Sebastian and Shantanu.

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

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

From report at bugs.python.org  Wed Feb  5 15:47:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Feb 2020 20:47:03 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1580935623.02.0.378008578688.issue39562@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/issue39562>
_______________________________________

From report at bugs.python.org  Wed Feb  5 16:02:29 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 05 Feb 2020 21:02:29 +0000
Subject: [issue18213] py-bt errors on backtrace with PyRun_SimpleString and
 friends
In-Reply-To: <1371218845.8.0.761231443863.issue18213@psf.upfronthosting.co.za>
Message-ID: <1580936549.39.0.210451565688.issue18213@roundup.psfhosted.org>


Enji Cooper <yaneurabeya at gmail.com> added the comment:

This particular issue has been resolved in python 3.x.

----------
nosy: +ngie

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

From report at bugs.python.org  Wed Feb  5 16:10:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Feb 2020 21:10:05 +0000
Subject: [issue39127] _Py_HashPointer's void * argument should be const
In-Reply-To: <1577162580.85.0.922460323342.issue39127@roundup.psfhosted.org>
Message-ID: <1580937005.12.0.482858099224.issue39127@roundup.psfhosted.org>


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


New changeset 3d06953c34fd6421dd1dfdb615578cde676ee0eb by Andy Lester in branch 'master':
bpo-39127: Make _Py_HashPointer's argument be const (GH-17690)
https://github.com/python/cpython/commit/3d06953c34fd6421dd1dfdb615578cde676ee0eb


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

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

From report at bugs.python.org  Wed Feb  5 16:21:22 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 05 Feb 2020 21:21:22 +0000
Subject: [issue39564] Parsed expression has wrong line/col info when
 concatenating f-strings
Message-ID: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

When concatenating f-strings, if there is an expression in any STRING node other than the first, col_offset of the parsed expression has a wrong value.

For example, parsing f"hello" f"{world}" outputs the following AST:

Module(
    body=[
        Expr(
            value=JoinedStr(
                values=[
                    Constant(
                        value="hello",
                        kind=None,
                        lineno=1,
                        col_offset=0,
                        end_lineno=1,
                        end_col_offset=19,
                    ),
                    FormattedValue(
                        value=Name(
                            id="world",
                            ctx=Load(),
                            lineno=1,
                            *col_offset=1,*
                            end_lineno=1,
                            *end_col_offset=6,*
                        ),
                        conversion=-1,
                        format_spec=None,
                        lineno=1,
                        col_offset=0,
                        end_lineno=1,
                        end_col_offset=19,
                    ),
                ],
                lineno=1,
                col_offset=0,
                end_lineno=1,
                end_col_offset=19,
            ),
            lineno=1,
            col_offset=0,
            end_lineno=1,
            end_col_offset=19,
        )
    ],
    type_ignores=[],
)

Here, col_offset and end_col_offset are wrong in the parsed NAME 'world'.

----------
components: Interpreter Core
messages: 361456
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Parsed expression has wrong line/col info when concatenating f-strings
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Feb  5 16:23:24 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 05 Feb 2020 21:23:24 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580937804.69.0.998702216249.issue39564@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
title: Parsed expression has wrong line/col info when concatenating f-strings -> Parsed expression has wrong col_offset when concatenating f-strings

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

From report at bugs.python.org  Wed Feb  5 17:05:07 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 05 Feb 2020 22:05:07 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580940307.93.0.00727486347484.issue39564@roundup.psfhosted.org>


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

There are a number of bugs about this. See issue 35212 and issue 34364, at least.

I have a stale patch that tried to fix this, but I was never able to get it completely correct.

I have another approach that I hope to discuss at the language summit at PyCon. Hopefully progress after that will be quick.

I'm going to close this as a duplicate. When I decide on a course of action, I'll either use issue 34364 or create a new issue.

----------
nosy: +eric.smith
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> problem with traceback for syntax error in f-string
type:  -> behavior

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

From report at bugs.python.org  Wed Feb  5 17:15:07 2020
From: report at bugs.python.org (Dan Arad)
Date: Wed, 05 Feb 2020 22:15:07 +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: <1580940907.19.0.878109719924.issue28859@roundup.psfhosted.org>


Change by Dan Arad <dan1994 at gmail.com>:


----------
nosy: +Dan Arad

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

From report at bugs.python.org  Wed Feb  5 17:15:07 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 05 Feb 2020 22:15:07 +0000
Subject: [issue39565] Modules/signalmodule.c only works with `NSIG` signals;
 requires fudging to support realtime signals, etc
Message-ID: <1580940907.68.0.904788237522.issue39565@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

The code in Modules/signalmodule.c makes a number of assumptions of what signals are considered valid, as well as what handlers need to be setup as part of the core interpreter.

For example: much of the initialization of signal handlers, etc, is actually keyed off of NSIG, as defined (and guessed on) here: https://github.com/python/cpython/blob/master/Modules/signalmodule.c#L50 . The problem with this is that it makes it impossible for end-users to use `signal.signal`, et al with signal numbers outside of `NSIG`, which includes realtime signals.

Furthermore, if one is to extend the size of `NSIG`, it results in an increased O(n) iteration over all of the signals if/when a handler needs to be handled (set or cleared).

Proposal:
The best way to handle this, in my opinion, is to use a dict-like container to iterate over all of the handlers and rely on the OS to trickle up errors in the signal(3) libcall, as opposed to thinking that the definitions/assumptions in signalmodule.c are absolutely correct.

This may or may not be possible, however, depending on code needing to be reentrant, but it would be nice to leverage a middle ground solution of some kind *shrug*.

----------
components: Interpreter Core
messages: 361458
nosy: ngie
priority: normal
severity: normal
status: open
title: Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc
versions: Python 3.8

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

From report at bugs.python.org  Wed Feb  5 17:28:21 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Feb 2020 22:28:21 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580940307.93.0.00727486347484.issue39564@roundup.psfhosted.org>
Message-ID: <CAP7+vJJnaMpsM_rgfMc+KCzTvT+XteuVKoYuwh_cgk9Wmfnyaw@mail.gmail.com>


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

Note that this is somewhat urgent for oefen, since we strive to match the
produced AST exactly.
-- 
--Guido (mobile)

----------

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

From report at bugs.python.org  Wed Feb  5 17:29:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 05 Feb 2020 22:29:00 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580941740.69.0.384283925193.issue39432@roundup.psfhosted.org>


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

issue39555 and PR 18357 have the fix for the buildbot.

----------

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

From report at bugs.python.org  Wed Feb  5 18:37:24 2020
From: report at bugs.python.org (Nicholas Matthews)
Date: Wed, 05 Feb 2020 23:37:24 +0000
Subject: [issue39566] inspect.Signature.__init__ asks for parameters as dict
 but treats as list
Message-ID: <1580945844.01.0.0291811112362.issue39566@roundup.psfhosted.org>


New submission from Nicholas Matthews <nmatthews at asapp.com>:

The class inspect.Signature asks for parameters of type dict in python 3.8+ (and OrderedDict in earlier versions); however the __init__ function iterates over parameters as if it were a list, specifically:

for param in parameters:
    name = param.name
    kind = param.kind
    ...

Either the docstring should be changed to specify Sequence / List, or the implementation should be changed to iterate over the values of parameters:

for param in parameters.values():
    ...

(https://github.com/python/cpython/blob/2cca8efe46935c39c445f585bce54954fad2485b/Lib/inspect.py#L2734)

----------
messages: 361461
nosy: Nicholas Matthews
priority: normal
severity: normal
status: open
title: inspect.Signature.__init__ asks for parameters as dict but treats as list
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Feb  5 19:48:44 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Feb 2020 00:48:44 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580950124.53.0.781176372311.issue39564@roundup.psfhosted.org>


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

This is indeed a duplicate of issue35212 (the second message there also shows a problem with implicit f-string concatenation). There's not much information in issue34364 (just a merged PR, and a mention of a PR of yours from 2 years ago that apparently never materialized).

FWIW I meant "pegen" (https://github.com/gvanrossum/pegen/) -- not sure why my mobile spell corrector turned that into "oefen" (maybe it's becoming multilingual :-).

And the reason I think called this "urgent" is that until this is fixed in CPython 3.8 we have to disable the part of our tests that compares the AST generated by pegen to the one generated by ast.parse. (We've found several other issues with incorrect column offsets in ast.parse this way, and always managed to fix them upstream. :-)

If we came up with a hacky fix, would you oppose incorporating it?

I'm guessing your alternate approach is modifying the tokenizer to treat f"x{y}z{a}b" as several tokens:

- f"x{
- y (or multiple tokens if there's a complex expression here)
- }z{
- a (same)
- }b"

(This has been proposed before by a few others, and IIRC we did it this way in ABC, in the early '80s.)

----------

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

From report at bugs.python.org  Wed Feb  5 19:55:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Feb 2020 00:55:10 +0000
Subject: [issue14149] argparse: Document how to use argument names that are
 not Python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1580950510.06.0.53065312576.issue14149@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think this one should have been closed long ago.

----------
nosy: +rhettinger
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Feb  5 20:19:21 2020
From: report at bugs.python.org (Stefano Rivera)
Date: Thu, 06 Feb 2020 01:19:21 +0000
Subject: [issue38501] multiprocessing.Pool hangs atexit (and garbage
 collection sometimes)
In-Reply-To: <1571250674.69.0.928369483471.issue38501@roundup.psfhosted.org>
Message-ID: <1580951961.04.0.0714096962334.issue38501@roundup.psfhosted.org>


Stefano Rivera <python at rivera.za.net> added the comment:

A bisect points at https://github.com/python/cpython/pull/11488 being the change that introduced this hang (bpo-35493)

----------
nosy: +stefanor

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

From report at bugs.python.org  Wed Feb  5 20:20:27 2020
From: report at bugs.python.org (Stefano Rivera)
Date: Thu, 06 Feb 2020 01:20:27 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1580952027.3.0.111077365298.issue35493@roundup.psfhosted.org>


Stefano Rivera <python at rivera.za.net> added the comment:

This change seems to be causing a deadlock in multiprocessing shut-down: bpo-38501

----------
nosy: +stefanor

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

From report at bugs.python.org  Wed Feb  5 20:21:01 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 06 Feb 2020 01:21:01 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1580952061.46.0.704071637225.issue1635741@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> 1) python-ast.c have one question, i fix it in PR18365.
> 2) most of the questions in extension module, for example: https://github.com/python/cpython/blob/master/Modules/gcmodule.c#L2019-L2022

brandt does relevant work already in PR17276?PR38823.

----------

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

From report at bugs.python.org  Wed Feb  5 20:48:00 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Feb 2020 01:48:00 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580953680.89.0.654519179637.issue39564@roundup.psfhosted.org>


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

Yes, my approach is to use the tokenizer to produce the parts of the f-string, instead of treating it as a normal string and making a second pass to parse out the pieces. I've been discussing this for a few years, and at last PyCon I talked to many tool vendors (editors, type checkers, etc.) to gather opinions, and no one was opposed. I've also had a few discussions since then, which were also positive. So I think I'll try to move ahead on it.

I'm not sure this is the best place to discuss it, but let me give a little example on why it's complicated.

Consider: f"x{y:.2f}z{a!s:10}b"

What type of token is ".2f", and how does the tokenizer recognize it? Or maybe the token is ":.2f". It can be an arbitrary sequence of characters (with a few restrictions, like no newlines), ending before a right brace. And there's the issue of backslash escapes there.

And the f"{z = :20}" thing we added doesn't make this any easier, since whitespace is significant after the "=" and before the ":", if it exists. And I need the entire text of the expression, before it's parsed, to make it work. I don't think that "unparsing" could ever be made to work in this case, or at least not so as to be compatible with 3.8 and preserving whitespace.

I really haven't looked at what's involved in the implementation in any greater depth: my first goal was (and will be) to get buy-off on the change, then to look at implementation issues. PEP 536 has some discussion of this, but if I go forward I would want to start from scratch (and reject PEP 536).

As far as the patch I was working on: the general problem is that you have to "prime" the compiler with a line number and column to start on, instead of it assuming line 1 column 1. Despite spending the better part of a week on it at the core sprints 1.5 years ago, I never got it to work (although I did delete and simplify a few functions, so it was a net win anyway). I wouldn't be opposed to a patch to fix this.

----------

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

From report at bugs.python.org  Wed Feb  5 20:58:26 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 06 Feb 2020 01:58:26 +0000
Subject: [issue37749] ipaddress - is_global method all multicast addresses and
 networks return true
In-Reply-To: <1564809406.61.0.356559045946.issue37749@roundup.psfhosted.org>
Message-ID: <1580954306.83.0.0166044887011.issue37749@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +pmoody
versions: +Python 3.9

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

From report at bugs.python.org  Wed Feb  5 21:58:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Feb 2020 02:58:13 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580957893.07.0.242376925131.issue39564@roundup.psfhosted.org>


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

Wow. Do you still have a branch with that non-working patch? Maybe there are some ideas that can be salvaged.

I'm wondering if maybe we're better leaving f-strings alone? The current code is quite voluminous, but it looks as if by the time you've addressed everything you mention using additional tokenizer state, you might end up with just as much or more convoluted code... F-strings totally rule, despite the current limitations!

----------

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

From report at bugs.python.org  Wed Feb  5 23:30:03 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Thu, 06 Feb 2020 04:30:03 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1580963403.86.0.928943285577.issue39384@roundup.psfhosted.org>


Mark Sapiro <mark at msapiro.net> added the comment:

I've researched this further, and I know how this happens. The original message contains a text/html part (in my case, the only part) which contains a base64 or quoted-printable body which when decoded contains non-ascii. It is parsed correctly by email.message_from_bytes.

It is then processed by Mailman's content filtering which retrieves html payload via

    part.get_payload(decode=True).decode(ctype, errors='replace'))

where part is the text/html part and ctype is 'utf-8' in this case. It then uses elinks, lynx or some other configured command to convert the html payload to plain text and that plain text still contains non-ascii.

It then replaces the payload and sets the content type via

    del part['content-transfer-encoding']
    part.set_payload(plain_text)
    part.set_type('text/plain')

And this results in a message which can't be flattened as_bytes.

The issue is set_payload() should encode the payload appropriately and in fact, it does if an appropriate charset is given, so this is our error in not providing a charset= argument to set_payload.

Closing this and the corresponding PR.

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

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

From report at bugs.python.org  Wed Feb  5 23:48:18 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 06 Feb 2020 04:48:18 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1580964498.1.0.675840030591.issue39555@roundup.psfhosted.org>


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


New changeset ab0d892288f3058856a8213333e8c3e4ed8a562b by Steve Dower in branch 'master':
bpo-39555: Fix distutils test to handle _d suffix on Windows debug build (GH-18357)
https://github.com/python/cpython/commit/ab0d892288f3058856a8213333e8c3e4ed8a562b


----------

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

From report at bugs.python.org  Wed Feb  5 23:48:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 06 Feb 2020 04:48:34 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1580964514.34.0.205837441351.issue39555@roundup.psfhosted.org>


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


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  6 01:55:54 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 06 Feb 2020 06:55:54 +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: <1580972154.96.0.194629997811.issue38967@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


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

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

From report at bugs.python.org  Thu Feb  6 02:21:40 2020
From: report at bugs.python.org (Isuru Fernando)
Date: Thu, 06 Feb 2020 07:21:40 +0000
Subject: [issue33351] Support compiling with clang-cl on Windows
In-Reply-To: <1524631004.17.0.682650639539.issue33351@psf.upfronthosting.co.za>
Message-ID: <1580973700.8.0.261340386914.issue33351@roundup.psfhosted.org>


Change by Isuru Fernando <isuruf at gmail.com>:


----------
pull_requests: +17747
pull_request: https://github.com/python/cpython/pull/18371

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

From report at bugs.python.org  Thu Feb  6 02:34:28 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 06 Feb 2020 07:34:28 +0000
Subject: [issue36792] [Windows] time: crash on formatting time with de_DE
 locale
In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org>
Message-ID: <1580974468.64.0.150746342352.issue36792@roundup.psfhosted.org>


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

> Perhaps it would be easy to do the replacement of underscores with 
> hyphens on Windows in this function? I think that's safe enough, yes?

Recent releases of ucrt implement this translation from underscore to hyphen for us, so this suggestion is no longer always necessary. However, I don't know what the PEP-11 stance is regarding the modern lifecycle policy of Windows 10. Will Python support a release for as long as it's supported by the enterprise version? For example, support for 1709 enterprise ends on 2020-04-14, so if we followed that, then Python 3.9 would require Windows 10 1803 or higher. That seems wrong while we're still supporting Windows 8.1, but what will the stance be when Python supports only Windows versions that use the modern lifecycle?

----------

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

From report at bugs.python.org  Thu Feb  6 03:20:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Feb 2020 08:20:48 +0000
Subject: [issue39567] Add audit for os.walk, os.fwalk,
 Path.glob() and Path.rglob()
Message-ID: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>


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

See issue38149.

There is an audit for os.scandir(), but it would be useful to have information about higher-level operations.

----------
components: Library (Lib)
messages: 361472
nosy: serhiy.storchaka, steve.dower
priority: normal
severity: normal
status: open
title: Add audit for os.walk, os.fwalk, Path.glob() and Path.rglob()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Feb  6 03:22:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Feb 2020 08:22:06 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1580977326.23.0.250420804098.issue39567@roundup.psfhosted.org>


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


----------
title: Add audit for os.walk, os.fwalk, Path.glob() and Path.rglob() -> Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

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

From report at bugs.python.org  Thu Feb  6 03:24:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Feb 2020 08:24:46 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1580977486.53.0.922388185932.issue39567@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  6 03:26:08 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 06 Feb 2020 08:26:08 +0000
Subject: [issue36792] [Windows] time: crash on formatting time with de_DE
 locale
In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org>
Message-ID: <1580977568.81.0.984499067128.issue36792@roundup.psfhosted.org>


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

> Even some well known locale names still use the utf-8 code page.  Most 
> seem to uncommon, but at least es-BR (Brazil) does and would still 
> fall victim to these UCRT bugs.

es-BR is a custom locale for the Spanish language in Brazil, as opposed to the common Portuguese locale (pt-BR). It's a Unicode-only locale, which means its ANSI codepage is 0. Since 0 is CP_ACP, its effective ANSI codepage is the system or process ANSI codepage. 

For example:

    >>> kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
    >>> buf = (ctypes.c_wchar * 10)()

Portuguese in Brazil uses codepage 1252 as its ANSI codepage:

    >>> n = kernel32.GetLocaleInfoEx('pt-BR', 0x1004, buf, 10)
    >>> buf.value
    '1252'

Spanish in Brazil uses CP_ACP:

    >>> n = kernel32.GetLocaleInfoEx('es-BR', 0x1004, buf, 10)
    >>> buf.value
    '0'

hi-IN (Hindi, India) is a common Unicode-only locale:

    >>> n = kernel32.GetLocaleInfoEx('hi-IN', 0x1004, buf, 10)
    >>> buf.value
    '0'

ucrt has switched to using UTF-8 for Unicode-only locales:

    >>> locale.setlocale(locale.LC_CTYPE, 'hi_IN')
    'hi_IN'
    >>> ucrt = ctypes.CDLL('ucrtbase', use_errno=True)
    >>> ucrt.___lc_codepage_func()
    65001

Note that ucrt uses UTF-8 for Unicode-only locales only when using an explicitly named locale such as "hi_IN", "Hindi_India" or even just "Hindi". On the other hand, if a Unicode-only locale is used implicitly, ucrt instead uses the system ANSI codepage:

    >>> locale.setlocale(locale.LC_CTYPE, '')
    'Hindi_India.1252'
    >>> ucrt.___lc_codepage_func()
    1252

I suppose this is for backwards compatibility. Windows 10 at least supports setting the system ANSI codepage to UTF-8, or overriding the process ANSI codepage to UTF-8 via the application manifest "actveCodePage" setting. For the latter, I modified the manifest in a "python_utf8.exe" copy of the normal "python.exe" binary, which is simpler than having to reboot to change the system locale:

    C:\>python_utf8 -q

    >>> import locale
    >>> locale.setlocale(locale.LC_CTYPE, '')
    'Hindi_India.utf8'

----------

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

From report at bugs.python.org  Thu Feb  6 03:26:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Feb 2020 08:26:41 +0000
Subject: [issue38149] sys.audit() is called multiple times for glob.glob()
In-Reply-To: <1568365671.05.0.0499818085141.issue38149@roundup.psfhosted.org>
Message-ID: <1580977601.6.0.672242471378.issue38149@roundup.psfhosted.org>


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


New changeset 54b4f14712b9350f11c983f1c8ac47a3716958a7 by Serhiy Storchaka in branch 'master':
bpo-38149: Call sys.audit() only once per call for glob.glob(). (GH-18360)
https://github.com/python/cpython/commit/54b4f14712b9350f11c983f1c8ac47a3716958a7


----------

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

From report at bugs.python.org  Thu Feb  6 03:26:58 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 08:26:58 +0000
Subject: [issue38149] sys.audit() is called multiple times for glob.glob()
In-Reply-To: <1568365671.05.0.0499818085141.issue38149@roundup.psfhosted.org>
Message-ID: <1580977618.77.0.628786561747.issue38149@roundup.psfhosted.org>


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


----------
pull_requests: +17749
pull_request: https://github.com/python/cpython/pull/18373

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

From report at bugs.python.org  Thu Feb  6 03:45:23 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 08:45:23 +0000
Subject: [issue38149] sys.audit() is called multiple times for glob.glob()
In-Reply-To: <1568365671.05.0.0499818085141.issue38149@roundup.psfhosted.org>
Message-ID: <1580978723.37.0.616798228521.issue38149@roundup.psfhosted.org>


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


New changeset 708f472dd92f4f46c27ace710492da65da4a3319 by Miss Islington (bot) in branch '3.8':
bpo-38149: Call sys.audit() only once per call for glob.glob(). (GH-18360)
https://github.com/python/cpython/commit/708f472dd92f4f46c27ace710492da65da4a3319


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

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

From report at bugs.python.org  Thu Feb  6 03:57:42 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 06 Feb 2020 08:57:42 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1580979462.01.0.75490287512.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17750
pull_request: https://github.com/python/cpython/pull/18374

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

From report at bugs.python.org  Thu Feb  6 04:02:02 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 06 Feb 2020 09:02:02 +0000
Subject: [issue36792] [Windows] time: crash on formatting time with de_DE
 locale
In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org>
Message-ID: <1580979722.66.0.188032500066.issue36792@roundup.psfhosted.org>


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

That the CRT caches the tzname strings as ANSI multibyte strings is frustrating -- whether or not it's buggy. I would expect there to be a _wtzname cache of the native OS strings that wcsftime uses directly, with no potential for failed encodings (e.g. empty strings or mojibake).

It's also strange that it encodes the time-zone name using the system ANSI codepage in the C locale. Normally LC_CTYPE in the C locale uses Latin-1, due to simple casting between WCHAR and CHAR. This leads to mojibake when the ANSI time-zone name gets decoded as Latin-1 by an internal mbstowcs call in wcsftime. I'm not saying one or the other is necessarily right, but more care should haven gone into this. At the very least, if we're stuck with system ANSI tzname strings in the C locale, then a flag should be set that tells wcsftime to decode them as system ANSI strings instead of via mbstowcs.

Also, the timezone name is determined by the preferred UI language of the current user, which is not necessarily compatible with the system ANSI codepage. It's not even necessarily compatible with the user-locale ANSI codepage, as used by setlocale(LC_CTYPE, ""). Windows 10 at least provides an option to sync the user locale with the user preferred UI language. IMO, this is a strong argument in favor of using _wtzname wide-character strings. UI Language (MUI) and locale are not tightly coupled in Windows NLS.

Here's an example where the user's preferred language is Hindi, and the time zone name is "??????? ??????? ???" (i.e. Coordinated Universal Time), but the system locale is English with codepage 1252 (for Western European languages). This is a normal configuration if the system locale doesn't have beta UTF-8 support enabled, or if the process ANSI codepage isn't overridden to UTF-8 via the "activeCodePage" manifest setting.

The tzname strings normally get set by a one-time _tzset call, and they're only reset if tzset is called manually. tzset uses the system ANSI encoding if LC_CTYPE is the "C" locale (again, normally ucrt uses Latin-1 in the "C" locale). Since the encoding of the Hindi timezone name to codepage 1252 contains the default character ("?"), which is not allowed, tzset sets the tzname strings to empty strings.

    import ctypes, locale, time
    ucrt = ctypes.CDLL('ucrtbase', use_errno=True)
    ucrt.__tzname.restype = ctypes.POINTER(ctypes.c_char_p)
    tzname = ucrt.__tzname()

    >>> locale.setlocale(locale.LC_CTYPE, 'C')
    'C'
    >>> ucrt._tzset()
    0
    >>> tzname[0], tzname[1]
    (b'', b'')
    >>> time.strftime('%Z')
    ''

If we update the LC_CTYPE category to use UTF-8, the cached tzname value doesn't get automatically updated, and strftime still returns an empty string:

    >>> locale.setlocale(locale.LC_CTYPE, '.utf8')
    'Hindi_India.utf8'

    >>> tzname[0], tzname[1]
    (b'', b'')
    >>> time.strftime('%Z')
    ''

The tzname values get updated if we manually call tzset:

    >>> ucrt._tzset()
    0
    >>> tzname[0].decode('utf-8'), tzname[1].decode('utf-8')
    ('??????? ??????? ???', '??????? ??????? ???')

However, LC_TIME is still in the "C" locale. strftime uses system ANSI (1252) in this case, so the encoded result from the CRT strftime call ends up using the default character (?):

    >>> time.strftime('%Z')
    '??????? ??????? ???'

If we set LC_TIME to UTF-8, we finally get a valid result:

    >>> locale.setlocale(locale.LC_TIME, '.utf8')
    'Hindi_India.utf8'
    >>> time.strftime('%Z')
    '??????? ??????? ???'

We wouldn't have to worry about LC_TIME here if Python called C wcsftime instead of C strftime. The problem that bpo-10653 was trying to work around is a design flaw in the C runtime library, and calling strftime is not a solution. 

Here's a variation on my example in msg243660, continuing with the current Hindi example. The setup in this example uses UTF-8 as the system ANSI codepage (via python_utf8.exe) and sets LC_CTYPE to the "C" locale. This yields the following monstrosity:

    >>> time.strftime('%Z')
    '?\xa0?????\xa0?????\xa0?????\xa0???\x8d?\xa0?????\xa0?????\xa0???? ?\xa0?????\xa0???\x88?\xa0?????\xa0???\x8d?\xa0?????\xa0?????\xa0???\x95 ?\xa0?????\xa0?????\xa0????'

It's due to the following sequence of encoding and decoding operations:

    >>> mbs_lcctype_utf8 = '??????? ??????? ???'.encode('utf-8')
    >>> wcs_lcctype_latin1 = mbs_lcctype_utf8.decode('latin-1')
    >>> mbs_lctime_utf8 = wcs_lcctype_latin1.encode('utf-8')

This last one is from PyUnicode_DecodeLocaleAndSize and mbstowcs:

    >>> py_str_lcctype_latin1 = mbs_lctime_utf8.decode('latin-1')
    >>> py_str_lcctype_latin1 == time.strftime('%Z')
    True

----------

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

From report at bugs.python.org  Thu Feb  6 04:23:19 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Feb 2020 09:23:19 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580980999.2.0.913112384097.issue39564@roundup.psfhosted.org>


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

I'll see if I can dig up the patch today. If I can find it, I'll attach it to issue 34364.

This is really the first time I've tried to write down all of the issues related to tokenizing f-strings. It does seem a little daunting, but I'm not done noodling it through. At first blush it looks like the tokenizer would need to remember if it's inside an f-string or not and switch to different rules if so. Which doesn't exactly describe your average tokenizer, but I'm not sure how Python's tokenizer would need to be changed to deal with it, or how messy that change would be.

I should probably write an informational PEP about parsing f-strings. And I should include the reason I went with the "just a regular string which is later hand-parsed" approach: at the time, f-strings were a controversial topic (there were any number of reddit threads predicting doom and gloom if they were added). By parsing them as just regular strings with one simple added string prefix, it allowed existing tooling (editors, syntax highlighters, etc.) to easily skip over them just by recognizing 'f' as an additional string prefix.

----------

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

From report at bugs.python.org  Thu Feb  6 06:08:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 06 Feb 2020 11:08:20 +0000
Subject: [issue38149] sys.audit() is called multiple times for glob.glob()
In-Reply-To: <1568365671.05.0.0499818085141.issue38149@roundup.psfhosted.org>
Message-ID: <1580987300.9.0.236766034098.issue38149@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Feb  6 06:14:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 11:14:41 +0000
Subject: [issue39541] distutils: Remove bdist_wininst (Windows .exe
 installers) in favor of bdist_wheel (.whl)
In-Reply-To: <1580735997.04.0.997914254478.issue39541@roundup.psfhosted.org>
Message-ID: <1580987681.81.0.212114656574.issue39541@roundup.psfhosted.org>


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

Small update, my setuptools change has been merged:

" Add support for installing scripts in environments where bdist_wininst is missing (i.e. Python 3.9)."

https://github.com/pypa/setuptools/commit/5d17586a56077dfa3109a5861cf0ff579095a42e

----------

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

From report at bugs.python.org  Thu Feb  6 07:03:30 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 06 Feb 2020 12:03:30 +0000
Subject: =?utf-8?q?=5Bissue39549=5D_The_reprlib=2ERepr_type_should_permit_the_?=
 =?utf-8?q?=E2=80=9Cfillvalue=E2=80=9D_to_be_set_by_the_user?=
In-Reply-To: <1580778450.13.0.746492669497.issue39549@roundup.psfhosted.org>
Message-ID: <1580990610.07.0.59312392601.issue39549@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +rhettinger
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/issue39549>
_______________________________________

From report at bugs.python.org  Thu Feb  6 07:37:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Feb 2020 12:37:36 +0000
Subject: [issue39566] inspect.Signature.__init__ asks for parameters as dict
 but treats as list
In-Reply-To: <1580945844.01.0.0291811112362.issue39566@roundup.psfhosted.org>
Message-ID: <1580992656.67.0.496823323029.issue39566@roundup.psfhosted.org>


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

It says list in the __init__ doc : https://github.com/python/cpython/blob/54b4f14712b9350f11c983f1c8ac47a3716958a7/Lib/inspect.py#L2759

It says that parameters is a public property that returns a mapping of parameter name to object at : https://github.com/python/cpython/blob/54b4f14712b9350f11c983f1c8ac47a3716958a7/Lib/inspect.py#L2734 . The change to dict was done with 2cca8efe46935c39c445f585bce54954fad2485b .

I can see the public attribute returning dictionary. Can you please point to the doc where it says the parameter should be a dictionary to the constructor?

----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Feb  6 07:42:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 12:42:10 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580992930.56.0.443529780633.issue39350@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17751
pull_request: https://github.com/python/cpython/pull/18375

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

From report at bugs.python.org  Thu Feb  6 07:43:26 2020
From: report at bugs.python.org (Stephen Balousek)
Date: Thu, 06 Feb 2020 12:43:26 +0000
Subject: [issue38686] WWW-Authenticate qop="auth,auth-int" rejected by urllib
In-Reply-To: <1572881244.97.0.30421713667.issue38686@roundup.psfhosted.org>
Message-ID: <1580993006.84.0.380465163787.issue38686@roundup.psfhosted.org>


Change by Stephen Balousek <stephen at balousek.net>:


----------
pull_requests: +17752
pull_request: https://github.com/python/cpython/pull/18338

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

From report at bugs.python.org  Thu Feb  6 07:56:25 2020
From: report at bugs.python.org (Another One)
Date: Thu, 06 Feb 2020 12:56:25 +0000
Subject: [issue39568] FORMATTING grouping_option ValueError: Cannot specify ', 
 ' with ...
Message-ID: <1580993785.28.0.694930470564.issue39568@roundup.psfhosted.org>


New submission from Another One <tn5v2l at gmail.com>:

Example for binary representation:

>>> x = 123456
>>> print("{:,b}".format(x))
Traceback (most recent call last):
  File "<pyshell#261>", line 1, in <module>
    print("{:,b}".format(x))
ValueError: Cannot specify ',' with 'b'.

Why? Comma work only with decimals?

But '_' groups delimiter properly work with any integer representation including decimals, hexadecimals, binaries, octals, etc..

----------
messages: 361480
nosy: Another One
priority: normal
severity: normal
status: open
title: FORMATTING grouping_option ValueError: Cannot specify ',' with ...
versions: Python 3.8

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

From report at bugs.python.org  Thu Feb  6 08:11:07 2020
From: report at bugs.python.org (Stephen Balousek)
Date: Thu, 06 Feb 2020 13:11:07 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1580994667.31.0.700528267392.issue39548@roundup.psfhosted.org>


Change by Stephen Balousek <stephen at balousek.net>:


----------
versions: +Python 3.7

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

From report at bugs.python.org  Thu Feb  6 08:42:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 13:42:26 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580996546.38.0.10705696753.issue39350@roundup.psfhosted.org>


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

I tried but failed to write a test to mimick numpy.int64 type. I tried to build a type which implements numbers.Rational but don't inherit from int, but there are way too many methods that I have to implement :-(

Morever, installing numpy on a Python 3.9 virtual environment is quite tricky. Lhe latest Cython release (0.29.14) isn't compatible with Python 3.9.

Miro gave me a command to install Cython on Python 3.9:

python -m pip install https://github.com/cython/cython/archive/master.tar.gz --install-option="--no-cython-compile"

But then "pip install numpy" tries to reinstall Cython which fails :-/

----------
resolution: fixed -> 

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

From report at bugs.python.org  Thu Feb  6 08:46:24 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Feb 2020 13:46:24 +0000
Subject: [issue39568] FORMATTING grouping_option ValueError: Cannot specify ', 
 ' with ...
In-Reply-To: <1580993785.28.0.694930470564.issue39568@roundup.psfhosted.org>
Message-ID: <1580996784.79.0.754239575884.issue39568@roundup.psfhosted.org>


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

No one thought it made sense to have a comma every 3 bits. Or for octal or hex, either.

Do you have some specific use case where it makes sense?

----------
nosy: +eric.smith

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

From report at bugs.python.org  Thu Feb  6 09:19:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 14:19:57 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580998797.08.0.0062662763261.issue39350@roundup.psfhosted.org>


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

I managed to test my PR with numpy:

$ env/bin/python 
>>> import fractions
>>> import numpy
>>> f=fractions.Fraction(numpy.int64(1*3), numpy.int64(2*3))
>>> f
Fraction(1, 2)
>>> type(f.numerator)
<class 'numpy.int64'>
>>> type(f.denominator)
<class 'numpy.int64'>

So it works as expected: numerator and denominator have the expected type, and there is no exception ;-)

I used the following commands to get numpy in a Python 3.9 virtual environment:

./python -m venv env
env/bin/python -m pip install https://github.com/cython/cython/archive/master.tar.gz --install-option="--no-cython-compile"
curl -O https://files.pythonhosted.org/packages/40/de/0ea5092b8bfd2e3aa6fdbb2e499a9f9adf810992884d414defc1573dca3f/numpy-1.18.1.zip
unzip -d . numpy-1.18.1.zip
cd numpy-1.18.1/
../env/bin/python setup.py install

----------

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

From report at bugs.python.org  Thu Feb  6 09:33:55 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 06 Feb 2020 14:33:55 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1580999635.02.0.798400943641.issue39564@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Also note that for pegen this is a solved problem. If we decide to change the parser, it may not be worth it to spend too much time on a universal solution.

----------

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

From report at bugs.python.org  Thu Feb  6 09:34:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 14:34:29 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580999669.02.0.413679217123.issue39350@roundup.psfhosted.org>


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

FYI the full numpy test suite pass with PR 18375:

(env) vstinner at apu$ python runtests.py  -v
(...)
======================= 9879 passed, 443 skipped, 180 deselected, 17 xfailed, 3 xpassed in 305.17s (0:05:05) =======================

----------

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

From report at bugs.python.org  Thu Feb  6 09:46:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 14:46:01 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1581000361.3.0.0388703916038.issue38823@roundup.psfhosted.org>


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


New changeset d2f96672642cc51b92f61b951ca1b11d615c12d1 by Brandt Bucher in branch 'master':
bpo-38823: Fix refleaks in _ast initialization error path (GH-17276)
https://github.com/python/cpython/commit/d2f96672642cc51b92f61b951ca1b11d615c12d1


----------

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

From report at bugs.python.org  Thu Feb  6 09:48:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 14:48:33 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1581000513.28.0.529775275376.issue39245@roundup.psfhosted.org>


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


New changeset 3f563cea567fbfed9db539ecbbacfee2d86f7735 by Petr Viktorin in branch 'master':
bpo-39245: Make Vectorcall C API public (GH-17893)
https://github.com/python/cpython/commit/3f563cea567fbfed9db539ecbbacfee2d86f7735


----------

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

From report at bugs.python.org  Thu Feb  6 09:54:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 14:54:11 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1581000851.01.0.594521142054.issue39274@roundup.psfhosted.org>


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


New changeset 427c84f13f7719e6014a21bd1b81efdc02a046fb by Sebastian Berg in branch 'master':
bpo-39274: Ensure Fraction.__bool__() returns a bool (GH-18017)
https://github.com/python/cpython/commit/427c84f13f7719e6014a21bd1b81efdc02a046fb


----------

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

From report at bugs.python.org  Thu Feb  6 09:55:51 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 14:55:51 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1581000951.11.0.202957245426.issue39274@roundup.psfhosted.org>


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


----------
pull_requests: +17753
pull_request: https://github.com/python/cpython/pull/18376

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

From report at bugs.python.org  Thu Feb  6 09:57:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 14:57:06 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1581001026.23.0.449676820364.issue39274@roundup.psfhosted.org>


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


----------
pull_requests: +17754
pull_request: https://github.com/python/cpython/pull/18377

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

From report at bugs.python.org  Thu Feb  6 09:59:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 14:59:07 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1581001147.9.0.665398938137.issue39274@roundup.psfhosted.org>


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

Thanks Sebastian Berg for the fix, and thanks Fran?ois Durand for the bug report! This issue is fixed in the master branch, and backports to 3.7 and 3.8 will land soon automatically (once the CI tests pass).

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

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

From report at bugs.python.org  Thu Feb  6 10:12:23 2020
From: report at bugs.python.org (Another One)
Date: Thu, 06 Feb 2020 15:12:23 +0000
Subject: [issue39568] FORMATTING grouping_option ValueError: Cannot specify ', 
 ' with ...
In-Reply-To: <1580993785.28.0.694930470564.issue39568@roundup.psfhosted.org>
Message-ID: <1581001943.66.0.777128133.issue39568@roundup.psfhosted.org>


Another One <tn5v2l at gmail.com> added the comment:

Not for 3 bits, just for 4 bits, like this:
>>> print("{:_b}".format(123456))
1_1110_0010_0100_0000

And as I already said: "But '_' groups delimiter properly work with any integer representation including decimals, hexadecimals, binaries, octals, etc.." Not only for binaries.
Why comma delimiter is not?
Logic must be the same. Simple use the one procedure for '_' delimiter with permit comma as parameter, instead of two different logic.

----------

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

From report at bugs.python.org  Thu Feb  6 10:13:43 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 15:13:43 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1581002023.24.0.540880244806.issue39274@roundup.psfhosted.org>


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


New changeset 0d03a1028200646479ef9bb0ad8973d0e73f9525 by Miss Islington (bot) in branch '3.8':
bpo-39274: Ensure Fraction.__bool__() returns a bool (GH-18017)
https://github.com/python/cpython/commit/0d03a1028200646479ef9bb0ad8973d0e73f9525


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

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

From report at bugs.python.org  Thu Feb  6 10:14:42 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 15:14:42 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1581002082.46.0.622545410365.issue39274@roundup.psfhosted.org>


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


New changeset 705d271d553b77fd170d27ab8d0f11f638c7f145 by Miss Islington (bot) in branch '3.7':
bpo-39274: Ensure Fraction.__bool__() returns a bool (GH-18017)
https://github.com/python/cpython/commit/705d271d553b77fd170d27ab8d0f11f638c7f145


----------

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

From report at bugs.python.org  Thu Feb  6 10:25:54 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 06 Feb 2020 15:25:54 +0000
Subject: [issue39568] FORMATTING grouping_option ValueError: Cannot specify ', 
 ' with ...
In-Reply-To: <1580993785.28.0.694930470564.issue39568@roundup.psfhosted.org>
Message-ID: <1581002754.96.0.670734446433.issue39568@roundup.psfhosted.org>


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

Well, you asked why commas only work with decimals and I told you.

Adding "_" would require a PEP. See PEP 378 if you want to write something similar for "_". I think it's a decent idea. You'll have to decide between 4 and 8 bits, and what to do with octal and hex.

But I'm going to close this issue, since it's about commas and non-base 10 representations. If you want to pursue underscores, the next step would be to discuss it on the python-ideas mailing list.

----------
assignee:  -> eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Feb  6 11:00:25 2020
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=)
Date: Thu, 06 Feb 2020 16:00:25 +0000
Subject: [issue39569] Is the return value of pathlib.Path.glob() sorted?
Message-ID: <1581004825.17.0.345840814568.issue39569@roundup.psfhosted.org>


New submission from Bj?rn Lindqvist <bjourne at gmail.com>:

It would be great if the docs were clearer on what you can assume on the ordering of pathlib.Path.glob() calls. Is it sorted? Is it the same in consecutive calls? I'm guessing you can't assume anything at all, which I think should be clarified in the docs.

----------
assignee: docs at python
components: Documentation
messages: 361494
nosy: Bj?rn.Lindqvist, docs at python
priority: normal
severity: normal
status: open
title: Is the return value of pathlib.Path.glob() sorted?
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu Feb  6 11:01:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 16:01:25 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1581004885.51.0.932320047345.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17755
pull_request: https://github.com/python/cpython/pull/18378

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

From report at bugs.python.org  Thu Feb  6 11:26:37 2020
From: report at bugs.python.org (UltraLutra)
Date: Thu, 06 Feb 2020 16:26:37 +0000
Subject: [issue39570] Python 3.7.3 Crash on msilib actions
Message-ID: <1581006397.33.0.114674633699.issue39570@roundup.psfhosted.org>


New submission from UltraLutra <eitaniasaf at gmail.com>:

Hello,

I'm trying to read MSI files using msilib.
Some files make python crash on Record.GetString of a specific cell.
Attached is one of the files that causes the crash, and this is the code that is causing it to crash:
db = msilib.OpenDatabase('6bcd682374529631be60819d20a71d9d40c67bf0b1909faa459298eda998f833', msilib.MSIDBOPEN_READONLY)
query = db.OpenView(f'SELECT * FROM Registry')
query.Execute(None)
for i in range(6):
    record = query.Fetch()
record.GetString(5)

The crash seems to be by trying to read the Value columns of the last row in the Registry table.

file: https://github.com/AsafEitani/msilib_crash

----------
components: Windows
messages: 361495
nosy: UltraLutra, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.7.3 Crash on msilib actions
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Thu Feb  6 11:56:26 2020
From: report at bugs.python.org (Natanael Copa)
Date: Thu, 06 Feb 2020 16:56:26 +0000
Subject: [issue21622] ctypes.util incorrectly fails for libraries without
 DT_SONAME
In-Reply-To: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za>
Message-ID: <1581008186.53.0.57959781304.issue21622@roundup.psfhosted.org>


Change by Natanael Copa <ncopa at alpinelinux.org>:


----------
pull_requests: +17756
pull_request: https://github.com/python/cpython/pull/18380

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

From report at bugs.python.org  Thu Feb  6 11:58:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Feb 2020 16:58:56 +0000
Subject: [issue39569] Is the return value of pathlib.Path.glob() sorted?
In-Reply-To: <1581004825.17.0.345840814568.issue39569@roundup.psfhosted.org>
Message-ID: <1581008336.49.0.500597982535.issue39569@roundup.psfhosted.org>


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

See also discussion at issue38764. I guess it's not sorted as per msg356356.

----------
nosy: +serhiy.storchaka, xtreak

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

From report at bugs.python.org  Thu Feb  6 12:00:32 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Thu, 06 Feb 2020 17:00:32 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581008432.21.0.402007690829.issue39491@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


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

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

From report at bugs.python.org  Thu Feb  6 12:09:39 2020
From: report at bugs.python.org (Sam Gross)
Date: Thu, 06 Feb 2020 17:09:39 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
Message-ID: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>


New submission from Sam Gross <colesbury at gmail.com>:

A recent commit added a typedef for PyTypeObject in Include/object.h

https://github.com/python/cpython/commit/0e4e735d06967145b49fd00693627f3624991dbc

This duplicates the typedef in Include/cpython/object.h. Building with clang now issues a warning:

./Include/cpython/object.h:274:3: warning: redefinition of typedef 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]

This is due to the combination of `-Wall` and `-std=c99`. GCC will only warn if the `-pedantic` option is specified.

----------
components: C API
messages: 361497
nosy: colesbury, vstinner
priority: normal
severity: normal
status: open
title: clang warns "warning: redefinition of typedef 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
versions: Python 3.9

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

From report at bugs.python.org  Thu Feb  6 12:17:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 17:17:33 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581009453.15.0.887804914811.issue1294959@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17757
pull_request: https://github.com/python/cpython/pull/18381

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

From report at bugs.python.org  Thu Feb  6 12:39:45 2020
From: report at bugs.python.org (Nicholas Matthews)
Date: Thu, 06 Feb 2020 17:39:45 +0000
Subject: [issue39566] inspect.Signature.__init__ asks for parameters as dict
 but treats as list
In-Reply-To: <1580945844.01.0.0291811112362.issue39566@roundup.psfhosted.org>
Message-ID: <1581010785.99.0.14160996124.issue39566@roundup.psfhosted.org>


Nicholas Matthews <nmatthews at asapp.com> added the comment:

I originally filed an issue believing the documentation for inspect.Signature was incorrect; I now think I misread the documentation. (Apologies, I'm used to a different docstring format)

----------

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

From report at bugs.python.org  Thu Feb  6 12:48:02 2020
From: report at bugs.python.org (Enji Cooper)
Date: Thu, 06 Feb 2020 17:48:02 +0000
Subject: [issue39565] Modules/signalmodule.c creates handlers for signals
 bound by `NSIG`; requires fudging to support realtime signals, etc
In-Reply-To: <1580940907.68.0.904788237522.issue39565@roundup.psfhosted.org>
Message-ID: <1581011282.7.0.479326941453.issue39565@roundup.psfhosted.org>


Change by Enji Cooper <yaneurabeya at gmail.com>:


----------
title: Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc -> Modules/signalmodule.c creates handlers for signals bound by `NSIG`; requires fudging to support realtime signals, etc

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

From report at bugs.python.org  Thu Feb  6 12:48:15 2020
From: report at bugs.python.org (Enji Cooper)
Date: Thu, 06 Feb 2020 17:48:15 +0000
Subject: [issue39565] Modules/signalmodule.c creates handlers for signals
 bounded by `NSIG`; requires fudging to support realtime signals, etc
In-Reply-To: <1580940907.68.0.904788237522.issue39565@roundup.psfhosted.org>
Message-ID: <1581011295.45.0.567148796164.issue39565@roundup.psfhosted.org>


Change by Enji Cooper <yaneurabeya at gmail.com>:


----------
title: Modules/signalmodule.c creates handlers for signals bound by `NSIG`; requires fudging to support realtime signals, etc -> Modules/signalmodule.c creates handlers for signals bounded by `NSIG`; requires fudging to support realtime signals, etc

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

From report at bugs.python.org  Thu Feb  6 13:21:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Feb 2020 18:21:56 +0000
Subject: [issue39566] inspect.Signature.__init__ asks for parameters as dict
 but treats as list
In-Reply-To: <1580945844.01.0.0291811112362.issue39566@roundup.psfhosted.org>
Message-ID: <1581013316.18.0.895790802905.issue39566@roundup.psfhosted.org>


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

No problem, closing it as not a bug. Feel free to reopen if needed.

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

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

From report at bugs.python.org  Thu Feb  6 13:24:31 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Feb 2020 18:24:31 +0000
Subject: [issue39569] Is the return value of pathlib.Path.glob() sorted?
In-Reply-To: <1581004825.17.0.345840814568.issue39569@roundup.psfhosted.org>
Message-ID: <1581013471.42.0.820836008546.issue39569@roundup.psfhosted.org>


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

The problem is you would have to say the same thing for all functions that return a list or touch the file system. So it's typically better to just assume unsorted and you can't expect idempotent results when dealing with the OS.

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

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

From report at bugs.python.org  Thu Feb  6 13:55:01 2020
From: report at bugs.python.org (Chris Withers)
Date: Thu, 06 Feb 2020 18:55:01 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1581015301.37.0.414718126016.issue39551@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Apologies, but I'm still not sure what "the modules are published" means?
"publish "x" as a child onto the package" also doesn't mean much to me, I'm afraid. Are you aware of any importlib docs or some such which might be able to explain this to me?

When "It can still have normal Python modules as a child which aren't immutable", what happens when you try to patch the immutable module? What happens if you try to patch the mutable module below it?

When "the assignment is ignored with a warning.", what is doing that ignoring?

Unless I'm missing something, this feels like such an edge case I'm not sure mock.patch should be trying to support it. Should this be something that is handled by your immutable import thing?

----------

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

From report at bugs.python.org  Thu Feb  6 14:59:04 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 06 Feb 2020 19:59:04 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1581019144.57.0.813056950902.issue39537@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Serhiy,
How would you handle bytecodes that have no line number?

----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Thu Feb  6 15:08:00 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Feb 2020 20:08:00 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
Message-ID: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

The docs mention __total__, but there's no mention of how to actually set that attribute, nor what it actually represents.

P.S. https://github.com/python/cpython/blob/master/Lib/typing.py#L16 says TypedDict "may be added soon"; I think that's outdated. ;)

----------
assignee: docs at python
components: Documentation
messages: 361503
nosy: brett.cannon, docs at python, gvanrossum, levkivskyi
priority: normal
severity: normal
stage: needs patch
status: open
title: [typing] TypedDict's 'total' argument is undocumented
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Feb  6 16:27:50 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 06 Feb 2020 21:27:50 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1581024470.63.0.9100873746.issue39551@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

Sorry, publish may not necessarily be the best term.  When you do "from foo import bar" and foo is a package Python will set the bar module onto the foo module.  That leads to the common mistake of doing "import foo" and then "foo.bar.baz" and later removing the thing that do "from foo import bar" and having things blow up later.

Without additional support there's no way to patch the immutable module.  We can provide a mode where we enable the patching for testing and disable it in a production environment though.  That basically just involves passing a proxy object down to Mock.  And monkey patching the mutable module is perfectly fine.

The thing that's doing the ignoring of the assignment is the import system.  So it's now okay if the package raises an AttributeError.

There's not really a great way to work around this other than just bypassing mock's resolution of the object here - i.e. replacing mock.patch along with _get_target, _importer, and _dot_lookup and calling mock._patch directly, which isn't very nice (but is do-able).

And while this is a strange way to arrive at a module existing in sys.modules but not being on the package it is something that can happen in the normal course of imports, hence the reason why the import system handles this by checking sys.modules today.  It's also just turning what is currently an error while mocking into a success case with a simple few line change.

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

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

From report at bugs.python.org  Thu Feb  6 16:41:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 21:41:47 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1581025307.6.0.551591244083.issue39542@roundup.psfhosted.org>


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


New changeset 2844336e6bb0dc932d710be5f4d8c126d0768d03 by Victor Stinner in branch 'master':
bpo-39542: Document limited C API changes (GH-18378)
https://github.com/python/cpython/commit/2844336e6bb0dc932d710be5f4d8c126d0768d03


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:09:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 22:09:45 +0000
Subject: [issue39542] Cleanup object.h header
In-Reply-To: <1580744521.06.0.137468585162.issue39542@roundup.psfhosted.org>
Message-ID: <1581026985.34.0.465092249586.issue39542@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17758
pull_request: https://github.com/python/cpython/pull/18384

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39542>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:09:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 22:09:52 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581026992.45.0.153441690486.issue39571@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Sorry, I only tested GCC and I forgot that clang is more pedantic on duplicated typedef. I looked better with PyTypeObject, but the fix is easy: just revert my change: PR 18384.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:14:10 2020
From: report at bugs.python.org (Sam Gross)
Date: Thu, 06 Feb 2020 22:14:10 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581027250.42.0.173896186519.issue39571@roundup.psfhosted.org>


Sam Gross <colesbury at gmail.com> added the comment:

Alternatively I think you can just remove the typedef from Include/cpython/object.h since Include/object.h is always included first. i.e.:

typedef struct _typeobject {
  ...
} PyTypeObject;

to simply

struct _typeobject {
  ...
};

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:16:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 22:16:25 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581027385.87.0.162731780759.issue39571@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17759
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18385

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:16:55 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 06 Feb 2020 22:16:55 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1581027415.94.0.215341761161.issue39534@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 446463f8dbce0556be8020914f37089b63bb8ab6 by Julien Palard in branch 'master':
bpo-39534: Doc: Clarify return in finally (GH-18324)
https://github.com/python/cpython/commit/446463f8dbce0556be8020914f37089b63bb8ab6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39534>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:17:05 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 22:17:05 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1581027425.0.0.601425286934.issue39534@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17760
pull_request: https://github.com/python/cpython/pull/18386

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39534>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:17:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 22:17:12 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581027432.73.0.63305444154.issue39571@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Alternatively I think you can just remove the typedef from Include/cpython/object.h since Include/object.h is always included first. i.e.:

Oh, nice! I proposed PR 18385. Would you mind to confirm that it fix the issue for you? At least, I tested manually and the clang warning goes away with this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:17:23 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 22:17:23 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1581027443.6.0.562978821798.issue39534@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17761
pull_request: https://github.com/python/cpython/pull/18387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39534>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:22:19 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 22:22:19 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1581027739.92.0.726117545032.issue39534@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 83efed9eba9e50ed2395bd3366c31628b9555b1e by Miss Islington (bot) in branch '3.7':
bpo-39534: Doc: Clarify return in finally (GH-18324)
https://github.com/python/cpython/commit/83efed9eba9e50ed2395bd3366c31628b9555b1e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39534>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:23:11 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Feb 2020 22:23:11 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1581027791.08.0.452058461965.issue39534@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 97e00b3c52796cb54dd0a50548760579b9cb7b3a by Miss Islington (bot) in branch '3.8':
bpo-39534: Doc: Clarify return in finally (GH-18324)
https://github.com/python/cpython/commit/97e00b3c52796cb54dd0a50548760579b9cb7b3a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39534>
_______________________________________

From report at bugs.python.org  Thu Feb  6 17:45:39 2020
From: report at bugs.python.org (Sam Gross)
Date: Thu, 06 Feb 2020 22:45:39 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581029139.2.0.434355639247.issue39571@roundup.psfhosted.org>


Sam Gross <colesbury at gmail.com> added the comment:

Yes, that fixes the warnings for me. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 18:07:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 23:07:12 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
Message-ID: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Today, CPython is leaking too many implementation through its public C API. We cannot easily change the "default" C API, but we can enhance the "limited" C API (when Py_LIMITED_API macro is defined). Example of leaking implementation details: memory allocator, garbage collector, structure layouts, etc.

Making PyObject an opaque structure would allow in the long term of modify structures to implement more efficient types (ex: list specialized for small integers), and it can prepare CPython to experiment tagged pointers.

Longer rationale:

* https://pythoncapi.readthedocs.io/
* https://pythoncapi.readthedocs.io/bad_api.html
* https://pythoncapi.readthedocs.io/optimization_ideas.html

I propose to incremental evolve the existing limited C API towards opaque PyObject, by trying to reduce the risk of breakage.

We may test changes on PyQt which uses the limited C API.

Another idea would be to convert some C extensions of the standard library to the limited C API. It would ensure that the limited C API contains enough functions to be useful, but would also notify us directly if the API is broken.

----------
components: C API
messages: 361513
nosy: vstinner
priority: normal
severity: normal
status: open
title: Make PyObject an opaque structure in the limited C API
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 18:16:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 23:16:05 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581030965.26.0.354757158971.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17762
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18388

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 18:38:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 23:38:40 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581032320.44.0.376363141773.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Another idea would be to convert some C extensions of the standard library to the limited C API. It would ensure that the limited C API contains enough functions to be useful, but would also notify us directly if the API is broken.

First issues that I met when I tried that:

* C code generated by Argument Clinic is incompatible the limited C API: METH_FASTCALL, _PyArg_CheckPositional(), static _PyArg_Parser, etc. are excluded from the limited C API.
* PyTypeObject is opaque and so it's not possible to implement a deallocator function (tp_dealloc) which calls tp_free like:
  Py_TYPE(self)->tp_free((PyObject*)self);
* _Py_IDENTIFIER() is not part of the limited C API

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 18:39:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 23:39:12 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581032352.06.0.285410185659.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a93c51e3a8e15f1a486d11d5b55a64f3381babe0 by Victor Stinner in branch 'master':
bpo-39573: Use Py_REFCNT() macro (GH-18388)
https://github.com/python/cpython/commit/a93c51e3a8e15f1a486d11d5b55a64f3381babe0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 18:41:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Feb 2020 23:41:28 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581032488.88.0.0431328833033.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17763
pull_request: https://github.com/python/cpython/pull/18389

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:11:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:11:48 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581034308.93.0.735025719787.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> it can prepare CPython to experiment tagged pointers

In September 2018, Neil Schemenauer did an experiment:

* https://mail.python.org/archives/list/capi-sig at python.org/thread/EGAY55ZWMF2WSEMP7VAZSFZCZ4VARU7L/
* https://github.com/nascheme/cpython/commits/tagged_int

More recent discussion on the capi-sig list:

https://mail.python.org/archives/list/capi-sig at python.org/thread/JPUNPN3AILGXOA3C2TTSLMOFNSWJE3QX/

See also my notes:
https://pythoncapi.readthedocs.io/optimization_ideas.html#tagged-pointers-doable

Wikipedia article: https://en.wikipedia.org/wiki/Tagged_pointer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:19:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:19:37 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581034777.27.0.937045301344.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In the limited C API, Py_REFCNT() should be converted to:

static inline Py_ssize_t _Py_REFCNT(const PyObject *ob)
{ return ob->ob_refcnt; }
#define Py_REFCNT(ob) _Py_REFCNT(_PyObject_CAST(ob))

It would enforce the usage of newly added Py_SET_REFCNT() (PR 18389) and advertise that the object is not modified (const).

That would only be the first step towards a really opaque Py_REFCNT() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:22:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:22:52 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581034972.67.0.0618243524149.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

TODO: Add Py_IS_TYPE() macro:

#define Py_IS_TYPE(ob, tp) (Py_TYPE(ob) == (tp)) 

For example, replace:

    #define PyBool_Check(x) (Py_TYPE(x) == &PyBool_Type) 

with:

    #define PyBool_Check(x) Py_IS_TYPE(x, &PyBool_Type)

IMHO it makes the code more readable.

https://github.com/nascheme/cpython/commit/c156300592dc1eab234b74ed5b7cc90a020ab82b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:24:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:24:36 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581035076.21.0.312862035894.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c86a11221df7e37da389f9c6ce6e47ea22dc44ff by Victor Stinner in branch 'master':
bpo-39573: Add Py_SET_REFCNT() function (GH-18389)
https://github.com/python/cpython/commit/c86a11221df7e37da389f9c6ce6e47ea22dc44ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:24:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:24:52 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581035092.09.0.388866307615.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:26:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:26:52 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581035212.96.0.255457349851.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17764
pull_request: https://github.com/python/cpython/pull/18390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:43:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:43:37 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581036217.6.0.112508611282.issue39571@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f95cd199b4bc16775c8c48641bd85416b17742e7 by Victor Stinner in branch 'master':
bpo-39571: Fix clang warning on PyTypeObject typedef (GH-18385)
https://github.com/python/cpython/commit/f95cd199b4bc16775c8c48641bd85416b17742e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:49:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:49:45 +0000
Subject: [issue39571] clang warns "warning: redefinition of typedef
 'PyTypeObject' is a C11 feature [-Wtypedef-redefinition]"
In-Reply-To: <1581008979.02.0.137849512464.issue39571@roundup.psfhosted.org>
Message-ID: <1581036585.27.0.542857438711.issue39571@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Sam Gross for the hint, it's now fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39571>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:53:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:53:27 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581036807.04.0.906326895951.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0d76d2bd28ac815dabae8b07240ed002ac8fce2d by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() in abstract.c (GH-18390)
https://github.com/python/cpython/commit/0d76d2bd28ac815dabae8b07240ed002ac8fce2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 19:55:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 00:55:54 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581036954.14.0.314918636431.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17765
pull_request: https://github.com/python/cpython/pull/18391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:01:54 2020
From: report at bugs.python.org (Zachary Westrick)
Date: Fri, 07 Feb 2020 01:01:54 +0000
Subject: [issue39574] str.__doc__ is misleading
Message-ID: <1581037314.11.0.0860041079795.issue39574@roundup.psfhosted.org>


Change by Zachary Westrick <zackzackzackw at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, kcirtsew
priority: normal
severity: normal
status: open
title: str.__doc__ is misleading
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:02:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 01:02:14 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581037334.38.0.585577914442.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Py_TYPE() is commonly used to render the type name in an error message. Example:

PyErr_Format(PyExc_TypeError,
             "cannot convert '%.200s' object to bytearray",
             Py_TYPE(arg)->tp_name);

This code has multiple issues:

* It truncates type name to 200 characters: there is no Python exception, not even a marker to indicate that the string has been truncated
* It's only the short name: the qualified name (tp_qualname) would be more helpful. The best would be to generate the fully qualified name: module + qualname.
* Py_TYPE() returns a borrowed reference which is causing multiple issues: https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references

In September 2018, I created bpo-34595: "PyUnicode_FromFormat(): add %T format for an object type name". But there was disagreement, so I rejected my change.

I started "bpo-34595: How to format a type name?" thread on python-dev:
* https://mail.python.org/archives/list/python-dev at python.org/thread/HKYUMTVHNBVB5LJNRMZ7TPUQKGKAERCJ/#3UAMHYG6UF4MPLXBZORHO4JVKUBRUZ53

I didn't continue this work (until now), since it wasn't my priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:07:08 2020
From: report at bugs.python.org (Zachary Westrick)
Date: Fri, 07 Feb 2020 01:07:08 +0000
Subject: [issue39574] str.__doc__ is misleading
Message-ID: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>


New submission from Zachary Westrick <zackzackzackw at gmail.com>:

The docstring for the str() builtin reads

str(object='') -> str
str(bytes_or_buffer[, encoding[, errors]]) -> str

Create a new string object from the given object. If encoding or
errors is specified, then the object must expose a data buffer
that will be decoded using the given encoding and error handler.
Otherwise, returns the result of object.__str__() (if defined)
or repr(object).
encoding defaults to sys.getdefaultencoding().
errors defaults to 'strict'.

The statement "encoding defaults to sys.getdefaultencoding()." implies that the encoding argument defaults to sys.getdefaultencoding(), which would typically mean that 

str(X, encoding=sys.getdefaultencoding()) == str(X)

However, this is not the case

str(b'mystring', encoding=sys.getdefaultencoding()) -> 'mystring'
str(b'mystring') -> "b'mystring'"

It seems that the phrase "encoding defaults" is not referring to the argument named encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:13:54 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Fri, 07 Feb 2020 01:13:54 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581038034.65.0.271868445948.issue39491@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
pull_requests: +17766
pull_request: https://github.com/python/cpython/pull/18379

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:15:19 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 07 Feb 2020 01:15:19 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581038119.33.0.288230273255.issue39491@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 38aaaaac805fa30870e2d093e52a900dddde3b34 by Jakub Stasiak in branch 'master':
bpo-39491: Mention Annotated in get_origin() docstring (GH-18379)
https://github.com/python/cpython/commit/38aaaaac805fa30870e2d093e52a900dddde3b34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:24:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 01:24:55 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581038695.22.0.0514995301744.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a102ed7d2f0e7e05438f14d5fb72ca0358602249 by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in Python and Include directories (GH-18391)
https://github.com/python/cpython/commit/a102ed7d2f0e7e05438f14d5fb72ca0358602249


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:26:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 01:26:55 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581038815.07.0.35051880379.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17767
pull_request: https://github.com/python/cpython/pull/18392

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:42:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 01:42:16 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581039736.63.0.148591907181.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Make PyObject an opaque structure is also a first step towards the more ambitious project "HPy" project which is fully opaque:
https://github.com/pyhandle/hpy

This API is written from scratch and currently implemented on top on the existing C API.

The following article is a nice introduction to the overall idea:
https://morepypy.blogspot.com/2019/12/hpy-kick-off-sprint-report.html

>From my point of view, the long term goal would be to get better performance on PyPy and having a single API for C extension which would be efficient on all Python implementations (not only CPython).

Currently, the C API is not only a performance issue to run C extensions on PyPy. It's also an issue in CPython. Because the C API leaks too many implementation details, we cannot experiment optimizations.

See also: https://pythoncapi.readthedocs.io/rationale.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:57:18 2020
From: report at bugs.python.org (MaskRay)
Date: Fri, 07 Feb 2020 01:57:18 +0000
Subject: [issue39575] `coverage` build target should use --coverage instead of
 -lgcov
Message-ID: <1581040638.77.0.976018979532.issue39575@roundup.psfhosted.org>


New submission from MaskRay <maskray at google.com>:

This allows clang to get rid of the dependency on libgcov.
When linking, GCC passes -lgcov while clang passes the path to libclang_rt.profile-$arch.a

----------
components: Build
messages: 361528
nosy: MaskRay
priority: normal
severity: normal
status: open
title: `coverage` build target should use --coverage instead of -lgcov
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39575>
_______________________________________

From report at bugs.python.org  Thu Feb  6 20:58:53 2020
From: report at bugs.python.org (MaskRay)
Date: Fri, 07 Feb 2020 01:58:53 +0000
Subject: [issue39575] `coverage` build target should use --coverage instead of
 -lgcov
In-Reply-To: <1581040638.77.0.976018979532.issue39575@roundup.psfhosted.org>
Message-ID: <1581040733.86.0.497901087963.issue39575@roundup.psfhosted.org>


Change by MaskRay <maskray at google.com>:


----------
keywords: +patch
pull_requests: +17768
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18382

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39575>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:04:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 02:04:30 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581041070.39.0.596459145307.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 58ac700fb09497df14d4492b6f820109490b2b88 by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in Objects directory (GH-18392)
https://github.com/python/cpython/commit/58ac700fb09497df14d4492b6f820109490b2b88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:06:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 02:06:14 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581041174.76.0.902013376147.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17769
pull_request: https://github.com/python/cpython/pull/18393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:14:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 02:14:28 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()?
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581041668.36.0.0138340867283.issue37413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-29241.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:35:54 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Fri, 07 Feb 2020 02:35:54 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1581042954.58.0.968514388855.issue39318@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:37:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 02:37:11 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581043031.66.0.411914700427.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset daa9756cb6395323d6f291efe5c7d7fdc6b2e9d8 by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in Modules directory (GH-18393)
https://github.com/python/cpython/commit/daa9756cb6395323d6f291efe5c7d7fdc6b2e9d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:39:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 02:39:37 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581043177.26.0.129250311384.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17770
pull_request: https://github.com/python/cpython/pull/18394

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:39:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 07 Feb 2020 02:39:57 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1581043197.16.0.376836101384.issue39564@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Can I ask how pegen solved this problem? Did you move parsing of f-strings into the grammar?

I found my patch and I'm working on resolving merge conflicts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39564>
_______________________________________

From report at bugs.python.org  Thu Feb  6 21:59:23 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 07 Feb 2020 02:59:23 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1581044363.25.0.714382126411.issue39465@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> The GIL avoids any risk of race condition, no?

Looks like the GIL would affect performance more or less?

>_Py_IDENTIFIER() would only be a "key" and _PyUnicode_FromId() would >store the value somewhere in a hash table stored in PyInterpreterState.

+1.

IMHO, for those two cases, the simplest idea is move IDENTIFIER to moduleState which would increase more memory usage than InterpreterState.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Thu Feb  6 22:12:44 2020
From: report at bugs.python.org (Avery Uslaner)
Date: Fri, 07 Feb 2020 03:12:44 +0000
Subject: [issue37815] 'Make Test' error while trying to install Python 3.7.4
 on Linux Mint
In-Reply-To: <1565484153.44.0.516842692215.issue37815@roundup.psfhosted.org>
Message-ID: <1581045164.26.0.394229363561.issue37815@roundup.psfhosted.org>


Avery Uslaner <uslaner.avery at gmail.com> added the comment:

I'm running into the same error while attempting to compile Python 3.8.1 on Ubuntu 18.04.

The actual test failure is this:

======================================================================
FAIL: test_errors_in_command (test.test_pdb.PdbTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/Python-3.8.1/Lib/test/test_pdb.py", line 1580, in test_errors_in_command
    self.assertEqual(stdout.splitlines()[1:], [
AssertionError: Lists differ: ['(Pd[283 chars]efined", 'LEAVING RECURSIVE DEBUGGER', '(Pdb) ', '\x1b[?1034h'] != ['(Pd[283 chars]efined", 'LEAVING RECURSIVE DEBUGGER', '(Pdb) ']

First list contains 1 additional elements.
First extra element 9:
'\x1b[?1034h'

  ['(Pdb) *** SyntaxError: unexpected EOF while parsing',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '*** SyntaxError: unexpected EOF while parsing',
   'LEAVING RECURSIVE DEBUGGER',
   '(Pdb) ENTERING RECURSIVE DEBUGGER',
   '> <string>(1)<module>()',
   "((Pdb)) *** NameError: name 'doesnotexist' is not defined",
   'LEAVING RECURSIVE DEBUGGER',
-  '(Pdb) ',
?          ^

+  '(Pdb) ']
?          ^

-  '\x1b[?1034h']

----------------------------------------------------------------------

This failure only appeared after I installed additional packages and attempted to reconfigure and reinstall. The install command I used was this:

sudo apt-get install libbz2-dev libreadline-gplv2-dev libncursesw5-dev libssl-dev libsqlite3-dev tk-dev libgdbm-dev libc6-dev

----------
nosy: +Avery Uslaner
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37815>
_______________________________________

From report at bugs.python.org  Thu Feb  6 22:32:04 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 07 Feb 2020 03:32:04 +0000
Subject: [issue39564] Parsed expression has wrong col_offset when
 concatenating f-strings
In-Reply-To: <1580937682.24.0.516632817266.issue39564@roundup.psfhosted.org>
Message-ID: <1581046324.33.0.339573877878.issue39564@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

> Can I ask how pegen solved this problem? Did you move parsing of f-strings into the grammar?

No, we actually do a very similar thing to what ast.c does.

I think there is only one major difference between what pegen does and what ast.c does. If I understand correctly, fstring_compile_expr calls fstring_fix_node_location with parent set to the whole STRING+ node. We OTOH only pass as parent the current STRING token (we work with tokens returned by the tokenizer) and then walk the AST tree and adjust the line/col_offset based on that. I'm not sure that this is bug-free, but after some testing, I could find any obvious errors.

If you want, you can take a loot at the code on https://github.com/gvanrossum/pegen/pull/183.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39564>
_______________________________________

From report at bugs.python.org  Thu Feb  6 22:39:20 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 07 Feb 2020 03:39:20 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
Message-ID: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>


New submission from Tim Peters <tim at python.org>:

Here under Python 3.8.1 on 64-bit Windows:

>>> import decimal
>>> c = decimal.getcontext()
>>> c.prec = decimal.MAX_PREC
>>> i = decimal.Decimal(4)
>>> i / 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

Of course the result is exactly 2.  Which I have enough RAM to hold ;-)

The implicit conversion is irrelevant:

>>> i / decimal.Decimal(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

Floor division instead works fine:

>>> i // 2
Decimal('2')

----------
components: Library (Lib)
messages: 361536
nosy: tim.peters
priority: normal
severity: normal
status: open
title: Surprising MemoryError in `decimal` with MAX_PREC
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 00:17:17 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 07 Feb 2020 05:17:17 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581052637.96.0.22762886944.issue39576@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 00:57:59 2020
From: report at bugs.python.org (Avery Uslaner)
Date: Fri, 07 Feb 2020 05:57:59 +0000
Subject: [issue37815] 'Make Test' error while trying to install Python 3.7.4
 on Linux Mint
In-Reply-To: <1565484153.44.0.516842692215.issue37815@roundup.psfhosted.org>
Message-ID: <1581055079.64.0.366442270268.issue37815@roundup.psfhosted.org>


Avery Uslaner <uslaner.avery at gmail.com> added the comment:

FYI, the problem seems isolated to the libreadline-gplv2-dev package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37815>
_______________________________________

From report at bugs.python.org  Fri Feb  7 01:44:43 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 07 Feb 2020 06:44:43 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581057883.55.0.638702816373.issue39576@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

> Of course the result is exactly 2.  Which I have enough RAM to hold ;-)

You might think so, but if you write it as 2.00...0 with 

>>> decimal.MAX_PREC
999999999999999999

zeros, I think you're overestimating your RAM capacity. :-P

Now, what is the exact significance of MAX_PREC, I don't know. But I guess some hard limits were needed for standards compliance, and Python didn't want to limit you there. Of course, same as with recursionlimit, it might be better to actually have some reasonable _lower_ limit that we know is actually safe.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 02:53:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 07:53:02 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581061982.17.0.73829997056.issue35134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17771
pull_request: https://github.com/python/cpython/pull/18395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:12:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:12:22 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()?
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581063142.91.0.782326965925.issue37413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

One of sys._enablelegacywindowsfsencoding() issue is that os.fsdecode() and os.fsencode() are not updated, they continue to use UTF-8. Example on Windows:

>>> import sys, os
>>> sys.getfilesystemencoding()
'utf-8'
>>> os.fsencode('\xe9')
b'\xc3\xa9'
>>> sys._enablelegacywindowsfsencoding()
>>> sys.getfilesystemencoding()
'mbcs'
>>> os.fsencode('\xe9')
b'\xc3\xa9'

See bpo-29241 for larger issues caused by this function.

--

The first reason is deprecate this function is that it sounds dangerous to me and it doesn't seem to be used.

I only found one project which used it temporarily until they fixed their code to encode/decode filenames on Windows. It was used to workaround a in bug in their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:17:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:17:11 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581063431.59.0.315748840043.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d2ec81a8c99796b51fb8c49b77a7fe369863226f by Victor Stinner in branch 'master':
bpo-39573: Add Py_SET_TYPE() function (GH-18394)
https://github.com/python/cpython/commit/d2ec81a8c99796b51fb8c49b77a7fe369863226f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:18:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:18:08 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()?
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581063488.3.0.285018705411.issue37413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17772
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18396

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:19:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:19:35 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()?
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581063575.08.0.623633019045.issue37413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also draft PEP 597 which proposes to use UTF-8 by default on Windows in Python 3.10:
https://www.python.org/dev/peps/pep-0597/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:19:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:19:43 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581063583.26.0.112565972319.issue37413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Deprecate sys._enablelegacywindowsfsencoding()? -> Deprecate sys._enablelegacywindowsfsencoding()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:20:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:20:25 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581063625.64.0.538440928047.issue35134@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bec4186c67345f1e6cd3f8a531bc228f14d7ed7b by Victor Stinner in branch 'master':
bpo-35134: Create Include/cpython/listobject.h (GH-18395)
https://github.com/python/cpython/commit/bec4186c67345f1e6cd3f8a531bc228f14d7ed7b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:38:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:38:40 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1581064720.32.0.619958911058.issue39500@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17773
pull_request: https://github.com/python/cpython/pull/18397

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:46:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 08:46:19 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1581065179.8.0.0616183550956.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ah, I also found the idea of immortal None in an old discussion on tagged pointer:
https://mail.python.org/archives/list/capi-sig at python.org/thread/JPUNPN3AILGXOA3C2TTSLMOFNSWJE3QX/

Stefan Behnel proposed the idea: "All negative refcounts would have special meanings, such as: this is the immortal None, (...)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Feb  7 03:50:47 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Feb 2020 08:50:47 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581065447.34.0.151467782709.issue39576@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agreed that this seems surprising.

@Vedran: Trailing zeros in a Decimal object are significant, so `Decimal("2.0")` and `Decimal("2.00")` are different (equal, but different). The rules about the "ideal exponent" of the result of an arithmetic operation are well-specified. In this case, the spec is clear that the answer should be `Decimal("2")`, and not `Decimal("2.0")` or `Decimal("2.00")`, or ....

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:01:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 09:01:25 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581066085.54.0.689948092236.issue37413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It's probably worth at least a post to python-dev to expand the audience, but unless someone speaks up with some really good reason why they must update to Python 3.10 without updating their own code then let's deprecate it.

I don't think that it deserves to be discussed on python-dev. I propose PR 18396 to add a deprecation in Python 3.9. We can open a discussion once we will reach the point of actually removing the feature. It's easy to revert a deprecation if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:05:11 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 07 Feb 2020 09:05:11 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581066311.97.0.0758820461018.issue39576@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Yeah, I should have said "represent" instead of "write". :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:05:14 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Feb 2020 09:05:14 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581066314.1.0.890895046682.issue39574@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The docs are correct, you are just misinterpreting them. Which could, I guess, suggest the docs could do with improvement.

With *one* argument, `str(obj)` returns a string via `object.__str__(obj)` or `repr(obj)`, whichever is defined. That includes the case where obj is a bytes object.

*Only* in the two or three argument case where you explicitly provide either the encoding or errors parameter will bytes be decoded. But you must provide at least one of encoding or errors. If you provide neither, you have the one-argument form above.

The default value for encoding is only relevant in cases like this:

    # encoding defaults to sys.getdefaultencoding()
    py> str(b'a', errors='ignore')
    'a'



Here's my suggested rewording:


***


str(object='') -> str
str(bytes_or_buffer [, encoding] [, errors]) -> str

Create a new string object from the given object.

If a single argument is given, returns the result of object.__str__() (if defined) or repr(object).

If encoding or errors or both are specified, then the object must expose a data buffer that will be decoded using the given encoding and error handler. If errors is specified, the default encoding is sys.getdefaultencoding(). If encoding is specified, errors defaults to 'strict'.

----------
nosy: +steven.daprano
versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:08:45 2020
From: report at bugs.python.org (Andrea)
Date: Fri, 07 Feb 2020 09:08:45 +0000
Subject: [issue39577] venv --prompt argument is ignored
Message-ID: <1581066525.57.0.495811141664.issue39577@roundup.psfhosted.org>


New submission from Andrea <andrea.moro.webma at gmail.com>:

In creating a new virtual environment, the help suggest a --prompt argument to specify a different name by the time the environment is active.

https://docs.python.org/3/library/venv.html

The argument is apparently ignored as the folder name always appears instead to whatever is specified in the prompt.
Checking at the config file content there nothing written inside, thought I'm not sure this should be the case.

----------
messages: 361548
nosy: andream
priority: normal
severity: normal
status: open
title: venv --prompt argument is ignored
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39577>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:19:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 09:19:24 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581067164.46.0.213131564474.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

To make PyObject opaque, we would have to convert Py_INCREF() and Py_DECREF() to opaque function calls. Example:

#define Py_XINCREF(op) Py_IncRef(op)
#define Py_XDECREF(op) Py_DecRef(op)

Benchmarks should be run to measure to overhead and balance the advantages and drawbacks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:20:00 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 07 Feb 2020 09:20:00 +0000
Subject: [issue36843] AIX build fails with failure to get random numbers
In-Reply-To: <1557262791.73.0.95279707159.issue36843@roundup.psfhosted.org>
Message-ID: <1581067200.92.0.385775099254.issue36843@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

FYI: I was contacted this week by someone with this problem. 

The problem was resolved after they updated AIX (was 7100-04-00-0000).

Please note: any oslevel -s reporting six zeros at the end needs the SP that is released in parallel with the base.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36843>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:26:51 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 07 Feb 2020 09:26:51 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581067611.87.0.806946260979.issue39574@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

That's a good improvement, Steven. I like your wording about errors better than the wording about encoding, so how about changing the next to last sentence to:

"If errors is specified, encoding defaults to sys.getdefaultencoding()."

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:38:41 2020
From: report at bugs.python.org (Frank Harrison)
Date: Fri, 07 Feb 2020 09:38:41 +0000
Subject: [issue39578] MagicMock specialisation instance can no longer be
 passed to new MagicMock instance
Message-ID: <1581068321.62.0.885951490226.issue39578@roundup.psfhosted.org>


New submission from Frank Harrison <frank at doublethefish.com>:

This is my first bug logged here, I've tried to follow the guideline and search for this issue; please let me know if I missed anything.

Summary:
unittest.mock.MagicMock has a regression starting in 3.8. The regression was only tested on latest non-prerelease versions of python 3.5, 3.6, 3.7, 3.8 and 3.9. Tested on OSX and Fedora 31.

Repro:
------
If you create an instance of a MagicMock specialisation with parameters to __init__(),  you can no longer pass that instance to the __init__() function of another MagicMock object e.g. a base-class is replaced with MagicMock. See the unittests bellow for more details, use-cases and fail situations.

What happens:
-------------
Here's a python3.9 example traceback. It may be worth noting that there is a difference in the tracebacks between 3.8 and 3.9.

Traceback (most recent call last):
  File "<...>", line <..>, in test_raw_magic_moc_passing_thru_single_pos
    mock_object = mock.MagicMock(mock_param)  # error is here, instantiating another object
  File "/usr/lib64/python3.9/unittest/mock.py", line 408, in __new__
    if spec_arg and _is_async_obj(spec_arg):
  File "/usr/lib64/python3.9/unittest/mock.py", line 2119, in __get__
    return self.create_mock()
  File "/usr/lib64/python3.9/unittest/mock.py", line 2112, in create_mock
    m = parent._get_child_mock(name=entry, _new_name=entry,
  File "/usr/lib64/python3.9/unittest/mock.py", line 1014, in _get_child_mock
    return klass(**kw)
TypeError: __init__() got an unexpected keyword argument 'name'


Code demonstrating the problem:
-------------------------------

import unittest

from unittest import mock


class TestMockMagicAssociativeHierarchies(unittest.TestCase):
    """ Mimicing real-world testing where we mock a base-class

    The intent here is to demonstrate some of the requirements of associative-
    hierarchies e.g. where a class may have its associative-parent set at
    run-time, rather that defining it via a class-hierarchy. Obviously this
    also needs to work with class-hierarchies, that is an associative-parent is
    likely to be a specialisation of some interface, usually one that is being
    mocked.

    For example tkinter and Qt have both a class-hierarchy and a layout-
    hierarchy; the latter is modifyable at runtime.

    Most of the tests here mimic a specialisation of an upstream object (say a
    tk.Frame class), instantiating that specialisation and then passing it to
    another object. The reason behind this is an observed regression in Python
    3.8.
    """
    def test_raw_magic_moc_passing_thru_no_params(self):
        """ REGRESSION: Python3.8 (inc Python3.9)

        Create a mocked specialisation passing it to another mock.

        One real-world use-case for this is simple cases where we simply want to
        define a new convenience type that forces a default configuration of
        the inherited type (calls super().__init__()).
        """
        class MockSubCallsParentInit(mock.MagicMock):
            def __init__(self):
                super().__init__()  # intentionally empty
        mock_param = MockSubCallsParentInit()
        mock_object = mock.MagicMock(mock_param)  # error is here, instantiating another object
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_raw_magic_moc_passing_thru_single_pos(self):
        """ REGRESSION: Python3.8 (inc Python3.9)

        Same as test_raw_magic_moc_no_init_params() but we want to specialise
        with positional arguments. """
        class MockSubCallsParentInitWithPositionalParam(mock.MagicMock):
            def __init__(self):
                super().__init__("specialise init calls")
        mock_param = MockSubCallsParentInitWithPositionalParam()
        mock_object = mock.MagicMock(mock_param)  # error is here, instantiating another object
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_raw_magic_moc_passing_thru_single_kwarg(self):
        """ REGRESSION: Python3.8 (inc Python3.9)

        Same as test_raw_magic_moc_passing_thru_single_pos() but we want to
        specialise with a key-word argument. """
        class MockSubCallsParentInitWithPositionalParam(mock.MagicMock):
            def __init__(self):
                super().__init__(__some_key_word__="some data")
        mock_param = MockSubCallsParentInitWithPositionalParam()
        mock_object = mock.MagicMock(mock_param)  # error is here, instantiating another object
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_mock_as_param_no_inheritance(self):
        """ PASSES 

        Mimic mocking out types, without type specialisation.
        for example in pseudo code 
            tk.Frame = mock.MagicMock; tk.Frame(t.Frame) """
        mock_param = mock.MagicMock()
        mock_object = mock.MagicMock(mock_param)
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_mock_as_param_no_init_override(self):
        """ PASSES 

        Leaves the __init__() function behaviour as default; should always
        work. Note that we do not specialise member functions.

        Although the intent here is similar to the one captured by
        test_raw_magic_moc_passing_thru_no_params(), this is a less likely
        usecase, although it does happen, but is here for completeness """
        class MockSub(mock.MagicMock): pass
        mock_param = MockSub()
        mock_object = mock.MagicMock(mock_param)
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_init_with_args_n_kwargs_passthru(self):
        """ PASSES

        Intended to be the same as test_mock_as_param_no_init_override as well
        as a base-test for ithe usecases where a user will define more complex
        behaviours such as key-word modification, member-variable definitions
        and so on. """
        class MockSubInitPassThruArgsNKwargs(mock.MagicMock):
            def __init__(self, *args, **kwargs):
                super().__init__(*args, **kwargs)  # intentionally redundant
        mock_param = MockSubInitPassThruArgsNKwargs()
        mock_object = mock.MagicMock(mock_param)
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_init_with_args_n_kwargs_modify_kwargs(self):
        """ PASSES

        Same as test_init_with_args_n_kwargs_passthru() but modifies the kwargs
        dict on the way through the __init__() function.
        """
        class MockSubModifyKwargs(mock.MagicMock):
            def __init__(self, *args, **kwargs):
                kwargs["__kw args added__"] = "test value"
                super().__init__(*args, **kwargs)
        mock_param = MockSubModifyKwargs()
        mock_object = mock.MagicMock(mock_param)
        self.assertIsInstance(mock_object, mock.MagicMock)

    def test_init_with_args_n_kwargs_modify_args(self):
        """ PASSES

        Same as test_init_with_args_n_kwargs_passthru() but modifies the args
        on their way through the __init__() function.
        """
        class MockSubModifyArgs(mock.MagicMock):
            def __init__(self, *args, **kwargs):
                super().__init__("test value", *args, **kwargs)
        mock_param = MockSubModifyArgs()
        mock_object = mock.MagicMock(mock_param)
        self.assertIsInstance(mock_object, mock.MagicMock)

----------
components: Library (Lib)
messages: 361552
nosy: Frank Harrison
priority: normal
severity: normal
status: open
title: MagicMock specialisation instance can no longer be passed to new MagicMock instance
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39578>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:40:28 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 07 Feb 2020 09:40:28 +0000
Subject: [issue39578] MagicMock specialisation instance can no longer be
 passed to new MagicMock instance
In-Reply-To: <1581068321.62.0.885951490226.issue39578@roundup.psfhosted.org>
Message-ID: <1581068428.83.0.756820055946.issue39578@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cjw296, lisroach, mariocj89, michael.foord, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39578>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:47:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 09:47:42 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581068862.48.0.345653561555.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17774
pull_request: https://github.com/python/cpython/pull/18398

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:47:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 07 Feb 2020 09:47:49 +0000
Subject: [issue39577] venv --prompt argument is ignored
In-Reply-To: <1581066525.57.0.495811141664.issue39577@roundup.psfhosted.org>
Message-ID: <1581068869.95.0.990769475458.issue39577@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add a reproducer of the steps along with the operating system and python version? The --prompt was modified in 3.9 to accept "." so that the current folder name is used in issue38901.

# Use custom name as testing for the prompt

?  cpython git:(master) ./python.exe -m venv foo-venv --prompt testing
?  cpython git:(master) ? source foo-venv/bin/activate
(testing) ?  cpython git:(master) ? deactivate

# Delete to recreate with prompt as . so that basename is used

?  cpython git:(master) ? rm -rf foo-venv
?  cpython git:(master) ./python.exe -m venv foo-venv --prompt .
?  cpython git:(master) ? source foo-venv/bin/activate
(cpython) ?  cpython git:(master) ?

----------
nosy: +vinay.sajip, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39577>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:55:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 09:55:12 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581069312.55.0.751550692654.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Would a Py_TYPE_IS() macro help code readability?

For example:
    #define Future_CheckExact(obj) (Py_TYPE(obj) == &FutureType)
would become:
    #define Future_CheckExact(obj) (Py_TYPE_IS(obj, &FutureType))

Py_TYPE_IS() would be more efficient for tagged pointers.

I'm not sure about the macro name. Neil used Py_IS_TYPE(obj, type).

Note: Py_TYPE_EQ(obj, type) name sounds confusing since the first parameter is an object, whereas the second one is a type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:01:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:01:18 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1581069678.3.0.501322337532.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17775
pull_request: https://github.com/python/cpython/pull/18399

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Feb  7 04:51:15 2020
From: report at bugs.python.org (Frank Harrison)
Date: Fri, 07 Feb 2020 09:51:15 +0000
Subject: [issue39578] MagicMock specialisation instance can no longer be
 passed to new MagicMock instance
In-Reply-To: <1581068321.62.0.885951490226.issue39578@roundup.psfhosted.org>
Message-ID: <1581069075.44.0.496450468419.issue39578@roundup.psfhosted.org>


Frank Harrison <frank at doublethefish.com> added the comment:

Minor correction: The regression was only tested on Python 3.9.0a2 (Fedora), Python 3.9a3 (OSX), CPython's master (build from source) and the latest non-prerelease versions of python 3.5, 3.6, 3.7, and 3.8. Tested on OSX and Fedora 31.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39578>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:16:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:16:48 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581070608.73.0.581372365572.issue37413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, INADA-san found an issue of this function: Mercurial. I close this issue and I closed my PR. We can reconsider to deprecate the function once Mercurial will stop to use it.

Copy of INADA-san message:

"""
I think we should keep this several years.

Currently, mercurial depends on it.
https://www.mercurial-scm.org/repo/hg/file/tip/mercurial/pycompat.py#l103

There is a plan for moving to UTF-8 path, and legacyfsencoding is not needed if this plan is implemented. But I don't know about current progress of this plan.
https://www.mercurial-scm.org/wiki/WindowsUTF8Plan
"""

https://github.com/python/cpython/pull/18396#issuecomment-583284632

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:18:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:18:42 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581070722.06.0.035634914892.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c65b320a95784d2b2133926921d67ac439259e9f by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in object.c (GH-18398)
https://github.com/python/cpython/commit/c65b320a95784d2b2133926921d67ac439259e9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:20:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:20:39 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581070839.39.0.588337561852.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17776
pull_request: https://github.com/python/cpython/pull/18400

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:23:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:23:00 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1581070980.83.0.300313570213.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 877ea88934a5164be4d9f15207694fad4173d87d by Victor Stinner in branch 'master':
bpo-38644: Add Py_EnterRecursiveCall() to python3.def (GH-18399)
https://github.com/python/cpython/commit/877ea88934a5164be4d9f15207694fad4173d87d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:24:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:24:48 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1581071088.94.0.48665166282.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> One further step would be to change the VECTORCALL/FASTCALL calling convention to pass tstate.

My first strong motivation is to get None singleton from tstate. It's now being discussed in bpo-39511: "[subinterpreters] Per-interpreter singletons (None, True, False, etc.)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:26:22 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Feb 2020 10:26:22 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581067611.87.0.806946260979.issue39574@roundup.psfhosted.org>
Message-ID: <20200207102616.GB8273@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Eric: sure, I'm happy with your modification.

Alas, I'm currently having technology issues which prevents me from 
doing a PR. Would you care to do the honours?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:29:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:29:48 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: Linux VFS/XFS bug
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1581071388.68.0.736096800298.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like AIX also has a kernel issue with timestamp after year 2038. The year 2107 is stored as year 1972.

test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000'

https://bugs.python.org/issue39502#msg361116

>>> print(datetime.datetime.fromtimestamp(91301504))
1972-11-22 18:31:44

--

The test is now skipped if the kernel or filesystem stores incorrectly the timestamp 4386268800 (2108-12-30). I don't think that we can do much more.

On the Linux kernel side, we reported the issue to:
https://bugzilla.redhat.com/show_bug.cgi?id=1795576

I close this issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:35:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:35:05 +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: <1581071705.06.0.502460408914.issue38699@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There is no clear consensus to change socket.listen() default backlog, so I close the issue.

> Anyway asyncio at least should probably update its default.

If someone cares, please open a separated issue ;-)

> 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 :-).

I dislike having to workaround operating system bugs. If the function misbehaves, I would prefer to see the OS being fixed, than Python trying to guess which value is supposed to work or not.

       int listen(int sockfd, int backlog);

backlog type is an int: its maximum value is INT_MAX. If the kernel rejects values larger than 65535, the kernel and/or the libc should reject such value.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38699>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:39:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:39:19 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1581071959.93.0.0563624260118.issue37266@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI python-jep project is broken by this change:
https://bugzilla.redhat.com/show_bug.cgi?id=1792062

"JEP embeds CPython in Java through JNI and is safe to use in a heavily threaded environment."
https://github.com/ninia/jep 

FAIL: test_shared_modules_threads (test_shared_modules.TestSharedModules)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/jep-3.9.0/src/test/python/test_shared_modules.py", line 15, in test_shared_modules_threads
    jep_pipe(build_java_process_cmd('jep.test.TestSharedModulesThreads'))
  File "/usr/lib64/python3.9/contextlib.py", line 240, in helper
    return _GeneratorContextManager(func, args, kwds)
  File "/usr/lib64/python3.9/contextlib.py", line 83, in __init__
    self.gen = func(*args, **kwds)
  File "/builddir/build/BUILD/jep-3.9.0/src/test/python/jep_pipe.py", line 36, in jep_pipe
    assert False, stderr
AssertionError: b'Exception in thread "main" jep.JepException: <class \'RuntimeError\'>: daemon thread are not supported in subinterpreters\n\tat /usr/lib64/python3.9/threading.start(threading.py:858)\n\tat <string>.<module>(<string>:1)\n\tat jep.Jep.eval(Native Method)\n\tat jep.Jep.eval(Jep.java:451)\n\tat jep.test.TestSharedModulesThreads.main(TestSharedModulesThreads.java:53)\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:41:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:41:45 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1581072105.45.0.426510682382.issue37266@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reported the issue to jep: https://github.com/ninia/jep/issues/229

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:48:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:48:47 +0000
Subject: [issue38207] subprocess: Popen.kill() + Popen.communicate() is
 blocking until all processes using the pipe close the pipe
In-Reply-To: <1568763048.2.0.765446302919.issue38207@roundup.psfhosted.org>
Message-ID: <1581072527.71.0.0743805628508.issue38207@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

My use case was specific to regrtest. I solved the issue differently in regrtest. I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38207>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:50:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:50:15 +0000
Subject: [issue37155] test_asyncio: test_stdin_broken_pipe() failed on AMD64
 FreeBSD CURRENT Shared 3.x
In-Reply-To: <1559669895.88.0.0230112144047.issue37155@roundup.psfhosted.org>
Message-ID: <1581072615.15.0.201382479542.issue37155@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37155>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:50:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:50:45 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1581072645.78.0.503643573909.issue35760@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:49:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:49:54 +0000
Subject: [issue38184] test_site: test_s_option() failed on AMD64 Fedora
 Rawhide Refleaks 2.7 and AMD64 Fedora Stable Refleaks 3.7
In-Reply-To: <1568620069.59.0.0713376910256.issue38184@roundup.psfhosted.org>
Message-ID: <1581072594.4.0.935623106186.issue38184@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38184>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:49:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:49:11 +0000
Subject: [issue31447] proc communicate not exiting on python subprocess
 timeout using PIPES
In-Reply-To: <1505297487.8.0.0553413859223.issue31447@psf.upfronthosting.co.za>
Message-ID: <1581072551.74.0.301991739679.issue31447@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-38207: "subprocess: Popen.kill() + Popen.communicate() is blocking until all processes using the pipe close the pipe".

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31447>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:51:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:51:16 +0000
Subject: [issue36339] test_ttk_guionly: test_traversal() fails randomly on
 AMD64 Windows8.1 Refleaks 2.7
In-Reply-To: <1552899428.95.0.891639199681.issue36339@roundup.psfhosted.org>
Message-ID: <1581072676.11.0.722900532945.issue36339@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

Moreover, Python 2 is not longer supported.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36339>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:51:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:51:37 +0000
Subject: [issue36632] test_multiprocessing_forkserver: test_rapid_restart()
 leaked a dangling process on AMD64 FreeBSD 10-STABLE Non-Debug 3.x
In-Reply-To: <1555326100.12.0.0433329524894.issue36632@roundup.psfhosted.org>
Message-ID: <1581072697.46.0.429750747175.issue36632@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36632>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:52:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:52:13 +0000
Subject: [issue37338] test_multiprocessing_forkserver,
 SemLock: test_thousand() logged on AMD64 Ubuntu Shared 3.x: Exception
 ignored in: <Finalize object, dead>
In-Reply-To: <1560938260.28.0.194629990204.issue37338@roundup.psfhosted.org>
Message-ID: <1581072733.62.0.612622617602.issue37338@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37338>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:52:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:52:28 +0000
Subject: [issue37368] test_asyncio: test_create_server_ssl_match_failed()
 failed on s390x SLES 3.x and logged an unraisable exception
In-Reply-To: <1561151330.27.0.514257001535.issue37368@roundup.psfhosted.org>
Message-ID: <1581072748.78.0.597266690944.issue37368@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37368>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:53:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:53:06 +0000
Subject: [issue37928] test_glob.test_selflink() fails randomly on AMD64 Fedora
 Rawhide Clang Installed 3.x
In-Reply-To: <1566556888.02.0.20425235487.issue37928@roundup.psfhosted.org>
Message-ID: <1581072786.89.0.507276091741.issue37928@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37928>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:53:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:53:52 +0000
Subject: [issue38182] test_asyncio:
 SubprocessMultiLoopWatcherTests.test_stdin_stdout() failed on AMD64 FreeBSD
 10-STABLE Non-Debug 3.x
In-Reply-To: <1568618932.29.0.888642013257.issue38182@roundup.psfhosted.org>
Message-ID: <1581072832.65.0.628138455418.issue38182@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I mark this issue as a duplicate of bpo-38323.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38182>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:54:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:54:15 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1581072855.97.0.76571154166.issue38323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-38182 as a duplicate of this issue: "test_asyncio: SubprocessMultiLoopWatcherTests.test_stdin_stdout() failed on AMD64 FreeBSD 10-STABLE Non-Debug 3.x".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:54:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:54:42 +0000
Subject: [issue38276] test_asyncio:
 test_cancel_make_subprocess_transport_exec() failed on RHEL7 LTO + PGO 3.x
In-Reply-To: <1569416953.01.0.173802643321.issue38276@roundup.psfhosted.org>
Message-ID: <1581072882.18.0.218591960144.issue38276@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38276>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:55:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:55:20 +0000
Subject: [issue38338] [2.7] test_ssl: test_protocol_sslv23() and
 test_protocol_tlsv1_1() fail on RHEL8
In-Reply-To: <1569934554.24.0.56143952582.issue38338@roundup.psfhosted.org>
Message-ID: <1581072920.09.0.507632133164.issue38338@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 2.7 is no longer maintained, I close this issue.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38338>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:55:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:55:35 +0000
Subject: [issue38447] test_multiprocessing_spawn: Dangling processes:
 {<SpawnProcess(QueueManager-1576, stopped)>} on AMD64 RHEL7 Refleaks 3.7
In-Reply-To: <1570798904.01.0.669672054648.issue38447@roundup.psfhosted.org>
Message-ID: <1581072935.82.0.101678390826.issue38447@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38447>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:55:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:55:56 +0000
Subject: [issue38476] test_multiprocessing_fork.test_terminate() failed on
 AMD64 Debian PGO 3.x
In-Reply-To: <1571089967.06.0.895638026997.issue38476@roundup.psfhosted.org>
Message-ID: <1581072956.21.0.995797101259.issue38476@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38476>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:56:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:56:24 +0000
Subject: [issue38795] test_asyncio.test_subprocess.test_terminate() timed out
 on AMD64 RHEL8 LTO + PGO 3.x
In-Reply-To: <1573735749.11.0.571095756017.issue38795@roundup.psfhosted.org>
Message-ID: <1581072984.71.0.545287241244.issue38795@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38795>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:56:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:56:37 +0000
Subject: [issue38796] test_multiprocessing_forkserver:
 test_mymanager_context() failed on AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1573735974.8.0.945088390844.issue38796@roundup.psfhosted.org>
Message-ID: <1581072997.98.0.816416022755.issue38796@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38796>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:57:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:57:10 +0000
Subject: [issue39268] test_asyncio: test_create_server_ssl_verified() failed
 on AMD64 FreeBSD Non-Debug 3.x
In-Reply-To: <1578528659.39.0.760822597005.issue39268@roundup.psfhosted.org>
Message-ID: <1581073030.63.0.244534627859.issue39268@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39268>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:57:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:57:27 +0000
Subject: [issue39266] [2.7] test_bsddb3 leaked [1, 1,
 1] file descriptors on AMD64 RHEL7 Refleaks 2.7
In-Reply-To: <1578528248.0.0.1734131404.issue39266@roundup.psfhosted.org>
Message-ID: <1581073047.37.0.512005275403.issue39266@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 2.7 is no longer supported, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39266>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:57:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:57:54 +0000
Subject: [issue39238] test_asyncio:
 test_cancel_make_subprocess_transport_exec() hangs randomly on PPC64LE Fedora
 3.x
In-Reply-To: <1578349019.82.0.0702143761935.issue39238@roundup.psfhosted.org>
Message-ID: <1581073074.33.0.206356054444.issue39238@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It only failed twice, I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39238>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:58:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:58:26 +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: <1581073106.33.0.869990857735.issue39014@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see these issues recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39014>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:58:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:58:38 +0000
Subject: [issue39005] test_faulthandler: test_dump_traceback_later_file()
 fails randomly on AMD64 RHEL8 Refleaks 3.x
In-Reply-To: <1575898119.77.0.459055301338.issue39005@roundup.psfhosted.org>
Message-ID: <1581073118.33.0.648159058219.issue39005@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39005>
_______________________________________

From report at bugs.python.org  Fri Feb  7 05:58:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 10:58:56 +0000
Subject: [issue38578] test_concurrent_futures failed on AMD64 FreeBSD Shared
 3.8
In-Reply-To: <1571908474.05.0.296505367308.issue38578@roundup.psfhosted.org>
Message-ID: <1581073136.17.0.349516678599.issue38578@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this issue recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38578>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:04:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 11:04:19 +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: <1581073459.58.0.579205534531.issue36732@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36732>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:05:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 11:05:16 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581073516.61.0.883031320028.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b10dc3e7a11fcdb97e285882eba6da92594f90f9 by Victor Stinner in branch 'master':
bpo-39573: Add Py_SET_SIZE() function (GH-18400)
https://github.com/python/cpython/commit/b10dc3e7a11fcdb97e285882eba6da92594f90f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:12:26 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 07 Feb 2020 11:12:26 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581073946.74.0.48712795453.issue39574@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
keywords: +patch
pull_requests: +17777
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18401

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:15:18 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 07 Feb 2020 11:15:18 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581074118.44.0.825483534533.issue39574@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I've created a PR and requested review from stevendaprano. I think the backports are correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:15:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 11:15:57 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581074157.1.0.875385245002.issue39573@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17778
pull_request: https://github.com/python/cpython/pull/18402

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:17:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 11:17:21 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581074241.38.0.302157019651.issue38324@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17779
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18403

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:18:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 11:18:53 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581074333.1.0.164030610161.issue38324@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_locale and test__locale are still failing on my Windows 10 VM. I proposed PR 18403 to skip failing tests on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Fri Feb  7 06:31:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2020 11:31:10 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581075070.81.0.294112925092.issue39573@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You have merged so much PRs today. What they do?

PyObject cannot just be made an opaque structure. The user code reads and writes its fields directly and via macros. This change would break working code.

We can encourage the user code to prepare to making PyObject an opaque structure. We need to provide a stable C API for access of PyObject fields for this. Note that there is a performance penalty of using functions instead of direct access, so you should have very good reasons to do this.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 07:33:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 07 Feb 2020 12:33:45 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581078825.2.0.726314602936.issue39574@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See a discussion on Python-Dev: https://mail.python.org/archives/list/python-dev at python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHRQJY6V/

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 07:55:50 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 07 Feb 2020 12:55:50 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581080150.01.0.201737985144.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17780
pull_request: https://github.com/python/cpython/pull/18404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Feb  7 09:44:54 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 07 Feb 2020 14:44:54 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
Message-ID: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

There is a problem with the end_col_offset of nested Attribute nodes in decorators. For example, parsing

@a.b.c
def f(): pass

produces the following AST tree (part):

decorator_list=[
    Attribute(
        value=Attribute(
            value=Name(
                id="a",
                ctx=Load(),
                lineno=1,
                col_offset=1,
                end_lineno=1,
                end_col_offset=2,
            ),
            attr="b",
            ctx=Load(),
            lineno=1,
            col_offset=1,
            end_lineno=1,
            *end_col_offset=6*,
        ),
        attr="c",
        ctx=Load(),
        lineno=1,
        col_offset=1,
        end_lineno=1,
        end_col_offset=6,
    )
],

Note that the Attribute node with attr="b" has end_col_offset=6, while it should actually be 4.

----------
components: Interpreter Core
messages: 361595
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Attribute node in a decorator has wrong end_col_offset
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39579>
_______________________________________

From report at bugs.python.org  Fri Feb  7 09:57:54 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 07 Feb 2020 14:57:54 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1581087474.16.0.367724414167.issue39579@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
keywords: +patch
pull_requests: +17781
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18405

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39579>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:08:59 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:08:59 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1581088139.86.0.405965203791.issue36225@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:12:27 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:12:27 +0000
Subject: [issue38880] Subinterpreters: List interpreters associated with a
 channel end
In-Reply-To: <1574352893.51.0.220552171167.issue38880@roundup.psfhosted.org>
Message-ID: <1581088347.2.0.239741580441.issue38880@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38880>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:16:01 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:16:01 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1581088561.39.0.877453776447.issue39511@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:19:28 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Feb 2020 15:19:28 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581088768.15.0.450402163057.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

With _pydecimal the memory also grows very slowly (I didn't have the patience 
to wait for MemoryError).

I'm pretty sure decNumber also does the same, it's just easier to implement 
and does not slow down division for small numbers.

libmpdec always favors precisions from roughly 9-34 digits whenever 
there's a potential performance issue.

The only thing I could imagine is to special-case, say, prec > 10000.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:21:02 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:21:02 +0000
Subject: [issue36876] Global C variables are a problem.
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1581088862.18.0.310593547855.issue36876@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:21:21 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:21:21 +0000
Subject: [issue36877] [meta] Move fields from _PyRuntimeState to
 PyInterpreterState.
In-Reply-To: <1557515517.79.0.229526383765.issue36877@roundup.psfhosted.org>
Message-ID: <1581088881.77.0.571305424062.issue36877@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36877>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:22:07 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:22:07 +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: <1581088927.53.0.610696169293.issue33608@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:22:19 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:22:19 +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: <1581088939.56.0.607805611539.issue10915@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:22:34 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:22:34 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1581088954.36.0.199320012603.issue15751@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:35:16 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Feb 2020 15:35:16 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581089716.69.0.122770962495.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

MAX_PREC is chosen so that 5*MAX_PREC does not overflow 32-bit or 64-bit signed integers. This eliminates many overflow checks for the exponent.

Updating the exponent is (perhaps surprisingly) quite performance sensitive, that's why the 32-bit build does not use a 64-bit exponent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:35:15 2020
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 07 Feb 2020 15:35:15 +0000
Subject: [issue37292] _xxsubinterpreters: Can't unpickle objects defined in
 __main__
In-Reply-To: <1560603991.54.0.788079404137.issue37292@roundup.psfhosted.org>
Message-ID: <1581089715.78.0.0195404183962.issue37292@roundup.psfhosted.org>


Change by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37292>
_______________________________________

From report at bugs.python.org  Fri Feb  7 10:55:35 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Feb 2020 15:55:35 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581090935.27.0.705082286299.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The feature would be nice to have; however, if you choose the precision to match the amount of available RAM things work (I have 8GB here, one word in the coefficient has 19 digits for the 4 bit version):

>>> from decimal import *
>>> c = getcontext()
>>> c.prec = 8 * 2**30 // 64 * 19
>>> c.prec
2550136832
>>> i = Decimal(4)
>>> i / 2
Decimal('2')



So I wonder if we really need to do something here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 11:13:10 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 07 Feb 2020 16:13:10 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581091990.88.0.127125707265.issue39576@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Vedran, as Mark said, the result is defined to have no trailing zeroes.  In general the module strives to return results "as if" infinite precision were used internally, not to actually _use_ infinite precision internally ;-)  Given the same setup, e.g.,

>>> i * decimal.Decimal(0.5)
Decimal('2.0')

works fine.

This isn't purely academic.  The `decimal` docs, at the end:

"""
Q. Is the CPython implementation fast for large numbers?

A. Yes. ...
However, to realize this performance gain, the context needs to be set for unrounded calculations.

>>> c = getcontext()
>>> c.prec = MAX_PREC
>>> c.Emax = MAX_EMAX
>>> c.Emin = MIN_EMIN
"""

I suggested this approach to someone on Stackoverflow, who was trying to compute and write out the result of a multi-hundred-million-digit integer exponentiation.  Which worked fine, and was enormously faster than using CPython's bigints.

But then I noticed "trivial" calculations - like the one here - blowing up with MemoryError too.  Which made sense for, e.g., 1/7, but not for 1/2.

I haven't looked at the implementation.  I assume it's trying in advance to reserve space for a result with MAX_PREC digits.

It's not limited to division; e.g.,

    >>> c.sqrt(decimal.Decimal(4))
    ...
    MemoryError

is also surprising.

Perhaps the only thing to be done is to add words to the part of the docs _recommending_ MAX_PREC, warning about some "unintended consequences" of doing so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 11:52:15 2020
From: report at bugs.python.org (Leslie)
Date: Fri, 07 Feb 2020 16:52:15 +0000
Subject: [issue22213] Make pyvenv style virtual environments easier to
 configure when embedding Python
In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>
Message-ID: <1581094335.23.0.671066596692.issue22213@roundup.psfhosted.org>


Leslie <laszlo.nemeth.pub at gmail.com> added the comment:

I just can say that sorting this issue (and PEP-0432) out would be great!
I run into this issue when embedding CPython in a Windows app, and want to use some pre-installed Python, which is not part of the install package...
So beside pyenv venvs, please keep Windows devs in mind, too!
:)

----------
nosy: +Leslie

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________

From report at bugs.python.org  Fri Feb  7 12:01:16 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Feb 2020 17:01:16 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581094876.31.0.00211547784591.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> This isn't purely academic.  The `decimal` docs, at the end:

Yes, that is a good point. I think for libmpdec I'll just do a trial divmod if prec > BIGNUM_THRESHOLD.



> Perhaps the only thing to be done is to add words to the part of the docs _recommending_ MAX_PREC, warning about some "unintended consequences" of doing so.

This, too. Probably some formula based on the amount of available RAM would do.

----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 12:18:56 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 07 Feb 2020 17:18:56 +0000
Subject: [issue39552] shell scripts use legacy
Message-ID: <1581095936.73.0.369363560314.issue39552@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

As mentioned in the PR, I don't see sufficient evidence that backticks are legacy.  So I'll close this.

----------
assignee:  -> skrah
nosy: +skrah
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39552>
_______________________________________

From report at bugs.python.org  Fri Feb  7 12:38:13 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 07 Feb 2020 17:38:13 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581097093.8.0.894360171063.issue1635741@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/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Feb  7 12:56:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 17:56:19 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1581098179.92.0.625373131364.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset de6f38db4859f7b8fe4da4556f06c52675fff24a by Michael Felt in branch 'master':
bpo-39502: Fix 64-bit Python PyTime_localtime() on AIX  (GH-18285)
https://github.com/python/cpython/commit/de6f38db4859f7b8fe4da4556f06c52675fff24a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Fri Feb  7 12:57:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 17:57:18 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1581098238.71.0.874788336167.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Does time.gmtime() accept year after 2038 on 64-bit AIX? Example on Linux:

>>> time.gmtime(4386268800)
time.struct_time(tm_year=2108, tm_mon=12, tm_mday=30, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=365, tm_isdst=0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Fri Feb  7 13:01:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 18:01:06 +0000
Subject: [issue37088] Add a way to schedule a function to be called from the
 main thread
In-Reply-To: <1559148389.14.0.649589094885.issue37088@roundup.psfhosted.org>
Message-ID: <1581098466.53.0.388990074414.issue37088@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There is not clear rationale to justify the addition of the function, so I reject the feature. If you are still interesting by the function, please elaborate the rationale.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37088>
_______________________________________

From report at bugs.python.org  Fri Feb  7 13:35:53 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 07 Feb 2020 18:35:53 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1581100553.37.0.559998968837.issue39576@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Formulas based on physical RAM probably work well on Linux, but not so well on Windows:  Windows has no "overcommit".  Whether a virtual memory request succeeds on Windows depends on how much RAM (+ swap space, if any) has already been requested across all processes.  It doesn't matter whether pages have actually been created, merely the total number of pages that _may_ be created.

I never bumped into this issue before, because I never used MAX_PREC before ;-)  When I intended to do exact arithmetic in `decimal`, I did this instead:

- guesstimated the max number of decimal digits a computation would need

- set `prec` to be comfortably - but not massively - larger than that

- enabled the Inexact trap, so if I guessed too low I'd get an exception

Maybe the docs could suggest that instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb  7 13:36:25 2020
From: report at bugs.python.org (jack1142)
Date: Fri, 07 Feb 2020 18:36:25 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1581100585.31.0.238090358251.issue12782@roundup.psfhosted.org>


Change by jack1142 <kuba.kuczys at gmail.com>:


----------
nosy: +jack1142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Fri Feb  7 13:45:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 18:45:00 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581101100.19.0.363291998073.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> You have merged so much PRs today. What they do?

I merged changes which prepares CPython code base to make PyObject opaque. I only merged changes which should have no impact on performance, but prepare the API to make the structure opaque.

Right now, Py_SET_REFNCT() stills access directly to PyObject.ob_refcnt. But it becomes possible to make Py_SET_REFNCT() an opaque function call.

Do you see any issue with the changes that I already merged? Using PGO+LTO, static inline functions should be as efficient as the previous code using Py_REFCNT() & cie macros.


> PyObject cannot just be made an opaque structure. The user code reads and writes its fields directly and via macros. This change would break working code.

I'm trying to modifying the limited C API to make it possible: all access to PyObject fields should go through macros or function calls. The question is now how which fields are accessed and how.


> We can encourage the user code to prepare to making PyObject an opaque structure. We need to provide a stable C API for access of PyObject fields for this.

For the short term, I don't plan to make PyObject opaque, so I don't plan to enforce usage of Py_TYPE(), Py_SET_REFCNT(), etc.


> Note that there is a performance penalty of using functions instead of direct access, so you should have very good reasons to do this.

Yeah, replacing Py_REFCNT() macro with an opaque function call is likely to have an impact on performance. It should be properly measure, I'm well aware of that, I already wrote it in a previous comment ;-) I don't plan to push change such right now. And I will wait for the review of my peers (like you) for such change ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 13:48:13 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Feb 2020 18:48:13 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1581101293.31.0.935565442888.issue39432@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

We should not be changing Distutils 3.7 behavior at this late point in its life cycle, particularly since AFAIK this issue has not come up before.  Let's see what ?ukasz thinks for 3.8.

----------
nosy: +lukasz.langa
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Fri Feb  7 14:05:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 07 Feb 2020 19:05:39 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1581102339.04.0.232524298429.issue39529@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/issue39529>
_______________________________________

From report at bugs.python.org  Fri Feb  7 14:32:10 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Feb 2020 19:32:10 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1581103930.1.0.516419925269.issue39529@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I think we still use get_event_loop() in asyncio code, no? If we do, we should start by raising deprecation warnings in those call sites, e.g. if a Future or Lock is created outside of a coroutine and no explicit event loop is passed. We should do this in 3.9. We can then think about deprecating get_event_loop in 3.10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39529>
_______________________________________

From report at bugs.python.org  Fri Feb  7 15:06:14 2020
From: report at bugs.python.org (Caleb Donovick)
Date: Fri, 07 Feb 2020 20:06:14 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1581105974.74.0.889694740256.issue17422@roundup.psfhosted.org>


Change by Caleb Donovick <donovick at cs.stanford.edu>:


----------
nosy: +donovick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Fri Feb  7 16:44:10 2020
From: report at bugs.python.org (Mike Solin)
Date: Fri, 07 Feb 2020 21:44:10 +0000
Subject: [issue39580] Check for COMMAND_LINE_INSTALL variable in
 Python_Documentation.pkg
Message-ID: <1581111850.29.0.0540786191291.issue39580@roundup.psfhosted.org>


New submission from Mike Solin <mike at mikesolin.com>:

Hello Python developers!

I'm looking to deploy Python 3 silently to the Macs that I manage, so I can use Python for various scripts. I'm using Munki to accomplish this. However, the Python_Documentation.pkg subpackage includes this code in the postinstall script:

```
# make link in /Applications/Python m.n/ for Finder users
if [ -d "${APPDIR}" ]; then
    ln -fhs "${FWK_DOCDIR}/index.html" "${APPDIR}/Python Documentation.html"
    open "${APPDIR}" || true  # open the applications folder
fi
```

Would it be possible to test for the $COMMAND_LINE_INSTALL variable before opening a Finder window? If the $COMMAND_LINE_INSTALL exists, it'd be really great if it didn't open the Finder. This would allow me to silently deploy Python 3 without disrupting my users.

Thanks!

Mike

----------
components: macOS
messages: 361610
nosy: flammable, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Check for COMMAND_LINE_INSTALL variable in Python_Documentation.pkg
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39580>
_______________________________________

From report at bugs.python.org  Fri Feb  7 16:46:46 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 07 Feb 2020 21:46:46 +0000
Subject: [issue39580] Check for COMMAND_LINE_INSTALL variable in
 Python_Documentation.pkg
In-Reply-To: <1581111850.29.0.0540786191291.issue39580@roundup.psfhosted.org>
Message-ID: <1581112006.9.0.310638527629.issue39580@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/issue39580>
_______________________________________

From report at bugs.python.org  Fri Feb  7 17:18:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 22:18:30 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581113910.58.0.697576166497.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 60ac6ed5579f6666130fc264d3b748ee9575e3aa by Victor Stinner in branch 'master':
bpo-39573: Use Py_SET_SIZE() function (GH-18402)
https://github.com/python/cpython/commit/60ac6ed5579f6666130fc264d3b748ee9575e3aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 17:42:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 22:42:55 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1581115375.13.0.15124612387.issue39350@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset dc7a50d73a3d16918529669ff7b8783c08cff090 by Victor Stinner in branch 'master':
bpo-39350: Fix fractions for int subclasses (GH-18375)
https://github.com/python/cpython/commit/dc7a50d73a3d16918529669ff7b8783c08cff090


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Feb  7 17:44:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Feb 2020 22:44:10 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1581115450.6.0.409956024914.issue39350@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Miro for the bug report and thanks Mark for the great review and discussion! It should now be fixed. I tested manually that my change fix numpy test suite.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Feb  7 18:36:35 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 07 Feb 2020 23:36:35 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1581118595.82.0.0903340913983.issue39579@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset d2e1098641f98594702ef29049c3c4a3f394786f by Lysandros Nikolaou in branch 'master':
bpo-39579: Fix Attribute end_col_offset to point at the current node (GH-18405)
https://github.com/python/cpython/commit/d2e1098641f98594702ef29049c3c4a3f394786f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39579>
_______________________________________

From report at bugs.python.org  Fri Feb  7 18:46:33 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 07 Feb 2020 23:46:33 +0000
Subject: [issue39575] `coverage` build target should use --coverage instead of
 -lgcov
In-Reply-To: <1581040638.77.0.976018979532.issue39575@roundup.psfhosted.org>
Message-ID: <1581119193.4.0.272479760186.issue39575@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 9a978ddb93bf5eaa519916d9a40c4fa4edf5d854 by Fangrui Song in branch 'master':
closes bpo-39575: Change -lgcov to --coverage. (GH-18382)
https://github.com/python/cpython/commit/9a978ddb93bf5eaa519916d9a40c4fa4edf5d854


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39575>
_______________________________________

From report at bugs.python.org  Fri Feb  7 18:53:05 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Fri, 07 Feb 2020 23:53:05 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1581119585.25.0.96237579576.issue39184@roundup.psfhosted.org>


Change by Saiyang Gou <gousaiyang223 at gmail.com>:


----------
pull_requests: +17782
pull_request: https://github.com/python/cpython/pull/18407

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Fri Feb  7 19:04:54 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 08 Feb 2020 00:04:54 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1581120294.4.0.690512959609.issue39579@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +17783
pull_request: https://github.com/python/cpython/pull/18408

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39579>
_______________________________________

From report at bugs.python.org  Fri Feb  7 19:09:20 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 08 Feb 2020 00:09:20 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1581120560.36.0.15060181398.issue39184@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

Thanks for your review! PR 18407 is for the second list. For now I haven't added audit hooks for the http, socketserver and xmlrpc modules because they look a bit complex. There seems to be so many classes and methods to hook, we may need to find good places to hook (similar to what has been done on ftplib, imaplib, nntplib, poplib, smtplib, telnetlib and urllib).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Fri Feb  7 19:21:47 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 08 Feb 2020 00:21:47 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1581121307.46.0.125366683329.issue39579@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8b9cebce09cb6919fdb97d8e608288a503681d13 by Lysandros Nikolaou in branch '3.8':
[3.8] bpo-39579: Fix Attribute end_col_offset to point at the current node (GH-18405) (GH-18408)
https://github.com/python/cpython/commit/8b9cebce09cb6919fdb97d8e608288a503681d13


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39579>
_______________________________________

From report at bugs.python.org  Fri Feb  7 19:22:17 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 08 Feb 2020 00:22:17 +0000
Subject: [issue39579] Attribute node in a decorator has wrong end_col_offset
In-Reply-To: <1581086694.35.0.395827343786.issue39579@roundup.psfhosted.org>
Message-ID: <1581121337.07.0.829824547076.issue39579@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/issue39579>
_______________________________________

From report at bugs.python.org  Fri Feb  7 19:57:53 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 08 Feb 2020 00:57:53 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581078825.2.0.726314602936.issue39574@roundup.psfhosted.org>
Message-ID: <20200208005747.GH8273@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Feb 07, 2020 at 12:33:45PM +0000, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
> 
> See a discussion on Python-Dev: https://mail.python.org/archives/list/python-dev at python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHRQJY6V/

I don't know whether the very odd calls 

    str(encoding='spam')
    str(errors='eggs')
    str(encoding='spam', errors='eggs')

are intentional or not. I suspect not: to me, it looks like an accident 
of implementation, not a deliberate feature. Under what circumstances 
would somebody intentionally provide an encoding and error handler when 
they aren't actually going to use them? There may be really unusual 
cases:

    args = () if condition else (mybytes,)
    str = str(*args, encoding='spam')

but I doubt they are going to be either common or something we ought to 
encourage. Regardless of whether we deprecate and remove those three odd 
cases or not, I don't think we should bother documenting them.

If anyone disagrees, and wants to document them, that's okay, but you 
can document them as a separate PR with a separate discussion. Let's 
just fix the confusion over the default encoding here and worry about 
other issues later. Don't let the perfect get in the way of the good 
enough for now :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 19:59:23 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 08 Feb 2020 00:59:23 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581123563.92.0.190164954986.issue39574@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that the current changes are an improvement, and should be committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Fri Feb  7 22:36:31 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 08 Feb 2020 03:36:31 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1581132991.34.0.444335974716.issue32309@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17784
pull_request: https://github.com/python/cpython/pull/18410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Fri Feb  7 22:38:45 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 08 Feb 2020 03:38:45 +0000
Subject: [issue25753] Reference leaks in test_smtplib
In-Reply-To: <1448660464.47.0.968238224363.issue25753@psf.upfronthosting.co.za>
Message-ID: <1581133125.25.0.470559253104.issue25753@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> I cannot reproduce these leaks. I think this issue should be closed.

+1, I have run 15+ times in my vm but not found these leaks:(

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25753>
_______________________________________

From report at bugs.python.org  Fri Feb  7 22:53:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 08 Feb 2020 03:53:01 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581133981.19.0.521227233989.issue39573@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17785
pull_request: https://github.com/python/cpython/pull/18411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb  7 23:02:21 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 08 Feb 2020 04:02:21 +0000
Subject: [issue38823] Improve stdlib module initialization error handling.
In-Reply-To: <1573930465.91.0.871939917002.issue38823@roundup.psfhosted.org>
Message-ID: <1581134541.22.0.367897893997.issue38823@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38823>
_______________________________________

From report at bugs.python.org  Fri Feb  7 23:23:54 2020
From: report at bugs.python.org (Martin Panter)
Date: Sat, 08 Feb 2020 04:23:54 +0000
Subject: [issue35318] Check accuracy of str() doc string for its encoding
 argument
In-Reply-To: <1543258146.71.0.788709270274.issue35318@psf.upfronthosting.co.za>
Message-ID: <1581135834.76.0.856244610989.issue35318@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Closing in favour of Issue 39574 where a new wording is proposed

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> str.__doc__ is misleading

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35318>
_______________________________________

From report at bugs.python.org  Sat Feb  8 04:55:36 2020
From: report at bugs.python.org (=?utf-8?b?7J6E7IiY7KeE7ZWZ67aA7IOd?=)
Date: Sat, 08 Feb 2020 09:55:36 +0000
Subject: [issue39581] Python Interpreter Doesn't Work Well In Thread Class
Message-ID: <1581155736.57.0.784199472147.issue39581@roundup.psfhosted.org>


New submission from ?????? <21600590 at handong.edu>:

================================================================
import threading
import time

def threadFunc():
    while True:
        print('new thread')
        time.sleep(2)
def main():
    th = threading.Thread(target=threadFunc())
    th.start()
    while True:
       print('main Thread')
       time.sleep(1)
    th.join()
 
if __name__ == '__main__':
   main()
==============================================================

When I run the above code in python 3.7, it works in unexpected way.

I expected this code causes an syntax error for giving an improper argument to parameter because I gave "threaFunc()" not "threaFun" as an argument of target in Thread class. However, this code executes a function "threadFunc()" as a general function not thread.

----------
components: Windows
messages: 361622
nosy: paul.moore, steve.dower, tim.golden, zach.ware, ??????
priority: normal
severity: normal
status: open
title: Python Interpreter Doesn't Work Well In Thread Class
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39581>
_______________________________________

From report at bugs.python.org  Sat Feb  8 05:14:31 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 Feb 2020 10:14:31 +0000
Subject: [issue39581] Python Interpreter Doesn't Work Well In Thread Class
In-Reply-To: <1581155736.57.0.784199472147.issue39581@roundup.psfhosted.org>
Message-ID: <1581156871.05.0.0249876649386.issue39581@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's no other reasonable way for Python to work here. It *is* an error to pass something that's not a callable as a thread "target", but it's a coding error that can only be detected at runtime, not a syntax error that can be detected statically before the code executes.

And because threadFunc() never returns, Python never gets the opportunity to check the arguments to threading.Thread: the arguments to a function call have to be evaluated before that function call can be made.

It is a fairly common error, though, and it might be possible for a linter to flag this error (though probably with a smattering of false positives and false negatives). That's out of scope for Python itself.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39581>
_______________________________________

From report at bugs.python.org  Sat Feb  8 05:23:15 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 08 Feb 2020 10:23:15 +0000
Subject: [issue39581] Python Interpreter Doesn't Work Well In Thread Class
In-Reply-To: <1581155736.57.0.784199472147.issue39581@roundup.psfhosted.org>
Message-ID: <1581157395.35.0.274067482109.issue39581@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

SyntaxError is produced when there is a syntax problem in the code to be executed, this code is fine from the syntax perspective, so this particular error would not be raised.

It is also perfectly fine to have a function call where you have it, the only thing one would need to observe is that the returned value is a callable (or None which would be return value in your case had your function terminated). Perhaps there is an improvement to be made in documentation by way of giving an example, but the solution you're suggesting is not feasible.

----------
assignee:  -> docs at python
components: +Documentation -Windows
nosy: +SilentGhost, docs at python, pitrou -mark.dickinson
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39581>
_______________________________________

From report at bugs.python.org  Sat Feb  8 05:24:08 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 08 Feb 2020 10:24:08 +0000
Subject: [issue39581] Python Interpreter Doesn't Work Well In Thread Class
In-Reply-To: <1581155736.57.0.784199472147.issue39581@roundup.psfhosted.org>
Message-ID: <1581157448.52.0.85001778121.issue39581@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39581>
_______________________________________

From report at bugs.python.org  Sat Feb  8 06:20:18 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 08 Feb 2020 11:20:18 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1581160818.17.0.598308016326.issue31718@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

The patch for this issue had some outstanding questions/changes to be made before being merged, but now a new PR needs to be opened to replace the original one.  Anyone who is interested can pick this up, but please only open one PR for this and please also credit the original author as per the dev guide.  Thank you!

----------
nosy: +cheryl.sabella
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Sat Feb  8 06:36:07 2020
From: report at bugs.python.org (David CARLIER)
Date: Sat, 08 Feb 2020 11:36:07 +0000
Subject: [issue39582] ossaudiodev update helpers signature
Message-ID: <1581161767.2.0.142949694785.issue39582@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
nosy: devnexen
priority: normal
pull_requests: 17786
severity: normal
status: open
title: ossaudiodev update helpers signature
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39582>
_______________________________________

From report at bugs.python.org  Sat Feb  8 07:08:44 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 08 Feb 2020 12:08:44 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581163724.6.0.326604782021.issue39573@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

"static inline" functions are not opaque - as they get inlined into 3rd-party compiled code, we can't change anything they reference, and so the structure layout is still fixed and has to be visible to the user's compiler.

I'm not totally against the changes, but it's worth pointing out that you aren't achieving what the issue title claims, so it's really just code cleanliness (and/or introducing macro-users to static inline functions ;) ).

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sat Feb  8 07:52:39 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 08 Feb 2020 12:52:39 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1581166359.8.0.337239419828.issue39465@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As Petr notes, as long as all subinterpreters share the GIL, and share str instances, then the existing _Py_IDENTIFIER mechanism will work fine for both single phase and multi-phase initialisation.

However, that constraint also goes the other way: as long as we have modules that use the existing _Py_IDENTIFIER mechanism, then subinterpreters *must* share str instances, and hence *must* share the GIL.

Hence the "enhancement" classification: there's nothing broken right now, but if we're ever going to achieve the design goal of using subinterpreters to exploit multiple CPU cores without the overhead of running multiple full interpreter processes, we're going to need to design a different way of handling this.

Something to keep in mind with `_Py_IDENTIFIER` and any replacement API: the baseline for performance comparisons is https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_InternFromString

The reason multi-phase initialisation makes this more complicated is that it means we can't use the memory addresses of C process globals as unique identifiers any more, since more than one module object may be created from the same C shared library.

However, if we assume we've moved to per-module state storage (to get unique memory addresses back), then we can largely re-use the existing `_Py_IDENTIFIER` machinery to make the lookup as fast as possible, while still avoiding conflicts between subinterpreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Sat Feb  8 08:50:05 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 08 Feb 2020 13:50:05 +0000
Subject: [issue39583] Remove superfluous "extern C" bits from
 Include/cpython/*.h
Message-ID: <1581169805.61.0.60673163843.issue39583@roundup.psfhosted.org>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

I noticed that the files in Include/cpython also have extern C declarations, despite the fact that the only files which #include them do as well. Seems like a small bit of cleanup. PR incoming...

----------
components: C API
messages: 361628
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Remove superfluous "extern C" bits from Include/cpython/*.h
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39583>
_______________________________________

From report at bugs.python.org  Sat Feb  8 08:54:51 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 08 Feb 2020 13:54:51 +0000
Subject: [issue39583] Remove superfluous "extern C" bits from
 Include/cpython/*.h
In-Reply-To: <1581169805.61.0.60673163843.issue39583@roundup.psfhosted.org>
Message-ID: <1581170091.67.0.453922261037.issue39583@roundup.psfhosted.org>


Change by Skip Montanaro <skip.montanaro at gmail.com>:


----------
keywords: +patch
pull_requests: +17787
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39583>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:03:37 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 08 Feb 2020 14:03:37 +0000
Subject: [issue39583] Remove superfluous "extern C" bits from
 Include/cpython/*.h
In-Reply-To: <1581169805.61.0.60673163843.issue39583@roundup.psfhosted.org>
Message-ID: <1581170617.77.0.235881806009.issue39583@roundup.psfhosted.org>


Change by Skip Montanaro <skip.montanaro at gmail.com>:


----------
nosy: +ncoghlan, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39583>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:18:24 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sat, 08 Feb 2020 14:18:24 +0000
Subject: [issue39584] MacOS crashes by running attached Python code
Message-ID: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>


New submission from Vinay Sharma <vinay0410sharma at gmail.com>:

Consider the following python Code.

```
from multiprocessing.shared_memory import SharedMemory
shm = SharedMemory(name='test-crash', create=True, size=1000000000000000000)
```

This causes macOS Catalina, Mojave to freeze and then crash. Although, this works fine on ubuntu.

After, debugging I realised that this is due to the ftruncate call. I could replicate the same by calling os.ftruncate and also using ftruncate in C code.

Following C++ code also crashes, which confirms that ftruncate in macOS is broken:

```
#include <fcntl.h>
#include <sys/shm.h>
#include <sys/stat.h>
#include <iostream>
#include <sys/mman.h>
#include <unistd.h>
#include <sys/types.h>
#include <errno.h>
#include <time.h>

int main() {

    int shm_fd = shm_open("/test-shm2", O_CREAT | O_RDWR, 0666);

    if (shm_fd == -1) {
        throw "Shared Memory Object couldn't be created or opened";
    }

    int rv = ftruncate(shm_fd, (long long)1000000000000000000);

}
```

Should python, in any way handle this, so as to prevent any crashes using python code.

----------
components: C API
messages: 361629
nosy: vinay0410
priority: normal
severity: normal
status: open
title: MacOS crashes by running attached Python code
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:18:41 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sat, 08 Feb 2020 14:18:41 +0000
Subject: [issue39584] MacOS crashes by running attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1581171521.57.0.359445836389.issue39584@roundup.psfhosted.org>


Change by Vinay Sharma <vinay0410sharma at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:27:40 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 08 Feb 2020 14:27:40 +0000
Subject: [issue39585] Delete a pending item in _warning.c
Message-ID: <1581172060.12.0.48939566603.issue39585@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

a pend item could be removed (https://github.com/python/cpython/blob/master/Python/_warnings.c#L493).

two reasons:
1) every warning have `__name__` and it must not NULL(`The tp_name slot must be set;` from pep0253)
2) the `__name__` of Warning class(including children class) can not be removed.

```
>>> del UserWarning.__name__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'UserWarning'
```

----------
components: Interpreter Core
messages: 361630
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Delete a pending item in _warning.c
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39585>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:28:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Feb 2020 14:28:50 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581172130.47.0.502264409075.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> "static inline" functions are not opaque

I'm well aware of that :-) But once the CPython code base will stop accessing directly PyObject fields directly, it would become possible to experiment changing PyObject layout, at least testing it in CPython.

First changes are just to prepare the code base to experiment the real change. But as Serhiy pointed out, the second part will have an impact on performance and so should be carefully benchmarked to balance advantages and drawbacks, even if it's only done in the limited C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:30:41 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 08 Feb 2020 14:30:41 +0000
Subject: [issue39585] Delete a pending item in _warning.c
In-Reply-To: <1581172060.12.0.48939566603.issue39585@roundup.psfhosted.org>
Message-ID: <1581172241.93.0.675253367712.issue39585@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +17789
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18414

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39585>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:32:45 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 08 Feb 2020 14:32:45 +0000
Subject: [issue39585] Delete a pending item in _warning.c
In-Reply-To: <1581172060.12.0.48939566603.issue39585@roundup.psfhosted.org>
Message-ID: <1581172365.59.0.407867171461.issue39585@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

If I am wrong, remove the check operation of `name` is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39585>
_______________________________________

From report at bugs.python.org  Sat Feb  8 09:51:44 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 08 Feb 2020 14:51:44 +0000
Subject: [issue39584] MacOS crashes by running attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1581173504.94.0.580268613224.issue39584@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +davin, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Sat Feb  8 10:07:52 2020
From: report at bugs.python.org (Hugo van Kemenade)
Date: Sat, 08 Feb 2020 15:07:52 +0000
Subject: [issue39586] Deprecate bdist_msi: use bdist_wheel instead
Message-ID: <1581174472.55.0.332465806553.issue39586@roundup.psfhosted.org>


New submission from Hugo van Kemenade <hugovk+python at gmail.com>:

According to the "Deprecate bdist_wininst" discussion (July 2019), bdist_msi can be deprecated:

https://discuss.python.org/t/deprecate-bdist-wininst/1929

Victor Stinner wrote:

"Now the question is if someone here wants to go further is deprecate all distutils commands except sdist and bdist_wheel? Steve Dower wants to deprecate bdist_msi as well: I?m not sure who use bdist_msi. It?s another form of GUI installer, so it?s similar to bdist_wininst. I would also strongly encourage to use bdist_wheel rather than bdist_msi."

Brett Cannon wrote:

"Probably a good idea, but I personally don?t have the time."

Steve Dower wrote:

"I think the others are fine to leave (though if people who work more closely with those tools want to say drop them then I?m fine with that too).

"bdist_msi and bdist_exe don?t integrate with any other package managers, can?t be integrated with any other installer besides our own Python installer, and in any case are worse than simply copying the files. (If we had a bdist_msm I?d be slightly more sympathetic, but we don?t and probably should not :) )

"I also don?t necessarily think that wheels are always the alternative, particularly for embedded scenarios, but I do think that the fewer options we provide by default will help people find the option they actually need, rather than assuming that because it?s ?blessed? it must see correct."


And in "Remove distutils bdist_wininst command" (February 2020):

https://discuss.python.org/t/remove-distutils-bdist-wininst-command/3115

Victor Stinner wrote:

"I don?t plan to remove bdist_msi, even if wheel packages are now recommended."

Steve Dower wrote:

"We should, though. Installing a package using an MSI is worse than an EXE, as it leaves far more cruft behind if you don?t uninstall it before changing/removing the Python install.

"Standalone apps should bundle everything, like pynsist or briefcase. GPO deployment should create their own MSI with everything they want in the bundle and deploy that. Perhaps someone can make an ?installer? based on the py.exe launcher (which I believe supports an attached zip file) that will use pip and a local/embedded wheel.

"But we should really discourage package installs that don?t support venv and/or leave cruft behind."

Victor Stinner wrote:

"If you want to see it disappear, you should start by deprecating it in Python 3.9. It would be a first step."

PR to follow.

See also:
* https://bugs.python.org/issue37481 "Deprecate bdist_wininst: use bdist_wheel instead"
* https://bugs.python.org/issue39541 "distutils: Remove bdist_wininst (Windows .exe installers) in favor of bdist_wheel (.whl)"

----------
components: Distutils, Windows
messages: 361633
nosy: dstufft, eric.araujo, hugovk, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Deprecate bdist_msi: use bdist_wheel instead
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39586>
_______________________________________

From report at bugs.python.org  Sat Feb  8 10:15:11 2020
From: report at bugs.python.org (Hugo van Kemenade)
Date: Sat, 08 Feb 2020 15:15:11 +0000
Subject: [issue39586] Deprecate bdist_msi: use bdist_wheel instead
In-Reply-To: <1581174472.55.0.332465806553.issue39586@roundup.psfhosted.org>
Message-ID: <1581174911.24.0.772235892542.issue39586@roundup.psfhosted.org>


Change by Hugo van Kemenade <hugovk+python at gmail.com>:


----------
keywords: +patch
pull_requests: +17790
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39586>
_______________________________________

From report at bugs.python.org  Sat Feb  8 10:34:54 2020
From: report at bugs.python.org (Nishant Misra)
Date: Sat, 08 Feb 2020 15:34:54 +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: <1581176094.82.0.946329680894.issue28859@roundup.psfhosted.org>


Nishant Misra <nishant.mnnit2k9 at gmail.com> added the comment:

I would like to take this issue as my first issue to start contributing to Python development.

----------
nosy: +scic0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28859>
_______________________________________

From report at bugs.python.org  Sat Feb  8 16:01:31 2020
From: report at bugs.python.org (Ryan McCampbell)
Date: Sat, 08 Feb 2020 21:01:31 +0000
Subject: [issue39587] Mixin repr overrides Enum repr in some cases
Message-ID: <1581195691.69.0.82674637062.issue39587@roundup.psfhosted.org>


New submission from Ryan McCampbell <rmccampbell7 at gmail.com>:

In Python 3.6 the following works:

class HexInt(int):
    def __repr__(self):
        return hex(self)

class MyEnum(HexInt, enum.Enum):
    A = 1
    B = 2
    C = 3

>>> MyEnum.A
<MyEnum.A: 0x1>

However in Python 3.7/8 it instead prints
>>> MyEnum.A
0x1

It uses HexInt's repr instead of Enum's. Looking at the enum.py module it seems that this occurs for mixin classes that don't define __new__ due to a change in the _get_mixins_ method. If I define a __new__ method on the HexInt class then the expected behavior occurs.

----------
components: Library (Lib)
messages: 361635
nosy: rmccampbell7
priority: normal
severity: normal
status: open
title: Mixin repr overrides Enum repr in some cases
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39587>
_______________________________________

From report at bugs.python.org  Sat Feb  8 16:45:30 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 08 Feb 2020 21:45:30 +0000
Subject: [issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
Message-ID: <1581198329.98.0.186422149655.issue39588@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

Four functions in Objects/unicodectype.c copy values out of lookup tables with a for loop

        int i;
        for (i = 0; i < n; i++)
            res[i] = _PyUnicode_ExtendedCase[index + i];

instead of a memcpy

        memcpy(res, &_PyUnicode_ExtendedCase[index], n * sizeof(Py_UCS4));

My Apple clang version 11.0.0 on my Mac optimizes away the for loop and generates equivalent code to the memcpy.

gcc 4.8.5 on my Linux box (the newest GCC I have) does not optimize away the loop.

The four functions are:
_PyUnicode_ToLowerFull
_PyUnicode_ToTitleFull
_PyUnicode_ToUpperFull
_PyUnicode_ToFoldedFull

----------
components: Unicode
messages: 361636
nosy: ezio.melotti, petdance, vstinner
priority: normal
severity: normal
status: open
title: Use memcpy() instead of for() loops in _PyUnicode_To*
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39588>
_______________________________________

From report at bugs.python.org  Sat Feb  8 16:52:56 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 08 Feb 2020 21:52:56 +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: <1581198776.13.0.940286466202.issue39150@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

I'm closing this as it seems there's not much interest in this.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Sat Feb  8 16:54:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Feb 2020 21:54:27 +0000
Subject: [issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
In-Reply-To: <1581198329.98.0.186422149655.issue39588@roundup.psfhosted.org>
Message-ID: <1581198867.13.0.239831256015.issue39588@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

In the past, we've also gotten some gains by replacing memcpy() with for-loops.  These kinds of optimization choices are best left to the compiler.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39588>
_______________________________________

From report at bugs.python.org  Sat Feb  8 18:46:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 08 Feb 2020 23:46:05 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581205565.85.0.520642947673.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7f6f7eef5206858030cbe4f80a7c04b02781cc9a by Dong-hee Na in branch 'master':
bpo-39573: Use Py_TYPE() macro in ctypes.h (GH-18411)
https://github.com/python/cpython/commit/7f6f7eef5206858030cbe4f80a7c04b02781cc9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sat Feb  8 20:52:36 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 01:52:36 +0000
Subject: [issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
In-Reply-To: <1581198329.98.0.186422149655.issue39588@roundup.psfhosted.org>
Message-ID: <1581213156.22.0.116677713782.issue39588@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Thanks for replying. I figured that might be the case, which is why I made a ticket before bothering with a pull request.

I've also seen this kind of thing around:

                i = ctx->pattern[0];
                Py_ssize_t groupref = i+i;

instead of

                Py_ssize_t groupref = ctx->pattern[0]*2;

Is that also the kind of thing we would leave for the compiler to sort out?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39588>
_______________________________________

From report at bugs.python.org  Sat Feb  8 22:31:28 2020
From: report at bugs.python.org (Simon)
Date: Sun, 09 Feb 2020 03:31:28 +0000
Subject: [issue39589] Logging QueueListener should support context manager
Message-ID: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>


New submission from Simon <sfbbrugman at gmail.com>:

The QueueListener could be extended to support the context manager.

----------
components: Library (Lib)
messages: 361641
nosy: sbrugman
priority: normal
severity: normal
status: open
title: Logging QueueListener should support context manager
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/issue39589>
_______________________________________

From report at bugs.python.org  Sat Feb  8 22:33:15 2020
From: report at bugs.python.org (Simon)
Date: Sun, 09 Feb 2020 03:33:15 +0000
Subject: [issue39589] Logging QueueListener should support context manager
In-Reply-To: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>
Message-ID: <1581219195.72.0.80541841669.issue39589@roundup.psfhosted.org>


Change by Simon <sfbbrugman at gmail.com>:


----------
keywords: +patch
pull_requests: +17792
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18417

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39589>
_______________________________________

From report at bugs.python.org  Sat Feb  8 23:15:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 09 Feb 2020 04:15:41 +0000
Subject: [issue39587] Mixin repr overrides Enum repr in some cases
In-Reply-To: <1581195691.69.0.82674637062.issue39587@roundup.psfhosted.org>
Message-ID: <1581221741.75.0.170206754845.issue39587@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/issue39587>
_______________________________________

From report at bugs.python.org  Sat Feb  8 23:17:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Feb 2020 04:17:18 +0000
Subject: [issue39587] Mixin repr overrides Enum repr in some cases
In-Reply-To: <1581195691.69.0.82674637062.issue39587@roundup.psfhosted.org>
Message-ID: <1581221838.62.0.849957396715.issue39587@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39587>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:02:53 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 09 Feb 2020 05:02:53 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
Message-ID: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Similar to https://bugs.python.org/issue39453, but with deques:

Python 3.9.0a3+:

>>> from collections import deque
>>> class A:
...     def __eq__(self, other):
...         L.clear()
...         return NotImplemented
...
>>> L = [A(), A(), A()]
>>> 17 in L
False
>>> L = deque([A(), A(), A()])
>>> 17 in L

(Crashes with "Unhandled exception thrown: read access violation.")

----------
components: Library (Lib)
messages: 361642
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: collections.deque.__contains__ and .count should hold strong references.
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:44:35 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 05:44:35 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
Message-ID: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

The functions tb_displayline and tb_printinternal can take const pointers on some of their arguments.

tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject *name)

tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit)

----------
components: Interpreter Core
messages: 361643
nosy: petdance
priority: normal
severity: normal
status: open
title: Functions in Python/traceback.c can take const pointer arguments
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:46:39 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 05:46:39 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581227199.0.0.114631572043.issue39491@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +17793
pull_request: https://github.com/python/cpython/pull/18420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:47:05 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 05:47:05 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581227225.52.0.290247197809.issue39591@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17794
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:48:39 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 09 Feb 2020 05:48:39 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581227319.83.0.807908175592.issue39573@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17795
pull_request: https://github.com/python/cpython/pull/18419

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:48:49 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 09 Feb 2020 05:48:49 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
In-Reply-To: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>
Message-ID: <1581227329.53.0.64746485555.issue39590@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
keywords: +patch
pull_requests: +17796
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18421

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:50:38 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 05:50:38 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581227438.0.0.504636828574.issue39491@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +17797
pull_request: https://github.com/python/cpython/pull/18422

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:50:50 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 05:50:50 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581227450.08.0.0126460643437.issue39591@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +17798
pull_request: https://github.com/python/cpython/pull/18422

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:51:15 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 05:51:15 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581227475.93.0.512412909573.issue39591@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -17794

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 00:57:11 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 09 Feb 2020 05:57:11 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
In-Reply-To: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>
Message-ID: <1581227831.24.0.158822851997.issue39590@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Should there be a similar generic test case in test.seq_test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 01:44:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 09 Feb 2020 06:44:25 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581230665.96.0.396027437608.issue39491@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -17797

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Sun Feb  9 01:44:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 09 Feb 2020 06:44:36 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581230676.88.0.249922261403.issue39491@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -17793

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Sun Feb  9 02:01:58 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 07:01:58 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
In-Reply-To: <1580865031.43.0.941790875733.issue39491@roundup.psfhosted.org>
Message-ID: <1581231718.72.0.161855993716.issue39491@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +17799
pull_request: https://github.com/python/cpython/pull/18422

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Sun Feb  9 02:08:17 2020
From: report at bugs.python.org (F4zi)
Date: Sun, 09 Feb 2020 07:08:17 +0000
Subject: [issue39592] Year not updated at python.org
Message-ID: <1581232097.07.0.139601971963.issue39592@roundup.psfhosted.org>


New submission from F4zi <fazbosoreq at gmail.com>:

The year in https://www.python.org/psf/donations/python-dev/

Should be changed from 2019 to 2020

----------
assignee: docs at python
components: Documentation
messages: 361645
nosy: F4zi, docs at python, eric.araujo, ezio.melotti, mdk, willingc
priority: normal
severity: normal
status: open
title: Year not updated at python.org

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39592>
_______________________________________

From report at bugs.python.org  Sun Feb  9 02:11:10 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 09 Feb 2020 07:11:10 +0000
Subject: [issue39592] Year not updated at python.org
In-Reply-To: <1581232097.07.0.139601971963.issue39592@roundup.psfhosted.org>
Message-ID: <1581232270.03.0.905248649418.issue39592@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Please direct this to https://github.com/python/pythondotorg/issues

This tracker is for issues pertaining to the interpreter.

----------
nosy: +ammar2
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39592>
_______________________________________

From report at bugs.python.org  Sun Feb  9 03:16:56 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Feb 2020 08:16:56 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
In-Reply-To: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>
Message-ID: <1581236216.68.0.74393634958.issue39590@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c6dedde160a9fce5d049e860f586ad8f93aec822 by sweeneyde in branch 'master':
bpo-39590: make deque.__contains__ and deque.count hold strong references (GH-18421)
https://github.com/python/cpython/commit/c6dedde160a9fce5d049e860f586ad8f93aec822


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 03:17:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 09 Feb 2020 08:17:08 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
In-Reply-To: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>
Message-ID: <1581236228.2.0.741841907924.issue39590@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17800
pull_request: https://github.com/python/cpython/pull/18423

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 03:17:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Feb 2020 08:17:34 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
In-Reply-To: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>
Message-ID: <1581236254.69.0.182723212875.issue39590@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 03:39:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Feb 2020 08:39:39 +0000
Subject: [issue39590] collections.deque.__contains__ and .count should hold
 strong references.
In-Reply-To: <1581224573.69.0.537740260718.issue39590@roundup.psfhosted.org>
Message-ID: <1581237579.39.0.200768320989.issue39590@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset dc56f5f48866bf3c5412642bba00890d9a090cfb by Miss Islington (bot) in branch '3.8':
bpo-39590: make deque.__contains__ and deque.count hold strong references (GH-18421) (GH-18423)
https://github.com/python/cpython/commit/dc56f5f48866bf3c5412642bba00890d9a090cfb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39590>
_______________________________________

From report at bugs.python.org  Sun Feb  9 07:35:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Feb 2020 12:35:04 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581251704.27.0.269328640792.issue39591@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

They cannot. PyObject cannot be const because the code that uses it can change its reference counter even if it does not change any other fields.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 07:35:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Feb 2020 12:35:22 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581251722.73.0.432856215876.issue39591@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 08:57:10 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Feb 2020 13:57:10 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581256630.55.0.785579454562.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

p.s. for what it's worth: I re-checked my math and as usual I goofed.  It takes *30* bits to store the non-fractional seconds part of the current time in a double, leaving 23 bits for the fractional part, so we're *7* bits short.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Feb  9 09:42:49 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 Feb 2020 14:42:49 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581259369.2.0.905718947899.issue39484@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Larry]

> It takes *30* bits to store the non-fractional seconds part of the current time in a double

I make it 31. :-)

>>> from datetime import datetime
>>> time_since_epoch = datetime.now() - datetime(1970, 1, 1)
>>> int(time_since_epoch.total_seconds()).bit_length()
31

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Feb  9 09:55:02 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 09 Feb 2020 14:55:02 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581260102.74.0.348471427723.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Yes, but you get the first 1 bit for free.  So it actually only uses 30 bits of storage inside the double.

This is apparently called "leading bit convention":

https://en.wikipedia.org/wiki/IEEE_754#Representation_and_encoding_in_memory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Feb  9 10:16:38 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 15:16:38 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581261398.47.0.692973140451.issue39591@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -17798

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 10:17:18 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 Feb 2020 15:17:18 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581261438.18.0.877744607165.issue39484@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Yes, but you get the first 1 bit for free.

Not really. :-) That's a detail of how floating-point numbers happen to be stored; it's not really relevant here. It doesn't affect the fact that IEEE 754 binary64 floats have 53 bits of *precision*, so using 31 for the integer part leaves only 22 for the fractional part, so we're 8 bits short, not 7.

(If you really want, you can subtract 30 from 52 instead of 31 from 53, but it's just a more complicated way of doing the same calculation, and doesn't change the result.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Feb  9 10:28:09 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 09 Feb 2020 15:28:09 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581262089.06.0.451796966853.issue39484@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's another way to see it. Let's get the Unix timestamp for right now:

>>> from datetime import datetime
>>> epoch = datetime(1970, 1, 1)
>>> now = (datetime.now() - epoch).total_seconds()
>>> now
1581261916.910558

Now let's figure out the resolution, by taking the next float up from that value and subtracting.

>>> from math import nextafter, inf
>>> nextafter(now, inf) - now
2.384185791015625e-07

That's 2**-22, or a little bit less than a quarter of a microsecond. We're out from our desired resolution (1ns) by a factor of ~239, so it's going to take another 8 bits (factor of 256) to get us there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Feb  9 10:54:03 2020
From: report at bugs.python.org (Andy Lester)
Date: Sun, 09 Feb 2020 15:54:03 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581263643.58.0.230029442364.issue39591@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

I'm sorry, I think my comment was misleading.

The changes I had proposed were not making the object itself const, but some of the arguments in the static worker functions.  For example:

-tb_displayline(PyObject *f, PyObject *filename, int lineno, PyObject *name)
+tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject *name)

and

-tb_printinternal(PyTracebackObject *tb, PyObject *f, long limit)
+tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit)

I've got -Wincompatible-pointer-types-discards-qualifiers and -Wcast-qual turned on, and no errors occur.

Is there somewhere in the deep internals of the Python macros where constness can be changed but the compiler isn't reporting on it?

Thanks,
Andy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 11:17:25 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 09 Feb 2020 16:17:25 +0000
Subject: [issue39593] Adding a unit test of ctypes
Message-ID: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

strlen(data) can not be replaced by Py_SIZE(value) in https://github.com/python/cpython/blob/master/Modules/_ctypes/cfield.c#L1297.

victor have give a great example about it in https://github.com/python/cpython/pull/18419

I create this bpo for two reasons:
1. This question info could be removed(some questions info will catch my attention?
2. Current tests should be enhanced(It can not help me found this backward incompatible:( ).

----------
components: Tests
messages: 361656
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Adding a unit test of ctypes
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Sun Feb  9 11:19:39 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 09 Feb 2020 16:19:39 +0000
Subject: [issue39593] Adding a unit test of ctypes
In-Reply-To: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>
Message-ID: <1581265179.07.0.253808431932.issue39593@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +17801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18424

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Sun Feb  9 11:46:43 2020
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 09 Feb 2020 16:46:43 +0000
Subject: [issue39578] MagicMock specialisation instance can no longer be
 passed to new MagicMock instance
In-Reply-To: <1581068321.62.0.885951490226.issue39578@roundup.psfhosted.org>
Message-ID: <1581266803.81.0.642192045977.issue39578@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Having not looked deeply at it but with the reproducer, running a quick bisect, it points to this commit: https://github.com/python/cpython/commit/77b3b7701a34ecf6316469e05b79bb91de2addfa 
I'll try having a look later at the day if I can manage to free some time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39578>
_______________________________________

From report at bugs.python.org  Sun Feb  9 12:19:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 09 Feb 2020 17:19:32 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581268772.13.0.611720695856.issue39591@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, Py_INCREF and Py_DECREF change the type, and therefore constness.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Sun Feb  9 12:30:30 2020
From: report at bugs.python.org (Chenyoo Hao)
Date: Sun, 09 Feb 2020 17:30:30 +0000
Subject: [issue39594] Typo in documentation for os.times
Message-ID: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>


New submission from Chenyoo Hao <solitaire2312 at gmail.com>:

1.Formatting error due to an extra space (After the MSDN link).
2.There are extra words.

Original?

See the Unix manual page :manpage:`times(2)` and :manpage:`times(3)` manual page on Unix or `the GetProcessTimes MSDN <https://docs.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes>` _ on Windows. On Windows, only :attr:`user` and :attr:`system` are known; the other attributes are zero.

After modification?

See the manual page :manpage:`times(2)` and :manpage:`times(3)` on Unix or the `GetProcessTimes MSDN <https://docs.microsoft.com/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes>`_ on Windows. On Windows, only :attr:`user` and :attr:`system` are known; the other attributes are zero.

----------
assignee: docs at python
components: Documentation
messages: 361659
nosy: Chenyoo Hao, docs at python
priority: normal
severity: normal
status: open
title: Typo in documentation for os.times
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Sun Feb  9 14:48:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Feb 2020 19:48:49 +0000
Subject: [issue39512] expat parser not xml 1.1 compliant (breaks xmlrpclib) -
 still
In-Reply-To: <1580495168.43.0.888386577415.issue39512@roundup.psfhosted.org>
Message-ID: <1581277729.18.0.826407043461.issue39512@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Stefen, do you know anything about this?  There is no coredev expert for xmlrpc.

----------
nosy: +scode, terry.reedy
title: expat parser not xml 1.1 (breaks xmlrpclib) - still -> expat parser not xml 1.1 compliant (breaks xmlrpclib) - still

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39512>
_______________________________________

From report at bugs.python.org  Sun Feb  9 15:12:34 2020
From: report at bugs.python.org (Chris Withers)
Date: Sun, 09 Feb 2020 20:12:34 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1581279154.57.0.484433210388.issue39551@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Hmm, the more we get into this, the less comfortable I am of the patch in the PR.

Instead of copying and pasting more code that's likely to get out of sync, could you change the PR to just replace _importer with the correct parts of importlib to support your usecase?

Keep the unit test though, useful to show in mock why the change is needed, and make sure we do something sensible in the backport!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39551>
_______________________________________

From report at bugs.python.org  Sun Feb  9 15:12:42 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Feb 2020 20:12:42 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1581279162.42.0.484650390968.issue39521@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I do not see the within-version slowdown on fresh Windows 10, Pro 64, 32-bit debug builds.

3.7: 26.4, 27.0
3.8: 26.8, 27.1  # installed normal 64 bit is 7.4, 7.4
3.9: 30.2, 30.1  # 10% slower

----------
components: +Windows
nosy: +paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39521>
_______________________________________

From report at bugs.python.org  Sun Feb  9 15:14:08 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Feb 2020 20:14:08 +0000
Subject: [issue39523] Unnecessary variable assignment and initial loop check
 in pysqlite_cursor_executescript
In-Reply-To: <1580609121.79.0.36186029109.issue39523@roundup.psfhosted.org>
Message-ID: <1581279248.18.0.145427908015.issue39523@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39523>
_______________________________________

From report at bugs.python.org  Sun Feb  9 15:16:24 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Feb 2020 20:16:24 +0000
Subject: [issue39531] Memory Leak in multiprocessing.Pool()
In-Reply-To: <1580671166.84.0.839644381298.issue39531@roundup.psfhosted.org>
Message-ID: <1581279384.37.0.756263765672.issue39531@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39531>
_______________________________________

From report at bugs.python.org  Sun Feb  9 15:20:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Feb 2020 20:20:00 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581037628.78.0.57098348034.issue39574@roundup.psfhosted.org>
Message-ID: <1581279600.49.0.478669182546.issue39574@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/issue39574>
_______________________________________

From report at bugs.python.org  Sun Feb  9 16:01:22 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 09 Feb 2020 21:01:22 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
Message-ID: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

As reported in [jaraco/zipp#32](https://github.com/jaraco/zipp/issues/32), performance of zipfile.Path is inadequate. This bug tracks the incorporation of those improvements as well as those in [importlib_metadata 1.5](https://importlib-metadata.readthedocs.io/en/latest/changelog%20(links).html#v1-5-0).

----------
messages: 361663
nosy: jaraco
priority: normal
severity: normal
status: open
title: Improve performance of importlib.metadata and zipfile.Path
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39595>
_______________________________________

From report at bugs.python.org  Sun Feb  9 16:01:31 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 09 Feb 2020 21:01:31 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
In-Reply-To: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>
Message-ID: <1581282091.79.0.858648379583.issue39595@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39595>
_______________________________________

From report at bugs.python.org  Sun Feb  9 16:16:15 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 09 Feb 2020 21:16:15 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
In-Reply-To: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>
Message-ID: <1581282975.53.0.734613742248.issue39595@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +17802
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18406

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39595>
_______________________________________

From report at bugs.python.org  Sun Feb  9 19:24:28 2020
From: report at bugs.python.org (mefistotelis)
Date: Mon, 10 Feb 2020 00:24:28 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1581294268.66.0.931362343079.issue39011@roundup.psfhosted.org>


mefistotelis <mefistotelis at gmail.com> added the comment:

Patch attached.

I was thinking about one for() instead, but didn't wanted to introduce too large changes..

Let me know if you would prefer something like:

    for i in (9,10,13,):
        if chr(i) not in text: continue
        text = text.replace(chr(i), "&#{:02d};".format(i))

That would also make it easy to extend for other chars, ie. if we'd like  the parser to be always able to re-read the XML we've created. Currently, placing control chars in attributes will prevent that. But I'm getting out of scope of this issue now.

----------
keywords: +patch
Added file: https://bugs.python.org/file48885/0001-bpo-39011-Preserve-line-endings-within-attributes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Sun Feb  9 20:28:45 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 10 Feb 2020 01:28:45 +0000
Subject: [issue38938] Possible performance improvement for heaqq.merge()
In-Reply-To: <1574995461.08.0.901532396583.issue38938@roundup.psfhosted.org>
Message-ID: <1581298125.46.0.395358298777.issue38938@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
pull_requests: +17803
pull_request: https://github.com/python/cpython/pull/18427

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38938>
_______________________________________

From report at bugs.python.org  Sun Feb  9 20:54:48 2020
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Feb 2020 01:54:48 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581299688.7.0.0951990507208.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Aha!  The crucial distinction is that IEEE 754 doubles have 52 bits of storage for the mantissa, but folks (e.g. Wikipedia, Mark Dickinson) describe this as "53 bits of precision" because that's easier saying "52 bits but you don't have to store the leading 1 bit".

To round the bases: the actual physical storage of a double is 1 sign bit + 52 mantissa bits + 11 exponent bits = 64 bits.  The current time in seconds is 31 bits, but we get the leading 1 for free so it only takes up 30 bits of the mantissa.  Therefore we only have 22 bits of precision left for the fractional second, therefore we're 8 bits short of being able to represent every billionth of a second.  We can represent approximately 0.4% of all distinct billionths of a second, which is just sliiightly more than 1/256 (0.39%).

Just to totally prove it to myself, I wrote a brute-force Python program.  It starts with 1581261916, then for i in range(one_billion) it adds i / one_billion to that number.  It then checks to see if that result is different from the previous result.  It detected 4194304 times the result was different, which is exactly 2**22.  QED.


p.s. I knew in my heart that I would never *actually* correct Mark Dickinson on something regarding floating point numbers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Sun Feb  9 23:26:22 2020
From: report at bugs.python.org (hongweipeng)
Date: Mon, 10 Feb 2020 04:26:22 +0000
Subject: [issue39451] enum.Enum reference count leaks
In-Reply-To: <1579933833.85.0.945475764886.issue39451@roundup.psfhosted.org>
Message-ID: <1581308782.08.0.0218185311434.issue39451@roundup.psfhosted.org>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
nosy: +hongweipeng

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39451>
_______________________________________

From report at bugs.python.org  Sun Feb  9 23:50:42 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 10 Feb 2020 04:50:42 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581310242.46.0.248495071154.issue39484@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

A binary float has the form (-1)**sign * (1 + frac) * 2**exp, where sign is 0 or 1, frac is a rational value in the range [0, 1), and exp is a signed integer (but stored in non-negative, biased form). The smallest value of frac is epsilon, and the smallest increment for a given power of two is thus epsilon * 2**exp. To get exp for a given value, we have log2(abs(value)) == log2((1 + frac) * 2**exp) == log2(1 + frac) + log2(2**exp) == log2(1 + frac) + exp. Thus exp == log2(abs(value)) - log2(1 + frac). We know log2(1 + frac) is in the range [0, 1), so exp is the floor of the log2 result. For a binary64, epsilon is 2**-52, but we can leave it up to the floating point implementation by using sys.float_info:

    >>> exp = math.floor(math.log2(time.time()))
    >>> sys.float_info.epsilon * 2**exp
    2.384185791015625e-07

Anyway, it's better to leave it to the experts:

    >>> t = time.time()
    >>> math.nextafter(t, math.inf) - t
    2.384185791015625e-07

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Mon Feb 10 00:55:23 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Feb 2020 05:55:23 +0000
Subject: [issue39587] Mixin repr overrides Enum repr in some cases
In-Reply-To: <1581195691.69.0.82674637062.issue39587@roundup.psfhosted.org>
Message-ID: <1581314123.83.0.160222598334.issue39587@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Bisecting points to issue29577 that introduced this change.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39587>
_______________________________________

From report at bugs.python.org  Mon Feb 10 01:47:14 2020
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 10 Feb 2020 06:47:14 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581317234.97.0.252432350615.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

> Anyway, it's better to leave it to the experts:

I'm not sure what you're suggesting here.  I shouldn't try to understand how floating-point numbers are stored?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Mon Feb 10 02:34:39 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 10 Feb 2020 07:34:39 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1581320079.27.0.418930640316.issue39484@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I'm not sure what you're suggesting here. I shouldn't try to understand 
> how floating-point numbers are stored?

No, that's the furthest thought from my mind. I meant only that I would not recommend using one's own understanding of floating-point numbers instead of something like math.nextafter. Even if I correctly understand the general case, there are probably corner cases that I'm not aware of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Mon Feb 10 02:35:43 2020
From: report at bugs.python.org (wyz23x2)
Date: Mon, 10 Feb 2020 07:35:43 +0000
Subject: [issue39596] reverse parameter for enumerate()
Message-ID: <1581320143.14.0.190118566768.issue39596@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Starting from Python 2.3, the handy enumerate() was introduced.
However, I suggest to add a "reverse" parameter:
>>> lis = ['a', 'b', 'c', 'd']
>>> list(enumerate(lis))
[(0,'a'),(1,'b'),(2,'c'),(3,'d')]
>>> list(enumerate(lis,reverse=True)
[('a',0),('b',1),('c',2),('d',3)]
>>>

----------
components: Build
messages: 361670
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: reverse parameter for enumerate()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39596>
_______________________________________

From report at bugs.python.org  Mon Feb 10 02:37:03 2020
From: report at bugs.python.org (wyz23x2)
Date: Mon, 10 Feb 2020 07:37:03 +0000
Subject: [issue39596] reverse parameter for enumerate()
In-Reply-To: <1581320143.14.0.190118566768.issue39596@roundup.psfhosted.org>
Message-ID: <1581320223.81.0.7609843098.issue39596@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

A typo in the previous comment:
>>> list(enumerate(lis,reverse=True))
[('a',0),('b',1),('c',2),('d',3)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39596>
_______________________________________

From report at bugs.python.org  Mon Feb 10 02:59:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 07:59:23 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1581321562.99.0.553718764965.issue39341@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close this issue as a duplicate of bpo-36260.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [security] CVE-2019-9674: Zip Bomb vulnerability

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Mon Feb 10 02:59:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 07:59:41 +0000
Subject: [issue36260] [security] CVE-2019-9674: Zip Bomb vulnerability
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1581321581.78.0.465038956624.issue36260@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-39341 as a duplicate of this issue: "[security] zipfile: ZIP Bomb vulnerability, don't check announced uncompressed size".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Mon Feb 10 03:09:00 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 10 Feb 2020 08:09:00 +0000
Subject: [issue39596] reverse parameter for enumerate()
In-Reply-To: <1581320143.14.0.190118566768.issue39596@roundup.psfhosted.org>
Message-ID: <1581322140.6.0.764650758737.issue39596@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

What is the use case for this? You seem to want `enumerate` to return (item, index) instead of (index, item) when `reverse=True`? You can achieve this yourself easily a custom generator:

>>> def swapped_enumerate(l):
...   for idx, item in enumerate(l):
...     yield item, idx
...
>>> list(swapped_enumerate(lis))
[('a', 0), ('b', 1), ('c', 2), ('d', 3)]

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39596>
_______________________________________

From report at bugs.python.org  Mon Feb 10 03:41:14 2020
From: report at bugs.python.org (Shani M)
Date: Mon, 10 Feb 2020 08:41:14 +0000
Subject: [issue39597] sorting the String
Message-ID: <1581324074.07.0.0879941203832.issue39597@roundup.psfhosted.org>


New submission from Shani M <itsmeurshani at gmail.com>:

It showing the wrong string order. 'sss' is to be appear at 3rd place but it comes at last place. 'qwe' is to appear at last place but it comes at 3rd place.

----------
files: Screenshot from 2020-02-10 14-08-52.png
messages: 361675
nosy: Shani M
priority: normal
severity: normal
status: open
title: sorting the String
versions: Python 2.7
Added file: https://bugs.python.org/file48886/Screenshot from 2020-02-10 14-08-52.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39597>
_______________________________________

From report at bugs.python.org  Mon Feb 10 04:24:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 10 Feb 2020 09:24:03 +0000
Subject: [issue39596] reverse parameter for enumerate()
In-Reply-To: <1581320143.14.0.190118566768.issue39596@roundup.psfhosted.org>
Message-ID: <1581326643.13.0.235200557048.issue39596@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You can already do this using existing composable tools, including:

>>> list((item, idx) for idx, item in enumerate(lis))
[('a', 0), ('b', 1), ('c', 2), ('d', 3)]
>>>

We won't be adding a parameter to enumerate in order add another way of doing this.

If you really want to pursue this, you should discuss it on the python-ideas mailing list and try to get the idea accepted there. But it really doesn't have any chance of being accepted.

----------
nosy: +eric.smith
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39596>
_______________________________________

From report at bugs.python.org  Mon Feb 10 04:48:58 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 09:48:58 +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: <1581328138.52.0.454101034649.issue39128@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17804
pull_request: https://github.com/python/cpython/pull/18428

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 10 04:49:11 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 10 Feb 2020 09:49:11 +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: <1581328150.99.0.610997660136.issue39128@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 5305cc9dbfe8a5a0ab666511f3ba7f026c8983f8 by idomic in branch 'master':
bpo-39128: Added happy_eyeballs_delay, interleave to function signature (GH-18315)
https://github.com/python/cpython/commit/5305cc9dbfe8a5a0ab666511f3ba7f026c8983f8


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 10 04:56:13 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 10 Feb 2020 09:56:13 +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: <1581328573.0.0.600827103775.issue39128@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

I merged the first PR about adding parameter, but I'm not closing this issue yet, as Andrew said, a small chapter with a description of Happy Eyeballs algorithm would be nice, if anyone want to write a PR, go for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 10 04:54:42 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 09:54:42 +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: <1581328482.4.0.608374555328.issue39128@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset af95d790a86fc46739badfa9edbaeb264ee96600 by Miss Islington (bot) in branch '3.8':
bpo-39128: Added happy_eyeballs_delay, interleave to function signature (GH-18315)
https://github.com/python/cpython/commit/af95d790a86fc46739badfa9edbaeb264ee96600


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 10 05:15:24 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 10 Feb 2020 10:15:24 +0000
Subject: [issue39534] Clarify tutorial on return statement in finally clause.
In-Reply-To: <1580718072.8.0.280721133758.issue39534@roundup.psfhosted.org>
Message-ID: <1581329724.2.0.155418340766.issue39534@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39534>
_______________________________________

From report at bugs.python.org  Mon Feb 10 05:58:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 10:58:26 +0000
Subject: [issue39584] MacOS crashes by running attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1581332306.36.0.627091713408.issue39584@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Mon Feb 10 05:58:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 10:58:45 +0000
Subject: [issue39584] multiprocessing.shared_memory: MacOS crashes by running
 attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1581332325.61.0.938289375505.issue39584@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: MacOS crashes by running attached Python code -> multiprocessing.shared_memory: MacOS crashes by running attached Python code

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Mon Feb 10 06:29:02 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 10 Feb 2020 11:29:02 +0000
Subject: [issue39597] sorting the String
In-Reply-To: <1581324074.07.0.0879941203832.issue39597@roundup.psfhosted.org>
Message-ID: <1581334142.34.0.678045265876.issue39597@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

>From the screenshot:

>>> b = ['sss', 'ase', 'klm', 'qwe']
>>> print sorted(b)
['ase', 'klm', 'qwe', 'sss']

This is the correct result, the output list is alphabetically sorted.

----------
nosy: +ronaldoussoren
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39597>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:13:40 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 10 Feb 2020 12:13:40 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1581336820.83.0.118011426103.issue39011@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Your patch looks good to me. Could you please add (or adapt) the tests and then create a PR from it? You also need to write a NEWS entry for this change, and it also seems worth an entry in the "What's new" document.

https://devguide.python.org/committing/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:20:52 2020
From: report at bugs.python.org (Reece Johnson)
Date: Mon, 10 Feb 2020 12:20:52 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1581337252.25.0.747667941122.issue39011@roundup.psfhosted.org>


Reece Johnson <kabirsingh215 at yahoo.com> added the comment:

Hope it is fixed now.

----------
nosy: +nows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:23:58 2020
From: report at bugs.python.org (Thomas Reed)
Date: Mon, 10 Feb 2020 12:23:58 +0000
Subject: [issue39598] ERR_CACHE_MISS
Message-ID: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>


New submission from Thomas Reed <shaneroach748 at yahoo.com>:

Hi, I have problem with cache.

If there is someone in the detail of product longer that 5 minutes and than click to button "back",it makes error "ERR_CACHE_MISS". Do you know, how can i solve it?

Thank you :)

----------
components: Windows
messages: 361683
nosy: judiction, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ERR_CACHE_MISS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:25:14 2020
From: report at bugs.python.org (Reece Johnson)
Date: Mon, 10 Feb 2020 12:25:14 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1581337514.01.0.756535338871.issue39598@roundup.psfhosted.org>


Reece Johnson <kabirsingh215 at yahoo.com> added the comment:

Is the user logged out from your site when receiving this message?

----------
nosy: +nows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:26:42 2020
From: report at bugs.python.org (Thomas Reed)
Date: Mon, 10 Feb 2020 12:26:42 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1581337602.42.0.921388437587.issue39598@roundup.psfhosted.org>


Thomas Reed <shaneroach748 at yahoo.com> added the comment:

No, normally browsing the web and products (without login in), after looking at the product details and then clicking the back button, the error will occur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:28:38 2020
From: report at bugs.python.org (Reece Johnson)
Date: Mon, 10 Feb 2020 12:28:38 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1581337718.14.0.131707515006.issue39598@roundup.psfhosted.org>


Reece Johnson <kabirsingh215 at yahoo.com> added the comment:

It's a google chrome issue: https://winerrorfixer.com/err-cache-miss

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:32:28 2020
From: report at bugs.python.org (Thomas Reed)
Date: Mon, 10 Feb 2020 12:32:28 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1581337948.04.0.464802314127.issue39598@roundup.psfhosted.org>


Thomas Reed <shaneroach748 at yahoo.com> added the comment:

Alright, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:45:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Feb 2020 12:45:42 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1581338742.45.0.868335791974.issue39598@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The tracker is for issues related to CPython. This doesn't seem like a Python issue to me. Please use other forums for discussion. Closing it as not a bug.

----------
nosy: +xtreak
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:54:16 2020
From: report at bugs.python.org (Julien Danjou)
Date: Mon, 10 Feb 2020 12:54:16 +0000
Subject: [issue39599] ABI breakage between 3.7.4 and 3.7.5
Message-ID: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>


New submission from Julien Danjou <julien at danjou.info>:

As I've reported originally on the python-dev list, there seems to be an ABI breakage between 3.7.4 and 3.7.5.

https://mail.python.org/archives/list/python-dev at python.org/message/J2FGZPS5PS7473TONJTPAVSNXRGV3TFL/

The culprit commit is https://github.com/python/cpython/commit/8766cb74e186d3820db0a855ccd780d6d84461f7

This happens on a custom C module (built via Cython) when using including <internal/pystate.h> with -DPy_BUILD_CORE. I'm not sure it'd happen otherwise.

I've tried to provide a minimal use case, but since it seems to be a memory overflow, the backtrace does not make any sense and it's hard to reproduce without the orignal code.

----------
components: C API
messages: 361689
nosy: jd
priority: normal
severity: normal
status: open
title: ABI breakage between 3.7.4 and 3.7.5
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:57:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 12:57:06 +0000
Subject: [issue39593] Adding a unit test of ctypes
In-Reply-To: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>
Message-ID: <1581339426.41.0.323615293452.issue39593@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Using strlen() seems to be as old as ctypes itself.

--

I don't know which behavior is correct. It's a little bit strange that ctypes truncate the string at "\0". A "char" buffer can be an arbitrary array of bytes. It may be a binary format which doesn't use null byte as string terminator, but just to encode a 16-bit integer as two bytes.

My attempt to understand the current behavior:

https://github.com/python/cpython/pull/18419#pullrequestreview-355606890

"size = strlen(data);" instruction was added when the ctypes was added by this commit:

commit d4c9320412177895f598a93d73a0e654db27c351
Author: Thomas Heller <theller at ctypes.org>
Date:   Wed Mar 8 19:35:11 2006 +0000

    Copy ctypes-0.9.9.4 sources from external into the trunk.

Sadly, Thomas Heller no longer contributes to Python since 2011:
https://blog.python.org/2011/04/thomas-heller-steps-down-as-ctypes.html

The original project is hosted at:
https://sourceforge.net/p/ctypes/code/

It seems like s_set() function was added between these source/cfield.c two versions:

revision 1.116
date: 2006/03/15 20:35:55;  author: theller;  state: Exp;  lines: +14 -4
PyString_FromFormat()b understands the C99 "z" qualifier on all
platforms, in Python 2.5.  Patch from Tim Peters, adapted to work with
older Python versions.

revision 1.115
date: 2006/03/03 20:17:15;  author: theller;  state: Exp;  lines: +636 -279
Moving files from branch_1_0 to HEAD.

Sadly, the commit message doesn't say much about the rationale.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Mon Feb 10 07:58:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 12:58:03 +0000
Subject: [issue39593] ctypes s_set() uses strlen() and so truncates string at
 null character
In-Reply-To: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>
Message-ID: <1581339483.41.0.656642778487.issue39593@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Adding a unit test of ctypes -> ctypes s_set() uses strlen() and so truncates string at null character

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:06:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:06:43 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1581340003.93.0.444639922167.issue38323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue is still failing frequently on buildbots. What can be done to stop getting test failures on buildbots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:25:14 2020
From: report at bugs.python.org (Ido Michael)
Date: Mon, 10 Feb 2020 13:25:14 +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: <1581341114.43.0.975824540164.issue39128@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Thanks Julien, I forgot about this part, will create a new PR.

I thought referencing the abstract of the algorithm + a link to the IETF RFC:

  Happy Eyeballs: Success with Dual-Stack Hosts
   When a server's IPv4 path and protocol are working, but the server's
   IPv6 path and protocol are not working, a dual-stack client
   application experiences significant connection delay compared to an
   IPv4-only client.  This is undesirable because it causes the dual-
   stack client to have a worse user experience.  This document
   specifies requirements for algorithms that reduce this user-visible
   delay and provides an algorithm.

https://tools.ietf.org/html/rfc6555

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:27:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:27:06 +0000
Subject: [issue39586] Deprecate bdist_msi: use bdist_wheel instead
In-Reply-To: <1581174472.55.0.332465806553.issue39586@roundup.psfhosted.org>
Message-ID: <1581341226.63.0.129681756003.issue39586@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 29b3fc0a18f105de666fdd586b537f34e349766d by Hugo van Kemenade in branch 'master':
bpo-39586: Deprecate distutils bdist_msi command (GH-18415)
https://github.com/python/cpython/commit/29b3fc0a18f105de666fdd586b537f34e349766d


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39586>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:30:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:30:02 +0000
Subject: [issue39586] Deprecate bdist_msi: use bdist_wheel instead
In-Reply-To: <1581174472.55.0.332465806553.issue39586@roundup.psfhosted.org>
Message-ID: <1581341402.31.0.398509669391.issue39586@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Steve Dower who knows well Windows installer discourage users to use MSI:
https://discuss.python.org/t/remove-distutils-bdist-wininst-command/3115/14

Other pip developers want to get ride of everything but sdist and bdist_wheel formats:
https://discuss.python.org/t/remove-distutils-bdist-wininst-command/3115/14

So let's deprecated bdist_msi. If someone comes with a use case which justify to keep the feature, it would be trivial to revert the deprecation.

Thanks Hugo van Kemenade ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39586>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:33:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:33:05 +0000
Subject: [issue39599] ABI breakage between 3.7.4 and 3.7.5
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581341585.82.0.224849132979.issue39599@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:34:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:34:19 +0000
Subject: [issue39599] ABI breakage between 3.7.4 and 3.7.5
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581341659.9.0.265251597779.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The latest 3.7 release is Python 3.7.6: Dec. 18, 2019. So at least two 3.7 release are impacted. Moreover, Python 3.8.0 and 3.8.1 have also been released with the change.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:34:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:34:57 +0000
Subject: [issue39599] ABI breakage between 3.7.4 and 3.7.5
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581341697.85.0.279287028141.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

You can find the rationale for this change in two issues:

* bpo-27987
* bpo-36618

First, it was a warning in clang ubsan (Undefined Behavior Sanitizer).
Then ctypes started to crash when Python was compiled with clang. It
means that compiling Python 3.7 with clang also had the issue.

The quick fix was to compile Python with -fmax-type-align=8 when clang
was detected.

But it was a signal that something was wrong in Python on x86-64:
Python didn't respect the x86-64 ABI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Mon Feb 10 08:35:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 13:35:36 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581341736.37.0.634407037384.issue39599@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: ABI breakage between 3.7.4 and 3.7.5 -> ABI breakage between Python 3.7.4 and 3.7.5: change in PyGC_Head structure

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Mon Feb 10 09:18:35 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 10 Feb 2020 14:18:35 +0000
Subject: [issue39498] Signpost security considerations in library
In-Reply-To: <1580361272.17.0.099312904306.issue39498@roundup.psfhosted.org>
Message-ID: <1581344315.97.0.968063784395.issue39498@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Asked on gh:

> this is a "security guidance for standard library modules" index?

(I'm not sure to understand the question exactly)

I think it could be usefull from a reviewer point of view to have such index so he can iterate over it and check point by point if the code is OK.

In this case, linking to all notes like "beware, wrong usage of this could lead to security issues" looks what's needed in this index.

Anthony: did you opened the issue with this in mind or any other usages?

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39498>
_______________________________________

From report at bugs.python.org  Mon Feb 10 09:32:10 2020
From: report at bugs.python.org (Paul Moore)
Date: Mon, 10 Feb 2020 14:32:10 +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: <1581345130.04.0.0711075703321.issue39090@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

> 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.

+1 on this.

Given that (as far as I can tell from the various discussions) `resolve` works fine as long as the file exists, maybe the key distinction to make is whether you have an existing file or not.

(More subtle questions like UNC path vs drive letter, mentioned on the Discourse thread, are probably things that we can defer to a "more advanced cases" discussion in the docs).

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Mon Feb 10 10:12:57 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Feb 2020 15:12:57 +0000
Subject: [issue39597] sorting the String
In-Reply-To: <1581324074.07.0.0879941203832.issue39597@roundup.psfhosted.org>
Message-ID: <1581347577.38.0.764770346835.issue39597@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39597>
_______________________________________

From report at bugs.python.org  Mon Feb 10 10:18:04 2020
From: report at bugs.python.org (Andy Lester)
Date: Mon, 10 Feb 2020 15:18:04 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581347884.0.0.261530296563.issue39591@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

> Yes, Py_INCREF and Py_DECREF change the type, and therefore constness.

Understood. The changes that I have proposed are not to objects that get sent through Py_INCREF/Py_DECREF.  If they did, -Wcast-qual would have caught it.  -Wcast-qual catches if you cast, say, a const char * to a char *.

Let's let this stay closed and I'll resubmit with a clearer ticket & PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Mon Feb 10 10:44:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 15:44:03 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two fonts have
 the same name
Message-ID: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

======================================================================
FAIL: test_fontlist_key (idlelib.idle_test.test_configdialog.FontPageTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.7/idlelib/idle_test/test_configdialog.py", line 104, in test_fontlist_key
    self.assertNotEqual(down_font, font)
AssertionError: 'Cantarell' == 'Cantarell'

Example:
---
import tkinter.ttk
import tkinter.font
frame = tkinter.ttk.Frame()
families=sorted(tkinter.font.families(frame))
for family in families:
    print(family)
---

Truncated output on my Fedora 31:
---
Abyssinica SIL
Android Emoji
AnjaliOldLipi
Bitstream Vera Sans
C059
Caladea
Cantarell
Cantarell
Cantarell
Cantarell
(...)
Comfortaa
Comfortaa
(...))
DejaVu Sans
DejaVu Sans
DejaVu Sans
(...)
Source Han Serif CN
Source Han Serif CN
Source Han Serif CN
Source Han Serif CN
Source Han Serif CN
Source Han Serif CN
Source Han Serif TW
Source Han Serif TW
Source Han Serif TW
Source Han Serif TW
Source Han Serif TW
Source Han Serif TW
(...)
---

I'm not sure if it's an issue in the unit test or an issue with the widget itself. Does it make sense to display the same font family name twice?

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 361700
nosy: cheryl.sabella, taleinat, terry.reedy, vstinner
priority: normal
severity: normal
status: open
title: idle_test: test_fontlist_key() fails if two fonts have the same name
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 10:44:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 15:44:16 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581349456.61.0.148814370574.issue39600@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: idle_test: test_fontlist_key() fails if two fonts have the same name -> idle_test: test_fontlist_key() fails if two font families have the same name

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 11:10:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 16:10:14 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581351014.27.0.0777020077432.issue39600@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17805
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18430

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 11:14:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 16:14:01 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581351241.39.0.554580365915.issue39600@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/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 11:14:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 16:14:18 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581351258.82.0.482184452663.issue39600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I proposed PR 18430 to remove duplicated font family names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 11:48:04 2020
From: report at bugs.python.org (JitterMan)
Date: Mon, 10 Feb 2020 16:48:04 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
Message-ID: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>


New submission from JitterMan <pythonbugs at shalmirane.com>:

It appears as if escaping the braces by doubling them up is not working properly if the braces are in a format specification within a f-string.

>>> print(f'Email:\n    {C:{{v.name}} {{v.email}}|\n    }')                         
Traceback (most recent call last):
  File "bugreport.py", line 95, in <module>
    print(f'Email:\n    {C:{{v.name}} {{v.email}}|\n    }')
NameError: name 'v' is not defined

The escaping works as expected when the string's format method is used.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: bugreport.py
messages: 361702
nosy: jitterman
priority: normal
severity: normal
status: open
title: brace escapes are not working in formatted string literal format specifications
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48887/bugreport.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 11:50:35 2020
From: report at bugs.python.org (JitterMan)
Date: Mon, 10 Feb 2020 16:50:35 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581353435.4.0.444515809874.issue39601@roundup.psfhosted.org>


JitterMan <pythonbugs at shalmirane.com> added the comment:

It appears as if escaping the braces by doubling them up is not working properly if the braces are in a format specification within a f-string.

>>> print(f'Email:\n    {C:{{v.name}} {{v.email}}|\n    }')                         
Traceback (most recent call last):
  File "bugreport.py", line 95, in <module>
    print(f'Email:\n    {C:{{v.name}} {{v.email}}|\n    }')
NameError: name 'v' is not defined

The escaping works as expected when the string's format method is used.

----------
Added file: https://bugs.python.org/file48888/bugreport.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 12:00:55 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 10 Feb 2020 17:00:55 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581354055.41.0.944821217858.issue39601@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

What result are you expecting here?

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 13:19:50 2020
From: report at bugs.python.org (Pox TheGreat)
Date: Mon, 10 Feb 2020 18:19:50 +0000
Subject: [issue39602] importlib: lazy loading can result in reimporting a
 submodule
Message-ID: <1581358790.35.0.810808142023.issue39602@roundup.psfhosted.org>


New submission from Pox TheGreat <poxthegreat at gmail.com>:

Using the LazyLoader class one can modify the sys.meta_path finders so that every import mechanism becomes lazy. This method has been used in Mercurial and by Facebook.

My problem is that if I have a package (pa) which imports a submodule (a) in the __init__.py and accesses its attributes (or uses a from list) then that submodule is imported (executed) twice without any warning.

I traced back the problem to importlib._bootstrap.py / _find_and_load_unlocked. There is a check there if the submodule has already been imported by the parent package, but the submodule will be imported just after that check because of the _LazyModule and the __path__ attribute access of the submodule.

# Crazy side-effects!
if name in sys.modules:
	return sys.modules[name]
parent_module = sys.modules[parent]
try:
	path = parent_module.__path__


Maybe we could check if name in sys.modules after the __path__ attribute access?

----------
components: Library (Lib)
files: LazyImport.zip
messages: 361705
nosy: Pox TheGreat
priority: normal
severity: normal
status: open
title: importlib: lazy loading can result in reimporting a submodule
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48889/LazyImport.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39602>
_______________________________________

From report at bugs.python.org  Mon Feb 10 13:38:32 2020
From: report at bugs.python.org (Elena Oat)
Date: Mon, 10 Feb 2020 18:38:32 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581359912.87.0.78227344531.issue39545@roundup.psfhosted.org>


Elena Oat <oat.elena at gmail.com> added the comment:

There was no update on this since 02/04, so I will work on this as I am at the PyCascades sprints right now.

----------
nosy: +Elena.Oat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Mon Feb 10 13:55:45 2020
From: report at bugs.python.org (Chris Wilcox)
Date: Mon, 10 Feb 2020 18:55:45 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581360945.24.0.788235115526.issue39601@roundup.psfhosted.org>


Chris Wilcox <python at crwilcox.com> added the comment:

The attached code implements `__format__` on the `Collections` class. In case 1, the template passed to `__format__` is "{v.name}: {v.email}|". In case 2, a name error will occur while processing the f string and v will not be found as no object 'v' exists in locals or globals.

In reviewing PEP 0498, https://www.python.org/dev/peps/pep-0498/, I think the difference is in what object is being formatted.

In case 1 of the attached code, the collection is being formatted. In case 2 where f-strings are used, 'v' is being formatted. Because v doesn't exist in this context, it fails. I found this in the PEP and I think it is what is going on here.

```
Note that __format__() is not called directly on each value. The actual code uses the equivalent of type(value).__format__(value, format_spec), or format(value, format_spec). See the documentation of the builtin format() function for more details.

```

----------
nosy: +crwilcox

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:19:45 2020
From: report at bugs.python.org (Roger Hurwitz)
Date: Mon, 10 Feb 2020 19:19:45 +0000
Subject: [issue16776] Document PyCFunction_New and PyCFunction_NewEx functions
In-Reply-To: <1356434154.16.0.0981038830976.issue16776@psf.upfronthosting.co.za>
Message-ID: <1581362384.99.0.398146697367.issue16776@roundup.psfhosted.org>


Roger Hurwitz <rogerhurwitz at gmail.com> added the comment:

I am at PyCascades at the CPython sprint, and I will work on this issue to the best of my ability.

----------
nosy: +rogerhurwitz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16776>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:28:27 2020
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 10 Feb 2020 19:28:27 +0000
Subject: [issue39551] mock patch should match behavior of import from when
 module isn't present in sys.modules
In-Reply-To: <1580848069.21.0.869527016064.issue39551@roundup.psfhosted.org>
Message-ID: <1581362907.04.0.846813286627.issue39551@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

I like that idea, let me see if I can find a way to do that.  This is a little bit different in that it's implicitly trying to find a module, and supports dotting through non-packages as well, but maybe there's a way to leverage importlib and still keep the existing behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39551>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:29:35 2020
From: report at bugs.python.org (Max)
Date: Mon, 10 Feb 2020 19:29:35 +0000
Subject: [issue39603] Injection in http.client
Message-ID: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>


New submission from Max <maxpl0it at protonmail.com>:

I recently came across a bug during a pentest that's allowed me to perform some really interesting attacks on a target. While originally discovered in requests, I had been forwarded to one of the urllib3 developers after agreeing that fixing it at it's lowest level would be preferable. I was informed that the vulnerability is also present in http.client and that I should report it here as well.

The 'method' parameter is not filtered to prevent the injection from altering the entire request.

For example:
>>> conn = http.client.HTTPConnection("localhost", 80)
>>> conn.request(method="GET / HTTP/1.1\r\nHost: abc\r\nRemainder:", url="/index.html")

This will result in the following request being generated:
GET / HTTP/1.1
Host: abc
Remainder: /index.html HTTP/1.1
Host: localhost
Accept-Encoding: identity

This was originally found in an HTTP proxy that was utilising Requests. It allowed me to manipulate the original path to access different files from an internal server since the developers had assumed that the method would filter out non-standard HTTP methods.

The recommended solution is to only allow the standard HTTP methods of GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH.

An alternate solution that would allow programmers to use non-standard methods would be to only support characters [a-z] and stop reading at any special characters (especially newlines and spaces).

----------
components: Library (Lib)
messages: 361710
nosy: maxpl0it
priority: normal
severity: normal
status: open
title: Injection in http.client
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/issue39603>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:34:41 2020
From: report at bugs.python.org (Chris Wilcox)
Date: Mon, 10 Feb 2020 19:34:41 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1581363280.99.0.286933392122.issue14678@roundup.psfhosted.org>


Chris Wilcox <python at crwilcox.com> added the comment:

What work remains to be done for this issue?

----------
nosy: +crwilcox

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:41:40 2020
From: report at bugs.python.org (Carol Willing)
Date: Mon, 10 Feb 2020 19:41:40 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581363700.15.0.970354340237.issue39600@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset ed335cf53b5d4bca9a08c9b83ba684ba17be0f10 by Victor Stinner in branch 'master':
bpo-39600, IDLE: Remove duplicated font names (GH-18430)
https://github.com/python/cpython/commit/ed335cf53b5d4bca9a08c9b83ba684ba17be0f10


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:43:29 2020
From: report at bugs.python.org (Ognyan Moore)
Date: Mon, 10 Feb 2020 19:43:29 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1581363809.76.0.527318558584.issue39417@roundup.psfhosted.org>


Ognyan Moore <ognyan.moore at gmail.com> added the comment:

Hi, I'm at pycascades cpython sprint, I can tackle this issue.

----------
nosy: +Ognyan Moore

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:53:20 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Feb 2020 19:53:20 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1581364400.32.0.231730589938.issue39417@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17806
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18432

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Mon Feb 10 14:58:04 2020
From: report at bugs.python.org (Elena Oat)
Date: Mon, 10 Feb 2020 19:58:04 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581364684.3.0.0955639034345.issue39545@roundup.psfhosted.org>


Change by Elena Oat <oat.elena at gmail.com>:


----------
keywords: +patch
pull_requests: +17807
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18433

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:00:49 2020
From: report at bugs.python.org (Ognyan Moore)
Date: Mon, 10 Feb 2020 20:00:49 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1581364849.74.0.703589260248.issue39417@roundup.psfhosted.org>


Ognyan Moore <ognyan.moore at gmail.com> added the comment:

Submitted PR 18432 to reflect this fix

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:03:06 2020
From: report at bugs.python.org (Chris Wilcox)
Date: Mon, 10 Feb 2020 20:03:06 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1581364986.45.0.593291382186.issue9305@roundup.psfhosted.org>


Chris Wilcox <python at crwilcox.com> added the comment:

Are you still working on this Ajay Mahato?

----------
nosy: +crwilcox

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:05:36 2020
From: report at bugs.python.org (Elena Oat)
Date: Mon, 10 Feb 2020 20:05:36 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581365136.73.0.591462883544.issue39545@roundup.psfhosted.org>


Change by Elena Oat <oat.elena at gmail.com>:


----------
pull_requests: +17808
pull_request: https://github.com/python/cpython/pull/18434

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:12:47 2020
From: report at bugs.python.org (Mariatta)
Date: Mon, 10 Feb 2020 20:12:47 +0000
Subject: [issue20265] Bring Windows docs up to date
In-Reply-To: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za>
Message-ID: <1581365567.97.0.689036042936.issue20265@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

I think this is done, so I'm going to close it.
Thanks all who participated. If there are more updates needed to the Windows documentation, I would suggest creating specific tickets with specific problems, instead of one big catchall ticket.

----------
nosy: +Mariatta
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20265>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:13:26 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 10 Feb 2020 20:13:26 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1581365606.23.0.555234725834.issue39417@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +newcomer friendly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:13:45 2020
From: report at bugs.python.org (Carol Willing)
Date: Mon, 10 Feb 2020 20:13:45 +0000
Subject: [issue39369] Doc: Update mmap readline method documentation
In-Reply-To: <1579269327.81.0.0431905682961.issue39369@roundup.psfhosted.org>
Message-ID: <1581365625.32.0.98792514553.issue39369@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 6c9974e12c50150149b989aaef68be1fe46ea670 by Wellington Pardim in branch 'master':
bpo-39369 Doc: Update mmap readline method documentation (GH-17957)
https://github.com/python/cpython/commit/6c9974e12c50150149b989aaef68be1fe46ea670


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39369>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:22:59 2020
From: report at bugs.python.org (Carl Tyndall)
Date: Mon, 10 Feb 2020 20:22:59 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1581366179.07.0.913973795324.issue3950@roundup.psfhosted.org>


Change by Carl Tyndall <c9tyndall at gmail.com>:


----------
pull_requests: +17809
pull_request: https://github.com/python/cpython/pull/18435

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:28:18 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Feb 2020 20:28:18 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581366498.79.0.27231095354.issue39545@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset a2963f09629a0a8c63e9acef79c1dcc0a040ddb6 by Elena Oat in branch '3.6':
bpo-39545: docs: do not use await in f-strings (GH-18434)
https://github.com/python/cpython/commit/a2963f09629a0a8c63e9acef79c1dcc0a040ddb6


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:30:41 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 10 Feb 2020 20:30:41 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581366641.57.0.65560708725.issue39545@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PR!  We don't normally accept doc changes for branches in security-fix mode but this seems like a worthwhile exception.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:37:46 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Feb 2020 20:37:46 +0000
Subject: [issue16776] Document PyCFunction_New and PyCFunction_NewEx functions
In-Reply-To: <1356434154.16.0.0981038830976.issue16776@psf.upfronthosting.co.za>
Message-ID: <1581367066.49.0.487707278077.issue16776@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I'm sprinting with Roger. Based on Petr's comment I am closing this issue -- if we should not draw attention to this function let's not document it.

@svetlov if you still think it should be documented, can you suggest where the documentation should go? The best place we could come up with is in the file where Andrew put it.

----------
nosy: +gvanrossum
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16776>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:47:06 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 20:47:06 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581367626.74.0.382941382294.issue39600@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17810
pull_request: https://github.com/python/cpython/pull/18436

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:47:15 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 20:47:15 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581367635.45.0.0653658463233.issue39600@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17811
pull_request: https://github.com/python/cpython/pull/18437

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 15:50:10 2020
From: report at bugs.python.org (Tim Smith)
Date: Mon, 10 Feb 2020 20:50:10 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581367810.68.0.518656322255.issue13826@roundup.psfhosted.org>


Change by Tim Smith <pythonbugs at tim-smith.us>:


----------
keywords: +patch
pull_requests: +17812
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18438

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:16:58 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Feb 2020 21:16:58 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581369418.02.0.525209851697.issue39600@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Serhiy, do you know anything about the tkinter.font.families() tuple having duplicate names?  It strikes me as an OS or tk error.

On Windows, the tuple has groups of related names with a base name, such as 'Segoe UI' both alone and with suffixes, such as 'light', 'black', and 'symbol'.  I wonder if on Fedora 31 the duplicates are related names with the suffixes somehow left off.  Cheryl, do you see any of the above duplicated names de-duplicated on Ubuntu with suffixes?

Whether the duplicates are true duplicates, (same family repeated) or mistakes (related families missing suffixes), they should be useless to the user.  Clicking or scrolling through the duplicates should not change the font sample as 'Font(family=dupname)' will not change.

Victor, your example does not create a Listbox, so that cannot be the issue.  The only change to ConfigDialog when testing is that it is not made modal.  What puzzles me is that test_fontlist_key starts by explicitly activating the first font on the list, so that the first test on the Fedora machine should be 'Android Emoji' != 'Abyssinica SIL'.  Perhaps there is a bug in the tk on that machine.

Carol Willing merged the PR before I could review and edit.  I will add a follow-up after getting backport to work.

----------
nosy: +serhiy.storchaka -willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:19:46 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:19:46 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1581369586.67.0.816108152928.issue3950@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17813
pull_request: https://github.com/python/cpython/pull/18440

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:20:15 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:20:15 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1581369615.44.0.357365357953.issue3950@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17814
pull_request: https://github.com/python/cpython/pull/18439

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:20:55 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:20:55 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581369655.7.0.760696967905.issue39600@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17815
pull_request: https://github.com/python/cpython/pull/18441

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:21:04 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:21:04 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581369664.36.0.209092111241.issue39600@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17816
pull_request: https://github.com/python/cpython/pull/18442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:22:03 2020
From: report at bugs.python.org (Anthony Tuininga)
Date: Mon, 10 Feb 2020 21:22:03 +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: <1581369723.47.0.378200079496.issue30155@roundup.psfhosted.org>


Anthony Tuininga <anthony.tuininga at gmail.com> added the comment:

Any progress on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:29:20 2020
From: report at bugs.python.org (Elena Oat)
Date: Mon, 10 Feb 2020 21:29:20 +0000
Subject: [issue39578] MagicMock specialisation instance can no longer be
 passed to new MagicMock instance
In-Reply-To: <1581068321.62.0.885951490226.issue39578@roundup.psfhosted.org>
Message-ID: <1581370160.06.0.0682205538832.issue39578@roundup.psfhosted.org>


Elena Oat <oat.elena at gmail.com> added the comment:

I am looking at reproducing this and creating a short example of where this fails. Will look further into more details of why this doesn't work.

----------
nosy: +Elena.Oat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39578>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:34:31 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:34:31 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1581370471.54.0.637422114585.issue3950@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3b888ad70aaed39df1985b38b4987feb5bee7981 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-3950: Fix docs for default locale used by gettext to match implementation (GH-18435) (GH-18439)
https://github.com/python/cpython/commit/3b888ad70aaed39df1985b38b4987feb5bee7981


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:37:16 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Feb 2020 21:37:16 +0000
Subject: [issue39501] gettext's default localedir does not match documentation
In-Reply-To: <1580388533.66.0.705426741296.issue39501@roundup.psfhosted.org>
Message-ID: <1581370636.57.0.547989132425.issue39501@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Fixed by Carl-y in PR 18435, PR 18440, PR 18439. (Sorry, those commits were attributed to issue3950 by mistake.)

----------
nosy: +gvanrossum
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39501>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:37:52 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Feb 2020 21:37:52 +0000
Subject: [issue3950] turtle.py: bug in TurtleScreenBase._drawimage
In-Reply-To: <1222208778.76.0.463273203686.issue3950@psf.upfronthosting.co.za>
Message-ID: <1581370672.51.0.795374781808.issue3950@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Sorry, those PRs were for issue39501.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3950>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:38:37 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:38:37 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581370717.42.0.627071665823.issue39600@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 021a5694ede9d7be119f9ceb3ee7e8e518ec5002 by Miss Islington (bot) in branch '3.8':
bpo-39600, IDLE: Remove duplicated font names (GH-18430)
https://github.com/python/cpython/commit/021a5694ede9d7be119f9ceb3ee7e8e518ec5002


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:39:47 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 21:39:47 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581370787.01.0.847576620049.issue39600@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2e8097d1c7c04dd96061ec1498cfa088bce9085b by Miss Islington (bot) in branch '3.7':
bpo-39600, IDLE: Remove duplicated font names (GH-18430)
https://github.com/python/cpython/commit/2e8097d1c7c04dd96061ec1498cfa088bce9085b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:49:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 21:49:10 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581371350.23.0.981420346836.issue39600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In LibreOffice, I see 4 flavors of "Cantarell" with different *weight* :

Cantarell
Cantarell Extra Bold
Cantarell Light
Cantarell Thin

whereas tkinter.font.families(frame) returns 4 times the same string: "Cantarell". The C function of Tk is TkpGetFontFamilies().

The X11 implementation uses XListFonts() which returns a string like "-foundry-family-weight-slant-(...)" but the function only returns the "family" substring: it ignores the foundy and the weight for example. So it's not surprising to get duplicates. Example: "-adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso8859-1" becomes "helvetica".

There is also a Xft implementation which uses XftListFonts(). Then it uses XftPatternGetString() to get a font family.

I see no logic in Tcl to exclude duplicated family names of different weights.

--

>>> tkinter.font.names(frame)
('TkCaptionFont', 'TkSmallCaptionFont', 'TkTooltipFont', 'TkFixedFont', 'TkHeadingFont', 'TkMenuFont', 'TkIconFont', 'TkTextFont', 'TkDefaultFont')

That's something different that I would call unrelated ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:51:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 21:51:40 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581371500.12.0.561292829518.issue39600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Victor, your example does not create a Listbox, so that cannot be the issue.  The only change to ConfigDialog when testing is that it is not made modal.  What puzzles me is that test_fontlist_key starts by explicitly activating the first font on the list, so that the first test on the Fedora machine should be 'Android Emoji' != 'Abyssinica SIL'.  Perhaps there is a bug in the tk on that machine.

The test failure comes from our build system where very few fonts are limited. For example, you can imagine that only a few variants of Cantarell are installed.

Sorry, I forgot to mention that the test failure and the list of strings come from two different machines.

The list comes from my laptop where I have many fonts installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 16:53:55 2020
From: report at bugs.python.org (Roger Hurwitz)
Date: Mon, 10 Feb 2020 21:53:55 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581371635.53.0.630591654491.issue39594@roundup.psfhosted.org>


Roger Hurwitz <rogerhurwitz at gmail.com> added the comment:

Reviewing this as part of the CPython sprint at PyCascades.

----------
nosy: +rogerhurwitz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:10:33 2020
From: report at bugs.python.org (Ognyan Moore)
Date: Mon, 10 Feb 2020 22:10:33 +0000
Subject: [issue39278] add docstrings to functions in pdb module
In-Reply-To: <1578591443.64.0.597501227111.issue39278@roundup.psfhosted.org>
Message-ID: <1581372633.98.0.827184311873.issue39278@roundup.psfhosted.org>


Ognyan Moore <ognyan.moore at gmail.com> added the comment:

Stumbled across this issue, is there a list of methods/functions that need docstrings or should we aim to add docstrings to all methods in pdb.py?

----------
nosy: +Ognyan Moore

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39278>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:17:29 2020
From: report at bugs.python.org (Roger Hurwitz)
Date: Mon, 10 Feb 2020 22:17:29 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581373049.86.0.203867339042.issue39594@roundup.psfhosted.org>


Change by Roger Hurwitz <rogerhurwitz at gmail.com>:


----------
keywords: +patch
pull_requests: +17817
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18443

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:21:41 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 10 Feb 2020 22:21:41 +0000
Subject: [issue39604] Document PyDateTimeAPI / PyDateTime_CAPI struct
Message-ID: <1581373301.32.0.397691619207.issue39604@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

The entire public interface documented for the datetime C API is various C macros (see: https://docs.python.org/3/c-api/datetime.html) which are wrappers around function calls to the PyDateTimeAPI / PyDatetime_CAPI struct, but the struct itself is undocumented. 

Unfortunately (or fortunately, depending on how you think the C API should look), pretty much everyone has to know the implementation details of the C API struct anyway. Bindings in other languages usually can't use the C preprocessor macros and have to directly use the C API struct so projects like PyPy, PyO3 and Cython are using it. The struct also can do things that the macros can't do: consider bug #30155 which is looking for a way to create a datetime object with a tzinfo (which is possible using the C struct).

I think we can should go ahead and make the `PyDateTimeAPI` struct "public" and document the functions on it. This may be a bit tougher than one would hope because the overlap between the macros and the struct functions isn't 100%, but it's pretty close, so I would think we'd want to document the two ways to do things rather close to one another.

nosy-ing Victor on here in case he has any strong opinions about whether these kinds of struct should be exposed as part of the official public interface.

----------
assignee: docs at python
components: C API, Documentation
messages: 361733
nosy: belopolsky, docs at python, lemburg, p-ganssle, vstinner
priority: normal
severity: normal
status: open
title: Document PyDateTimeAPI / PyDateTime_CAPI struct
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39604>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:25:02 2020
From: report at bugs.python.org (Malcolm Smith)
Date: Mon, 10 Feb 2020 22:25:02 +0000
Subject: [issue34592] cdll.LoadLibrary allows None as an argument
In-Reply-To: <1536183341.44.0.56676864532.issue34592@psf.upfronthosting.co.za>
Message-ID: <1581373502.12.0.476534653585.issue34592@roundup.psfhosted.org>


Malcolm Smith <malcolm.smith at gmail.com> added the comment:

This isn't documented, but CDLL(None) is translated to dlopen(NULL), which "causes a search for a symbol in the main program, followed by all shared libraries loaded at program startup, and then all shared libraries loaded by dlopen() with the flag RTLD_GLOBAL" (https://linux.die.net/man/3/dlopen).

This is sometimes useful because it lets you look up a symbol in an already-loaded library without needing to give the library's name. For example:

>>> import ctypes
>>> dll = ctypes.CDLL(None)
>>> dll.printf
<_FuncPtr object at 0x7f3427d547c0>
>>> dll.PyObject_Str
<_FuncPtr object at 0x7f3427d54880>

----------
nosy: +Malcolm Smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34592>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:27:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 22:27:11 +0000
Subject: [issue34592] cdll.LoadLibrary allows None as an argument
In-Reply-To: <1536183341.44.0.56676864532.issue34592@psf.upfronthosting.co.za>
Message-ID: <1581373631.24.0.750511440098.issue34592@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm using LoadLibrary(None) commonly to load symbols in Python itself ;-)

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34592>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:27:47 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Feb 2020 22:27:47 +0000
Subject: [issue11664] Add patch method to unittest.TestCase
In-Reply-To: <1300999439.71.0.376555102459.issue11664@psf.upfronthosting.co.za>
Message-ID: <1581373667.13.0.879433783983.issue11664@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Given the two recent -1 responses let's close this.

----------
nosy: +gvanrossum
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11664>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:31:28 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 10 Feb 2020 22:31:28 +0000
Subject: [issue30155] Add ability to get tzinfo from a datetime instance in C
 API
In-Reply-To: <1493047646.24.0.156322797242.issue30155@psf.upfronthosting.co.za>
Message-ID: <1581373888.54.0.867536506321.issue30155@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

So this bug is asking for two things:

1. An official accessor for the `tzinfo` component of an existing datetime, which I think is very reasonable in light of the fact that there are official accessors for all the other components of a datetime.

2. An official constructor for a timezone-aware datetime, which I think basically exists in the form of PyDatetime_CAPI->PyDateTimeAPI->DateTime_FromDateAndTime / ->DateTime_FromDateAndTimeAndFold, and we just need to document it. I think this is basically a separate issue, and I have opened #39604 to track it.

I'm going to rename this bug to focus only on issue #1. I think we can accept a PR adding two new macros. I would suggest calling them:

- PyDateTime_DATE_GET_TZINFO
- PyDateTime_TIME_GET_TZINFO

Please make sure to add tests to any PR you make. See the CapiTest case (https://github.com/python/cpython/blob/d68e0a8a165761604e820c8cb4f20abc735e717f/Lib/test/datetimetester.py#L5914) for examples. You may want to look at the git blame for a few of those tests to see the PRs that they were added in, since part of the tests are defined in a C file.

(As an aside: I don't love that the accessor methods are not available on the struct, since all the "macro-only" code needs to be re-implemented in all other-language bindings. Since the accessors are already all macro-only, though, might as well keep with the tradition for now :P)

----------
stage:  -> needs patch
title: Add ability to get/set tzinfo on datetime instances in C API -> Add ability to get tzinfo from a datetime instance in C API
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30155>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:43:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 22:43:44 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581374624.09.0.843132062498.issue38324@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Details on this error:

ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\vstinner\python\3.8\lib\test\test_locale.py", line 567, in test_getsetlocale_issue1813
    locale.setlocale(locale.LC_CTYPE, loc)
  File "C:\vstinner\python\3.8\lib\locale.py", line 608, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

On Windows 10 (version 1903), ANSI code page 1252, OEM code page 437, LC_CTYPE locale "French_France.1252":

vstinner at WIN C:\vstinner\python\master>python
Running Debug|x64 interpreter...
Python 3.9.0a3+ (heads/master:d68e0a8a16, Feb 10 2020, 22:59:58) [MSC v.1916 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_CTYPE, "tr_TR")
'tr_TR'
>>> loc=locale.getlocale(locale.LC_CTYPE)     
>>> loc
('tr_TR', 'ISO8859-9')
>>> locale.setlocale(locale.LC_CTYPE, loc)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\vstinner\python\master\lib\locale.py", line 610, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> name=locale._build_localename(loc)
>>> name
'tr_TR.ISO8859-9'
>>> name2 = locale.normalize(name)
>>> name2 == name
True
>>> name2
'tr_TR.ISO8859-9'
>>> locale.setlocale(locale.LC_CTYPE, 'tr_TR.ISO8859-9') 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\vstinner\python\master\lib\locale.py", line 610, in setlocale        
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

Note: I changed the OEM code page, usually OEM cp is 850, but the OEM code page should have no effect on setlocale().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:50:29 2020
From: report at bugs.python.org (Mariatta)
Date: Mon, 10 Feb 2020 22:50:29 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581375029.64.0.522435135531.issue39594@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Thanks!

----------
nosy: +Mariatta
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:50:30 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:50:30 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581375030.22.0.529576440283.issue39594@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 37c55b2b49a3acb7c56c9f6a5062bc6e4e35bc1c by Roger Hurwitz in branch 'master':
bpo-39594: Fix typo in os.times documentation (GH-18443)
https://github.com/python/cpython/commit/37c55b2b49a3acb7c56c9f6a5062bc6e4e35bc1c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:50:37 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:50:37 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581375037.28.0.0990504604652.issue39594@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17818
pull_request: https://github.com/python/cpython/pull/18444

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:51:05 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:51:05 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581375065.31.0.367634213315.issue13826@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 95d024d585bd3ed627437a2f0cbc783c8a014c8a by Tim D. Smith in branch 'master':
bpo-13826: Clarify Popen constructor example (GH-18438)
https://github.com/python/cpython/commit/95d024d585bd3ed627437a2f0cbc783c8a014c8a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:51:16 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:51:16 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581375076.14.0.0662366231515.issue13826@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17819
pull_request: https://github.com/python/cpython/pull/18445

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:51:25 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:51:25 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581375085.7.0.172766085011.issue13826@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17820
pull_request: https://github.com/python/cpython/pull/18446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:51:34 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:51:34 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581375094.73.0.462374392079.issue39594@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17821
pull_request: https://github.com/python/cpython/pull/18447

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:55:39 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:55:39 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581375339.46.0.274212307803.issue39594@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a12effde34e7cf7ced767ca232cc2ed95e62cd46 by Miss Islington (bot) in branch '3.7':
bpo-39594: Fix typo in os.times documentation (GH-18443)
https://github.com/python/cpython/commit/a12effde34e7cf7ced767ca232cc2ed95e62cd46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:56:18 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:56:18 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581375378.13.0.504400879195.issue13826@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 78982f94faaa05e363d15b49ec230d11a4d8bebd by Miss Islington (bot) in branch '3.7':
bpo-13826: Clarify Popen constructor example (GH-18438)
https://github.com/python/cpython/commit/78982f94faaa05e363d15b49ec230d11a4d8bebd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:57:09 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:57:09 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581375429.79.0.460046029749.issue13826@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e6690f6cd1b0c2bd5804bad30239a4070f79102c by Miss Islington (bot) in branch '3.8':
bpo-13826: Clarify Popen constructor example (GH-18438)
https://github.com/python/cpython/commit/e6690f6cd1b0c2bd5804bad30239a4070f79102c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 17:57:17 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Feb 2020 22:57:17 +0000
Subject: [issue39594] Typo in documentation for os.times
In-Reply-To: <1581269430.53.0.74728045521.issue39594@roundup.psfhosted.org>
Message-ID: <1581375437.88.0.976276888366.issue39594@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4d4301782cbc789eedc5b76741d1028df579cfa5 by Miss Islington (bot) in branch '3.8':
bpo-39594: Fix typo in os.times documentation (GH-18443)
https://github.com/python/cpython/commit/4d4301782cbc789eedc5b76741d1028df579cfa5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39594>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:07:17 2020
From: report at bugs.python.org (Carol Willing)
Date: Mon, 10 Feb 2020 23:07:17 +0000
Subject: [issue39498] Signpost security considerations in library
In-Reply-To: <1580361272.17.0.099312904306.issue39498@roundup.psfhosted.org>
Message-ID: <1581376037.3.0.0366022198939.issue39498@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

I agree that a helpful entry in the index would be a nice addition. Christian would be the person to start with since he probably has ideas what would be useful too.

----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39498>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:16:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:16:23 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581376583.8.0.484632681283.issue38324@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>>> loc=locale.getlocale(locale.LC_CTYPE)     
>>> loc
('tr_TR', 'ISO8859-9')

getlocale() has issues on Unix, but worse issues on Windows. See:

* bpo-12726
* bpo-20087
* bpo-20088
* bpo-23425
* bpo-33934
* bpo-38805

I never use getlocale() and I never understood the purpose of this function. I use locale.setlocale(loc) (same than locale.setlocale(loc, None)) to *get* a locale: the result can be passed to locale.setlocale(loc, result) with no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:25:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:25:57 +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: <1581377157.81.0.720561697528.issue38887@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38887>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:26:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:26:57 +0000
Subject: [issue38515] regrtest main process timed out after 5 min on AMD64
 FreeBSD CURRENT Shared 3.8
In-Reply-To: <1571396664.18.0.656974468417.issue38515@roundup.psfhosted.org>
Message-ID: <1581377217.45.0.408285578046.issue38515@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38515>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:37:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:37:47 +0000
Subject: [issue38325] [Windows] test_winconsoleio failures
In-Reply-To: <1569849615.84.0.245223982483.issue38325@roundup.psfhosted.org>
Message-ID: <1581377867.48.0.183391607541.issue38325@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17822
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18448

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38325>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:41:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:41:37 +0000
Subject: [issue38061] FreeBSD: Optimize subprocess.Popen(close_fds=True) using
 closefrom()
In-Reply-To: <1568013936.15.0.668992536534.issue38061@roundup.psfhosted.org>
Message-ID: <1581378097.93.0.520395379557.issue38061@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FreeBSD change has been merged:
"lang/python{27,35,36,37,38}: Add closefrom(2) support"
https://svnweb.freebsd.org/ports?view=revision&revision=518640

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38061>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:44:44 2020
From: report at bugs.python.org (JitterMan)
Date: Mon, 10 Feb 2020 23:44:44 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581378284.43.0.593850029735.issue39601@roundup.psfhosted.org>


JitterMan <pythonbugs at shalmirane.com> added the comment:

My expectation is that doubling up the braces acts to escape them, meaning that characters between the braces is treated as simple text and passed to the __format__ method as is. The only processing that should occur on the format specification is to convert the double braces to single braces. The fact that an error occurs saying that 'v' is not defined before the __format__ method is ever called indicates that the contents of the braces are being evaluated as an expression, which fails because v is not defined in the outer scope.  Thus the f-string seems to be ignoring the escaping of the braces, but it only does so in the format specifier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:48:53 2020
From: report at bugs.python.org (Katherine Michel)
Date: Mon, 10 Feb 2020 23:48:53 +0000
Subject: [issue39530] Documentation about comparisons between numeric types is
 misleading
In-Reply-To: <1580653054.78.0.127921454413.issue39530@roundup.psfhosted.org>
Message-ID: <1581378533.62.0.120212521655.issue39530@roundup.psfhosted.org>


Katherine Michel <kthrnmichel at gmail.com> added the comment:

I'm at the sprints at PyCascades and was looking for an issue to work on and came across this and wanted to know more about it. As I was doing some research, I found the terms "narrower" and "wider" to seem ambiguous. I'm assuming "narrower" to mean that an integer has a more precise value and "wider" to mean that a float has a less precise/wider range of possible values, but unless I'm missing something, it isn't clear. I think the first paragraph?should be revised to make the meaning more explicit.?Happy to assist (with some input), if applicable.

----------
nosy: +Katherine Michel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39530>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:50:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:50:04 +0000
Subject: [issue11871] test_default_timeout() of test_threading.BarrierTests
 failure: BrokenBarrierError
In-Reply-To: <1303163944.05.0.666091618845.issue11871@psf.upfronthosting.co.za>
Message-ID: <1581378604.89.0.0584225919871.issue11871@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this failure recently, I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11871>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:51:05 2020
From: report at bugs.python.org (Carol Willing)
Date: Mon, 10 Feb 2020 23:51:05 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1581378665.17.0.281835591215.issue39417@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160 by Ogi Moore in branch 'master':
bpo-39417: Fix broken link to guide to building venvs (GH-18432)
https://github.com/python/cpython/commit/c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:51:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:51:31 +0000
Subject: [issue21998] asyncio: support fork
In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za>
Message-ID: <1581378691.01.0.0912991936232.issue21998@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There is no activity for 2 years. Asyncio is mature now. It seems like users learnt how to work around this issue, or don't use fork() with asyncio.

I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21998>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:52:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 10 Feb 2020 23:52:18 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581378738.39.0.406325982717.issue39600@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +17823
pull_request: https://github.com/python/cpython/pull/18449

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:54:57 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 10 Feb 2020 23:54:57 +0000
Subject: [issue13826] Having a shlex example in the subprocess.Popen docs is
 confusing
In-Reply-To: <1326983115.48.0.551767400168.issue13826@psf.upfronthosting.co.za>
Message-ID: <1581378897.02.0.127362562596.issue13826@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/issue13826>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:56:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:56:08 +0000
Subject: [issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with
 an internal compiler error in create_edge
In-Reply-To: <1510005461.16.0.213398074469.issue31963@psf.upfronthosting.co.za>
Message-ID: <1581378968.63.0.645541881658.issue31963@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this failure recently, I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31963>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:57:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:57:24 +0000
Subject: [issue35501] "make coverage" should not leak coverage compiler flags
 to third party C extensions
In-Reply-To: <1544813222.33.0.788709270274.issue35501@psf.upfronthosting.co.za>
Message-ID: <1581379044.85.0.1180471985.issue35501@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's unclear to me if it's a real issue or not. Moreover, I'm not comfortable to change the Makefile. So I just close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35501>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:58:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:58:28 +0000
Subject: [issue38325] [Windows] test_winconsoleio failures
In-Reply-To: <1569849615.84.0.245223982483.issue38325@roundup.psfhosted.org>
Message-ID: <1581379108.49.0.880201030174.issue38325@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 038770edc4680e9a3dc39bacb35a8358034fb901 by Victor Stinner in branch 'master':
bpo-38325: Skip non-BMP tests of test_winconsoleio (GH-18448)
https://github.com/python/cpython/commit/038770edc4680e9a3dc39bacb35a8358034fb901


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38325>
_______________________________________

From report at bugs.python.org  Mon Feb 10 18:59:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 10 Feb 2020 23:59:42 +0000
Subject: [issue38325] [Windows] test_winconsoleio failures
In-Reply-To: <1569849615.84.0.245223982483.issue38325@roundup.psfhosted.org>
Message-ID: <1581379182.6.0.967666233636.issue38325@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I "fixed" the issue by skipping broken tests. If anyone wants to fix the underlying issue: go ahead and open an issue, it would be way better with a PR to fix these tests!

In the meanwhile, skipping broken tests help to detect regressions (new issues).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38325>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:00:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 00:00:42 +0000
Subject: [issue35361] Update libffi dependency to 3.2.1?
In-Reply-To: <1543581435.81.0.788709270274.issue35361@psf.upfronthosting.co.za>
Message-ID: <1581379242.36.0.327148835414.issue35361@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 2.7 and 3.6 don't accept bugfixes anymore. I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.6 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35361>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:01:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 00:01:33 +0000
Subject: [issue36194] Add "make regen-configure"
In-Reply-To: <1551793843.2.0.191897840943.issue36194@roundup.psfhosted.org>
Message-ID: <1581379293.28.0.483007385634.issue36194@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Most developers seem to be used to "autoconf && autoheader", so it's not obvious that "make regen-configure" would benefit to anyone. I just close the issue.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36194>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:02:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 00:02:54 +0000
Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x
In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org>
Message-ID: <1581379374.97.0.584275581773.issue36273@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see this failure on PPC64 AIX 3.x recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36273>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:03:09 2020
From: report at bugs.python.org (Elena Oat)
Date: Tue, 11 Feb 2020 00:03:09 +0000
Subject: [issue39578] MagicMock specialisation instance can no longer be
 passed to new MagicMock instance
In-Reply-To: <1581068321.62.0.885951490226.issue39578@roundup.psfhosted.org>
Message-ID: <1581379389.49.0.391019449242.issue39578@roundup.psfhosted.org>


Elena Oat <oat.elena at gmail.com> added the comment:

Here's the example I ran, that indeed fails in Python 3.8 and Python 3.9 (with different errors) and works in Python 3.7. 

from unittest.mock import MagicMock


class CustomMock(MagicMock):
    def __init__(self):
        super().__init__(__something__='something')


mock = CustomMock()
MagicMock(mock)


In Python 3.8 the error is TypeError: __init__() got an unexpected keyword argument '_new_parent'. 

In Python 3.9 the error is TypeError: __init__() got an unexpected keyword argument 'name'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39578>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:04:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 00:04:06 +0000
Subject: [issue38063] Modify test_socket.py to use unittest test discovery
In-Reply-To: <1568025092.75.0.792665697576.issue38063@roundup.psfhosted.org>
Message-ID: <1581379446.87.0.329921502664.issue38063@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I mark this issue as a duplicate of bpo-14408.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Support ./python -m unittest in test_socket

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38063>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:04:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 00:04:15 +0000
Subject: [issue14408] Support ./python -m unittest in test_socket
In-Reply-To: <1332735237.61.0.855199980132.issue14408@psf.upfronthosting.co.za>
Message-ID: <1581379455.74.0.549935322398.issue14408@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-38063 as a duplicate of this issue.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14408>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:08:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 00:08:47 +0000
Subject: [issue39604] Document PyDateTimeAPI / PyDateTime_CAPI struct
In-Reply-To: <1581373301.32.0.397691619207.issue39604@roundup.psfhosted.org>
Message-ID: <1581379727.58.0.99751120228.issue39604@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39604>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:46:32 2020
From: report at bugs.python.org (Andrea)
Date: Tue, 11 Feb 2020 00:46:32 +0000
Subject: [issue39577] venv --prompt argument is ignored
In-Reply-To: <1581066525.57.0.495811141664.issue39577@roundup.psfhosted.org>
Message-ID: <1581381992.98.0.499617928348.issue39577@roundup.psfhosted.org>


Andrea <andrea.moro.webma at gmail.com> added the comment:

Operative system is OS X 10.15.3 (19D76) Catalina
Python 3.7.4 installed via HomeBrew

If I do this python -m venv ciao --prompt NewOne by the time I activate the environment, the prompt looks like (ciao) andreamoro at MacBookAir:~/Python

Am I misunderstanding the behaviour of the prompt argument?

Thanks
Andrea

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39577>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:51:32 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 11 Feb 2020 00:51:32 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581382292.46.0.0421958876196.issue39600@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I don't see the same duplicates that Victor listed, however I do see some duplicates.

(...)
DejaVu Sans
DejaVu Sans Mono
DejaVu Serif
(...)
Manjari
Manjari
Manjari
(...)
Mukti Narrow
Mukti Narrow
(...)
Ubuntu
Ubuntu
Ubuntu Condensed
Ubuntu Mono
(...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 19:55:16 2020
From: report at bugs.python.org (Roger Hurwitz)
Date: Tue, 11 Feb 2020 00:55:16 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581382516.12.0.657736408397.issue38374@roundup.psfhosted.org>


Roger Hurwitz <rogerhurwitz at gmail.com> added the comment:

At PyCascades CPython sprint and reviewing this issue.

----------
nosy: +rogerhurwitz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:09:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Feb 2020 01:09:05 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581383345.33.0.992305986693.issue39600@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 96ce22706735779cf8cc46eaaa5ac61359364b5a by Terry Jan Reedy in branch 'master':
bpo-39600: Adjust code, add idlelib/NEWS item (GH-18449)
https://github.com/python/cpython/commit/96ce22706735779cf8cc46eaaa5ac61359364b5a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:09:22 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 01:09:22 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581383362.42.0.501949944829.issue39600@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17824
pull_request: https://github.com/python/cpython/pull/18450

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:09:30 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 01:09:30 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581383370.89.0.289942199323.issue39600@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17825
pull_request: https://github.com/python/cpython/pull/18451

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:13:25 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Feb 2020 01:13:25 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581383605.49.0.693717437972.issue39600@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

font.names() lists 'symbolic' family names guaranteed to exist.  'TkDefaultFont' is the default Text widget font on a particular OS.  IDLE replaces that with 'TkFixedFont', which is translated to the actual family name on each OS: Courier on Windows (ugh) and something like Monaco on macOS.

Thank you for the additional information.  For *nix users, removing the useless duplicates should be an improvement.  (This is aside from the test issue, which could have been fixed otherwise: perhaps by inserting 'TestFont' at the top of the list and making other adjustments.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:21:27 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Feb 2020 01:21:27 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581384087.64.0.0863559859786.issue39600@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Cheryl, it appears that only 'weight' words are deleted.  For a given family, Tk only has a (user) settable 'bold', so other weight options must be 'baked in' to the family.  Perhaps X11 allows more weight settings within a family, even if not exposed in Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:27:38 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 01:27:38 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581384458.4.0.819969738052.issue39600@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c372f9b9e758a22608b8df33423b7413d224fdad by Miss Islington (bot) in branch '3.8':
bpo-39600: Adjust code, add idlelib/NEWS item (GH-18449)
https://github.com/python/cpython/commit/c372f9b9e758a22608b8df33423b7413d224fdad


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:28:07 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 01:28:07 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581384487.09.0.21092558426.issue39600@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 32c88407d24a700946e1a6429cd5ca616cb3a810 by Miss Islington (bot) in branch '3.7':
bpo-39600: Adjust code, add idlelib/NEWS item (GH-18449)
https://github.com/python/cpython/commit/32c88407d24a700946e1a6429cd5ca616cb3a810


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 20:29:50 2020
From: report at bugs.python.org (Chris Wilcox)
Date: Tue, 11 Feb 2020 01:29:50 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581384590.38.0.888643047424.issue39601@roundup.psfhosted.org>


Chris Wilcox <python at crwilcox.com> added the comment:

Double curly braces do not indicate to not process the inner content. They indicate to include a literal curly brace. That said, I think there may be something not quite correct.

I came up with an example based on the example in the format specifiers section of the PEP.

>From the PEP.
```
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal('12.34567')
>>> f'result: {value:{width}.{precision}}'
'result:      12.35'
```
The template in this instance is "10.4"

If we leave the sample the same, but don't wrap width or precision in single curly braces,
```
>>> f'result: {value:width.precision}'
```
I would expect the template "width.precision".

Further, I would expect
```
>>> f'result: {value:{{width}}.{{precision}}}'
```
to have a template of "{width}.{precision}". This is not the case.


Here is some code that should demonstrate this.
```
class Decimal:
    def __init__(self, value):
        pass
    def __format__(self, template):
        return template
width = 10
precision = 4
value = Decimal('12.34567')
print("Expect Template to be '10.4' (TRUE)")
print(f'result0: {value:{width}.{precision}}')
print("Expect Template to be 'width.precision' (TRUE)")
print(f'result1: {value:width.precision}')
print("Expect Template to be '{width}.{precision}' (FALSE)")
print(f'result2: {value:{{width}}.{{precision}}}') # ACTUAL: {10}.{4}
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 21:10:58 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 11 Feb 2020 02:10:58 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581387058.63.0.676943854325.issue38324@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> On Windows 10 (version 1903), ANSI code page 1252, OEM code page 437, 
> LC_CTYPE locale "French_France.1252"

The CRT default locale (i.e. the empty locale "") uses the user locale, which is the "Format" value on the Region->Formats tab. It does not use the system locale from the Region->Administrative tab. 

The default locale normally uses the user locale's ANSI codepage, as returned by GetLocaleInfoEx(LOCALE_NAME_USER_DEFAULT, LOCALE_IDEFAULTANSICODEPAGE, ...). But if the active codepage of the process is UTF-8, then GetACP(), GetOEMCP(), and setlocale(LC_CTYPE, "") all use UTF-8 (i.e. CP_UTF8, i.e. 65001). The active codepage can be set to UTF-8 either at the system-locale level or in the application-manifest. For example, with the active codepage setting in the manifest:

    C:\>python.utf8.exe -q

    >>> from locale import setlocale, LC_CTYPE
    >>> setlocale(LC_CTYPE, "")
    'English_Canada.utf8'

    >>> kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
    >>> kernel32.GetACP()
    65001
    >>> kernel32.GetOEMCP()
    65001

A default locale name can also specify the codepage to use. It could be UTF-8, a particular codepage, ".ACP" (ANSI), or ".OCP" (OEM). "ACP" and "OCP" have to be in upper case. For example:

    >>> setlocale(LC_CTYPE, '.utf8')
    'English_Canada.utf8'
    >>> setlocale(LC_CTYPE, '.437')
    'English_Canada.437'

    >>> setlocale(LC_CTYPE, ".ACP")
    'English_Canada.1252'
    >>> setlocale(LC_CTYPE, ".OCP")
    'English_Canada.850'

Otherwise, if you provide a known locale -- using full names, or three-letter abbreviations, or from the small set of locale aliases, then setlocale queries any missing values from the NLS database. 

One snag in the road is the set of Unicode-only locales, such as "Hindi_India". Querying the ANSI and OEM codepages for a Unicode-only locale respectively returns CP_ACP (0) and CP_OEMCP (1). It used to be that the CRT would end up using the system locale for these cases. But recently ucrt has switched to using UTF-8 for these cases. For example:

    >>> setlocale(LC_CTYPE, "Hindi_India")
    'Hindi_India.utf8'

That brings us to the case of modern Windows BCP-47 locale names, which usually lack an implicit encoding. For example:

    >>> setlocale(LC_CTYPE, "hi_IN")
    'hi_IN'

The current CRT codepage can be queried via __lc_codepage_func:

    >>> import ctypes; ucrt = ctypes.CDLL('ucrtbase', use_errno=True)
    >>> ucrt.___lc_codepage_func()
    65001

With the exception of Unicode-only locales, using a modern name without an encoding defaults to the named locale's ANSI codepage. For example:

    >>> setlocale(LC_CTYPE, "en_CA")
    'en_CA'
    >>> ucrt.___lc_codepage_func()
    1252

The only encoding allowed in BCP-47 locale names is ".utf8" or ".utf-8" (case insensitive):

    >>> setlocale(LC_CTYPE, "fr_FR.utf8")
    'fr_FR.utf8'
    >>> setlocale(LC_CTYPE, "fr_FR.UTF-8")
    'fr_FR.UTF-8'

No other encoding is allowed with this form. For example:

    >>> try: setlocale(LC_CTYPE, "fr_FR.ACP")
    ... except Exception as e: print(e)
    ...
    unsupported locale setting
    >>> try: setlocale(LC_CTYPE, "fr_FR.1252")
    ... except Exception as e: print(e)
    ...
    unsupported locale setting

As to the "tr_TR" locale bug, the Windows implementation is broken due to assumptions that POSIX locale names are directly supported. A significant redesign is required to connect the dots.

    >>> from locale import getlocale
    >>> setlocale(LC_CTYPE, 'tr_TR')
    'tr_TR'
    >>> ucrt.___lc_codepage_func()
    1254

    >>> getlocale(LC_CTYPE)
    ('tr_TR', 'ISO8859-9')

Codepage 1254 is similar to ISO8859-9, except, in typical fashion, Microsoft assigned most of the upper control range 0x80-0x9F to an assortment of characters it deemed useful, such as the Euro symbol "?". The exact codepage needs to be queried via __lc_codepage_func() and returned as ('tr_TR', 'cp1254'). 

Conversely, setlocale() needs to know that this BCP-47 name does not support an explicit encoding, unless it's "utf8". If the given codepage, or an associated alias, doesn't match the locale's ANSI codepage, then the locale name has to be expanded to the full name "Turkish_Turkey". The long name allows specifying an arbitrary codepage. 

For example, say we have ('tr_TR', 'ISO8859-7'), i.e. Greek with Turkish locale rules. This transforms to the closest approximation ('tr_TR', '1253'). When setlocale queries the OS, it will find that the ANSI codepage is actually 1254, so it cannot use "tr_TR" or "tr-TR". It needs to expand to the long form:

    >>> setlocale(LC_CTYPE, 'Turkish_Turkey.1253')
    'Turkish_Turkey.1253'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Mon Feb 10 22:54:09 2020
From: report at bugs.python.org (Ido Michael)
Date: Tue, 11 Feb 2020 03:54:09 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1581393249.2.0.0186855624881.issue37970@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Any update on this? Adding @Tal Einat on the PR

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:03:13 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 11 Feb 2020 04:03:13 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1581393793.01.0.437506896647.issue37970@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Ido, there was a change requested by a core-dev, Zachary , on your PR.

>  Please have a look at PEP 257 for docstring formatting guidelines.

https://github.com/python/cpython/pull/16458/files#r353422155

Please let us know if that is addressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:04:47 2020
From: report at bugs.python.org (ppperry)
Date: Tue, 11 Feb 2020 04:04:47 +0000
Subject: [issue39585] Delete a pending item in _warning.c
In-Reply-To: <1581172060.12.0.48939566603.issue39585@roundup.psfhosted.org>
Message-ID: <1581393887.77.0.347770454401.issue39585@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

What if a warning has a metaclass with a custom __getattribute__ method?

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39585>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:12:40 2020
From: report at bugs.python.org (Ido Michael)
Date: Tue, 11 Feb 2020 04:12:40 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1581394360.59.0.545186327239.issue37970@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Hey Senthil,
Yes the PEP guides was fixed a while ago, also the new comment of adding the same change for the second function were taken care of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:24:24 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 11 Feb 2020 04:24:24 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581395064.65.0.159311588302.issue39600@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/issue39600>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:34:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 11 Feb 2020 04:34:28 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581395668.62.0.0239852350367.issue39601@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:34:50 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 11 Feb 2020 04:34:50 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581395690.41.0.28068195787.issue39601@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components:  -2to3 (2.x to 3.x conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:38:43 2020
From: report at bugs.python.org (Roger Hurwitz)
Date: Tue, 11 Feb 2020 04:38:43 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581395923.37.0.442441630812.issue38374@roundup.psfhosted.org>


Change by Roger Hurwitz <rogerhurwitz at gmail.com>:


----------
keywords: +patch
pull_requests: +17826
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18452

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:45:38 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 11 Feb 2020 04:45:38 +0000
Subject: [issue39605] Fix some casts to not cast away const
Message-ID: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

gcc -Wcast-qual turns up a number of instances of casting away constness of pointers.  Some of these can be safely modified, by either:

* Adding the const to the type cast, as in:

-    return _PyUnicode_FromUCS1((unsigned char*)s, size);
+    return _PyUnicode_FromUCS1((const unsigned char*)s, size);

* Removing the cast entirely, because it's not necessary (but probably was at one time), as in:

-    PyDTrace_FUNCTION_ENTRY((char *)filename, (char *)funcname, lineno);
+    PyDTrace_FUNCTION_ENTRY(filename, funcname, lineno);

These changes will not change code, but they will make it much easier to check for errors in consts.

----------
components: Interpreter Core
messages: 361780
nosy: petdance
priority: normal
severity: normal
status: open
title: Fix some casts to not cast away const
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Mon Feb 10 23:48:08 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 11 Feb 2020 04:48:08 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581396488.46.0.151563376124.issue39605@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17827
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18453

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 00:21:51 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 11 Feb 2020 05:21:51 +0000
Subject: [issue39577] venv --prompt argument is ignored
In-Reply-To: <1581066525.57.0.495811141664.issue39577@roundup.psfhosted.org>
Message-ID: <1581398511.3.0.719368348968.issue39577@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Am I misunderstanding the behaviour of the prompt argument?

You can see from Karthikeyan's post how it's supposed to work, and how it does work in his example. It may be that something else is overwriting the prompt in your environment - we can't tell without knowing what's in your .bashrc, .profile etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39577>
_______________________________________

From report at bugs.python.org  Tue Feb 11 01:31:28 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 11 Feb 2020 06:31:28 +0000
Subject: [issue39593] ctypes s_set() uses strlen() and so truncates string at
 null character
In-Reply-To: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>
Message-ID: <1581402688.13.0.768788214047.issue39593@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

releated bpo: issue12769

s_get() in cfield.c function have similar behavior. So far, this is a planned action(lack evidence).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Tue Feb 11 01:35:23 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 11 Feb 2020 06:35:23 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
Message-ID: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>


New submission from Nathaniel Smith <njs at pobox.com>:

In bpo-39386, the 'aclose' method for async generators was fixed so that the following broken code would correctly raise an error:

# -- bad code --
async def agen_fn():
    yield

async def do_bad_thing():
    agen = agen_fn()
    aclose_coro = agen.aclose()
    await aclose_coro
    # Should raise RuntimeError:
    await aclose_coro

asyncio.run(do_bad_thing())

# -----------------

However, the merged fix also broke the following correct code, which should *not* raise an error:

# -- good code --
async def agen_fn():
    yield

async def do_good_thing():
    agen = agen_fn()
    await agen.aclose()
    # Should *not* raise an error, but currently does in Python dev branches:
    await agen.aclose()

asyncio.run(do_good_thing())

# ----------------

It's not supported to iterate the same coroutine object twice. However, making two *independent* calls to aclose should return two independent coroutine objects, and it should be legal to iterate over each object once.

This can also occur even if there's only a single call to 'aclose'. For example, this is the recommended idiom for making sure that an async generator correctly closes all its resources:

# -- good code --
async def agen_fn():
    yield

async def careful_loop():
    agen = agen_fn()
    try:
        async for _ in agen:
            pass
    finally:
        await agen.aclose()

asyncio.run(careful_loop())

# -------------------

On released Python, the code above runs correctly. On the latest Python dev branches, it raises a RuntimeError.

So basically the problem is that the fix for bpo-39386 is storing the "was aclose iterated?" state on the async generator object, but in fact it needs to be stored on the aclose coroutine object.

----------
keywords: 3.7regression, 3.8regression, 3.9regression
messages: 361783
nosy: asvetlov, lukasz.langa, ned.deily, njs, yselivanov
priority: release blocker
severity: normal
status: open
title: Regression: it should be possible to close async iterators multiple times
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Tue Feb 11 01:56:16 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 06:56:16 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581404176.39.0.940354356146.issue38374@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4eb9f4313cfaea6a9611221024a1c54f5662cc37 by Roger Hurwitz in branch 'master':
bpo-38374: Remove weakref.ReferenceError from docs (GH-18452)
https://github.com/python/cpython/commit/4eb9f4313cfaea6a9611221024a1c54f5662cc37


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Tue Feb 11 01:56:18 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 06:56:18 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581404178.17.0.67822813619.issue38374@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17828
pull_request: https://github.com/python/cpython/pull/18454

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Tue Feb 11 01:56:24 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 06:56:24 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581404184.37.0.447054638796.issue38374@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17829
pull_request: https://github.com/python/cpython/pull/18455

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Tue Feb 11 02:00:10 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 11 Feb 2020 07:00:10 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581404410.74.0.915610974949.issue38374@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/issue38374>
_______________________________________

From report at bugs.python.org  Tue Feb 11 02:01:26 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 07:01:26 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581404486.87.0.637874820865.issue38374@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fcfc3c8fbe3942e8deef15acc25bfa371db7766a by Miss Islington (bot) in branch '3.7':
bpo-38374: Remove weakref.ReferenceError from docs (GH-18452)
https://github.com/python/cpython/commit/fcfc3c8fbe3942e8deef15acc25bfa371db7766a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Tue Feb 11 02:02:05 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 07:02:05 +0000
Subject: [issue38374] Remove weakref.ReferenceError entry from documentation
In-Reply-To: <1570229721.54.0.2203597595.issue38374@roundup.psfhosted.org>
Message-ID: <1581404525.0.0.291335042597.issue38374@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3f8d181446aa9d87e3773896c2695161ea8f6e42 by Miss Islington (bot) in branch '3.8':
bpo-38374: Remove weakref.ReferenceError from docs (GH-18452)
https://github.com/python/cpython/commit/3f8d181446aa9d87e3773896c2695161ea8f6e42


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38374>
_______________________________________

From report at bugs.python.org  Tue Feb 11 02:18:24 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Feb 2020 07:18:24 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581405504.57.0.467285906145.issue39601@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I always use datetime for testing such things. Its __format__() returns its argument, as long as you don't have '%' in it.

I do agree that it's odd that the doubled braces cause the expression to be evaluated, but are still kept as single braces in the resulting string. I'll have to investigate, although I'm not sure if we can change it at this point. Surely someone, somewhere is relying on this behavior.

I'll assume that what the OP wants in my example below is a format specifier of "x{x}x":

>>> x = 42
>>> import datetime
>>> now = datetime.datetime.now()

>>> f'{now:x{{x}}x}'
'x{42}x'

Given the current behavior, I'm not sure it's possible to get 'x{x}x'. Sometimes nested f-strings will help, but I don't think that will work here. The OP might need to use a separate expression to calculate the format specifier, which I realize isn't a very satisfying solution.

>>> spec = 'x{x}x'
>>> f'{now:{spec}}'
'x{x}x'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Tue Feb 11 02:20:20 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 11 Feb 2020 07:20:20 +0000
Subject: [issue39530] Documentation about comparisons between numeric types is
 misleading
In-Reply-To: <1580653054.78.0.127921454413.issue39530@roundup.psfhosted.org>
Message-ID: <1581405620.09.0.240163750516.issue39530@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hi Katherine,

My report was really just about the last sentence, but I agree that the "narrower" language is confusing here. If someone says that a type "A" is narrower than type "B", that suggests to my ears that "A" represents a subset of the values of "B" (but conversely, that "B" can represent everything "A" can). That applies to the float/complex pair, or to Python 2's int/long, or to NumPy's float32/float64 or int32/int64, but not really to int/float, since int has many values that can't be represented as a float (and even has larger range than float).

I suspect that the wording may have made a bit (but only a bit) more sense in Python 2, where `long` was still in the mix, and `int` was the fixed-width type, which really would have been a subset of `float` on a typical 32-bit machine.

So yes, if we can find a way to ditch the "narrower" language altogether but still convey that idea of implicit conversions from int to float, and from float to complex, that would be good.

And then the last sentence still needs fixing somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39530>
_______________________________________

From report at bugs.python.org  Tue Feb 11 03:47:44 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 11 Feb 2020 08:47:44 +0000
Subject: [issue39593] ctypes s_set() uses strlen() and so truncates string at
 null character
In-Reply-To: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>
Message-ID: <1581410863.99.0.900864474559.issue39593@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I am not sure it have realtion of libffi's type or not?

`s_set()` and `s_get()`'s type of ffi is `FFI_TYPE_POINTER`;

REF: https://www.manpagez.com/info/libffi/libffi-3.0.13/libffi_6.php#index-ffi_005ftype_005fpointer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Tue Feb 11 04:04:18 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 11 Feb 2020 09:04:18 +0000
Subject: [issue39593] ctypes s_set() uses strlen() and so truncates string at
 null character
In-Reply-To: <1581265045.65.0.359928840546.issue39593@roundup.psfhosted.org>
Message-ID: <1581411858.12.0.657913871484.issue39593@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I guess the `xx_get()` and `xx_set()` function's process logic have relation with ffi's type, after I checked some `xx_get()` and `xx_set()`'s process logic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39593>
_______________________________________

From report at bugs.python.org  Tue Feb 11 04:40:20 2020
From: report at bugs.python.org (Chris Rogers)
Date: Tue, 11 Feb 2020 09:40:20 +0000
Subject: [issue39607] Add a parameter to strip, lstrip,
 and rstrip that treats the first parameter as a full string
Message-ID: <1581414020.64.0.469287582867.issue39607@roundup.psfhosted.org>


New submission from Chris Rogers <chihuahuasare2cute at gmail.com>:

Consider this string:

'mailto:mailto:mailto:main at example.com'

If you try to remove the mailtos with lstrip('mailto:'), you'll be left with this:

'n at example.com'

That's because the three strip functions look at each character separately rather than as a whole string.

Currently, as a workaround, you have to either use regex or a loop. This can take several lines of code.

It would be great if the strip functions had a second parameter that lets you keep the first parameter intact.

You could then use this code to get the desired result:

'mailto:mailto:mailto:main at example.com'.lstrip('mailto:', true)
>>main at example.com

----------
messages: 361791
nosy: Chris Rogers
priority: normal
severity: normal
status: open
title: Add a parameter to strip, lstrip, and rstrip that treats the first parameter as a full string
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39607>
_______________________________________

From report at bugs.python.org  Tue Feb 11 04:45:21 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 11 Feb 2020 09:45:21 +0000
Subject: [issue39585] Delete a pending item in _warning.c
In-Reply-To: <1581172060.12.0.48939566603.issue39585@roundup.psfhosted.org>
Message-ID: <1581414321.19.0.818049594172.issue39585@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> What if a warning has a metaclass with a custom __getattribute__ method?

Sorry, ppperry. I don't understand your question clearly. Could you give me some examples?

This function could be touched when user call `warnings.warn_explicit()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39585>
_______________________________________

From report at bugs.python.org  Tue Feb 11 04:47:07 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 11 Feb 2020 09:47:07 +0000
Subject: [issue39585] Delete a pending item in _warning.c
In-Reply-To: <1581172060.12.0.48939566603.issue39585@roundup.psfhosted.org>
Message-ID: <1581414427.91.0.797648226463.issue39585@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
components: +Extension Modules -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39585>
_______________________________________

From report at bugs.python.org  Tue Feb 11 05:06:19 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Feb 2020 10:06:19 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1581415579.64.0.357573066784.issue34788@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
assignee:  -> asvetlov
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34788>
_______________________________________

From report at bugs.python.org  Tue Feb 11 05:10:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Feb 2020 10:10:27 +0000
Subject: [issue39591] Functions in Python/traceback.c can take const pointer
 arguments
In-Reply-To: <1581227075.1.0.0304587287578.issue39591@roundup.psfhosted.org>
Message-ID: <1581415827.08.0.970988573345.issue39591@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Even if the object is not modified currently in common case, it does not guarantee that it cannot be modified in uncommon cases, or that it cannot be modified in future after introducing changes in different files.

For example, if names was created by the legacy C API like PyUnicode_FromUnicode(), it will be modified by calling PyUnicode_READY().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39591>
_______________________________________

From report at bugs.python.org  Tue Feb 11 05:28:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Feb 2020 10:28:04 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581416884.04.0.527101375365.issue39545@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Needed also notes in 3.7+.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Tue Feb 11 05:29:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Feb 2020 10:29:32 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581416972.7.0.785739098512.issue39545@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +17830
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18456

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Tue Feb 11 05:39:02 2020
From: report at bugs.python.org (mefistotelis)
Date: Tue, 11 Feb 2020 10:39:02 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1581417542.01.0.0158635899532.issue39011@roundup.psfhosted.org>


mefistotelis <mefistotelis at gmail.com> added the comment:

I'm on it.

Test update attached.

----------
Added file: https://bugs.python.org/file48890/0002-bpo-39011-Test-white-space-preservation-in-attribs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:04:06 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 11 Feb 2020 11:04:06 +0000
Subject: [issue39608] Bug in 00000000000000000
Message-ID: <1581419046.4.0.944643641611.issue39608@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Why is this?
>>> 0000000000000000000000000000000 # No error
0
>>> 0000000000000000000000000000002
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers

----------
components: Build
messages: 361796
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Bug in 00000000000000000
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39608>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:04:38 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 11 Feb 2020 11:04:38 +0000
Subject: [issue39608] Bug in lots of 0s
In-Reply-To: <1581419046.4.0.944643641611.issue39608@roundup.psfhosted.org>
Message-ID: <1581419078.08.0.156166974347.issue39608@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
title: Bug in 00000000000000000 -> Bug in lots of 0s

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39608>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:09:45 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 11 Feb 2020 11:09:45 +0000
Subject: [issue39608] Bug in lots of 0s
In-Reply-To: <1581419046.4.0.944643641611.issue39608@roundup.psfhosted.org>
Message-ID: <1581419385.14.0.49819240094.issue39608@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

0000000000002 is not supported;
So 000000000000000 should not too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39608>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:16:45 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 11:16:45 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581419805.5.0.909465592841.issue1635741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1ea45ae257971ee7b648e3b031603a31fc059f81 by Hai Shi in branch 'master':
bpo-1635741: Port _codecs extension module to multiphase initialization (PEP 489) (GH-18065)
https://github.com/python/cpython/commit/1ea45ae257971ee7b648e3b031603a31fc059f81


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:34:29 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Feb 2020 11:34:29 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1581420869.74.0.954215213987.issue38323@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +17831
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18457

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:35:18 2020
From: report at bugs.python.org (Markus Mohrhard)
Date: Tue, 11 Feb 2020 11:35:18 +0000
Subject: [issue39609] Set the thread_name_prefix for asyncio's default
 executor ThreadPoolExecutor
Message-ID: <1581420918.89.0.0710307394.issue39609@roundup.psfhosted.org>


New submission from Markus Mohrhard <markusm at dug.com>:

The ThreadPoolExecutor in BaseEventLoop.run_in_executor should set a thread_name_prefix to simplify debugging.

Might also be worth to limit the number of max threads. On our 256 core machines we sometimes get 1000+ threads due to the cpu_count() * 5 default limit.

----------
components: asyncio
messages: 361799
nosy: Markus Mohrhard, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Set the thread_name_prefix for asyncio's default executor ThreadPoolExecutor
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39609>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:35:46 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Feb 2020 11:35:46 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1581420946.27.0.482747803893.issue39432@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I'm with Stefan on "Definitely 3.8". It's a bug fix (for a rarely used feature).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:39:10 2020
From: report at bugs.python.org (Markus Mohrhard)
Date: Tue, 11 Feb 2020 11:39:10 +0000
Subject: [issue39609] Set the thread_name_prefix for asyncio's default
 executor ThreadPoolExecutor
In-Reply-To: <1581420918.89.0.0710307394.issue39609@roundup.psfhosted.org>
Message-ID: <1581421150.87.0.0315292707696.issue39609@roundup.psfhosted.org>


Change by Markus Mohrhard <markusm at dug.com>:


----------
keywords: +patch
pull_requests: +17832
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18458

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39609>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:41:21 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Feb 2020 11:41:21 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1581421281.18.0.800907757907.issue38323@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Victor, sorry.
I spent about 4 days in total trying to figure out what is the reason for hanging.
I see that the signal handler is installed; but, in a rare situation, it is not called when the process is killed.

If I reduce an amount of code executed in a signal handler by spawning a auxiliary thread, setting threading. Event in sighandler, and doing all dirty work in this secondary thread -- the problem goes away.
I'm not happy with this "patch" because it looks like reducing a change of the race without the elimination of the root cause.

I've mastered a quick hack to skip the problematic test on a hang, it may unblock other developers.
I want to spend more time on the issue detection. Unfortunately, it is not easy because of non-determenistic problem source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Tue Feb 11 06:59:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 11:59:49 +0000
Subject: [issue39600] idle_test: test_fontlist_key() fails if two font
 families have the same name
In-Reply-To: <1581349443.21.0.804865306435.issue39600@roundup.psfhosted.org>
Message-ID: <1581422389.19.0.704205172624.issue39600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks to everybody who was involved in this issue, it's nice to see a test fixed so quickly, especially when it enhances IDLE UI for end users ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39600>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:12:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:12:32 +0000
Subject: [issue39608] Bug in lots of 0s
In-Reply-To: <1581419046.4.0.944643641611.issue39608@roundup.psfhosted.org>
Message-ID: <1581423152.63.0.281532368065.issue39608@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +BTaskaya, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39608>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:14:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:14:59 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581423299.03.0.686548303779.issue38324@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I mark this issuse as a duplicate of bpo-37945.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:15:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:15:22 +0000
Subject: [issue37945] [Windows] locale.getdefaultlocale() issues on Windows:
 test_locale.test_getsetlocale_issue1813()
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1581423322.16.0.0698018903804.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-38324 as a duplicate of this issue.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:21:08 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 11 Feb 2020 12:21:08 +0000
Subject: [issue39608] Bug in lots of 0s
In-Reply-To: <1581419046.4.0.944643641611.issue39608@roundup.psfhosted.org>
Message-ID: <1581423668.44.0.518697699851.issue39608@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Its not a bug, it's deliberately designed that way. 0000 is not ambiguous: it's just zero, in any base. 0012 is ambiguous.

There's a recent thread about it here:

https://mail.python.org/archives/list/python-ideas at python.org/message/7IKEXSMVVDOTLHA7CNI7MIOBK4EU2ZSG/


If you want to change the behaviour, your first step is to get a consensus on the mailing list that it should change.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39608>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:24:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:24:25 +0000
Subject: [issue37945] [Windows] locale.getdefaultlocale() issues on Windows:
 test_locale.test_getsetlocale_issue1813()
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1581423865.74.0.684284092187.issue37945@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

For me, the locale.getlocale() function is broken. Python attempts to guess too many things about the current locale. For example, it relies on an hard coded locale.locale_encoding_alias dictionary which seems to come from X11!? In 2020, Wayland replaced X11 and locales are updated frequently. This dictionary makes no sense on Windows. For example, 'ka_ge' is mapped to 'ka_GE.GEORGIAN-ACADEMY': "GEORGIAN-ACADEMY" is not an encoding, what is the purpose of this string?

I fixed dozens and dozens of locale issues and I never ever used locale.getlocale(). I never understood its purpose nor how it guess the encoding.

I always use locale.setlocale(category) or locale.setlocale(category, None) which returns a simply string which I can pass back to locale.setlocale(category, string) to restore the locale, when I need to temporarily change a locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:25:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:25:18 +0000
Subject: [issue34592] cdll.LoadLibrary allows None as an argument
In-Reply-To: <1536183341.44.0.56676864532.issue34592@psf.upfronthosting.co.za>
Message-ID: <1581423918.97.0.314190086858.issue34592@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In clear, it's a feature, not a bug.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34592>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:27:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:27:34 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581424054.23.0.989500638485.issue39603@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Injection in http.client -> [security] http.client: HTTP Header Injection in the HTTP method

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:29:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 12:29:20 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581424160.53.0.713697873011.issue39603@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The recommended solution is to only allow the standard HTTP methods of GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH.

I don't think that we have to be so strict. We can maybe restrict the HTTP method to ASCII letters, or just reject control characters (U+0000-U+001f).

Similar issues (fixed):

* https://python-security.readthedocs.io/vuln/http-header-injection2.html
* https://python-security.readthedocs.io/vuln/http-header-injection.html

----------
nosy: +orsenthil, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:32:18 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 11 Feb 2020 12:32:18 +0000
Subject: [issue39607] Add a parameter to strip, lstrip,
 and rstrip that treats the first parameter as a full string
In-Reply-To: <1581414020.64.0.469287582867.issue39607@roundup.psfhosted.org>
Message-ID: <1581424338.83.0.31394901799.issue39607@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This has been discussed not long ago, it seems like it will need a PEP. See Brett's comment:

https://mail.python.org/archives/list/python-dev at python.org/message/BDK6BDBOG2462SJIIOC5QMYPAJ5A4523/

and various discussions:

https://mail.python.org/archives/list/python-dev at python.org/message/ZWRGCGANHGVDPP44VQKRIYOYX7LNVDVG/

https://mail.python.org/archives/list/python-ideas at python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/#WIRID57ESUFUAQQQ6ZUY2RK5PKQQYSJ3

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39607>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:36:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Feb 2020 12:36:05 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581424565.57.0.821683416563.issue39545@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +17833
pull_request: https://github.com/python/cpython/pull/18459

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Tue Feb 11 07:54:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Feb 2020 12:54:59 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581425699.19.0.170074930173.issue39603@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/issue39603>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:00:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:00:48 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1581426048.08.0.76213788951.issue39521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close this issue. It's likely just a hiccup in the PGO compilation. It's not the thing that we can easily control. The good thing is that the common code path iter(list) is efficient ;-)


> The code for listiter_next() and listreviter_next() is almost the same. 

Right. It cannot explain a 2x slowdown.


> python -m timeit -s "a = list(range(1000))" "list(iter(a))"
> 50000 loops, best of 5: 5.73 usec per loop

It means around 5.73 ns per iteration. This is almost "nothing": just a few CPU cycles. For such microbenchmark, you are very close to the bare metal. You have to take in account CPU low-level metrics like usage of the CPU caches.


> Another possible cause is that this is just a random build outcome due to PGO or incidental branch mis-prediction from aliasing (as described in https://stackoverflow.com/a/17906589/1001643 ).

If someone cares about such microbenchmark, I suggest to get access to a profiling tool and measure the CPU cache usage and other metrics like that. On Linux, I know the "perf" command which can be used. I don't know performance tooling on Windows. Maybe search in Intel developer tools.

I expect that list(iter(a)) better uses the CPU (cache? branch predictor?) than list(reversed(a)), because of how listiter_next() and listreviter_next() have been optimized.

Bad code placement has a high cost on performance on such microbenchmarks. See:

* https://llvmdevelopersmeetingbay2016.sched.org/event/8YzY/causes-of-performance-instability-due-to-code-placement-in-x86
* https://vstinner.github.io/analysis-python-performance-issue.html

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39521>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:02:10 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Feb 2020 13:02:10 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1581426130.02.0.650662660129.issue39245@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +17834
pull_request: https://github.com/python/cpython/pull/18460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:04:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:04:13 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581426253.24.0.365364050966.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The PyObject structure is part of the stable ABI, but PyGC_Head is not.
https://www.python.org/dev/peps/pep-0384/#structures

I can understand that it's annoying to not be able to use the same wheel package on Python 3.7 <= 3.7.4 and Python Python 3.7 >= 3.7.5, but I don't think that we can fix this issue.

I suggest to close it as "rejected".

One solution is to require to build your C extension on installation (don't ship wheel packages).

If you want to ship wheel package, another compromise would be to require Python 3.7.5 or newer, and check early the Python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:05:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:05:31 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581426331.71.0.0508621297756.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This happens on a custom C module (built via Cython) when using including <internal/pystate.h> with -DPy_BUILD_CORE. I'm not sure it'd happen otherwise.

By the way, I don't think that wheel packages are designed to C extensions accessing Python internals.

The internal C API is excluded from the stable ABI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:10:10 2020
From: report at bugs.python.org (Julien Danjou)
Date: Tue, 11 Feb 2020 13:10:10 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581426610.32.0.0027200477357.issue39599@roundup.psfhosted.org>


Julien Danjou <julien at danjou.info> added the comment:

> If you want to ship wheel package, another compromise would be to require Python 3.7.5 or newer, and check early the Python version.

Yes, this is what I do now to avoid getting a segmentation fault.

I'm fine with closing this as wontfix or reject, your call. As you said, if it's not part of the stable ABI it makes sense.

The sad part if that my code does not access PyGC_Head at all. It's just a side effect when loading the code that makes it crash. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:10:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:10:51 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1581426651.57.0.500139467348.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17835
pull_request: https://github.com/python/cpython/pull/18461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:15:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:15:06 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581426906.57.0.973950086894.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The sad part if that my code does not access PyGC_Head at all. It's just a side effect when loading the code that makes it crash. :(

Python stores pointers to PyObject*. If your code doesn't access PyGC_Head directly, maybe it does acess it indirectly? I don't understand why you get a crash. It would help if you can provide more information about the crash. In which function does it happen? Try to get a gdb trace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:20:49 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 11 Feb 2020 13:20:49 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1581427249.68.0.796842782138.issue27657@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Lukaz / Ned:

I will like to revert the backports done in 3.8 and 3.7.

Preferably in 3.8.2 and 3.7.7, so that this undesirable behavior exists only for a single release. 

I have set this is a release blocker to catch your attention.

----------
nosy: +benjamin.peterson, lukasz.langa, ned.deily
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:29:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:29:37 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1581427777.38.0.165625600756.issue39500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f3e7ea5b8c220cd63101e419d529c8563f9c6115 by Victor Stinner in branch 'master':
bpo-39500: Document PyUnicode_IsIdentifier() function (GH-18397)
https://github.com/python/cpython/commit/f3e7ea5b8c220cd63101e419d529c8563f9c6115


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:29:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 13:29:53 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1581427793.66.0.986743504862.issue39500@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/issue39500>
_______________________________________

From report at bugs.python.org  Tue Feb 11 08:34:48 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 11 Feb 2020 13:34:48 +0000
Subject: [issue39574] str.__doc__ is misleading
In-Reply-To: <1581073946.77.0.371242797253.issue39574@roundup.psfhosted.org>
Message-ID: <20200211133442.GM8273@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Sorry everyone, due to technology problems I am unable to comment on the 
github page, and due to ISP problems I've been off the internet for a 
few days.

> pull_request: https://github.com/python/cpython/pull/18401

[Serhiy]
> Is not "or both" redundant?

I don't think so. In regular English, "or" can imply exclusive-or:

    "Shall we eat at the Thai or the Italian restaurant?"

There are four relevant cases:

- supply neither encoding nor errors;
- supply only encoding;
- supply only errors;
- supply both encoding and errors.

Using "or" may be, for some readers, ambiguous: is the last option 
included or not? For the sake of two extra words, let's make it clear 
and unambiguous.

[Serhiy]
> Use just 'utf-8' instead of sys.getdefaultencoding(). It is a 
> constant in Python 3.

I didn't know that. I'm okay with that change, thank you.

[Serhiy]
> - str(bytes_or_buffer[, encoding[, errors]]) -> str
> + str(bytes_or_buffer, encoding='utf-8', errors='strict') -> str

I'm happy with that.

Thank you everyone, and sorry again that I have trouble with the Github 
process. (I need a new computer with a newer OS.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39574>
_______________________________________

From report at bugs.python.org  Tue Feb 11 09:13:39 2020
From: report at bugs.python.org (Max)
Date: Tue, 11 Feb 2020 14:13:39 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581430419.33.0.953562256145.issue39603@roundup.psfhosted.org>


Max <maxpl0it at protonmail.com> added the comment:

I agree that the solution is quite restrictive.
Restricting to ASCII characters alone would certainly work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Tue Feb 11 09:36:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 14:36:14 +0000
Subject: [issue38243] [security][CVE-2019-16935] A reflected XSS in
 python/Lib/DocXMLRPCServer.py
In-Reply-To: <1569032250.18.0.545337961077.issue38243@roundup.psfhosted.org>
Message-ID: <1581431774.45.0.817817736056.issue38243@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

CVE-2019-16935 has been assigned to this vulnerability.

----------
title: A reflected XSS in python/Lib/DocXMLRPCServer.py -> [security][CVE-2019-16935] A reflected XSS in python/Lib/DocXMLRPCServer.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38243>
_______________________________________

From report at bugs.python.org  Tue Feb 11 10:32:47 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Feb 2020 15:32:47 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1581435167.69.0.467896842341.issue39299@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d3f9fb2d28ceedb0a17a703338424ff284a578c8 by Miss Islington (bot) in branch '3.8':
bpo-39299: Add more tests for mimetypes and its cli. (GH-17949)
https://github.com/python/cpython/commit/d3f9fb2d28ceedb0a17a703338424ff284a578c8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Tue Feb 11 10:34:33 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Feb 2020 15:34:33 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1581435273.97.0.164738220096.issue39299@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/issue39299>
_______________________________________

From report at bugs.python.org  Tue Feb 11 10:42:52 2020
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 11 Feb 2020 15:42:52 +0000
Subject: [issue39610] memoryview.__len__ should raise an exception for 0d
 buffers
Message-ID: <1581435772.39.0.91175671687.issue39610@roundup.psfhosted.org>


New submission from Eric Wieser <wieser.eric at gmail.com>:

Right now, the behavior is:

>>> import numpy as np
>>> arr_0d = np.array(42)
>>> mem_0d = memoryview(arr_0d)
>>> len(mem_0d)
1
>>> mem_0d[0]
TypeError: invalid indexing of 0-dim memory

It seems bizarre to have this object pretend to be a sequence when you ask for its length, yet not behave like one when you actually try to use this length. I'd suggest cpython should behave like numpy here, and fail:

>>> len(arr_0d)
TypeError: len() of unsized object


Perhaps `TypeError: cannot get length of 0-dim memory` would be more appropriate as a message.

---

Wasn't sure how to classify this, feel free to reclassify

----------
components: Interpreter Core
messages: 361821
nosy: Eric Wieser, skrah
priority: normal
severity: normal
status: open
title: memoryview.__len__ should raise an exception for 0d buffers
type: behavior
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/issue39610>
_______________________________________

From report at bugs.python.org  Tue Feb 11 10:51:35 2020
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 11 Feb 2020 15:51:35 +0000
Subject: [issue39610] memoryview.__len__ should raise an exception for 0d
 buffers
In-Reply-To: <1581435772.39.0.91175671687.issue39610@roundup.psfhosted.org>
Message-ID: <1581436295.07.0.581893600749.issue39610@roundup.psfhosted.org>


Change by Eric Wieser <wieser.eric+pybug at gmail.com>:


----------
keywords: +patch
pull_requests: +17836
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18463

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39610>
_______________________________________

From report at bugs.python.org  Tue Feb 11 11:26:30 2020
From: report at bugs.python.org (Angel Cervera Claudio)
Date: Tue, 11 Feb 2020 16:26:30 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1581378665.17.0.281835591215.issue39417@roundup.psfhosted.org>
Message-ID: <CAEwMphVsPqonLr_+O1Zr38S3+ZsSNKcj6C=Zj0zfFm5WGPe63w@mail.gmail.com>


Angel Cervera Claudio <angelcervera at silyan.com> added the comment:

Thanks for handling this. I'm sorry   I didn't have a chance to create the
pr. :(

On Mon 10 Feb 2020, 23:51 Carol Willing, <report at bugs.python.org> wrote:

>
> Carol Willing <willingc at gmail.com> added the comment:
>
>
> New changeset c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160 by Ogi Moore in
> branch 'master':
> bpo-39417: Fix broken link to guide to building venvs (GH-18432)
>
> https://github.com/python/cpython/commit/c4a65ed7fe342bd18b5a5b0eea3470dc4fc31160
>
>
> ----------
> nosy: +willingc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39417>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Tue Feb 11 11:37:44 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Feb 2020 16:37:44 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1581439064.37.0.89387362153.issue37207@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +17837
pull_request: https://github.com/python/cpython/pull/18464

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Tue Feb 11 11:47:02 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Feb 2020 16:47:02 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1581439622.35.0.599482400022.issue39245@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset ffd9753a944916ced659b2c77aebe66a6c9fbab5 by Petr Viktorin in branch 'master':
bpo-39245: Switch to public API for Vectorcall (GH-18460)
https://github.com/python/cpython/commit/ffd9753a944916ced659b2c77aebe66a6c9fbab5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Feb 11 11:50:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 16:50:02 +0000
Subject: [issue39611] PyVectorcall_NARGS(): change return type to Py_ssize_t
Message-ID: <1581439802.08.0.269605929245.issue39611@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I propose to change PyVectorcall_NARGS() return type from unsigned size_t to signed Py_ssize_t.

Currently, the function is defined as:

static inline Py_ssize_t
PyVectorcall_NARGS(size_t n)
{
    return n & ~PY_VECTORCALL_ARGUMENTS_OFFSET;
}

But in CPython code base, the result is always stored in a *signed* Py_ssize_t:

    Py_ssize_t nargs = PyVectorcall_NARGS(nargsf);

Sometimes, this nargs is passed to _PyObject_MakeTpCall() which expects nargs to be Py_ssize_t, so it's consistent.

In general in CPython, a size uses type Py_ssize_t, not size_t. Example: PyVarObject.ob_size type is Py_ssize_t.

----------
components: C API
messages: 361824
nosy: jdemeyer, petr.viktorin, vstinner
priority: normal
severity: normal
status: open
title: PyVectorcall_NARGS(): change return type to Py_ssize_t
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39611>
_______________________________________

From report at bugs.python.org  Tue Feb 11 11:50:14 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Feb 2020 16:50:14 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1581439814.28.0.203142018406.issue38644@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset f3fda374685dffa31ebda9e681e00ef7032b8a1d by Victor Stinner in branch 'master':
bpo-38644: Rephrase What's New entry (GH-18461)
https://github.com/python/cpython/commit/f3fda374685dffa31ebda9e681e00ef7032b8a1d


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Tue Feb 11 12:47:09 2020
From: report at bugs.python.org (Chris Wilcox)
Date: Tue, 11 Feb 2020 17:47:09 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581443229.29.0.042648213076.issue39601@roundup.psfhosted.org>


Chris Wilcox <python at crwilcox.com> added the comment:

Thanks Eric. That is very handy.

I had made a test case earlier on a branch. Attached as a patch here if helpful.

I haven't tried to fix this yet, but would be interested if it is something that makes sense to address.

----------
keywords: +patch
Added file: https://bugs.python.org/file48891/test_case.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Tue Feb 11 12:48:42 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 11 Feb 2020 17:48:42 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1581443322.88.0.491678964315.issue39521@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Just FYI, there is no PGO run on the official 32-bit builds. I only run it on the 64-bit build.

It might be worth investigating differences between the 3.7 and 3.8 implementations of reversed().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39521>
_______________________________________

From report at bugs.python.org  Tue Feb 11 13:34:30 2020
From: report at bugs.python.org (Amir Mohamadi)
Date: Tue, 11 Feb 2020 18:34:30 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581446070.54.0.95750880974.issue39603@roundup.psfhosted.org>


Amir Mohamadi <amiremohamadi at yahoo.com> added the comment:

can I work on it?!

----------
nosy: +Amir

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Tue Feb 11 14:35:51 2020
From: report at bugs.python.org (ArtOfCode Studio)
Date: Tue, 11 Feb 2020 19:35:51 +0000
Subject: [issue39612] Python UnicodeDecodeError while using modulefinder
Message-ID: <1581449751.58.0.336622448133.issue39612@roundup.psfhosted.org>


New submission from ArtOfCode Studio <artofcodestudio at gmail.com>:

I want to find all imported modules in a python program. I am using the ``modulefinder`` standard module for my job. I am trying to follow [this example](https://docs.python.org/3.8/library/modulefinder.html#example-usage-of-modulefinder) on docs, but I get this error even if I use the same code as the documents:

````python
Traceback (most recent call last):
  File "C:\Users\Din?el\Desktop\Deploy\zipperutils\find modules.py", line 4, in <module>
    finder.run_script('bacon.py')
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 165, in run_script
    self.load_module('__main__', fp, pathname, stuff)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 360, in load_module
    self.scan_code(co, m)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 433, in scan_code
    self._safe_import_hook(name, m, fromlist, level=0)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 378, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 177, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 233, in find_head_package
    q = self.import_module(head, qname, parent)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 326, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 360, in load_module
    self.scan_code(co, m)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 433, in scan_code
    self._safe_import_hook(name, m, fromlist, level=0)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 378, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 177, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 233, in find_head_package
    q = self.import_module(head, qname, parent)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 326, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 360, in load_module
    self.scan_code(co, m)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 433, in scan_code
    self._safe_import_hook(name, m, fromlist, level=0)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 378, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 177, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 233, in find_head_package
    q = self.import_module(head, qname, parent)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 326, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 360, in load_module
    self.scan_code(co, m)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 466, in scan_code
    self.scan_code(c, m)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 433, in scan_code
    self._safe_import_hook(name, m, fromlist, level=0)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 378, in _safe_import_hook
    self.import_hook(name, caller, level=level)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 177, in import_hook
    q, tail = self.find_head_package(parent, name)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 233, in find_head_package
    q = self.import_module(head, qname, parent)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 326, in import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\modulefinder.py", line 343, in load_module
    co = compile(fp.read()+'\n', pathname, 'exec')
  File "C:\Users\Din?el\AppData\Local\Programs\Python\Python38\lib\encodings\cp1254.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 308: character maps to <undefined>
````
My operating system is Windows 10.

I am using Python3.8.1

If there is a better way of finding imported modules let me know it.

Also is there any way of saying that to Python: "use unicode for directory names"?

----------
components: Unicode
messages: 361829
nosy: ArtOfCode Studio, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Python UnicodeDecodeError while using modulefinder
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39612>
_______________________________________

From report at bugs.python.org  Tue Feb 11 14:36:49 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 11 Feb 2020 19:36:49 +0000
Subject: [issue38324] [Windows] test_locale and test__locale failures on
 Windows
In-Reply-To: <1569849277.36.0.00648751871696.issue38324@roundup.psfhosted.org>
Message-ID: <1581449809.49.0.567352273734.issue38324@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

It is not a duplicate of bpo-37945. The tests in test/test__locale.py need to be fixed to work with Windows. 

In msg354021, I discussed the problem reported with test_lc_numeric_localeconv. The "ps_AF" (Pashto, Afghanistan) item in known_numerics has to be skipped in Windows because the system data does not agree with the test's assumed Arabic decimal and thousands separator, U+066B and U+066C, but instead uses "," and ".".
  
Also, all tests need to swap the order of setting LC_NUMERIC and LC_CTYPE in order to avoid a UnicodeDecodeError with locales that use UTF-8, such as "ka_GE". _locale.localeconv should be using the wide-character_W_ prefixed string fields from the lconv structure in Windows [1], such as _W_decimal_point. Until that gets fixed, tests need to be mindful that ucrt in Windows uses the current LC_CTYPE to update the multibyte strings in the lconv structure when setting LC_NUMERIC. So they should be changed as a pair, with LC_CTYPE set first.

[1]: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/localeconv?view=vs-2019

----------
resolution: duplicate -> 
stage: resolved -> needs patch
status: closed -> open
superseder: [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813() -> 
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38324>
_______________________________________

From report at bugs.python.org  Tue Feb 11 14:51:37 2020
From: report at bugs.python.org (Artur Rodrigues)
Date: Tue, 11 Feb 2020 19:51:37 +0000
Subject: [issue39613] IsolatedAsyncioTestCase closes default event loop
Message-ID: <1581450697.14.0.885131821456.issue39613@roundup.psfhosted.org>


New submission from Artur Rodrigues <arturhoo at gmail.com>:

This means that subsequent test cases executed within the same application that don't create the event loop will fail. This seems like a behaviour change that wasn't raised on the original PR.

$ cat test.py
from unittest import IsolatedAsyncioTestCase, TestCase, main
import asyncio

class Test1(IsolatedAsyncioTestCase):
    async def test_one(self):
        self.assertTrue(True)

class Test2(TestCase):
    def test_two(self):
        loop = asyncio.get_event_loop()
        self.assertTrue(true)

if __name__ == "__main__":
    main()
$ /usr/local/opt/python at 3.8/bin/python3 test.py
.E
======================================================================
ERROR: test_two (__main__.Test2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test.py", line 13, in test_two
    loop = asyncio.get_event_loop()
  File "/usr/local/Cellar/python at 3.8/3.8.1/Frameworks/Python.framework/Versions/3.8/lib/python3.8/asyncio/events.py", line 639, in get_event_loop
    raise RuntimeError('There is no current event loop in thread %r.'
RuntimeError: There is no current event loop in thread 'MainThread'.

----------------------------------------------------------------------
Ran 2 tests in 0.006s

FAILED (errors=1)
$ uname -a
Darwin arturhoo-mbp 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec  1 18:59:03 PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64 x86_64

----------
components: asyncio
messages: 361831
nosy: arturhoo, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: IsolatedAsyncioTestCase closes default event loop
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39613>
_______________________________________

From report at bugs.python.org  Tue Feb 11 16:56:56 2020
From: report at bugs.python.org (JitterMan)
Date: Tue, 11 Feb 2020 21:56:56 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581458216.79.0.838479506889.issue39601@roundup.psfhosted.org>


JitterMan <pythonbugs at shalmirane.com> added the comment:

I believe it is worth fixing as it clears up some rather glaring inconsistencies?
and enables a useful capability. Specifically,

1. Formatted string literals and the string format method are currently 
   inconsistent in the way that they handle double braces in the format 
   specifier.

    >>> x = 42
    >>> import datetime
    >>> now = datetime.datetime.now()

    >>> f'{now:x{{x}}x}'
    'x{42}x'

    >>> '{:x{{x}}x}'.format(now)
    'x{x}x'

2. Formatted string literals currently seem inconsistent in the way they handle 
   handle doubled braces.

   In the base string doubling the braces escapes them.

    >>> f'x{{x}}x'
    'x{x}x'

   In the replacement expression doubling the braces escapes them.
    >>> f'{f"x{{x}}x"}'
    'x{x}x'

   In the format specifier doubling the braces does not escape them.
    >>> f'{now:x{{x}}x}'
    'x{42}x'

3. Currently there is no way I know of escape the braces in the format 
   specifier.

4. Allowing the braces to be escaped in the format specifier allows the user to 
   defer the interpretation of the of a format specifier so that it is evaluated 
   by a format function inside the object rather than being evaluated in the 
   current context.  That seems like a generally useful feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Tue Feb 11 17:02:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 22:02:53 +0000
Subject: [issue39521] reversed(mylist) much slower on Python 3.8 32-bit for
 Windows
In-Reply-To: <1580593329.06.0.491648028148.issue39521@roundup.psfhosted.org>
Message-ID: <1581458573.66.0.776528098258.issue39521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Just FYI, there is no PGO run on the official 32-bit builds. I only run it on the 64-bit build.

Aaaah :-) That's good to know ;-) It can explain the performance difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39521>
_______________________________________

From report at bugs.python.org  Tue Feb 11 17:03:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 22:03:24 +0000
Subject: [issue39612] Python UnicodeDecodeError while using modulefinder
In-Reply-To: <1581449751.58.0.336622448133.issue39612@roundup.psfhosted.org>
Message-ID: <1581458604.27.0.0691894900114.issue39612@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39612>
_______________________________________

From report at bugs.python.org  Tue Feb 11 17:03:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Feb 2020 22:03:57 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581458637.56.0.0407723123565.issue39601@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

But you can't just change it without breaking the code of anyone who's relying on the current behavior. If we could say "no one relies on that", that's would let us move forward with such a breaking change. But I don't think we can make that determination. And we're generally conservative with such breaking changes.

I think the current behavior doesn't make much sense, although I haven't completely analyzed the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Tue Feb 11 17:04:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 11 Feb 2020 22:04:03 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581458643.59.0.812989830558.issue39601@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/issue39601>
_______________________________________

From report at bugs.python.org  Tue Feb 11 17:32:05 2020
From: report at bugs.python.org (JitterMan)
Date: Tue, 11 Feb 2020 22:32:05 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581460325.66.0.434690080891.issue39601@roundup.psfhosted.org>


JitterMan <pythonbugs at shalmirane.com> added the comment:

Okay, I get it. Someone might be using two braces in the format specifier because they found that it is a way to both evaluate a sub-expression and get braces in the formatted result. I was thinking that they would just use three braces, but that does not appear to work, though I cannot understand the resulting error message.

    >>> x = 42
    >>> import datetime
    >>> now = datetime.datetime.now()

    >>> f'{now:x{x}x}'
    'x42x'

    >>> f'{now:x{{x}}x}'
    'x{42}x'

    >>> f'{now:x{{{x}}}x}'
    Traceback (most recent call last):
    ...
    TypeError: unhashable type: 'set'

I think you are right. This particular ship may have already sailed away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Tue Feb 11 18:05:13 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Feb 2020 23:05:13 +0000
Subject: [issue37088] Add a way to schedule a function to be called from the
 main thread
In-Reply-To: <1559148389.14.0.649589094885.issue37088@roundup.psfhosted.org>
Message-ID: <1581462313.77.0.669543939103.issue37088@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> There is not clear rationale to justify the addition of the function

Yeah, with the new threaded watcher being the default we don't need this anymore.


> so I reject the feature

NP, here, but, hm, can you unilaterally reject features now? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37088>
_______________________________________

From report at bugs.python.org  Tue Feb 11 18:17:29 2020
From: report at bugs.python.org (Dirk Herrmann)
Date: Tue, 11 Feb 2020 23:17:29 +0000
Subject: [issue39614] Documentation of attribute reference is unclear
Message-ID: <1581463049.18.0.764231801329.issue39614@roundup.psfhosted.org>


New submission from Dirk Herrmann <dirk.herrmann-privat at gmx.de>:

Trying to understand attribute reference in Python, I was lost:

* In the "Python Language Reference" (I will refer to this as PLR, sorry if that is uncommon, did not find an abbreviation in the glossary): Chapter 6.3.1 is about attribute reference.  How the attribute reference actually works is not explained in detail, only with the sentence "This object is then asked to produce the attribute whose name is the identifier." which I find vague.  Moreover, in PLR 6.3.1 it is said that it can be customized overriding "__getattr__()", but again, details are unclear.  And, when following the link to "__getattr__()" it turns out that "__getattr__()" is not called for attribute access, but only in certain circumstances:

* PLR 3.3.1 section "object.__getattr__(self, name)" explains that this is only called when "default attribute access" fails.  There is nowhere an explanation of "default attribute access", it is also not mentioned in the index.  There is some explanation in parentheses what it means if "default attribute access" fails, but the actual procedure of the "default attribute access" is still not clear.  A bit further down in this section it is also mentioned that if an attribute is found using the "normal mechanism" then "__getattr__()" is not called - again not explaining what the "normal mechanism" is.  There is some reference to "__getattribute__()" here, saying that with "__getattribute__()" there would be "total control over attribute access", but this leads again to confusion:

* PLR 3.3.1 section "object.__getattribute__(self, name)" indicates that this "may still be bypassed" in certain circumstances, referring to PLR 3.3.10, special method lookup, which refers to the "conventional lookup process", to which this is an exception.  The basis why this is an exception remains unclear - is it that certain method names are detected during attribute reference?

Summary: There is not (or I was too stupid to find) a concise description of how attribute reference works.  There are several terms used to refer to certain aspects of it: "default attribute access", "normal mechanism [of attribute access]", "conventional lookup process", which may or may not refer to the same thing, which seems not to be documented anyway.

----------
assignee: docs at python
components: Documentation
messages: 361837
nosy: Dirk Herrmann, docs at python
priority: normal
severity: normal
status: open
title: Documentation of attribute reference is unclear
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39614>
_______________________________________

From report at bugs.python.org  Tue Feb 11 18:30:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Feb 2020 23:30:30 +0000
Subject: [issue37088] Add a way to schedule a function to be called from the
 main thread
In-Reply-To: <1559148389.14.0.649589094885.issue37088@roundup.psfhosted.org>
Message-ID: <1581463830.2.0.308038834453.issue37088@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> NP, here, but, hm, can you unilaterally reject features now? :)

Eric Snow and me are basically against the idea of exposing the "pending calls" mechanism in Python, since it's fragile and dangerous. Andrew Sveltov wrote "@vstinner had objections, perhaps this PR should be rejected." So I don't think that it's an unilaterally decision :)

There are multiple unanswered questions which have been asked here. For example, the ratione to add this feature seems to be based on a wrong assumption (signal handling using the pending call mechanism).

I'm not strongly against the feature. I first proposed to expose it, but make it private. Almost one year later, the PR was not updated. So I just closed the PR and the issue.

The problem is not only asynico, it's how this feature can be abused in general, and users who may have wrong expectations on how it works.


> Yeah, with the new threaded watcher being the default we don't need this anymore.

Handling subprocesses in asyncio also seem to be a can of worms. bpo-38323 is a good example :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37088>
_______________________________________

From report at bugs.python.org  Tue Feb 11 18:39:10 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Feb 2020 23:39:10 +0000
Subject: [issue37088] Add a way to schedule a function to be called from the
 main thread
In-Reply-To: <1559148389.14.0.649589094885.issue37088@roundup.psfhosted.org>
Message-ID: <1581464350.55.0.437775857129.issue37088@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I'm not strongly against the feature. I first proposed to expose it, but make it private. Almost one year later, the PR was not updated. So I just closed the PR and the issue.

All clear, Victor. Let's keep this closed. The reason I didn't reply is because we are no longer need it and this is a very low-level piece of functionality that I myself feel uneasy about. It can have potential problems to implement in PyPy/other interpreters in a compatible with CPython fashion.

I'll reopen if there's a need for this in asyncio. But even then, we can make this a "private" and undocumented function in the sys module (of course that would mean that we only use it to issue warnings / add extra debug functionality).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37088>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:00:50 2020
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 12 Feb 2020 00:00:50 +0000
Subject: [issue39610] memoryview.__len__ should raise an exception for 0d
 buffers
In-Reply-To: <1581435772.39.0.91175671687.issue39610@roundup.psfhosted.org>
Message-ID: <1581465650.76.0.589895531862.issue39610@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The change looks reasonable, but unfortunately this is a long-standing
behavior that originates from before the Python-3.3 memoryview rewrite.

It is also present in 2.7 (the previous implementation) and documented
in 3.3:

https://docs.python.org/3/library/stdtypes.html#memoryview


I think I documented it because it looked strange back then, too.
So I've to think a bit what will be affected and how this behavior
came into place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39610>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:05:07 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 12 Feb 2020 00:05:07 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1581465907.11.0.0885918685453.issue39483@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

??????,

Here's how you can fix your example:


import asyncio


class Singleton:
    _LOCK = None
    _LOOP = None

    @classmethod
    async def create(cls):
        if cls._LOOP is None:
            cls._LOOP = asyncio.get_running_loop()
            cls._LOCK = asyncio.Lock()
        loop = cls._LOOP
        if loop is not asyncio.get_running_loop():
            raise RuntimeError()

        if not hasattr(cls, '_Singleton__instance'):
            async with cls._LOCK:
                if not hasattr(cls, '_Singleton__instance'):
                    await asyncio.sleep(1)
                    cls.__instance = cls()
        return cls.__instance

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:09:13 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 12 Feb 2020 00:09:13 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581466153.1.0.716691779356.issue39474@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
nosy: +lys.nikolaou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:39:58 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Feb 2020 00:39:58 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581467998.58.0.314722557217.issue39474@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This is also a 3.8 issue. We discovered this with pegen, and would love to see it fixed.

----------
nosy: +gvanrossum
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:53:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 00:53:14 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581468794.13.0.293800112891.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I closed bpo-858809 as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:53:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 00:53:00 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1581468780.8.0.107927512327.issue858809@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Start of this issue:

"Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64."

That's a duplicate of bpo-1294959. This issue discuss also modifying distutils but there is no clear plan on how it should behave or not. My PR 18381 of bpo-1294959 updates sysconfig and distutils to support $prefix/$python_libdir/ path.

----------
nosy: +vstinner
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Problems with /usr/lib64 builds.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue858809>
_______________________________________

From report at bugs.python.org  Tue Feb 11 19:56:31 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 12 Feb 2020 00:56:31 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581468991.07.0.552537230892.issue39474@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Are you going to work on a patch then, Batuhan?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:05:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:05:53 +0000
Subject: [issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64
 folders
In-Reply-To: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za>
Message-ID: <1581469553.24.0.770128131104.issue15631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I mark this issue as a duplicate of bpo-1294959.

----------
nosy: +vstinner
resolution: out of date -> duplicate
superseder:  -> Problems with /usr/lib64 builds.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15631>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:06:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:06:13 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581469573.15.0.893001373433.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-15631 as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:11:10 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Feb 2020 01:11:10 +0000
Subject: [issue39011] ElementTree attributes replace "\r" with "\n"
In-Reply-To: <1575934850.24.0.848331688216.issue39011@roundup.psfhosted.org>
Message-ID: <1581469870.21.0.161121298547.issue39011@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +17838
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18468

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39011>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:15:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:15:18 +0000
Subject: [issue34032] Add platlibdir to allow distinction between /usr/lib and
 /usr/lib64 for Linux
In-Reply-To: <1530630040.09.0.56676864532.issue34032@psf.upfronthosting.co.za>
Message-ID: <1581470118.54.0.483013058807.issue34032@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I mark this issue as a duplicate of bpo-1294959.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Problems with /usr/lib64 builds.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34032>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:16:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:16:08 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581470168.44.0.910057909806.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-34032 as a duplicate of this issue. It has an open PR written by Mat?j Cepl (OpenSUSE): PR 8068. It looks similar to PR 3698.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:18:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:18:30 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581470310.97.0.737895992755.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-34058 "Default Python 3.7 install broken on openSUSE Leap 42.3: $PYTHONHOME/lib64/python3.7/lib-dynload/ not linked to $PYTHONHOME/lib/python3.7/lib-dynload/": OpenSUSE and Centos are mentioned as being impacted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:19:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:19:16 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581470356.95.0.482766721341.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-14791: "setup.py only adds /prefix/lib, not /prefix/lib64".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:20:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:20:43 +0000
Subject: [issue16529] Compiler error when trying to compile ceval.c on
 OpenSUSE 11.3
In-Reply-To: <1353574185.01.0.323738312876.issue16529@psf.upfronthosting.co.za>
Message-ID: <1581470443.99.0.0754669648098.issue16529@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

That's a GCC bug which has likely been fixed since 2014.

----------
nosy: +vstinner
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16529>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:21:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:21:56 +0000
Subject: [issue18092] Python 2.7.5 installation broken on OpenSuse 12.2
In-Reply-To: <1369808700.25.0.570015045706.issue18092@psf.upfronthosting.co.za>
Message-ID: <1581470516.24.0.232237659602.issue18092@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Problems with /usr/lib64 builds.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18092>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:22:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:22:01 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581470521.83.0.289172277246.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-18092 ("Python 2.7.5 installation broken on OpenSuse 12.2") as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:22:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:22:39 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581470559.29.0.351644965183.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-21016: "trace: $prefix and $exec_prefix improperly replaced on Fedora".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:24:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:24:03 +0000
Subject: [issue32897] test_gdb failed on Fedora 27
In-Reply-To: <1519241602.1.0.467229070634.issue32897@psf.upfronthosting.co.za>
Message-ID: <1581470643.9.0.024580079472.issue32897@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_gdb got multiple bugfixes since 2018. Please test Python 3.8.1 on Fedora 31. Your issue should be fixed.

----------
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32897>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:24:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:24:37 +0000
Subject: [issue19482] _pickle build warnings on Fedora 19
In-Reply-To: <1383460283.32.0.964490197084.issue19482@psf.upfronthosting.co.za>
Message-ID: <1581470677.18.0.569771103311.issue19482@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I don't get these warnings on Fedora anymore. I close the issue.

----------
nosy: +vstinner
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19482>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:26:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:26:27 +0000
Subject: [issue38180] Test pyexpat fails on Fedora 30
In-Reply-To: <1568583669.12.0.757725102986.issue38180@roundup.psfhosted.org>
Message-ID: <1581470787.86.0.6714637488.issue38180@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm unable to reproduce the issue on Fedora 31. We now have multiple Fedora buildbots (Stable and Rawhide flavors): test_pyexpat pass on all of them.

Maybe you didn't use "./configure --with-system-expat".

Reopen the issue if you can still reproduce it.

----------
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38180>
_______________________________________

From report at bugs.python.org  Tue Feb 11 20:29:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 01:29:27 +0000
Subject: [issue15976] Inconsistent behavior of search_for_exec_prefix()
 results in startup failure in certain cases
In-Reply-To: <1348084661.36.0.682682476046.issue15976@psf.upfronthosting.co.za>
Message-ID: <1581470967.35.0.468697754929.issue15976@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue was reported on Python 2.7 eight years ago. getpath.c has been deeply reworked, especially by the PEP 587 (PyConfig) implementation. I consider that the issue is now fixed. If it's not the case, feel free to reopen it.

----------
nosy: +vstinner
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15976>
_______________________________________

From report at bugs.python.org  Tue Feb 11 21:28:44 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Feb 2020 02:28:44 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581474524.07.0.631419616966.issue39605@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset e6be9b59a911626d6597fe148c32f0342bd2bd24 by Andy Lester in branch 'master':
closes bpo-39605: Fix some casts to not cast away const. (GH-18453)
https://github.com/python/cpython/commit/e6be9b59a911626d6597fe148c32f0342bd2bd24


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 21:28:49 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 02:28:49 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581474529.17.0.0334889169122.issue39605@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17839
pull_request: https://github.com/python/cpython/pull/18471

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 21:47:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 02:47:27 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581475647.17.0.865915883002.issue39605@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 190433d8150bf719fa0ba972dbacf2214942f54e by Miss Islington (bot) in branch '3.8':
closes bpo-39605: Fix some casts to not cast away const. (GH-18453)
https://github.com/python/cpython/commit/190433d8150bf719fa0ba972dbacf2214942f54e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 21:58:51 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 12 Feb 2020 02:58:51 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
In-Reply-To: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>
Message-ID: <1581476331.42.0.270103251536.issue39595@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset e5bd73632e77dc5ab0cab77e48e94ca5e354be8a by Jason R. Coombs in branch 'master':
bpo-39595: Improve zipfile.Path performance (#18406)
https://github.com/python/cpython/commit/e5bd73632e77dc5ab0cab77e48e94ca5e354be8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39595>
_______________________________________

From report at bugs.python.org  Tue Feb 11 21:59:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 02:59:53 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
In-Reply-To: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>
Message-ID: <1581476393.44.0.509687548889.issue39595@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17840
pull_request: https://github.com/python/cpython/pull/18472

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39595>
_______________________________________

From report at bugs.python.org  Tue Feb 11 22:07:01 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Feb 2020 03:07:01 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581476821.69.0.12734635766.issue39605@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +17841
pull_request: https://github.com/python/cpython/pull/18473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 22:21:35 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 12 Feb 2020 03:21:35 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
In-Reply-To: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>
Message-ID: <1581477695.78.0.00311608909683.issue39595@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset ed4d263e8767b0e4c47df99141b500d36ce0275d by Miss Islington (bot) in branch '3.8':
bpo-39595: Improve zipfile.Path performance (GH-18406) (GH-18472)
https://github.com/python/cpython/commit/ed4d263e8767b0e4c47df99141b500d36ce0275d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39595>
_______________________________________

From report at bugs.python.org  Tue Feb 11 22:22:02 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 12 Feb 2020 03:22:02 +0000
Subject: [issue39595] Improve performance of importlib.metadata and
 zipfile.Path
In-Reply-To: <1581282081.96.0.175299571443.issue39595@roundup.psfhosted.org>
Message-ID: <1581477722.48.0.613399481945.issue39595@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/issue39595>
_______________________________________

From report at bugs.python.org  Tue Feb 11 22:36:21 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Feb 2020 03:36:21 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581478581.14.0.981618360379.issue39605@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 95905ce0f41fd42eb1ef60ddb83f057401c3d52f by Benjamin Peterson in branch 'master':
bpo-39605: Remove a cast that causes a warning. (GH-18473)
https://github.com/python/cpython/commit/95905ce0f41fd42eb1ef60ddb83f057401c3d52f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 22:36:28 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 03:36:28 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581478588.11.0.608724271822.issue39605@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17842
pull_request: https://github.com/python/cpython/pull/18474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Tue Feb 11 22:52:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 03:52:53 +0000
Subject: [issue39605] Fix some casts to not cast away const
In-Reply-To: <1581396337.96.0.129945209612.issue39605@roundup.psfhosted.org>
Message-ID: <1581479573.55.0.650220303096.issue39605@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0b8f738eb3ee0110461e7da28c0b6b452f91999d by Miss Islington (bot) in branch '3.8':
bpo-39605: Remove a cast that causes a warning. (GH-18473)
https://github.com/python/cpython/commit/0b8f738eb3ee0110461e7da28c0b6b452f91999d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39605>
_______________________________________

From report at bugs.python.org  Wed Feb 12 02:02:38 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 12 Feb 2020 07:02:38 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1581490958.66.0.0567628298655.issue1812@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Wed Feb 12 02:09:21 2020
From: report at bugs.python.org (Amir Mohamadi)
Date: Wed, 12 Feb 2020 07:09:21 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581491361.12.0.0312404474271.issue39603@roundup.psfhosted.org>


Amir Mohamadi <amiremohamadi at yahoo.com> added the comment:

@vstinner sorry to bother you, I have a quick question.

the request(...) method is like this:

def request(self, method, url, body=None, headers={}, *,          
            encode_chunked=False):                                
    """Send a complete request to the server."""                  
    self._send_request(method, url, body, headers, encode_chunked)

'request' calls '_send_request' method and '_send_request' calls 'putrequest' inside itself.

So is it good if I encode 'method' parameter to ASCII inside 'putrequest'??!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Wed Feb 12 02:38:34 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Feb 2020 07:38:34 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581493114.44.0.697340834715.issue39599@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Julien Danjou]

> As you said, if it's not part of the stable ABI it makes sense.

I think this is a misunderstanding of what the stable ABI is for. I'm not sure whether this is spelled out explicitly anywhere, but my understanding was that ABI breakage shouldn't happen *at all* in bugfix releases, whether stable ABI or not.

The stable ABI is about feature releases within the Python 3.x series, not bugfix releases: that is, if your extension module limits itself to using the stable ABI, then a version of that module compiled for Python 3.7.x should still work for Python 3.8.x.

But lots of extension modules don't or can't restrict themselves to the stable ABI. For those modules, it should still be reasonable to expect that bugfix releases don't break the ABI: you should always be able to upgrade from Python 3.7.5 to Python 3.7.6 (for example) without having to recompile your extension modules.

Or am I misunderstanding?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Wed Feb 12 02:41:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 07:41:40 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581493300.89.0.574529980389.issue39474@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/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 02:46:54 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 12 Feb 2020 07:46:54 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581493614.55.0.502307310834.issue39599@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

https://github.com/python/cpython/blob/95905ce0f41fd42eb1ef60ddb83f057401c3d52f/Include/cpython/objimpl.h#L89

_Py_AS_GC and all APIs to get PyGC_Head from PyObject* are not only unstable, but also private.

I thought PyGC_Head must not be used directly from extensions, so we changed its layout.

Since Julien said "my code does not access PyGC_Head at all", I still think it was not real ABI breakage.

I suppose other serious bug (e.g. dungling pointer, missing refcount increment, etc) caused the segfault.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Wed Feb 12 02:57:00 2020
From: report at bugs.python.org (Carlos Velasco)
Date: Wed, 12 Feb 2020 07:57:00 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581494220.54.0.471649967215.issue1294959@roundup.psfhosted.org>


Change by Carlos Velasco <carlos.velasco at nimastelecom.com>:


----------
nosy: +carlos.velasco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 03:04:59 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 12 Feb 2020 08:04:59 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581494699.28.0.521462197622.issue39606@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
keywords: +patch
pull_requests: +17843
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Wed Feb 12 03:04:59 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 12 Feb 2020 08:04:59 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1581494699.48.0.458003201359.issue39386@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
pull_requests: +17844
pull_request: https://github.com/python/cpython/pull/18475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Wed Feb 12 03:04:59 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 12 Feb 2020 08:04:59 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1581494699.41.0.101295621182.issue39599@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> _Py_AS_GC and all APIs to get PyGC_Head from PyObject* are not only unstable, but also private.

Understood; thanks. I agree that there shouldn't be a guarantee for private undocumented calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Wed Feb 12 03:11:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 08:11:22 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581495082.79.0.781658020074.issue39474@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 03:52:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Feb 2020 08:52:07 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1581497527.49.0.507835522109.issue37373@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/issue37373>
_______________________________________

From report at bugs.python.org  Wed Feb 12 03:57:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 08:57:22 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581497842.61.0.567350387594.issue1294959@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 04:14:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 09:14:37 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581498877.57.0.874358718456.issue21016@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17845
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 04:14:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 09:14:37 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581498877.64.0.369560020298.issue1294959@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17846
pull_request: https://github.com/python/cpython/pull/18476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 04:17:06 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Feb 2020 09:17:06 +0000
Subject: [issue22213] Make pyvenv style virtual environments easier to
 configure when embedding Python
In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>
Message-ID: <1581499026.35.0.198200943826.issue22213@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I run into this issue when embedding CPython in a Windows app, and want to use some pre-installed Python, which is not part of the install package...

You'll run into many more issues if you keep doing this...

The way to use a pre-installed Python on Windows is to follow PEP 514 to find and run "python.exe" (or force your users to learn how to configure PATH, which is pretty hostile IMHO, but plenty of apps do it anyway).

If you really need to embed, then add the embeddable package (available from our downloads page) into your distribution and refer to that. Then you can also bundle whatever libraries you need and set up sys.path using the ._pth file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________

From report at bugs.python.org  Wed Feb 12 04:38:30 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Feb 2020 09:38:30 +0000
Subject: [issue37413] Deprecate sys._enablelegacywindowsfsencoding()
In-Reply-To: <1561562151.11.0.833046423852.issue37413@roundup.psfhosted.org>
Message-ID: <1581500310.54.0.183029162288.issue37413@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I think we can deprecate it but leave it there - the original idea (courtesy of Guido) was to enable apps to transition to the change on their timeline, but it certainly should not be considered a core CPython feature for the rest of time.

I don't have a problem with Mercurial using it, though. The risk was that libraries would use it, which is somewhat helped by the fact that it doesn't work reliably if you don't call it early enough :)

On the console encoding, I haven't heard of any issues either. Deprecating that environment variable is also fine, in my opinion.

Neither of these flags need to be their own special initialisation option. Embedders have always had other (better) ways to change these settings - unfortunately, PEP 587 didn't spend long enough gathering requirements before being implemented to avoid committing these design flaws...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37413>
_______________________________________

From report at bugs.python.org  Wed Feb 12 04:43:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Feb 2020 09:43:03 +0000
Subject: [issue36792] [Windows] time: crash on formatting time with de_DE
 locale
In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org>
Message-ID: <1581500583.66.0.446456825823.issue36792@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Will Python support a release for as long as it's supported by the enterprise version? For example, support for 1709 enterprise ends on 2020-04-14, so if we followed that, then Python 3.9 would require Windows 10 1803 or higher. That seems wrong while we're still supporting Windows 8.1, but what will the stance be when Python supports only Windows versions that use the modern lifecycle?

This needs a separate discussion on python-dev, but for issues like this I think it's fine to blame the underlying platform and recommend getting their updates. We don't have to work around every Windows bug for all time.

I'll read the rest of what's been happening on this issue when I'm less tired, but not quite up to it right now ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36792>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:03:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:03:55 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581501835.4.0.189854231228.issue39474@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17847
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18477

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:11:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:11:41 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581502301.27.0.402464514912.issue39567@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f4f445b69306c68a2ba8ce8eb8c6cb3064db5fe7 by Serhiy Storchaka in branch 'master':
bpo-39567: Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob(). (GH-18372)
https://github.com/python/cpython/commit/f4f445b69306c68a2ba8ce8eb8c6cb3064db5fe7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:11:55 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 10:11:55 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581502315.23.0.413975934614.issue39567@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17848
pull_request: https://github.com/python/cpython/pull/18478

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:17:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:17:07 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1581502627.95.0.830644255952.issue39219@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0cc6b5e559b8303b18fdd56c2befd900fe7b5e35 by Serhiy Storchaka in branch 'master':
bpo-39219: Fix SyntaxError attributes in the tokenizer. (GH-17828)
https://github.com/python/cpython/commit/0cc6b5e559b8303b18fdd56c2befd900fe7b5e35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:17:14 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 10:17:14 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1581502634.24.0.839987965444.issue39219@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17849
pull_request: https://github.com/python/cpython/pull/18479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:19:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:19:07 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1581502747.25.0.323375745307.issue32856@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8c579b1cc86053473eb052b76327279476740c9b by Serhiy Storchaka in branch 'master':
bpo-32856: Optimize the assignment idiom in comprehensions. (GH-16814)
https://github.com/python/cpython/commit/8c579b1cc86053473eb052b76327279476740c9b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32856>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:21:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:21:58 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581502918.4.0.447687999976.issue39567@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:22:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:22:26 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1581502946.04.0.296146207134.issue32856@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32856>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:35:14 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 10:35:14 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1581503714.58.0.855162246219.issue39219@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset efd878cdb46d9c7038d93fb36eb1ff7dc5baf9ec by Miss Islington (bot) in branch '3.8':
bpo-39219: Fix SyntaxError attributes in the tokenizer. (GH-17828)
https://github.com/python/cpython/commit/efd878cdb46d9c7038d93fb36eb1ff7dc5baf9ec


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:57:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 10:57:48 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1581505068.93.0.400753779086.issue39219@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Wed Feb 12 05:58:28 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 12 Feb 2020 10:58:28 +0000
Subject: [issue37685] Fix equality checks for some types
In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org>
Message-ID: <1581505108.67.0.423706315313.issue37685@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Unfortunately, we released 3.8.0, 3.8.1, and 3.8.2rc1 without this change. It seems too late in the release cycle to introduce this change. I'd feel better seeing it in 3.9 only. Sorry that we didn't act in time to include this in 3.8.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37685>
_______________________________________

From report at bugs.python.org  Wed Feb 12 06:05:08 2020
From: report at bugs.python.org (Amir Mohamadi)
Date: Wed, 12 Feb 2020 11:05:08 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581505508.85.0.143920568464.issue39603@roundup.psfhosted.org>


Change by Amir Mohamadi <amiremohamadi at yahoo.com>:


----------
keywords: +patch
pull_requests: +17850
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18480

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Wed Feb 12 06:33:07 2020
From: report at bugs.python.org (Floris Lambrechts)
Date: Wed, 12 Feb 2020 11:33:07 +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: <1581507187.85.0.351609816462.issue39090@roundup.psfhosted.org>


Floris Lambrechts <florisla at gmail.com> added the comment:

I've written an "Absolute paths" section based on the knowledge I found in the various threads.

Any review is appreciated.

https://github.com/florisla/cpython/tree/pathlib-chapter-absolute-paths

With some related documentation changes:

https://github.com/florisla/cpython/tree/absolute-path-related-improvements

----------
nosy: +florisla

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Wed Feb 12 06:38:54 2020
From: report at bugs.python.org (Paul Moore)
Date: Wed, 12 Feb 2020 11:38:54 +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: <1581507534.13.0.439659101028.issue39090@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

You've provided links to your branches, but not to the specific text you're proposing to add. Can you link to a diff or something that shows what you've added more precisely?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Wed Feb 12 06:43:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Feb 2020 11:43:47 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581507827.75.0.938621270759.issue39567@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Do these new audit events have to be documented?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Wed Feb 12 06:55:07 2020
From: report at bugs.python.org (Peter Eisentraut)
Date: Wed, 12 Feb 2020 11:55:07 +0000
Subject: [issue39615] cpython/abstract.h not compatible with C90
Message-ID: <1581508507.12.0.731337298421.issue39615@roundup.psfhosted.org>


New submission from Peter Eisentraut <peter at eisentraut.org>:

Some inline functions use mixed declarations and code.  These end up visible in third-party code that includes Python.h, which might not be using a C99 compiler.

Example:

In file included from /Users/peter/python-builds/3.9/include/python3.9/abstract.h:843,
                 from /Users/peter/python-builds/3.9/include/python3.9/Python.h:147,
                 from plpython.h:59,
                 from plpy_typeio.h:10,
                 from plpy_cursorobject.h:8,
                 from plpy_cursorobject.c:14:
/Users/peter/python-builds/3.9/include/python3.9/cpython/abstract.h:74:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   74 |     Py_ssize_t offset = tp->tp_vectorcall_offset;
      |     ^~~~~~~~~~

----------
components: Interpreter Core
messages: 361880
nosy: petere
priority: normal
severity: normal
status: open
title: cpython/abstract.h not compatible with C90
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39615>
_______________________________________

From report at bugs.python.org  Wed Feb 12 06:55:33 2020
From: report at bugs.python.org (Peter Eisentraut)
Date: Wed, 12 Feb 2020 11:55:33 +0000
Subject: [issue39615] cpython/abstract.h not compatible with C90
In-Reply-To: <1581508507.12.0.731337298421.issue39615@roundup.psfhosted.org>
Message-ID: <1581508533.96.0.865715527307.issue39615@roundup.psfhosted.org>


Change by Peter Eisentraut <peter at eisentraut.org>:


----------
keywords: +patch
pull_requests: +17851
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18481

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39615>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:02:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 12:02:42 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581508962.06.0.762259506342.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd by Victor Stinner in branch 'master':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:02:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 12:02:42 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581508961.95.0.384984182924.issue21016@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd by Victor Stinner in branch 'master':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd


----------
message_count: 1.0 -> 2.0
nosy: +vstinner
nosy_count: 1.0 -> 2.0
pull_requests: +17853
pull_request: https://github.com/python/cpython/pull/18482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:02:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 12:02:41 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581508961.95.0.384984182924.issue21016@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd by Victor Stinner in branch 'master':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/4fac7ed43ebf1771a8fe86fdfe7b9991f3be78cd


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:02:42 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:02:42 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581508962.49.0.249098029153.issue1294959@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17854
pull_request: https://github.com/python/cpython/pull/18482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:02:49 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:02:49 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581508969.24.0.537176609226.issue1294959@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17856
pull_request: https://github.com/python/cpython/pull/18483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:02:49 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:02:49 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581508969.17.0.419427179449.issue21016@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17855
pull_request: https://github.com/python/cpython/pull/18483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:03:29 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 12 Feb 2020 12:03:29 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581509009.55.0.156022796635.issue39567@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yes, they should be.

They can also be backported to 3.8 - it was deliberate in the original PEP that adding new events is not a breaking change or a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:15:42 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 12 Feb 2020 12:15:42 +0000
Subject: [issue39615] cpython/abstract.h not compatible with C90
In-Reply-To: <1581508507.12.0.731337298421.issue39615@roundup.psfhosted.org>
Message-ID: <1581509742.94.0.187589070035.issue39615@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

PEP 7 says that this is allowed:

Python versions greater than or equal to 3.6 use C89 with several select C99 features:
...
- intermingled declarations

So I don't think these changes should be accepted.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39615>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:18:46 2020
From: report at bugs.python.org (Floris Lambrechts)
Date: Wed, 12 Feb 2020 12:18:46 +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: <1581509926.02.0.364171457259.issue39090@roundup.psfhosted.org>


Floris Lambrechts <florisla at gmail.com> added the comment:

This is the new chapter:

https://github.com/florisla/cpython/commit/c146ad3d086fe9e401284c12fc670ea4f9398f3b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:22:24 2020
From: report at bugs.python.org (Maximilian Peters)
Date: Wed, 12 Feb 2020 12:22:24 +0000
Subject: [issue29620] unittest.TestCase.assertWarns raises RuntimeEror if
 sys.modules changes size
In-Reply-To: <1487780571.93.0.503711972358.issue29620@psf.upfronthosting.co.za>
Message-ID: <1581510144.13.0.177347815883.issue29620@roundup.psfhosted.org>


Maximilian Peters <peters.maximilian at gmail.com> added the comment:

Ran into the same issue using Python 3.6.8 [GCC 5.4.0 20160609] on Linux.

The same code worked on Windows 10 with Python 3.7 32-bit and 64-bit.

----------
nosy: +Maximilian Peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29620>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:32:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:32:53 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581510773.66.0.593551738572.issue1294959@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca133e53fafdec1aa77613fcb7558deed959383f by Miss Islington (bot) in branch '3.7':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/ca133e53fafdec1aa77613fcb7558deed959383f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:32:53 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:32:53 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581510773.55.0.290390262538.issue21016@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca133e53fafdec1aa77613fcb7558deed959383f by Miss Islington (bot) in branch '3.7':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/ca133e53fafdec1aa77613fcb7558deed959383f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:32:58 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:32:58 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581510778.03.0.625016875239.issue21016@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ac6f4d2db703c0ff88e496bcb7b7fe55cf2ac458 by Miss Islington (bot) in branch '3.8':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/ac6f4d2db703c0ff88e496bcb7b7fe55cf2ac458


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:32:58 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 12:32:58 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581510778.09.0.0225252373459.issue1294959@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ac6f4d2db703c0ff88e496bcb7b7fe55cf2ac458 by Miss Islington (bot) in branch '3.8':
bpo-21016: pydoc and trace use sysconfig (GH-18476)
https://github.com/python/cpython/commit/ac6f4d2db703c0ff88e496bcb7b7fe55cf2ac458


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:33:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 12:33:38 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581510818.16.0.946682968983.issue21016@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Ben Boeckel for the bugfix. Sorry for the delay (6 years)! But it's now fixed in 3.7, 3.8 and master branches.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:37:07 2020
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 12 Feb 2020 12:37:07 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
Message-ID: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>


New submission from Ville Skytt? <ville.skytta at iki.fi>:

Doc says "Whether to match the peer cert?s hostname with match_hostname() in SSLSocket.do_handshake()." but match_hostname() is no longer used to do that in the first place, OpenSSL is used for that. check_hostname affects the OpenSSL usage, too.

----------
assignee: docs at python
components: Documentation
messages: 361892
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: SSLContext.check_hostname description is inaccurate wrt match_hostname
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Wed Feb 12 07:39:13 2020
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Wed, 12 Feb 2020 12:39:13 +0000
Subject: [issue39616] SSLContext.check_hostname description is inaccurate wrt
 match_hostname
In-Reply-To: <1581511027.29.0.201714121734.issue39616@roundup.psfhosted.org>
Message-ID: <1581511153.41.0.840272447202.issue39616@roundup.psfhosted.org>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
keywords: +patch
pull_requests: +17857
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18484

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39616>
_______________________________________

From report at bugs.python.org  Wed Feb 12 08:48:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 13:48:31 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581515311.81.0.904019231977.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Summary:

* This issue is mostly about pushing a 16-years old patch from Fedora and SuSE to Python upstream. Other Linux distributions use different solutions to support multiple architectures in the same filesystem. For example, Debian and Ubuntu uses "Multiarch" which continues to use /usr/lib/ for 32-bit and 64-bit x86 architecture (x86 and x86-64).

* I pushed the non controversial part of PR 3698: fix pydoc and trace modules to use sysconfig to get the stdlib path

* CI tests pass on PR 18381.

* Matthias Klose asked to not add another sys attribute, but Jan Mat?jek explained that the option value is needed to import the sysconfig module. Moreover, the option value is needed in the site module and we are trying to avoid "import sysconfig" in site since it would slowdown Python startup time.

* I chose "./configure --with-python-libdir" and "sys.python_libdir" names. PR 3698 uses "./configure --with-custom-platsubdir" and sysconfig.get_config_var('platsubdir') names. Other proposed names: sys.lib, os.lib_dir. It was proposed to drop "custom" from "./configure --with-custom-platsubdir" option name.

Python use many paths. The sysconfig module is a good starting point to discover them all in the _INSTALL_SCHEMES directories. PR 18381 changes the following paths:

* posix_prefix: stdlib, platstdlib, platlib
* posix_user: stdlib, platstdlib, platlib


Examples on Fedora:

* pure Python: /usr/lib64/python3.7/os.py
* C extension: /usr/lib64/python3.7/lib-dynload/_multiprocessing.cpython-37m-x86_64-linux-gnu.so

Examples on SuSE:

* pure Python: /usr/lib64/python3.7/os.py

Ubuntu 16.04:

* pure Python: /usr/lib/python3.5/os.py
* C extension: /usr/lib/python3.5/lib-dynload/_multiprocessing.cpython-35m-x86_64-linux-gnu.so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 08:52:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 13:52:08 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581515528.78.0.988700827728.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Default with prefix=/usr:

* posix_prefix:

  * stdlib: '/usr/lib/python3.9'
  * platstdlib: '/usr/lib/python3.9'
  * platlib: '/usr/lib/python3.9/site-packages'
 
* posix_user:

  * stdlib: '~/.local/lib/python3.9'
  * platstdlib: '~/.local/lib/python3.9'
  * platlib: '~/.local/lib/python3.9/site-packages'

Customized with prefix=/usr and python_libdir=lib64, PR 18381:

* posix_prefix:

  * stdlib: '/usr/lib64/python3.9'
  * platstdlib: '/usr/lib64/python3.9'
  * platlib: '/usr/lib64/python3.9/site-packages'

* posix_user:

  * stdlib: '~/.local/lib64/python3.9'
  * platstdlib: '~/.local/lib64/python3.9'
  * platlib: '~/.local/lib64/python3.9/site-packages'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 08:54:56 2020
From: report at bugs.python.org (Amir Mohamadi)
Date: Wed, 12 Feb 2020 13:54:56 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581515696.53.0.864380445047.issue39603@roundup.psfhosted.org>


Change by Amir Mohamadi <amiremohamadi at yahoo.com>:


----------
pull_requests: +17858
pull_request: https://github.com/python/cpython/pull/18485

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Wed Feb 12 09:09:28 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 12 Feb 2020 14:09:28 +0000
Subject: [issue25753] Reference leaks in test_smtplib
In-Reply-To: <1448660464.47.0.968238224363.issue25753@psf.upfronthosting.co.za>
Message-ID: <1581516568.32.0.516456056581.issue25753@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

+1 for me to close this issue.
On the master branch, this issue is not reproducible.
I am closing this issue, if someone wants to open this issue, please re-open this :)

----------
nosy: +corona10
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25753>
_______________________________________

From report at bugs.python.org  Wed Feb 12 09:31:44 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 12 Feb 2020 14:31:44 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581517904.95.0.041768921362.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17859
pull_request: https://github.com/python/cpython/pull/18486

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Feb 12 09:35:43 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 12 Feb 2020 14:35:43 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1581518143.29.0.383776125947.issue39603@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Welcome to work on the patch, Amir.

* We shouldn't be encoding anything.
* Create reject for Unicode control characters and reject the request if the request contains any control character. Write tests for this.

It will similar to one of the examples Victor has shared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Wed Feb 12 09:49:16 2020
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 12 Feb 2020 14:49:16 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581518956.34.0.704223636989.issue1294959@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

> posix_user:
> 
> * stdlib: '~/.local/lib64/python3.9'
> * platstdlib: '~/.local/lib64/python3.9'
> * platlib: '~/.local/lib64/python3.9/site-packages'

I am still not sure about the this one. I know that I have mentioned a possibility of multiplatform $HOME on NFS, but it seems too far fetched idea to break the current not-completely-standard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 09:54:41 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 12 Feb 2020 14:54:41 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581519281.55.0.74114101354.issue1294959@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Also note that the extension modules have archful suffix, so they will not collide in $HOME, unless they are installed as name.so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 09:54:38 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 12 Feb 2020 14:54:38 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581519278.06.0.417418318685.issue39474@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> Are you going to work on a patch then, Batuhan?

Serhiy already submitted a PR, which looks great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 10:12:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 15:12:11 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581520331.95.0.93440827256.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> posix_user:
> 
> * stdlib: '~/.local/lib64/python3.9'
> * platstdlib: '~/.local/lib64/python3.9'
> * platlib: '~/.local/lib64/python3.9/site-packages'

Honestly, I have no idea how posix_user is used.

~/.local/lib64/ directory doesn't exist on my work machine, whereas I'm installed various Python modules and applications.

In practice, ~/.local/lib/ is used on Fedora, even if posix_user scheme uses ~/.local/lib64/. Examples:

* pure Python: ~/.local/lib/python3.7/site-packages/pip/__main__.py
* C extension: ~/.local/lib/python3.7/site-packages/typed_ast/_ast3.cpython-37m-x86_64-linux-gnu.so

So changing posix_user should have no impact on end users.


I also tested a legacy "python3 setup.py install" to install a C extension, it also lands into ~/.local/lib:

~/.local/lib/python3.7/site-packages/test_cext-0.0.0-py3.7-linux-x86_64.egg/test_cext.cpython-37m-x86_64-linux-gnu.so

The setup.py uses setuptools.


Miro:
> Also note that the extension modules have archful suffix, so they will not collide in $HOME, unless they are installed as name.so.

Yeah, it seems like pip install adopted Debian multiarch naming: "x86_64-linux-gnu" triplet in "_ast3.cpython-37m-x86_64-linux-gnu.so" filename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 10:20:17 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 12 Feb 2020 15:20:17 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581520817.53.0.856906797332.issue1294959@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

> > Also note that the extension modules have archful suffix, so they will not collide in $HOME, unless they are installed as name.so.
> 
> Yeah, it seems like pip install adopted Debian multiarch naming: "x86_64-linux-gnu" triplet in "_ast3.cpython-37m-x86_64-linux-gnu.so" filename.

For reference: issue22980

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 10:28:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 15:28:07 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581521287.75.0.267977918855.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

SuSE currently uses this patch for lib64 in the Python 3 package:
https://build.opensuse.org/package/view_file/devel:languages:python:Factory/python3/F00102-lib64.patch?expand=1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 10:31:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 15:31:30 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581521490.44.0.294302534419.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ooops, SuSE has 2 patches.

SuSE currently uses these patches for lib64 in the Python 3 package:

(1) https://build.opensuse.org/package/view_file/devel:languages:python:Factory/python3/F00102-lib64.patch?expand=1

(2) https://build.opensuse.org/package/view_file/devel:languages:python:Factory/python3/SUSE-FEDORA-multilib.patch?expand=1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 10:36:10 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 12 Feb 2020 15:36:10 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581521770.64.0.633795434758.issue39573@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

FYI, I am working on to add Py_IS_TYPE macro. :)

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Wed Feb 12 10:42:42 2020
From: report at bugs.python.org (Daniel Bengtsson)
Date: Wed, 12 Feb 2020 15:42:42 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1581522162.18.0.974512091771.issue24916@roundup.psfhosted.org>


Change by Daniel Bengtsson <dbengt at redhat.com>:


----------
pull_requests: +17860
pull_request: https://github.com/python/cpython/pull/18487

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Wed Feb 12 11:54:09 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 12 Feb 2020 16:54:09 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581526449.56.0.471219019262.issue39573@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17861
pull_request: https://github.com/python/cpython/pull/18488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Wed Feb 12 12:21:04 2020
From: report at bugs.python.org (sds)
Date: Wed, 12 Feb 2020 17:21:04 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
Message-ID: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>


New submission from sds <sds at gnu.org>:

The number of workers (max_workers) I want to use often depends on the server load.
Imagine this scenario: I have 64 CPUs and I need to run 200 processes.
However, others are using the server too, so currently loadavg is 50, thus I will set `max_workers` to (say) 20. 
But 2 hours later when those 20 processes are done, loadavg is now 0 (because the 50 processes run by my colleagues are done too), so I want to increase the pool size max_workers to 70.
It would be nice if it were possible to adjust the pool size depending on the server loadavg when a worker is started.
Basically, the intent is maintaining a stable load average and full resource utilization.

----------
components: Library (Lib)
messages: 361905
nosy: sam-s
priority: normal
severity: normal
status: open
title: max_workers argument to concurrent.futures.ProcessPoolExecutor is not flexible enough
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Wed Feb 12 12:25:17 2020
From: report at bugs.python.org (sds)
Date: Wed, 12 Feb 2020 17:25:17 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
In-Reply-To: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>
Message-ID: <1581528317.83.0.844595200199.issue39617@roundup.psfhosted.org>


sds <sds at gnu.org> added the comment:

cf https://github.com/joblib/joblib/issues/1006

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Wed Feb 12 12:50:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 17:50:19 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581529819.89.0.869625476255.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

lib64_tests.py: test suite hardcoded for Fedora, SuSE and PR 18381 with --with-python-libdir=lib64. I wrote it to help me to understand differences between Fedora, SuSE and PR 18381.

On Fedora, the test fails because we have an additional patch on distutils to install packages in /usr/local instead of /usr when using pip:

======================================================================
FAIL: test_distutils_install (__main__.Lib64Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "lib64_tests.py", line 81, in test_distutils_install
    self.assertEqual(cmd.install_platlib, PLATLIB)
AssertionError: '/usr/local/lib64/python3.7/site-packages' != '/usr/lib64/python3.7/site-packages'
- /usr/local/lib64/python3.7/site-packages
?     ------
+ /usr/lib64/python3.7/site-packages

----------
Added file: https://bugs.python.org/file48892/lib64_tests.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 12:56:31 2020
From: report at bugs.python.org (Denis Vieira)
Date: Wed, 12 Feb 2020 17:56:31 +0000
Subject: [issue39618] logger.exception with default message
Message-ID: <1581530191.64.0.316604727727.issue39618@roundup.psfhosted.org>


New submission from Denis Vieira <deniswvieira at gmail.com>:

On my Python projects i like to use the logger.exception() method without any other message. 

I'm forced to send an empty string on every call.
logger.exception('')

It would be nice the exception method have the expected parameter "msg" with an default value ('').

----------
messages: 361908
nosy: Denis Vieira
priority: normal
severity: normal
status: open
title: logger.exception with default message
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39618>
_______________________________________

From report at bugs.python.org  Wed Feb 12 13:04:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 18:04:46 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581530686.63.0.23657082896.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Links on Debian Multiarch:

* https://wiki.debian.org/Multiarch/HOWTO
* https://lwn.net/Articles/711199/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 13:13:43 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 12 Feb 2020 18:13:43 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1581531223.26.0.147233703782.issue1294959@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Wed Feb 12 13:42:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 12 Feb 2020 18:42:16 +0000
Subject: [issue39618] logger.exception with default message
In-Reply-To: <1581530191.64.0.316604727727.issue39618@roundup.psfhosted.org>
Message-ID: <1581532936.85.0.270267103033.issue39618@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39618>
_______________________________________

From report at bugs.python.org  Wed Feb 12 14:53:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 19:53:01 +0000
Subject: [issue24916] In sysconfig, don't rely on sys.version format
In-Reply-To: <1440265954.47.0.288307978254.issue24916@psf.upfronthosting.co.za>
Message-ID: <1581537181.68.0.119219679288.issue24916@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The "py_version" variable of sysconfig is discussed since 2015 but... it's unused. It is supposed to build paths. Does it really make sense to build a path which contains "+"? It can confuse some application which may associate a special meaning to "+".

What about simply removing this variable? Does anyone know if it's used in the wild?

To me it sounds surprising to have a different path for alpha, beta and release candidate releases. Usually, Python paths only contain MAJOR.MINOR versions, no alpha, beta or rc marker. Nor "+" marker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24916>
_______________________________________

From report at bugs.python.org  Wed Feb 12 14:56:09 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 12 Feb 2020 19:56:09 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1581537369.74.0.385338391874.issue18819@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 674935b8caf33e47c78f1b8e197b1b77a04992d2 by William Chargin in branch 'master':
bpo-18819: tarfile: only set device fields for device files (GH-18080)
https://github.com/python/cpython/commit/674935b8caf33e47c78f1b8e197b1b77a04992d2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:25:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 20:25:09 +0000
Subject: [issue35081] Move internal headers to Include/internal/
In-Reply-To: <1540600944.05.0.788709270274.issue35081@psf.upfronthosting.co.za>
Message-ID: <1581539109.18.0.58643410127.issue35081@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17862
pull_request: https://github.com/python/cpython/pull/18489

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35081>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:33:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 20:33:22 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581539602.16.0.220766159378.issue35134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17863
pull_request: https://github.com/python/cpython/pull/18490

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:35:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 20:35:36 +0000
Subject: [issue37685] Fix equality checks for some types
In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org>
Message-ID: <1581539736.8.0.451075413183.issue37685@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you ?ukasz. I considered this as a bug fix, but was not sure that we should fix these bugs. They were here from the beginning.

Josh, as for using total_ordering, I think it is a different issue. I did not want to change the behavior except fixing bugs (and raising an error or not supporting comparison with objects which support comparison when used at LHS looks like a bug). Feel free to open separate issues for using total_ordering or changing its semantic.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37685>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:37:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Feb 2020 20:37:53 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581539873.56.0.125012027051.issue39474@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6e619c48b8e804ece9521453fc8da0640a04d5b1 by Serhiy Storchaka in branch 'master':
bpo-39474: Fix AST pos for expressions like (a)(b), (a)[b] and (a).b. (GH-18477)
https://github.com/python/cpython/commit/6e619c48b8e804ece9521453fc8da0640a04d5b1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:38:18 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 20:38:18 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581539898.26.0.29497386715.issue39474@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17864
pull_request: https://github.com/python/cpython/pull/18491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:41:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 20:41:25 +0000
Subject: [issue35081] Move internal headers to Include/internal/
In-Reply-To: <1540600944.05.0.788709270274.issue35081@psf.upfronthosting.co.za>
Message-ID: <1581540085.17.0.631794576021.issue35081@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17865
pull_request: https://github.com/python/cpython/pull/18492

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35081>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:44:31 2020
From: report at bugs.python.org (Zsolt Dollenstein)
Date: Wed, 12 Feb 2020 20:44:31 +0000
Subject: [issue39613] IsolatedAsyncioTestCase closes default event loop
In-Reply-To: <1581450697.14.0.885131821456.issue39613@roundup.psfhosted.org>
Message-ID: <1581540271.75.0.324986654921.issue39613@roundup.psfhosted.org>


Change by Zsolt Dollenstein <zsol.zsol at gmail.com>:


----------
nosy: +zsol

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39613>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:50:01 2020
From: report at bugs.python.org (Peter Eisentraut)
Date: Wed, 12 Feb 2020 20:50:01 +0000
Subject: [issue39615] cpython/abstract.h not compatible with C90
In-Reply-To: <1581508507.12.0.731337298421.issue39615@roundup.psfhosted.org>
Message-ID: <1581540601.89.0.588621868435.issue39615@roundup.psfhosted.org>


Peter Eisentraut <peter at eisentraut.org> added the comment:

That's fair for code internal to CPython itself, but these are header files included by third-party code that is embedding Python, so a bit more flexibility and adaptability would be welcome there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39615>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:56:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 12 Feb 2020 20:56:06 +0000
Subject: [issue39615] cpython/abstract.h not compatible with C90
In-Reply-To: <1581508507.12.0.731337298421.issue39615@roundup.psfhosted.org>
Message-ID: <1581540966.44.0.82979293417.issue39615@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'd suggest mentioning this on python-dev, if you want to change the policy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39615>
_______________________________________

From report at bugs.python.org  Wed Feb 12 15:56:50 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Feb 2020 20:56:50 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581541010.38.0.810376163518.issue39474@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2076d4f97ef514bb4dc4ca768fbaa3f538ce7f1f by Miss Islington (bot) in branch '3.8':
bpo-39474: Fix AST pos for expressions like (a)(b), (a)[b] and (a).b. (GH-18477)
https://github.com/python/cpython/commit/2076d4f97ef514bb4dc4ca768fbaa3f538ce7f1f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 16:32:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 21:32:37 +0000
Subject: [issue35081] Move internal headers to Include/internal/
In-Reply-To: <1540600944.05.0.788709270274.issue35081@psf.upfronthosting.co.za>
Message-ID: <1581543157.76.0.91134821909.issue35081@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 45876a90e2663f12b90c2090ec3e48bd97841aae by Victor Stinner in branch 'master':
bpo-35081: Move bytes_methods.h to the internal C API (GH-18492)
https://github.com/python/cpython/commit/45876a90e2663f12b90c2090ec3e48bd97841aae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35081>
_______________________________________

From report at bugs.python.org  Wed Feb 12 16:42:52 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Wed, 12 Feb 2020 21:42:52 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1581543772.57.0.362292453114.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

Version 0.2.0 of the BLAKE3 repo includes optimized assembly implementations. These are behind the "c" Cargo feature for the `blake3` Rust crate, but included by default for the internal bindings crate. So the easiest way to rerun our favorite benchmark is:

git clone https://github.com/BLAKE3-team/BLAKE3
cd BLAKE3
git fetch
# I rebased this branch on top of version 0.2.0 today.
git checkout origin/bench_406668786
cd c/blake3_c_rust_bindings
# Nightly is currently broken for unrelated reasons, so
# we use stable with this internal bootstrapping flag.
RUSTC_BOOTSTRAP=1 cargo bench 406668786

Running the above on my machine, I get 2888 MB/s, up another 12% from the 0.1.3 numbers. As a bonus, we don't need to worry about the difference between GCC and Clang.

These new assembly files are essentially drop-in replacements for the instruction-set-specific C files we had before, which are also still supported. The updated C README has more details: https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.md

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Wed Feb 12 16:54:32 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Feb 2020 21:54:32 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1581544472.1.0.272667298855.issue39474@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Wed Feb 12 16:54:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 21:54:52 +0000
Subject: [issue35081] Move internal headers to Include/internal/
In-Reply-To: <1540600944.05.0.788709270274.issue35081@psf.upfronthosting.co.za>
Message-ID: <1581544492.71.0.025358694716.issue35081@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e9e7d284c434768333fdfb53a3663eae74cb995a by Victor Stinner in branch 'master':
bpo-35081: Move dtoa.h header to the internal C API (GH-18489)
https://github.com/python/cpython/commit/e9e7d284c434768333fdfb53a3663eae74cb995a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35081>
_______________________________________

From report at bugs.python.org  Wed Feb 12 17:08:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 22:08:48 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581545328.15.0.603195024202.issue35134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17866
pull_request: https://github.com/python/cpython/pull/18493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Wed Feb 12 17:25:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 22:25:52 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581546352.45.0.101315676002.issue35134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17867
pull_request: https://github.com/python/cpython/pull/18494

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Wed Feb 12 17:33:53 2020
From: report at bugs.python.org (Ian Norton)
Date: Wed, 12 Feb 2020 22:33:53 +0000
Subject: [issue39619] os.chroot is not enabled on HP-UX builds
Message-ID: <1581546833.04.0.518216269375.issue39619@roundup.psfhosted.org>


New submission from Ian Norton <inorton at gmail.com>:

When building on HP-UX using:

The configure stage fails to detect chroot().  This is due to setting  _XOPEN_SOURCE to a value higher than 500.

The fix for this is to not set _XOPEN_SOURCE when configuring for HP-UX

----------
components: Interpreter Core
messages: 361921
nosy: Ian Norton
priority: normal
severity: normal
status: open
title: os.chroot is not enabled on HP-UX builds
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39619>
_______________________________________

From report at bugs.python.org  Wed Feb 12 17:36:04 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 12 Feb 2020 22:36:04 +0000
Subject: [issue39619] os.chroot is not enabled on HP-UX builds
In-Reply-To: <1581546833.04.0.518216269375.issue39619@roundup.psfhosted.org>
Message-ID: <1581546964.47.0.571898692283.issue39619@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17868
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18495

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39619>
_______________________________________

From report at bugs.python.org  Wed Feb 12 17:54:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 22:54:34 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581548074.84.0.509101578786.issue35134@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 98921aeaf5879b51e2dd1870c9285cfa8d1a52c7 by Victor Stinner in branch 'master':
bpo-35134: Add Include/cpython/bytesobject.h file (GH-18494)
https://github.com/python/cpython/commit/98921aeaf5879b51e2dd1870c9285cfa8d1a52c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Wed Feb 12 17:55:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 12 Feb 2020 22:55:13 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1581548113.35.0.102565085712.issue35134@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8c3aee65ed3aff3668da330ccd6f9ba7b2aa4567 by Victor Stinner in branch 'master':
bpo-35134: Add Include/cpython/fileutils.h header file (GH-18493)
https://github.com/python/cpython/commit/8c3aee65ed3aff3668da330ccd6f9ba7b2aa4567


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Wed Feb 12 18:06:19 2020
From: report at bugs.python.org (Davin Potts)
Date: Wed, 12 Feb 2020 23:06:19 +0000
Subject: [issue39584] multiprocessing.shared_memory: MacOS crashes by running
 attached Python code
In-Reply-To: <1581171504.91.0.0818206259105.issue39584@roundup.psfhosted.org>
Message-ID: <1581548779.62.0.344449413665.issue39584@roundup.psfhosted.org>


Davin Potts <python at discontinuity.net> added the comment:

My sense is that it would be nice if we can catch this before ftruncate does something nasty.

Where else is ftruncate used in CPython that this could similarly trigger a problem?  How is it handled there (or not)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39584>
_______________________________________

From report at bugs.python.org  Wed Feb 12 19:57:10 2020
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 13 Feb 2020 00:57:10 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1581555430.5.0.703351803308.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Personally I'm enjoying these BLAKE3 status updates, and I wouldn't mind at all being kept up-to-date during BLAKE3's development via messages on this issue.  But, given the tenor of the conversation so far, I'm guessing Python is gonna hold off until BLAKE3 reaches 1.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Wed Feb 12 20:21:24 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Feb 2020 01:21:24 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1581556883.99.0.62382675911.issue1812@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Allow me to ask a maybe very naive question:

Wouldn't it be possible to fix the problem at the source, that is, use `open(filename, "rU")` in the two spots you found rather than doing ad-hoc line ending translation?

(I get that the second one uses `rb` at the moment, so switching from bytes to str is not just a one-liner there)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Wed Feb 12 20:25:34 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 13 Feb 2020 01:25:34 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1581557134.1.0.590525129364.issue1812@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I got it wrong, get_data itself uses `rb`, not default `r`.
It makes sense given that package data could be any kind of file, not necessarily text.  Too bad there isn?t a `get_text(encoding)` method in the loader API!

With Python 3?s rich IO system, isn?t there a quick and correct way to get a text file from a bytes stream?  TextIOWrapper?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Wed Feb 12 20:43:16 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 13 Feb 2020 01:43:16 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581558196.36.0.301092239255.issue39573@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +17870
pull_request: https://github.com/python/cpython/pull/18496

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Wed Feb 12 21:00:28 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Feb 2020 02:00:28 +0000
Subject: [issue39615] cpython/abstract.h not compatible with C90
In-Reply-To: <1581508507.12.0.731337298421.issue39615@roundup.psfhosted.org>
Message-ID: <1581559228.92.0.368232730439.issue39615@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

C99 is not disallowed in headers.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39615>
_______________________________________

From report at bugs.python.org  Wed Feb 12 22:23:38 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 13 Feb 2020 03:23:38 +0000
Subject: [issue39620] PyObject_GetAttrString and tp_getattr do not agree
Message-ID: <1581564218.88.0.011311131475.issue39620@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

PyObject_GetAttrString(PyObject *v, const char *name)

typedef PyObject *(*getattrfunc)(PyObject *, char *)

The outer PyObject_GetAttrString takes a const char *name, but then casts away the const when calling the underlying tp_getattr.  This means that an underlying function would be free to modify or free() the char* passed in to it, which might be, for example, a string literal, which would be a Bad Thing.

The setattr function pair has the same problem.

The API doc at https://docs.python.org/3/c-api/typeobj.html says that the tp_getattr and tp_setattr slots are deprecated.  If they're not going away soon, I would think this should be addressed.

Fixing this in the cPython code by making tp_getattr and tp_setattr take const char * pointers would be simple.  I don't have any idea how much outside code it would affect.

----------
components: C API
messages: 361929
nosy: petdance
priority: normal
severity: normal
status: open
title: PyObject_GetAttrString and tp_getattr do not agree
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39620>
_______________________________________

From report at bugs.python.org  Wed Feb 12 22:34:12 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 13 Feb 2020 03:34:12 +0000
Subject: [issue39620] PyObject_GetAttrString and tp_getattr do not agree
In-Reply-To: <1581564218.88.0.011311131475.issue39620@roundup.psfhosted.org>
Message-ID: <1581564852.58.0.135490030478.issue39620@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Note that there was an earlier attempt to make it const
https://github.com/python/cpython/commit/af68c874a6803b4e90b616077a602c0593719a1d

but this was reverted as part of https://github.com/python/cpython/commit/15e62742fad688b026ba80bf17d1345c4cbd423b

----------
nosy: +ammar2, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39620>
_______________________________________

From report at bugs.python.org  Wed Feb 12 22:47:18 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 13 Feb 2020 03:47:18 +0000
Subject: [issue39620] PyObject_GetAttrString and tp_getattr do not agree
In-Reply-To: <1581564218.88.0.011311131475.issue39620@roundup.psfhosted.org>
Message-ID: <1581565638.73.0.015532814462.issue39620@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Do you know why it was reverted?  (Granted, it was 15 years ago...)

It looks like the original changeset is trying to address at least two different problems with non-const string literals.  My ticket here is focusing only on getattrfunc and setattrfunc.  The handling of all the kwlist is a separate issue, that I'm about to write up as a different ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39620>
_______________________________________

From report at bugs.python.org  Wed Feb 12 23:05:21 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 13 Feb 2020 04:05:21 +0000
Subject: [issue39621] md5_compress() in Modules/md5module.c can take a const
 buf
Message-ID: <1581566721.26.0.324789449334.issue39621@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

The function md5_compress does not modify its buffer argument.

static void md5_compress(struct md5_state *md5, unsigned char *buf)

buf should be const.

----------
components: Extension Modules
messages: 361932
nosy: petdance
priority: normal
severity: normal
status: open
title: md5_compress() in Modules/md5module.c can take a const buf
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39621>
_______________________________________

From report at bugs.python.org  Wed Feb 12 23:08:54 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 13 Feb 2020 04:08:54 +0000
Subject: [issue39621] md5_compress() in Modules/md5module.c can take a const
 buf
In-Reply-To: <1581566721.26.0.324789449334.issue39621@roundup.psfhosted.org>
Message-ID: <1581566934.95.0.506294390895.issue39621@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17871
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18497

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39621>
_______________________________________

From report at bugs.python.org  Wed Feb 12 23:42:07 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Thu, 13 Feb 2020 04:42:07 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581568927.72.0.815967961089.issue39601@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I can't help with the issue itself (though I must say that I philosophically don't believe in "sailed off ships" -- in the limit, Python must be the best it can be, though it can take decades to get there), but I can help you with the error message. It simply tries to take {{x}} as your v (expression to be formatted). That is, a set containing a set containing x. But since sets themselves are not hashable (being mutable), they cannot be contained in sets (that's why frozensets were invented).

>>> {{4}}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'set'

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Wed Feb 12 23:53:08 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Feb 2020 04:53:08 +0000
Subject: [issue39621] md5_compress() in Modules/md5module.c can take a const
 buf
In-Reply-To: <1581566721.26.0.324789449334.issue39621@roundup.psfhosted.org>
Message-ID: <1581569588.18.0.296507590734.issue39621@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 597ebed748d0b0c061f8c108bd98270d103286c1 by Andy Lester in branch 'master':
closes bpo-39621: Make buf arg to md5_compress be const. (GH-18497)
https://github.com/python/cpython/commit/597ebed748d0b0c061f8c108bd98270d103286c1


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39621>
_______________________________________

From report at bugs.python.org  Wed Feb 12 23:53:20 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 04:53:20 +0000
Subject: [issue39621] md5_compress() in Modules/md5module.c can take a const
 buf
In-Reply-To: <1581566721.26.0.324789449334.issue39621@roundup.psfhosted.org>
Message-ID: <1581569600.52.0.252392318198.issue39621@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17872
pull_request: https://github.com/python/cpython/pull/18498

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39621>
_______________________________________

From report at bugs.python.org  Thu Feb 13 00:12:56 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 05:12:56 +0000
Subject: [issue39621] md5_compress() in Modules/md5module.c can take a const
 buf
In-Reply-To: <1581566721.26.0.324789449334.issue39621@roundup.psfhosted.org>
Message-ID: <1581570776.68.0.0533574945612.issue39621@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 669981b3b14dd16dec42089d6ac8d6449fde8abd by Miss Islington (bot) in branch '3.8':
closes bpo-39621: Make buf arg to md5_compress be const. (GH-18497)
https://github.com/python/cpython/commit/669981b3b14dd16dec42089d6ac8d6449fde8abd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39621>
_______________________________________

From report at bugs.python.org  Thu Feb 13 00:34:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Feb 2020 05:34:35 +0000
Subject: [issue39620] PyObject_GetAttrString and tp_getattr do not agree
In-Reply-To: <1581564218.88.0.011311131475.issue39620@roundup.psfhosted.org>
Message-ID: <1581572075.78.0.113652504803.issue39620@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was reverted because it is backward incompatible change. It breaks a code which assigns to the tp_getattr field without explicit type cast to getattrfunc.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39620>
_______________________________________

From report at bugs.python.org  Thu Feb 13 01:21:00 2020
From: report at bugs.python.org (JitterMan)
Date: Thu, 13 Feb 2020 06:21:00 +0000
Subject: [issue39601] brace escapes are not working in formatted string
 literal format specifications
In-Reply-To: <1581353284.54.0.569958060726.issue39601@roundup.psfhosted.org>
Message-ID: <1581574860.19.0.268873424956.issue39601@roundup.psfhosted.org>


JitterMan <pythonbugs at shalmirane.com> added the comment:

Ah, that make sense. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39601>
_______________________________________

From report at bugs.python.org  Thu Feb 13 02:06:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Feb 2020 07:06:22 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581577582.04.0.902479430068.issue39567@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +17873
pull_request: https://github.com/python/cpython/pull/18499

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Thu Feb 13 02:08:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Feb 2020 07:08:35 +0000
Subject: [issue39567] Add audit for os.walk(), os.fwalk(),
 Path.glob() and Path.rglob()
In-Reply-To: <1580977248.64.0.174366488821.issue39567@roundup.psfhosted.org>
Message-ID: <1581577715.0.0.204059380009.issue39567@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oh, I did not know about the audit-event directive. Thanks Karthikeyan.

As for backporting this to 3.8 I left it on to the RM.

----------
nosy: +lukasz.langa
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39567>
_______________________________________

From report at bugs.python.org  Thu Feb 13 02:09:49 2020
From: report at bugs.python.org (Zhibin Dong)
Date: Thu, 13 Feb 2020 07:09:49 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Message-ID: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>


New submission from Zhibin Dong <developerdong at gmail.com>:

As shown in the code, when 0 is passed to asyncio.sleep function, sometimes the program does not exit when I press <Ctrl-C>. I must press <Ctrl-C> again to close the program. However, when a number, such as 0.01, which is bigger than 0, is passed to the sleep function, the program will exit as expected when I press <Ctrl-C> just once.

Is there any bug or just a wrong way to use? Thanks.

----------
components: asyncio
files: SleepTest.py
messages: 361939
nosy: Zhibin Dong, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: KeyboardInterrupt is ignored when await asyncio.sleep(0)
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48893/SleepTest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Thu Feb 13 02:47:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Feb 2020 07:47:49 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1581580069.45.0.0398229940905.issue39184@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 7514f4f6254f4a2d13ea8e5632a8e5f22b637e0b by Saiyang Gou in branch 'master':
bpo-39184: Add audit events to functions in `fcntl`, `msvcrt`, `os`, `resource`,  `shutil`, `signal`, `syslog` (GH-18407)
https://github.com/python/cpython/commit/7514f4f6254f4a2d13ea8e5632a8e5f22b637e0b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 13 02:52:10 2020
From: report at bugs.python.org (Ben Boeckel)
Date: Thu, 13 Feb 2020 07:52:10 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581580330.59.0.530691404372.issue21016@roundup.psfhosted.org>


Ben Boeckel <bugs.python at me.benboeckel.net> added the comment:

Thanks!

Should I file a new issue for the other (less urgent) problem mentioned at the bottom or is it not really worth fixing?

> It also erroneously replaces things like '$prefixpath'. It should probably do split the path on the path separators and only replace components that are equal to $prefix or $exec_prefix (so that the '$' can be escaped for directories named as such literally, but that would require a pass to parse the escapes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:04:59 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Feb 2020 08:04:59 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1581581099.33.0.526693331596.issue39184@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17874
pull_request: https://github.com/python/cpython/pull/18500

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:15:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 08:15:45 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1581581745.14.0.602529173744.issue39386@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 925dc7fb1d0db85dc137afa4cd14211bf0d67414 by Nathaniel J. Smith in branch 'master':
bpo-39606: allow closing async generators that are already closed (GH-18475)
https://github.com/python/cpython/commit/925dc7fb1d0db85dc137afa4cd14211bf0d67414


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:15:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 08:15:45 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581581745.26.0.644224464521.issue39606@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 925dc7fb1d0db85dc137afa4cd14211bf0d67414 by Nathaniel J. Smith in branch 'master':
bpo-39606: allow closing async generators that are already closed (GH-18475)
https://github.com/python/cpython/commit/925dc7fb1d0db85dc137afa4cd14211bf0d67414


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:19:35 2020
From: report at bugs.python.org (Stuart Ball)
Date: Thu, 13 Feb 2020 08:19:35 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
Message-ID: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>


New submission from Stuart Ball <corin.patterson at gmail.com>:

This is not very helpful if your gather or wait contains multiple versions of foo with different argument values: 

`<Task pending coro=<foo() running at c.py:6>`

Should just be:

`<Task pending coro=<foo(42, "hello") running at c.py:6>`

Would probably take all of 5 minutes to implement and make a lot of people's lives easier.

----------
messages: 361944
nosy: stuball123
priority: normal
severity: normal
status: open
title: __str__ and __repr__ for asyncio.Task still omit arg values

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:19:49 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 08:19:49 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581581989.94.0.228104603525.issue39606@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17875
pull_request: https://github.com/python/cpython/pull/18501

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:19:50 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 08:19:50 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1581581990.06.0.179736916302.issue39386@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17876
pull_request: https://github.com/python/cpython/pull/18501

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:26:32 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 13 Feb 2020 08:26:32 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1581582392.04.0.421280654863.issue39623@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/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:26:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 13 Feb 2020 08:26:52 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1581582412.01.0.0353009913375.issue39623@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/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:30:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 13 Feb 2020 08:30:34 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1581582634.45.0.0672665064634.issue39184@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset a00b5be5f71b702ab80b0a7c046485046aaae160 by Steve Dower in branch '3.8':
bpo-39184: Add audit events to functions in `fcntl`, `msvcrt`, `os`, `resource`,  `shutil`, `signal`, `syslog` (GH-18407)
https://github.com/python/cpython/commit/a00b5be5f71b702ab80b0a7c046485046aaae160


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:35:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 08:35:46 +0000
Subject: [issue21016] trace: $prefix and $exec_prefix improperly replaced on
 Fedora
In-Reply-To: <1395459980.48.0.405815532542.issue21016@psf.upfronthosting.co.za>
Message-ID: <1581582946.76.0.998743401211.issue21016@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It also erroneously replaces things like '$prefixpath'. It should probably do split the path on the path separators and only replace components that are equal to $prefix or $exec_prefix (so that the '$' can be escaped for directories named as such literally, but that would require a pass to parse the escapes).

re.sub() can be used to leave $prefixpath unchanged. Yeah, please open a separed issue. Sorry, I missed this part of the bug report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21016>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:42:09 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 13 Feb 2020 08:42:09 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581583329.4.0.589647300074.issue39606@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
pull_requests: +17877
pull_request: https://github.com/python/cpython/pull/18502

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:42:09 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 13 Feb 2020 08:42:09 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1581583329.71.0.654183678914.issue39386@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
pull_requests: +17878
pull_request: https://github.com/python/cpython/pull/18502

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:43:28 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 08:43:28 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1581583408.02.0.41827800229.issue39386@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8dbdf5f275c6462bb522bcf3a29054239d72989d by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39606: allow closing async generators that are already closed (GH-18475) (GH-18501)
https://github.com/python/cpython/commit/8dbdf5f275c6462bb522bcf3a29054239d72989d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:43:28 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 08:43:28 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581583408.1.0.55024945594.issue39606@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8dbdf5f275c6462bb522bcf3a29054239d72989d by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39606: allow closing async generators that are already closed (GH-18475) (GH-18501)
https://github.com/python/cpython/commit/8dbdf5f275c6462bb522bcf3a29054239d72989d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Thu Feb 13 03:53:15 2020
From: report at bugs.python.org (Ben Boeckel)
Date: Thu, 13 Feb 2020 08:53:15 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
Message-ID: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>


New submission from Ben Boeckel <bugs.python at me.benboeckel.net>:

Previously reported as a sidenote in Issue21016.

The `--ignore-dir` option in trace.py replaces `$prefix` and `$exec_prefix` *anywhere* in the path when it really should just replace it in the start of the path and if it is followed by nothing or a path separator (that is, it is a path component). I suspect that there's always a separator though.

----------
components: Library (Lib)
messages: 361949
nosy: mathstuf, vstinner
priority: normal
severity: normal
status: open
title: Trace greedy replaces $prefix and $exec_prefix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Thu Feb 13 04:03:31 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 13 Feb 2020 09:03:31 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1581584611.36.0.520842064597.issue39623@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This could sometimes make the output verbose when the arguments themselves are tasks while including arguments in the signature in _format_coroutine.

$ cat /tmp/foo.py
import asyncio

async def foo(a, b): pass

async def main():
    task = asyncio.create_task(foo(1, b=1))
    task1 = asyncio.create_task(foo(1, b=task))
    print(repr(task))
    print(repr(task1))

asyncio.run(main())

$ python3.8 /tmp/foo.py
<Task pending name='Task-2' coro=<foo() running at /tmp/foo.py:3>>
<Task pending name='Task-3' coro=<foo() running at /tmp/foo.py:3>>

$ ./python.exe /tmp/foo.py
<Task pending name='Task-2' coro=<foo(a=1, b=1) running at /tmp/foo.py:3>>
<Task pending name='Task-3' coro=<foo(a=1, b=<Task pending name='Task-2' coro=<foo(a=1, b=1) running at /tmp/foo.py:3>>) running at /tmp/foo.py:3>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 13 04:03:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 13 Feb 2020 09:03:47 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1581584627.12.0.221006303557.issue39623@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
type:  -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 13 04:33:42 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 13 Feb 2020 09:33:42 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1581586422.12.0.404234033051.issue39386@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:


New changeset f464edf3239f7867fe31c9cd238a68fb3b90feaa by Nathaniel J. Smith in branch '3.7':
bpo-39606: allow closing async generators that are already closed (GH-18475) (GH-18502)
https://github.com/python/cpython/commit/f464edf3239f7867fe31c9cd238a68fb3b90feaa


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Thu Feb 13 04:33:42 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 13 Feb 2020 09:33:42 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581586422.24.0.356127706518.issue39606@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:


New changeset f464edf3239f7867fe31c9cd238a68fb3b90feaa by Nathaniel J. Smith in branch '3.7':
bpo-39606: allow closing async generators that are already closed (GH-18475) (GH-18502)
https://github.com/python/cpython/commit/f464edf3239f7867fe31c9cd238a68fb3b90feaa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Thu Feb 13 04:44:45 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 13 Feb 2020 09:44:45 +0000
Subject: [issue39606] Regression: it should be possible to close async
 iterators multiple times
In-Reply-To: <1581402923.1.0.805434272092.issue39606@roundup.psfhosted.org>
Message-ID: <1581587085.69.0.200429388119.issue39606@roundup.psfhosted.org>


Change by Nathaniel Smith <njs at pobox.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39606>
_______________________________________

From report at bugs.python.org  Thu Feb 13 07:10:14 2020
From: report at bugs.python.org (Andrew Wall)
Date: Thu, 13 Feb 2020 12:10:14 +0000
Subject: [issue39625] Traceback needs more details
Message-ID: <1581595814.35.0.681093135233.issue39625@roundup.psfhosted.org>


New submission from Andrew Wall <quamrana at gmail.com>:

I encountered a question on Stackoverflow where, unusually, a Traceback was given in full, but I couldn't diagnose the problem.

It was like this:

Traceback (most recent call last):
  File "soFailedTraceback.py", line 15, in <module>
    c = C(C1("C1"), C2("C2"))
TypeError: __init__() missing 1 required positional argument: 'p'

What I am claiming is missing is info about class C1:
  File "soFailedTraceback.py", line 8, in <module>
    def __init__(self, s1, p):


Here is the file soFailedTraceback.py:
#soFailedTraceback

class C:
    def __init__(self, c1, p):
        pass

class C1:
    def __init__(self, s1, p):
        pass

class C2:
    def __init__(self, s1):
        pass

c = C(C1("C1"), C2("C2"))

I find the Traceback confusing, because it so happens there are two classes which have required positional argument "p", but python does not directly show which class it is.

----------
messages: 361953
nosy: Andrew Wall
priority: normal
severity: normal
status: open
title: Traceback needs more details
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39625>
_______________________________________

From report at bugs.python.org  Thu Feb 13 07:59:45 2020
From: report at bugs.python.org (Ilya Kamenshchikov)
Date: Thu, 13 Feb 2020 12:59:45 +0000
Subject: [issue39626] random choice to delegate to sample on sets
Message-ID: <1581598785.79.0.74304854999.issue39626@roundup.psfhosted.org>


New submission from Ilya Kamenshchikov <ikamenshchikov at gmail.com>:

In a few of my projects I had this (minor) pain of having to remember which collections of elements are sets and which are [list, tuple]. It causes me to double check and have random.sample(my_set, 1)[0] in many places. 

To me this is not how I think and causes friction: conceptually, I know something is a collection and I want 1 random choice from it. Having to differentiate on sequences vs sets makes my code uglier :(

This issue is similar to https://bugs.python.org/issue37708.

----------
components: Library (Lib)
messages: 361954
nosy: Ilya Kamenshchikov
priority: normal
severity: normal
status: open
title: random choice to delegate to sample on sets

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39626>
_______________________________________

From report at bugs.python.org  Thu Feb 13 08:04:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 13 Feb 2020 13:04:49 +0000
Subject: [issue39626] random choice to delegate to sample on sets
In-Reply-To: <1581598785.79.0.74304854999.issue39626@roundup.psfhosted.org>
Message-ID: <1581599089.29.0.0048127914871.issue39626@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/issue39626>
_______________________________________

From report at bugs.python.org  Thu Feb 13 08:41:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 13:41:49 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581601309.35.0.417584431491.issue39624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

str.replace() can be replaced with re.sub() and \b marker.

Example:

>>> re.sub(r'\$prefix\b', '[xxx]', '$prefix $prefixpath')
'[xxx] $prefixpath'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Thu Feb 13 09:26:39 2020
From: report at bugs.python.org (sds)
Date: Thu, 13 Feb 2020 14:26:39 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
In-Reply-To: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>
Message-ID: <1581603999.82.0.931504500551.issue39617@roundup.psfhosted.org>


sds <sds at gnu.org> added the comment:

cf https://github.com/joblib/loky/issues/233

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Thu Feb 13 09:31:28 2020
From: report at bugs.python.org (Vlad Emelianov)
Date: Thu, 13 Feb 2020 14:31:28 +0000
Subject: [issue39627] Fix TypedDict totalizy check for inherited keys
Message-ID: <1581604288.74.0.402732748269.issue39627@roundup.psfhosted.org>


New submission from Vlad Emelianov <volshebnyi at gmail.com>:

Add changes made in https://github.com/python/typing/pull/700 to upstream.

----------
components: Library (Lib)
messages: 361957
nosy: Vlad Emelianov
priority: normal
severity: normal
status: open
title: Fix TypedDict totalizy check for inherited keys
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39627>
_______________________________________

From report at bugs.python.org  Thu Feb 13 09:52:58 2020
From: report at bugs.python.org (Vlad Emelianov)
Date: Thu, 13 Feb 2020 14:52:58 +0000
Subject: [issue39627] Fix TypedDict totalizy check for inherited keys
In-Reply-To: <1581604288.74.0.402732748269.issue39627@roundup.psfhosted.org>
Message-ID: <1581605578.0.0.901703354657.issue39627@roundup.psfhosted.org>


Change by Vlad Emelianov <volshebnyi at gmail.com>:


----------
keywords: +patch
pull_requests: +17879
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18503

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39627>
_______________________________________

From report at bugs.python.org  Thu Feb 13 09:54:01 2020
From: report at bugs.python.org (Vlad Emelianov)
Date: Thu, 13 Feb 2020 14:54:01 +0000
Subject: [issue39627] Fix TypedDict totality check for inherited keys
In-Reply-To: <1581604288.74.0.402732748269.issue39627@roundup.psfhosted.org>
Message-ID: <1581605641.93.0.0910606113589.issue39627@roundup.psfhosted.org>


Change by Vlad Emelianov <volshebnyi at gmail.com>:


----------
title: Fix TypedDict totalizy check for inherited keys -> Fix TypedDict totality check for inherited keys

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39627>
_______________________________________

From report at bugs.python.org  Thu Feb 13 10:05:11 2020
From: report at bugs.python.org (Ben Boeckel)
Date: Thu, 13 Feb 2020 15:05:11 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581606311.53.0.45342764411.issue39624@roundup.psfhosted.org>


Ben Boeckel <bugs.python at me.benboeckel.net> added the comment:

`\b` is a bit too loose. That example should *not* have it replaced because it is not a full path component.

(Granted, any of these conflicting paths are "dumb" in general; I'm fine with just leaving this as a low priority, but if it does get modified, it should actually get fixed.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Thu Feb 13 10:05:28 2020
From: report at bugs.python.org (Marco)
Date: Thu, 13 Feb 2020 15:05:28 +0000
Subject: [issue39628] msg.walk memory leak?
Message-ID: <1581606328.48.0.533988298686.issue39628@roundup.psfhosted.org>


New submission from Marco <m.faverof at gmail.com>:

Hello,

 if I write

```
msg = email.message_from_bytes(...)
for part in msg.walk():
  content_type = part.get_content_type()
  if not part.get_content_maintype() == 'multipart':
     filename = part.get_filename(None)
     attachment = part.get_payload(decode=True)
```

if the mime parts are more than one, then the memory increases at each iteration and will never be released.

----------
components: email
messages: 361959
nosy: barry, falon, r.david.murray
priority: normal
severity: normal
status: open
title: msg.walk memory leak?
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39628>
_______________________________________

From report at bugs.python.org  Thu Feb 13 10:55:19 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 13 Feb 2020 15:55:19 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581609319.06.0.64664978748.issue39573@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Hi, guys. Is there value in adding `PyNone_Check` macro?(`_PyNone_Type` is not esposed to CAPI directly, so I am not sure about it)
If the answer is 'yes', i can add it ;)

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 10:58:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 15:58:01 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581609481.65.0.646832299426.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Hi, guys. Is there value in adding `PyNone_Check` macro?

"obj == Py_None" is a very common pattern.

You have check how it is done in HPy: https://github.com/pyhandle/hpy

See also bpo-39511: "[subinterpreters] Per-interpreter singletons (None, True, False, etc.)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 10:59:33 2020
From: report at bugs.python.org (nmacleod)
Date: Thu, 13 Feb 2020 15:59:33 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1581609573.82.0.757319409681.issue5537@roundup.psfhosted.org>


nmacleod <launchpad at nmacleod.com> added the comment:

Apologies for the necro on this issue, but should this now be fixed in Python3.7? As it appears to still be an issue.

Testing on a Raspberry Pi with LibreELEC (32-bit OS):

rpi512:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 12 2020, 17:36:39)
[GCC 9.2.0]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.7/cookiejar.py", line 101, in time2isoz
OverflowError: timestamp out of range for platform time_t


This is on a distribution built with latest glibc-2.31.

----------
nosy: +nmacleod

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Thu Feb 13 11:03:41 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 13 Feb 2020 16:03:41 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581609821.21.0.957567300199.issue39573@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>"obj == Py_None" is a very common pattern.
>You have check how it is done in HPy: https://github.com/pyhandle/hpy
>See also bpo-39511: "[subinterpreters] Per-interpreter singletons (None, >True, False, etc.)".

Thanks, I will check it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 11:51:32 2020
From: report at bugs.python.org (Benedikt Bieringer)
Date: Thu, 13 Feb 2020 16:51:32 +0000
Subject: [issue5996] abstract class instantiable when subclassing built-in
 types
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1581612692.26.0.111802767514.issue5996@roundup.psfhosted.org>


Change by Benedikt Bieringer <2xB.coding at wwu.de>:


----------
nosy: +2xB

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Thu Feb 13 12:35:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 17:35:08 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581615308.16.0.429256461064.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 968dcd9e7a4d3aa9aaa1dfca693adf60d6b71ce7 by Brandt Bucher in branch 'master':
bpo-39573: Fix bad copy-paste in Py_SET_SIZE (GH-18496)
https://github.com/python/cpython/commit/968dcd9e7a4d3aa9aaa1dfca693adf60d6b71ce7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 12:37:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 17:37:20 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581615440.97.0.827100951023.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d905df766c367c350f20c46ccd99d4da19ed57d8 by Dong-hee Na in branch 'master':
bpo-39573: Add Py_IS_TYPE() function (GH-18488)
https://github.com/python/cpython/commit/d905df766c367c350f20c46ccd99d4da19ed57d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 13:16:37 2020
From: report at bugs.python.org (Eric Fahlgren)
Date: Thu, 13 Feb 2020 18:16:37 +0000
Subject: [issue39629] inspect.signature fails on math.hypot
Message-ID: <1581617797.68.0.659166194612.issue39629@roundup.psfhosted.org>


New submission from Eric Fahlgren <ericfahlgren at gmail.com>:

Python 3.8's new math.hypot function also appears to suffer from the same issue as math.log:

>>> import math, inspect
>>> inspect.signature(math.hypot)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\Python38\lib\inspect.py", line 3093, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "C:\Program Files\Python38\lib\inspect.py", line 2842, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "C:\Program Files\Python38\lib\inspect.py", line 2296, in _signature_from_callable
    return _signature_from_builtin(sigcls, obj,
  File "C:\Program Files\Python38\lib\inspect.py", line 2107, in _signature_from_builtin
    raise ValueError("no signature found for builtin {!r}".format(func))
ValueError: no signature found for builtin <built-in function hypot>

Possibly related to issue29299?

----------
components: Library (Lib)
messages: 361966
nosy: eric.fahlgren
priority: normal
severity: normal
status: open
title: inspect.signature fails on math.hypot
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39629>
_______________________________________

From report at bugs.python.org  Thu Feb 13 13:24:13 2020
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 13 Feb 2020 18:24:13 +0000
Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make
 debugging easier
In-Reply-To: <1433071409.14.0.465304271938.issue24337@psf.upfronthosting.co.za>
Message-ID: <1581618253.0.0.992124480472.issue24337@roundup.psfhosted.org>


Change by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24337>
_______________________________________

From report at bugs.python.org  Thu Feb 13 13:32:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 13 Feb 2020 18:32:13 +0000
Subject: [issue39524] Escape sequences in doc string of ast._pad_whitespace
In-Reply-To: <1580616588.9.0.5083341091.issue39524@roundup.psfhosted.org>
Message-ID: <1581618733.55.0.238732267354.issue39524@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset fbeba8f2481411d608a616366394e07cdc52e0bb by mpheath in branch 'master':
bpo-39524: Fixed doc-string in ast._pad_whitespace (GH-18340)
https://github.com/python/cpython/commit/fbeba8f2481411d608a616366394e07cdc52e0bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39524>
_______________________________________

From report at bugs.python.org  Thu Feb 13 14:25:10 2020
From: report at bugs.python.org (dHannasch)
Date: Thu, 13 Feb 2020 19:25:10 +0000
Subject: [issue17050] argparse.REMAINDER doesn't work as first argument
In-Reply-To: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>
Message-ID: <1581621910.85.0.574586866724.issue17050@roundup.psfhosted.org>


dHannasch <dahanna at sandia.gov> added the comment:

I've attached a file that can be run, but it's a simple script that I can include here inline, too:


"""
Context:
I am trying to set up a cookiecutter so that newly-created packages will come with a Jupyter notebook users can play with.
That is, python -m package_name jupyter would open up a Jupyter quickstart notebook demonstrating the package's features.
argparse.REMAINDER as the first argument isn't important for a top-level parser, since we can work around it by not using argparse at all,
but using argparse.REMAINDER in a subparser seems like a pretty straightforward use case.
Any time we want to dispatch a subcommand to a separate tool --- forwarding all following arguments --- we're going to need it.
"""

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('command', default='cmdname')
parser.add_argument('cmdname_args', nargs=argparse.REMAINDER)
args = parser.parse_args('cmdname --arg1 XX ZZ --foobar'.split())
if args != argparse.Namespace(cmdname_args=['--arg1', 'XX', 'ZZ', '--foobar'], command='cmdname'):
    raise Exception(args)
print('This is how argparse.REMAINDER works when there is an argument in front.')

parser = argparse.ArgumentParser()
parser.add_argument('--foo')
parser.add_argument('command', default='cmdname')
parser.add_argument('cmdname_args', nargs=argparse.REMAINDER)
args = parser.parse_args('--foo B cmdname --arg1 XX ZZ --foobar'.split())
if args != argparse.Namespace(cmdname_args=['--arg1', 'XX', 'ZZ', '--foobar'], command='cmdname', foo='B'):
    raise Exception(args)
print('This is how argparse.REMAINDER works there is an option in front.')

parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers(dest='command')
commandParser = subparsers.add_parser('cmdname')
commandParser.add_argument('--filler-boundary-marker', dest='cmdname_args', nargs=argparse.REMAINDER)
args = parser.parse_args('--foo B cmdname --filler-boundary-marker --arg1 XX ZZ --foobar'.split())
if args != argparse.Namespace(cmdname_args=['--arg1', 'XX', 'ZZ', '--foobar'], command='cmdname', foo='B'):
    raise Exception(args)
print('This is how argparse.REMAINDER works with a visible "filler" name for the list of arguments.')

parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers(dest='command')
commandParser = subparsers.add_parser('cmdname')
commandParser.add_argument('--filler-boundary-marker', dest='cmdname_args', nargs=argparse.REMAINDER)
args = parser.parse_args('cmdname --filler-boundary-marker --arg1 XX ZZ --foobar --foo B'.split())
if args != argparse.Namespace(cmdname_args=['--arg1', 'XX', 'ZZ', '--foobar', '--foo', 'B'], command='cmdname', foo=None):
    raise Exception(args)
print("If an optional argument is provided after cmdname instead of before, it will get interpreted as part of the argparse.REMAINDER instead of normally. And that's great! We don't even need to be paranoid about other functions of our command-line tool sharing arguments with the tool we want to wrap. Everything will be forwarded.")

parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers(dest='command')
commandParser = subparsers.add_parser('cmdname')
commandParser.add_argument('positional_arg')
commandParser.add_argument('cmdname_args', nargs=argparse.REMAINDER)
args = parser.parse_args('cmdname can_put_anything_here --arg1 XX ZZ --foobar --foo B'.split())
if args != argparse.Namespace(cmdname_args=['--arg1', 'XX', 'ZZ', '--foobar', '--foo', 'B'], command='cmdname', positional_arg='can_put_anything_here', foo=None):
    raise Exception(args)
print("If an optional argument is provided after cmdname instead of before, it will get interpreted as part of the argparse.REMAINDER instead of normally. And that's great! We don't even need to be paranoid about other functions of our command-line tool sharing arguments with the tool we want to wrap. Everything will be forwarded.")

"""
Note that this means we can fix the bug simply by,
whenever the cmdname subparser is invoked and the cmdname subparser uses argparse.REMAINDER,
automatically adding an imaginary first positional argument to the subparser
and inserting that imaginary first positional argument into the stream before parsing the arguments to cmdname.
https://github.com/python/cpython/blob/master/Lib/argparse.py#L1201
(Obviously it would be better to fix the underlying cause.)
"""

print('What we want to do is have a subparser that, in the case of one particular selection, forwards all following arguments to another tool.')
print('script.py --foo B cmdname --arg1 XX ZZ --foobar should dispatch to cmdname --arg1 XX ZZ --foobar.')
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
subparsers = parser.add_subparsers(dest='command')
commandParser = subparsers.add_parser('cmdname')
commandParser.add_argument('cmdname_args', nargs=argparse.REMAINDER)
parser.parse_args('--foo B cmdname --arg1 XX ZZ --foobar'.split())
# error: unrecognized arguments: --arg1

----------
nosy: +dHannasch, rhettinger -aldencolerain, bethard, chris.jerdonek, danielsh, paul.j3
versions: +Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48894/argparse_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17050>
_______________________________________

From report at bugs.python.org  Thu Feb 13 14:53:33 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 13 Feb 2020 19:53:33 +0000
Subject: [issue39627] Fix TypedDict totality check for inherited keys
In-Reply-To: <1581604288.74.0.402732748269.issue39627@roundup.psfhosted.org>
Message-ID: <1581623613.26.0.759179260331.issue39627@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 10e87e5ef4c1b4fb8415d9ddc362e2591f2f0b6c by Vlad Emelianov in branch 'master':
bpo-39627: Fix TypedDict totality check for inherited keys (#18503)
https://github.com/python/cpython/commit/10e87e5ef4c1b4fb8415d9ddc362e2591f2f0b6c


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39627>
_______________________________________

From report at bugs.python.org  Thu Feb 13 14:56:50 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 13 Feb 2020 19:56:50 +0000
Subject: [issue39629] inspect.signature fails on math.hypot
In-Reply-To: <1581617797.68.0.659166194612.issue39629@roundup.psfhosted.org>
Message-ID: <1581623810.13.0.64872520185.issue39629@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/issue39629>
_______________________________________

From report at bugs.python.org  Thu Feb 13 14:54:11 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 13 Feb 2020 19:54:11 +0000
Subject: [issue39627] Fix TypedDict totality check for inherited keys
In-Reply-To: <1581604288.74.0.402732748269.issue39627@roundup.psfhosted.org>
Message-ID: <1581623651.92.0.291136728833.issue39627@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/issue39627>
_______________________________________

From report at bugs.python.org  Thu Feb 13 16:43:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 21:43:38 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581630218.41.0.223996800694.issue39624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Would you mind to add examples of patterns should be replaced and patterns which should not be replaced?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Thu Feb 13 16:50:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 21:50:34 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581630634.31.0.714870108318.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Hi, guys.

By the way, please find another more inclusive way to say hi, see:
https://heyguys.cc/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 17:01:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Feb 2020 22:01:00 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1581631260.23.0.206113914856.issue5537@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, maybe the bug wasn't properly fixed?

Can you please try the patch above?

diff --git a/Lib/http/cookiejar.py b/Lib/http/cookiejar.py
index 47ed5c3d64..55915cf18a 100644
--- a/Lib/http/cookiejar.py
+++ b/Lib/http/cookiejar.py
@@ -99,7 +99,7 @@ def time2isoz(t=None):
     if t is None:
         dt = datetime.datetime.utcnow()
     else:
-        dt = datetime.datetime.utcfromtimestamp(t)
+        dt = datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=t)
     return "%04d-%02d-%02d %02d:%02d:%02dZ" % (
         dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second)
 

For example, copy http/ subdirectory in the current directory, and then patch manually http/cookiejar.py file.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Thu Feb 13 17:48:40 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 13 Feb 2020 22:48:40 +0000
Subject: [issue39411] pyclbr rewrite using AST
In-Reply-To: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>
Message-ID: <1581634120.98.0.249143418485.issue39411@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Thu Feb 13 18:54:07 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Feb 2020 23:54:07 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581638047.18.0.196722784272.issue39545@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset cebe9ee988837b292f2c571e194ed11e7cd4abbb by Serhiy Storchaka in branch '3.6':
bpo-39545: Document restrictions on "await" and "async for" in f-strings. (GH-18459)
https://github.com/python/cpython/commit/cebe9ee988837b292f2c571e194ed11e7cd4abbb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Thu Feb 13 18:57:39 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 23:57:39 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581638259.05.0.97221200664.issue39545@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f632736023502816f2e6bd714d1b48c81aa2ccc1 by Serhiy Storchaka in branch 'master':
bpo-39545: Document changes in the support of await in f-strings. (GH-18456)
https://github.com/python/cpython/commit/f632736023502816f2e6bd714d1b48c81aa2ccc1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Thu Feb 13 18:58:02 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 23:58:02 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581638282.72.0.327515230171.issue39545@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17881
pull_request: https://github.com/python/cpython/pull/18505

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Thu Feb 13 18:58:10 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 13 Feb 2020 23:58:10 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581638290.68.0.591300559812.issue39545@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17882
pull_request: https://github.com/python/cpython/pull/18506

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Thu Feb 13 19:03:19 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Feb 2020 00:03:19 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581638599.39.0.502137804348.issue39545@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 46cf4fc8a5646ca35f7d1ac06d2ef33eb9efca1d by Miss Islington (bot) in branch '3.7':
bpo-39545: Document changes in the support of await in f-strings. (GH-18456)
https://github.com/python/cpython/commit/46cf4fc8a5646ca35f7d1ac06d2ef33eb9efca1d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Thu Feb 13 19:04:03 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Feb 2020 00:04:03 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581638643.69.0.713402697715.issue39545@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 581b8606ca0609cf36c4eb9a5bb025eb77540e5e by Miss Islington (bot) in branch '3.8':
bpo-39545: Document changes in the support of await in f-strings. (GH-18456)
https://github.com/python/cpython/commit/581b8606ca0609cf36c4eb9a5bb025eb77540e5e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Thu Feb 13 19:50:55 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 14 Feb 2020 00:50:55 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581641455.94.0.392084284642.issue39573@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> By the way, please find another more inclusive way to say hi, see:
https://heyguys.cc/

Oh, copy that. Sorry for my poor english.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 20:11:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 14 Feb 2020 01:11:53 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581642713.73.0.735547602361.issue39573@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17883
pull_request: https://github.com/python/cpython/pull/18507

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 20:17:40 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 14 Feb 2020 01:17:40 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1581643060.04.0.5083272196.issue39511@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Thu Feb 13 20:21:52 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 14 Feb 2020 01:21:52 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581643312.59.0.0141885843132.issue39573@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17884
pull_request: https://github.com/python/cpython/pull/18508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Thu Feb 13 20:31:58 2020
From: report at bugs.python.org (Neil MacLeod)
Date: Fri, 14 Feb 2020 01:31:58 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1581643918.56.0.598228141817.issue5537@roundup.psfhosted.org>


Neil MacLeod <launchpad at nmacleod.com> added the comment:

Hi Victor

I can confirm the patch is working on both 32-bit and 64-bit systems running Python3.7.6, with both platforms returning the same result after patching - many thanks!

#### UNPATCHED, 32-bit (RPi3+)
LibreELEC (Milhouse.testing): devel-20200213234919-#0213f-g70b69eb (RPi2.arm)
rpi22:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 14 2020, 00:35:22)
[GCC 9.2.0]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.7/cookiejar.py", line 101, in time2isoz
OverflowError: timestamp out of range for platform time_t

#### PATCHED, 32-bit (RPi3+)
LibreELEC (Milhouse.testing): devel-20200214012134-#0213g-g70b69eb (RPi2.arm)
rpi22:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 14 2020, 01:22:50)
[GCC 9.2.0]
2043-08-11 16:36:07Z

#### UNPATCHED, 64-bit (x86_64)
LibreELEC (Milhouse.next): devel-20200213053123-#0212x-g67aedc9 (Generic.x86_64)
NUC:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 12 2020, 20:54:03)
[GCC 9.2.0]
2043-08-11 16:36:07Z

#### PATCHED, 64-bit (x86_64)
LibreELEC (Milhouse.next): devel-20200214005606-#0214-g70b69eb (Generic.x86_64)
NUC:~ # python -c "import sys, http.cookiejar; print(sys.version); print(http.cookiejar.time2isoz(2322923767))"
3.7.6 (default, Feb 14 2020, 01:00:37)
[GCC 9.2.0]
2043-08-11 16:36:07Z

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Thu Feb 13 20:37:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Feb 2020 01:37:27 +0000
Subject: [issue39626] random choice to delegate to sample on sets
In-Reply-To: <1581598785.79.0.74304854999.issue39626@roundup.psfhosted.org>
Message-ID: <1581644247.74.0.680460634534.issue39626@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestion.  I think this is close to being a duplicate of 37708 which was rejected.  For the most part, it was mistake that sample() accepted sets.  The implicit conversion has led to surprising performance issues.  If that API was being created from scratch, it would not support sets at and would require the user to explicitly convert to a sequence.  I do not wish to replicate this mistake with choices().

As for delegating to sample(), that doesn't make sense because choices() works with replacement and sample() works without replacement.  The two are semantically different.

----------
assignee:  -> rhettinger
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39626>
_______________________________________

From report at bugs.python.org  Thu Feb 13 20:45:35 2020
From: report at bugs.python.org (Neil MacLeod)
Date: Fri, 14 Feb 2020 01:45:35 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1581644735.63.0.326928215789.issue5537@roundup.psfhosted.org>


Neil MacLeod <launchpad at nmacleod.com> added the comment:

Just an FYI, this is also broken on 32-bit with Python2.7.16, so possibly it was never fixed originally (rather than being a regression).

LibreELEC (Milhouse): devel-20191012235627-#1012-ge416c8b (RPi2.arm)
rpi22:~ # python -c "import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767)"
2.7.16 (default, Sep 29 2019, 04:11:31)
[GCC 9.2.0]
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/cookielib.py", line 99, in time2isoz
ValueError: timestamp out of range for platform time_t

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Thu Feb 13 22:09:17 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Feb 2020 03:09:17 +0000
Subject: [issue39619] os.chroot is not enabled on HP-UX builds
In-Reply-To: <1581546833.04.0.518216269375.issue39619@roundup.psfhosted.org>
Message-ID: <1581649757.62.0.475262060038.issue39619@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a9edf44a2de9b23a1690b36cdfeed7b41ab763bd by Ian Norton in branch 'master':
closes bpo-39619 Fix os.chroot on HP-UX 11.31 (GH-18495)
https://github.com/python/cpython/commit/a9edf44a2de9b23a1690b36cdfeed7b41ab763bd


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39619>
_______________________________________

From report at bugs.python.org  Thu Feb 13 22:09:23 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Feb 2020 03:09:23 +0000
Subject: [issue39619] os.chroot is not enabled on HP-UX builds
In-Reply-To: <1581546833.04.0.518216269375.issue39619@roundup.psfhosted.org>
Message-ID: <1581649763.28.0.276514924417.issue39619@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17885
pull_request: https://github.com/python/cpython/pull/18509

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39619>
_______________________________________

From report at bugs.python.org  Thu Feb 13 22:25:13 2020
From: report at bugs.python.org (Andy Lester)
Date: Fri, 14 Feb 2020 03:25:13 +0000
Subject: [issue39630] Const some pointers to string literals
Message-ID: <1581650712.98.0.799868474663.issue39630@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

Here are some fixes of char * pointers to literals that should be const char * in these four files.

+++ Objects/frameobject.c
+++ Objects/genobject.c
+++ Python/codecs.c
+++ Python/errors.c

----------
components: Interpreter Core
messages: 361982
nosy: petdance
priority: normal
severity: normal
status: open
title: Const some pointers to string literals
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39630>
_______________________________________

From report at bugs.python.org  Thu Feb 13 22:27:10 2020
From: report at bugs.python.org (Andy Lester)
Date: Fri, 14 Feb 2020 03:27:10 +0000
Subject: [issue39630] Const some pointers to string literals
In-Reply-To: <1581650712.98.0.799868474663.issue39630@roundup.psfhosted.org>
Message-ID: <1581650830.14.0.848719869409.issue39630@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17886
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18510

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39630>
_______________________________________

From report at bugs.python.org  Thu Feb 13 22:27:31 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Feb 2020 03:27:31 +0000
Subject: [issue39619] os.chroot is not enabled on HP-UX builds
In-Reply-To: <1581546833.04.0.518216269375.issue39619@roundup.psfhosted.org>
Message-ID: <1581650851.49.0.513657238124.issue39619@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 28fc1bac0fbe1f4ae2e3dcba1dee38d2c063a539 by Miss Islington (bot) in branch '3.8':
closes bpo-39619 Fix os.chroot on HP-UX 11.31 (GH-18495)
https://github.com/python/cpython/commit/28fc1bac0fbe1f4ae2e3dcba1dee38d2c063a539


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39619>
_______________________________________

From report at bugs.python.org  Thu Feb 13 23:43:15 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Feb 2020 04:43:15 +0000
Subject: [issue39630] Const some pointers to string literals
In-Reply-To: <1581650712.98.0.799868474663.issue39630@roundup.psfhosted.org>
Message-ID: <1581655395.78.0.650040532696.issue39630@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 7386a70746cf9aaf2d95db75d9201fb124f085df by Andy Lester in branch 'master':
closes bpo-39630: Update pointers to string literals to be const char *. (GH-18510)
https://github.com/python/cpython/commit/7386a70746cf9aaf2d95db75d9201fb124f085df


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39630>
_______________________________________

From report at bugs.python.org  Thu Feb 13 23:45:21 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Feb 2020 04:45:21 +0000
Subject: [issue39630] Const some pointers to string literals
In-Reply-To: <1581650712.98.0.799868474663.issue39630@roundup.psfhosted.org>
Message-ID: <1581655521.85.0.170875005651.issue39630@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +17887
pull_request: https://github.com/python/cpython/pull/18511

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39630>
_______________________________________

From report at bugs.python.org  Fri Feb 14 00:05:07 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Feb 2020 05:05:07 +0000
Subject: [issue39630] Const some pointers to string literals
In-Reply-To: <1581650712.98.0.799868474663.issue39630@roundup.psfhosted.org>
Message-ID: <1581656707.28.0.801979167721.issue39630@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 0d860dd43c72dc7046a5d18fc72d495cadd4a2df by Benjamin Peterson in branch '3.8':
[3.8] closes bpo-39630: Update pointers to string literals to be const char *. (GH-18511)
https://github.com/python/cpython/commit/0d860dd43c72dc7046a5d18fc72d495cadd4a2df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39630>
_______________________________________

From report at bugs.python.org  Fri Feb 14 00:39:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Feb 2020 05:39:39 +0000
Subject: [issue39629] inspect.signature fails on math.hypot
In-Reply-To: <1581617797.68.0.659166194612.issue39629@roundup.psfhosted.org>
Message-ID: <1581658779.63.0.510170030216.issue39629@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This isn't a bug.  It is a known limitation of the ArgumentClinic that it cannot currently describe functions with *args.   That and other limitations is also why we don't have signatures for min() max() range() etc.

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39629>
_______________________________________

From report at bugs.python.org  Fri Feb 14 02:48:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Feb 2020 07:48:34 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581666514.93.0.828358380329.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d212c3c55d414203b0579e000d9f340f8cd11be7 by Dong-hee Na in branch 'master':
bpo-39573: PyXXX_Check() macros use Py_IS_TYPE() (GH-18508)
https://github.com/python/cpython/commit/d212c3c55d414203b0579e000d9f340f8cd11be7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb 14 02:50:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Feb 2020 07:50:23 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581666623.08.0.230850761692.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9aeb0ef9309384099e2f23bcee2240fbc096568e by Dong-hee Na in branch 'master':
 bpo-39573: Update clinic to use Py_IS_TYPE() function (GH-18507)
https://github.com/python/cpython/commit/9aeb0ef9309384099e2f23bcee2240fbc096568e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb 14 03:05:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Feb 2020 08:05:34 +0000
Subject: [issue39545] await is not supported in f-string in 3.6
In-Reply-To: <1580754398.55.0.721406999094.issue39545@roundup.psfhosted.org>
Message-ID: <1581667534.54.0.0150803262595.issue39545@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39545>
_______________________________________

From report at bugs.python.org  Fri Feb 14 03:49:42 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Feb 2020 08:49:42 +0000
Subject: [issue39631] Fix file association MIME type on Windows
Message-ID: <1581670182.52.0.370257427786.issue39631@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The installer for Windows creates file associations in Tools/msi/launcher/launcher_reg.wxs that identify ".py[w]" files as text/plain.

This is inconsistent with the mimetypes module, which uses text/x-python, and may cause some applications to assume that calling ShellExecute on a .py file will open a text editor rather than executing the script.

We should update the MIME type to text/x-python. This can be backported, as the change is in the launcher and isn't tied to the usual upgrade paths anyway.

----------
components: Windows
messages: 361989
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix file association MIME type on Windows
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39631>
_______________________________________

From report at bugs.python.org  Fri Feb 14 03:51:42 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 14 Feb 2020 08:51:42 +0000
Subject: [issue39631] Fix file association MIME type on Windows
In-Reply-To: <1581670182.52.0.370257427786.issue39631@roundup.psfhosted.org>
Message-ID: <1581670302.42.0.117277371376.issue39631@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The most likely negative potential impact of this would be for any users who have added additional verbs based on the content type. I don't recall whether we set PerceivedType or not, but that can probably stay.

I'm not aware of any applications (besides Windows itself) that set verbs based on content type rather than extensions, so I doubt anyone will be too upset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39631>
_______________________________________

From report at bugs.python.org  Fri Feb 14 04:16:24 2020
From: report at bugs.python.org (Murali Ravipudi)
Date: Fri, 14 Feb 2020 09:16:24 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1581671784.43.0.836046031351.issue9305@roundup.psfhosted.org>


Change by Murali Ravipudi <murali.ravipudi at gmail.com>:


----------
nosy: +Murali Ravipudi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Fri Feb 14 04:18:07 2020
From: report at bugs.python.org (Dobatymo)
Date: Fri, 14 Feb 2020 09:18:07 +0000
Subject: [issue31116] base85 z85 variant encoding
In-Reply-To: <1501799542.97.0.652442678927.issue31116@psf.upfronthosting.co.za>
Message-ID: <1581671887.19.0.997085751453.issue31116@roundup.psfhosted.org>


Dobatymo <the-real-hazzard at outlook.com> added the comment:

base64.b85encode does not use ", ' or \ as well.

That's the _b85alphabet 

_b85alphabet = (b"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
                b"abcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~")

----------
nosy: +Dobatymo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31116>
_______________________________________

From report at bugs.python.org  Fri Feb 14 05:03:28 2020
From: report at bugs.python.org (Nicolas Dessart)
Date: Fri, 14 Feb 2020 10:03:28 +0000
Subject: [issue39632] variadic function call broken on armhf when passing a
 float argument
Message-ID: <1581674608.19.0.403543141988.issue39632@roundup.psfhosted.org>


New submission from Nicolas Dessart <nicolas.dessart at gmail.com>:

On armhf and for variadic functions (and contrary to non-variadic functions), the VFP co-processor registers are not used for float argument parameter passing. This specificity is apparently completely disregarded by ctypes which always uses `ffi_prep_cif` to prepare the parameter passing of a function while it should most probably use `ffi_prep_cif_var` for variadic functions.

As such variadic function call with float arguments through ctypes
is currently broken on armhf targets.

I think that ctypes API should be updated to let the user specify if a function is variadic.

I've attached a patch to the ctypes unit tests that I'm using to reproduce this bug.


pi at raspberrypi:~/code/cpython $ ./python -m test test_ctypes    
0:00:00 load avg: 0.00 Run tests sequentially
0:00:00 load avg: 0.00 [1/1] test_ctypes
_testfunc_d_bhilfd_var got 2 3 4 -1242230680 -0.000000 -0.000000
test test_ctypes failed -- Traceback (most recent call last):
  File "/home/pi/code/cpython/Lib/ctypes/test/test_functions.py", line 146, in test_doubleresult_var
    self.assertEqual(result, 21)
AssertionError: -7.086855952261741e-44 != 21

test_ctypes failed

== Tests result: FAILURE ==

1 test failed:
    test_ctypes

Total duration: 3.8 sec
Tests result: FAILURE

----------
components: ctypes
files: ctypes_variadic_function_tests.diff
keywords: patch
messages: 361992
nosy: Nicolas Dessart
priority: normal
severity: normal
status: open
title: variadic function call broken on armhf when passing a float argument
versions: Python 3.9
Added file: https://bugs.python.org/file48895/ctypes_variadic_function_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39632>
_______________________________________

From report at bugs.python.org  Fri Feb 14 05:11:07 2020
From: report at bugs.python.org (Nicolas Dessart)
Date: Fri, 14 Feb 2020 10:11:07 +0000
Subject: [issue39632] variadic function call broken on armhf when passing a
 float argument
In-Reply-To: <1581674608.19.0.403543141988.issue39632@roundup.psfhosted.org>
Message-ID: <1581675067.42.0.0583922597947.issue39632@roundup.psfhosted.org>


Change by Nicolas Dessart <nicolas.dessart at gmail.com>:


Added file: https://bugs.python.org/file48896/ctypes_variadic_function_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39632>
_______________________________________

From report at bugs.python.org  Fri Feb 14 05:11:19 2020
From: report at bugs.python.org (Nicolas Dessart)
Date: Fri, 14 Feb 2020 10:11:19 +0000
Subject: [issue39632] variadic function call broken on armhf when passing a
 float argument
In-Reply-To: <1581674608.19.0.403543141988.issue39632@roundup.psfhosted.org>
Message-ID: <1581675079.53.0.341343596615.issue39632@roundup.psfhosted.org>


Change by Nicolas Dessart <nicolas.dessart at gmail.com>:


Removed file: https://bugs.python.org/file48895/ctypes_variadic_function_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39632>
_______________________________________

From report at bugs.python.org  Fri Feb 14 06:44:39 2020
From: report at bugs.python.org (Mark Hammond)
Date: Fri, 14 Feb 2020 11:44:39 +0000
Subject: [issue39631] Fix file association MIME type on Windows
In-Reply-To: <1581670182.52.0.370257427786.issue39631@roundup.psfhosted.org>
Message-ID: <1581680679.05.0.0963372346122.issue39631@roundup.psfhosted.org>


Change by Mark Hammond <mhammond at skippinet.com.au>:


----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39631>
_______________________________________

From report at bugs.python.org  Fri Feb 14 09:06:58 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 14 Feb 2020 14:06:58 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
Message-ID: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

At the moment running python -m venv venv or python3 -m venv venv creates a virtual environment that does not contain a python<major>.<minor> symlink, which results in executing whatever the default python is when running i.e. python<major>.<minor> within an activated virtual env. OTOH if one runs python<major>.<minor> -m venv venv, then everything is OK. Would it be possible to include a python<major>.<minor> symlink in all cases? If not, then I think we should update the docs to mention that somewhere, since it took me quite a while to figure this out.

----------
components: Library (Lib)
messages: 361993
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: venv does not include python<major>.<minor> symlink by default
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Fri Feb 14 11:03:01 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 14 Feb 2020 16:03:01 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1581696181.39.0.0358044159418.issue18819@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Fri Feb 14 13:23:16 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 18:23:16 +0000
Subject: [issue33983] unify types for lib2to3.pytree.Base.children
In-Reply-To: <1530131899.35.0.56676864532.issue33983@psf.upfronthosting.co.za>
Message-ID: <1581704596.84.0.107477849745.issue33983@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> Isn't children annotated as List in typeshed?

Yes, lib2to3.pytree.Base.children is annotated as a list of (Node or Leafs)
https://github.com/python/typeshed/blob/ea0a9c2bd6f6a69c3e49b47870e0109d98316fc6/stdlib/2and3/lib2to3/pytree.pyi#L23

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33983>
_______________________________________

From report at bugs.python.org  Fri Feb 14 13:41:01 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 14 Feb 2020 18:41:01 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581705661.99.0.246037787419.issue39633@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Fri Feb 14 14:37:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 19:37:52 +0000
Subject: [issue39159] Ideas for making ast.literal_eval() usable
In-Reply-To: <1577658169.97.0.393062022698.issue39159@roundup.psfhosted.org>
Message-ID: <1581709072.61.0.522497316363.issue39159@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> 1) We should document possible exceptions that need to be caught.  So far, I've found TypeError, MemoryError, SyntaxError, ValueError.

Maybe we should wrap all of these into something like LiteralEvalError to easily catch all of them, LiteralEvalError can be subclass of that four but I guess in some cases this change might break code.

> 2) Define a size limit guaranteed not to give a MemoryError.  The smallest unsafe size I've found so far is 301 characters:

>>> s = "(" * 101 + ")" * 101
>>> len(s)
202
>>> ast.literal_eval(s)
s_push: parser stack overflow
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/ast.py", line 61, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/usr/local/lib/python3.9/ast.py", line 49, in parse
    return compile(source, filename, mode, flags,
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).

Can you explain it a bit more detailed, how does this standalone expression compiler should work?

----------
components: +Library (Lib)
nosy: +BTaskaya
type:  -> enhancement
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39159>
_______________________________________

From report at bugs.python.org  Fri Feb 14 15:29:40 2020
From: report at bugs.python.org (Harsh Patel)
Date: Fri, 14 Feb 2020 20:29:40 +0000
Subject: [issue39634] Incorrect heapq heapify naming
Message-ID: <1581712180.36.0.700524012127.issue39634@roundup.psfhosted.org>


New submission from Harsh Patel <harsh at nyu.edu>:

heapify method is a misnomer in that it is actually the make-heap or build-heap procedure from textbooks

----------
components: Library (Lib)
messages: 361996
nosy: hp685
priority: normal
pull_requests: 17888
severity: normal
status: open
title: Incorrect heapq heapify naming

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Fri Feb 14 15:42:51 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 20:42:51 +0000
Subject: [issue28308] Accelerate 'string'.format(value,
 ...) by using formatted string literals
In-Reply-To: <1475139004.07.0.645331102167.issue28308@psf.upfronthosting.co.za>
Message-ID: <1581712971.45.0.0952481055062.issue28308@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28308>
_______________________________________

From report at bugs.python.org  Fri Feb 14 15:49:46 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 20:49:46 +0000
Subject: [issue34822] Simplify AST for slices
In-Reply-To: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>
Message-ID: <1581713386.75.0.445924506906.issue34822@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

Serhiy, any plans to bump this patch to 3.9 and continue / merge? In general the benefits looks great, but on the other hand this might cause some breakage which I guess as @nascheme is OK in AST.

----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Fri Feb 14 15:58:12 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 20:58:12 +0000
Subject: [issue38131] compile(mode='eval') uninformative error message
In-Reply-To: <1568283719.06.0.851695472479.issue38131@roundup.psfhosted.org>
Message-ID: <1581713892.69.0.884580979024.issue38131@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +benjamin.peterson, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38131>
_______________________________________

From report at bugs.python.org  Fri Feb 14 16:11:17 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 21:11:17 +0000
Subject: [issue39562] Asynchronous comprehensions don't work in asyncio REPL
In-Reply-To: <1580923705.71.0.29233909242.issue39562@roundup.psfhosted.org>
Message-ID: <1581714677.63.0.106241825181.issue39562@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39562>
_______________________________________

From report at bugs.python.org  Fri Feb 14 16:13:46 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 21:13:46 +0000
Subject: [issue39159] Ideas for making ast.literal_eval() usable
In-Reply-To: <1577658169.97.0.393062022698.issue39159@roundup.psfhosted.org>
Message-ID: <1581714826.68.0.977480622217.issue39159@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> 1) We should document possible exceptions that need to be caught.  So far, I've found TypeError, MemoryError, SyntaxError, ValueError.

Also, an addition to these errors is RecursionError
>>> t = ast.Tuple(elts=[], ctx=ast.Load())
>>> t.elts.append(t)
>>> ast.literal_eval(t)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/ast.py", line 101, in literal_eval
    return _convert(node_or_string)
  File "/usr/local/lib/python3.9/ast.py", line 81, in _convert
    return tuple(map(_convert, node.elts))
  File "/usr/local/lib/python3.9/ast.py", line 81, in _convert
    return tuple(map(_convert, node.elts))
  File "/usr/local/lib/python3.9/ast.py", line 81, in _convert
    return tuple(map(_convert, node.elts))
  [Previous line repeated 496 more times]
RecursionError: maximum recursion depth exceeded

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39159>
_______________________________________

From report at bugs.python.org  Fri Feb 14 16:38:25 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 14 Feb 2020 21:38:25 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1581716305.29.0.0514710859624.issue39537@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39537>
_______________________________________

From report at bugs.python.org  Fri Feb 14 16:59:24 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 14 Feb 2020 21:59:24 +0000
Subject: [issue39634] Incorrect heapq heapify naming
In-Reply-To: <1581712180.36.0.700524012127.issue39634@roundup.psfhosted.org>
Message-ID: <1581717564.42.0.271702525987.issue39634@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The "-ify" or "-fy" suffix in English means "to make". For example, "amplify", "magnify", "terrify", etc.

https://en.wiktionary.org/wiki/-ify

So heapify literally means "make into a heap". Not only is the name correct, but it is a better name for an in-place operation than either of the terms you give:

* "build-heap" does not describe an in-place operation;
* "make-heap" is ambiguous in whether it is in-place or not.

But even if we agreed that the name needs to change to match text books (which text books?), since heapify is a public function, we cannot just change the name. We would have to keep the old name around for many, many years, possibly forever.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Fri Feb 14 17:02:21 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 14 Feb 2020 22:02:21 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581717741.55.0.160168916647.issue12915@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 1ed61617a4a6632905ad6a0b440cd2cafb8b6414 by Vinay Sajip in branch 'master':
bpo-12915: Add pkgutil.resolve_name (GH-18310)
https://github.com/python/cpython/commit/1ed61617a4a6632905ad6a0b440cd2cafb8b6414


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Fri Feb 14 17:07:09 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 14 Feb 2020 22:07:09 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581718029.41.0.396248418495.issue12915@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Fri Feb 14 17:10:16 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 14 Feb 2020 22:10:16 +0000
Subject: [issue39618] logger.exception with default message
In-Reply-To: <1581530191.64.0.316604727727.issue39618@roundup.psfhosted.org>
Message-ID: <1581718216.81.0.0873181329642.issue39618@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sorry, I don't think this change is a good idea. It's not clear what the value is in logging exceptions with no message.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39618>
_______________________________________

From report at bugs.python.org  Fri Feb 14 17:14:57 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 14 Feb 2020 22:14:57 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581718497.68.0.314776079892.issue39633@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

When a venv is activated, only one Python interpreter is active - whichever one the venv was created with. Why would you want to invoke it with `pythonX.Y` when `python` would do? I don't think that this is something people generally do - this has never come up before AFAIK. What if you invoked it with the wrong values of X.Y?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Fri Feb 14 17:30:28 2020
From: report at bugs.python.org (Harsh Patel)
Date: Fri, 14 Feb 2020 22:30:28 +0000
Subject: [issue39634] Incorrect heapq heapify naming
In-Reply-To: <1581717564.42.0.271702525987.issue39634@roundup.psfhosted.org>
Message-ID: <CAJT45QioWnFdR_eVVQWss9vdbNVmuC6iNCH-ojmuCSPqqGFVwA@mail.gmail.com>


Harsh Patel <harsh at nyu.edu> added the comment:

This ticket is not intended to rename heapify method in the stdlib (its too
late for that). This is to merely add a clarification in the docs to state
that heapify here has a different connotation than what's used in standard
algorithmic literature (CLRS, Sedgewick etc).  See here
https://xlinux.nist.gov/dads/HTML/heapify.html

References:
https://algs4.cs.princeton.edu/24pq/
http://math.utoledo.edu/~codenth/Fall_16/4380/heap-hw.pdf

On Fri, Feb 14, 2020 at 2:00 PM Steven D'Aprano <report at bugs.python.org>
wrote:

>
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
>
> The "-ify" or "-fy" suffix in English means "to make". For example,
> "amplify", "magnify", "terrify", etc.
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wiktionary.org_wiki_-2Dify&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=owI_YZl60rgj74U9tzqxcA&m=jUulcI-27ChSIukpI4uzg0LktqA5zRt9HI8Lz0JxRYU&s=o95nXSmjNMCHMbmoWeL7LildI9qwEdnusnlAOenreQ4&e=
>
> So heapify literally means "make into a heap". Not only is the name
> correct, but it is a better name for an in-place operation than either of
> the terms you give:
>
> * "build-heap" does not describe an in-place operation;
> * "make-heap" is ambiguous in whether it is in-place or not.
>
> But even if we agreed that the name needs to change to match text books
> (which text books?), since heapify is a public function, we cannot just
> change the name. We would have to keep the old name around for many, many
> years, possibly forever.
>
> ----------
> nosy: +steven.daprano
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.python.org_issue39634&d=DwIFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=owI_YZl60rgj74U9tzqxcA&m=jUulcI-27ChSIukpI4uzg0LktqA5zRt9HI8Lz0JxRYU&s=kE5QfuakDzLUOPpeWAGCf7Z0zJeeeC1iDUSj-bMFzrE&e=
> >
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Fri Feb 14 17:35:24 2020
From: report at bugs.python.org (Harsh Patel)
Date: Fri, 14 Feb 2020 22:35:24 +0000
Subject: [issue39634] Add clarification in documentation for incorrect heapq
 heapify naming
In-Reply-To: <1581712180.36.0.700524012127.issue39634@roundup.psfhosted.org>
Message-ID: <1581719724.57.0.0905183132882.issue39634@roundup.psfhosted.org>


Change by Harsh Patel <harsh at nyu.edu>:


----------
title: Incorrect heapq heapify naming -> Add clarification in documentation for incorrect heapq heapify naming

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Fri Feb 14 20:16:18 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 15 Feb 2020 01:16:18 +0000
Subject: [issue39634] Add clarification in documentation for heapq.heapify
 naming
In-Reply-To: <1581712180.36.0.700524012127.issue39634@roundup.psfhosted.org>
Message-ID: <1581729378.9.0.35214947911.issue39634@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
title: Add clarification in documentation for incorrect heapq heapify naming -> Add clarification in documentation for heapq.heapify naming
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Fri Feb 14 20:19:13 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 15 Feb 2020 01:19:13 +0000
Subject: [issue39634] Add clarification in documentation for heapq.heapify
 naming
In-Reply-To: <1581712180.36.0.700524012127.issue39634@roundup.psfhosted.org>
Message-ID: <1581729553.13.0.661336260112.issue39634@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Fri Feb 14 21:24:08 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 15 Feb 2020 02:24:08 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581733448.32.0.827998781115.issue39633@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

The thing is that some projects I've worked on, like pegen, include a Makefile which uses `pythonX.Y` to choose the version and I have to change it to `python` quite frequently. 

I can't really figure out any way this could harm anyone, other than what you said (running `pythonX.Y` with the wrong values for X and Y), but even in that case you get something like `command not fonund` and that's an easy enough typo to find.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sat Feb 15 01:08:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Feb 2020 06:08:37 +0000
Subject: [issue39634] Add clarification in documentation for heapq.heapify
 naming
In-Reply-To: <1581712180.36.0.700524012127.issue39634@roundup.psfhosted.org>
Message-ID: <1581746917.22.0.47658551411.issue39634@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you, but I'm going to decline this suggestion.

The docs are pretty clear about what heapify does:

* "To create a heap, use a list initialized to [], or you can transform a populated list into a heap via function heapify()."

* "Transform list x into a heap, in-place, in linear time."

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39634>
_______________________________________

From report at bugs.python.org  Sat Feb 15 01:12:53 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 15 Feb 2020 06:12:53 +0000
Subject: [issue17050] argparse.REMAINDER doesn't work as first argument
In-Reply-To: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>
Message-ID: <1581747173.26.0.375147399026.issue17050@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Paul's suggestion.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17050>
_______________________________________

From report at bugs.python.org  Sat Feb 15 05:02:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 15 Feb 2020 10:02:24 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581760944.25.0.775928419919.issue12915@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The regex looks too strict. Python 3 accepts non-ASCII module names.

Should existing functions be modified to reuse the new function?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Feb 15 05:20:36 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 15 Feb 2020 10:20:36 +0000
Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za>
Message-ID: <1581762036.3.0.0502522181346.issue20184@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17889
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18512

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20184>
_______________________________________

From report at bugs.python.org  Sat Feb 15 05:22:55 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 15 Feb 2020 10:22:55 +0000
Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9
 files
In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za>
Message-ID: <1581762175.02.0.0889614878475.issue20184@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Looks like `builtins.vars` and `builtins.dir` should be migrated to AC too, so I create PR18512.

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20184>
_______________________________________

From report at bugs.python.org  Sat Feb 15 05:57:43 2020
From: report at bugs.python.org (=?utf-8?q?Fr=C3=A9d=C3=A9ric_Danna?=)
Date: Sat, 15 Feb 2020 10:57:43 +0000
Subject: [issue39635] One paragraph of the doc is not translated in French
Message-ID: <1581764263.43.0.781386094953.issue39635@roundup.psfhosted.org>


New submission from Fr?d?ric Danna <frederic.danna at gmail.com>:

In the French doc of the 3.8 version, https://docs.python.org/fr/3/tutorial/interpreter.html, there is an entire parapragph which is still writtent in Englush (not translated in French):
> On Windows machines where you have installed Python from the
> Microsoft Store, the python3.8 command will be available. If you have
> the py.exe launcher installed, you can use the py command. See
> Digression : D?finition des variables d'environnement for other ways
> to launch Python.
```
(See the screenshot attached.)

----------
assignee: docs at python
components: Documentation
files: ksnip_20200215-115221.png
messages: 362009
nosy: Fr?d?ric Danna, docs at python
priority: normal
severity: normal
status: open
title: One paragraph of the doc is not translated in French
versions: Python 3.8
Added file: https://bugs.python.org/file48897/ksnip_20200215-115221.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39635>
_______________________________________

From report at bugs.python.org  Sat Feb 15 06:01:47 2020
From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0J/QsNGA0LjQtdCy?=)
Date: Sat, 15 Feb 2020 11:01:47 +0000
Subject: [issue39636] Can't change Treeview row color in Tkinter
Message-ID: <1581764507.66.0.693125881903.issue39636@roundup.psfhosted.org>


New submission from ???? ?????? <oleg.pariev at gmail.com>:

Good afternoon! Cannot change the color of a Treeview string in Python version 3.8.x. The same problem would be in Python version 3.7.3, but a solution for it does not help. You can see the question by reference: https://bugs.python.org/issue36468

PS Sorry for the clumsy English

----------
components: Tkinter
messages: 362010
nosy: gpolo, serhiy.storchaka, ???? ??????
priority: normal
severity: normal
status: open
title: Can't change Treeview row color in Tkinter
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39636>
_______________________________________

From report at bugs.python.org  Sat Feb 15 06:23:56 2020
From: report at bugs.python.org (Rick van Rein)
Date: Sat, 15 Feb 2020 11:23:56 +0000
Subject: [issue39637] Probably incorrect message after failed import
Message-ID: <1581765836.84.0.753268318543.issue39637@roundup.psfhosted.org>


New submission from Rick van Rein <rick at openfortress.nl>:

The following error message surprises me:

>>> import os.environ
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'os.environ'; 'os' is not a package

Shouldn't that say that "'environ' is not a package" instead?

After all, 'os' will support

>>> import os.path
>>> 

This is confusing :)

----------
components: Interpreter Core
messages: 362011
nosy: vanrein
priority: normal
severity: normal
status: open
title: Probably incorrect message after failed import
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39637>
_______________________________________

From report at bugs.python.org  Sat Feb 15 06:32:26 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 15 Feb 2020 11:32:26 +0000
Subject: [issue39638] Keep ASDL signatures for AST nodes
Message-ID: <1581766346.86.0.0377348739096.issue39638@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

It would be super convenient to keep ASDL declarations in AST nodes. There are multiple benefits of it;

1 -> When debugging or playing with the AST, time to time you may require to know what kind of things a field gets or is that field an optional one. 

2 -> The AST nodes are pretty limited on what can they do by default. For extending their scope, 3rd party tools often copy python's ASDL to their source and build custom AST nodes from that. And with knowing what every field gets they can automatically generate autotransformer codes from that ASDL spec which takes python's standard AST and convert it to their own AST nodes. 

We can either create a new attribute or keep this in the docstring. I think keeping this in the docstring can at least give some info about the node rather than None so it makes more sense to me. If the feature wanted, I can propose a PR.

----------
components: Library (Lib)
messages: 362012
nosy: BTaskaya, benjamin.peterson, pablogsal
priority: low
severity: normal
status: open
title: Keep ASDL signatures for AST nodes
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39638>
_______________________________________

From report at bugs.python.org  Sat Feb 15 06:38:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Feb 2020 11:38:28 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1581766708.92.0.838398157064.issue39537@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Every bytecode is generated from some AST node which has an associated range of lines. So there should not be bytecodes that have no line number.

If for some reasons you generate bytecodes that have no line number, you can just set lineno > end_lineno for them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39537>
_______________________________________

From report at bugs.python.org  Sat Feb 15 06:46:49 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 15 Feb 2020 11:46:49 +0000
Subject: [issue39639] Remote Suite node from AST
Message-ID: <1581767209.41.0.653411841191.issue39639@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

AST is containing a node from past that is explained as "not really an actual node but useful in Jython's typesystem.". There is no usage of it anywhere in the CPython repo, just some code in ast_optimizer, symbol table and compiler to forbid it from running. If there is not any specific reason to keep it, we can just remove and clean some code.

----------
components: Library (Lib)
messages: 362014
nosy: BTaskaya, benjamin.peterson, brett.cannon, pablogsal, yselivanov
priority: normal
severity: normal
status: open
title: Remote Suite node from AST
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39639>
_______________________________________

From report at bugs.python.org  Sat Feb 15 06:47:40 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 15 Feb 2020 11:47:40 +0000
Subject: [issue39639] Remove Suite node from AST
In-Reply-To: <1581767209.41.0.653411841191.issue39639@roundup.psfhosted.org>
Message-ID: <1581767260.54.0.818924689343.issue39639@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
priority: normal -> low
title: Remote Suite node from AST -> Remove Suite node from AST

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39639>
_______________________________________

From report at bugs.python.org  Sat Feb 15 07:08:27 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 15 Feb 2020 12:08:27 +0000
Subject: [issue39637] Probably incorrect message after failed import
In-Reply-To: <1581765836.84.0.753268318543.issue39637@roundup.psfhosted.org>
Message-ID: <1581768507.64.0.80911870738.issue39637@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Shouldn't that say that "'environ' is not a package" instead?

No. The os module is special, so I'll talk about the usual case first.

Normally, for `import spam.eggs` to succeed, *spam* has to be a package, and *eggs* has to be either a sub-module inside that package, or a sub-package. So the general error message is correct. You can't normally use the dotted import syntax to import functions from a module.

But the `os` module is special: it is very old, pre-dating the invention of packages, and the `os` module fakes a pretend package for `os.path` by doing this:

    sys.modules['os.path'] = path


So even though `os` is not a package, you can still use dotted package syntax to import `os.path`.

I guess this was intended as a convenience, without considering how this could be confusing.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39637>
_______________________________________

From report at bugs.python.org  Sat Feb 15 07:33:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 15 Feb 2020 12:33:14 +0000
Subject: [issue39639] Remove Suite node from AST
In-Reply-To: <1581767209.41.0.653411841191.issue39639@roundup.psfhosted.org>
Message-ID: <1581769994.15.0.206546221096.issue39639@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17890
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18513

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39639>
_______________________________________

From report at bugs.python.org  Sat Feb 15 07:35:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Feb 2020 12:35:04 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1581770104.13.0.248996828285.issue32892@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +17891
pull_request: https://github.com/python/cpython/pull/18514

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Sat Feb 15 07:50:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Feb 2020 12:50:56 +0000
Subject: [issue34822] Simplify AST for slices
In-Reply-To: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>
Message-ID: <1581771056.62.0.137221288442.issue34822@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Updated the PR.

I can obviously be biased about my changes, so I need an approval of other core developer to merge them.

I created several PRs to popular third-party projects which work with AST to support both old and new AST schemes.

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Sat Feb 15 08:14:57 2020
From: report at bugs.python.org (Rick van Rein)
Date: Sat, 15 Feb 2020 13:14:57 +0000
Subject: [issue39637] Probably incorrect message after failed import
In-Reply-To: <1581768507.64.0.80911870738.issue39637@roundup.psfhosted.org>
Message-ID: <5E47EEC2.6070101@openfortress.nl>


Rick van Rein <rick at openfortress.nl> added the comment:

Thanks for explaining.  It is indeed confusing, even though I'm quite experienced with Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39637>
_______________________________________

From report at bugs.python.org  Sat Feb 15 08:15:44 2020
From: report at bugs.python.org (Rick van Rein)
Date: Sat, 15 Feb 2020 13:15:44 +0000
Subject: [issue39637] Probably incorrect message after failed import
In-Reply-To: <1581765836.84.0.753268318543.issue39637@roundup.psfhosted.org>
Message-ID: <1581772544.69.0.949764903638.issue39637@roundup.psfhosted.org>


Change by Rick van Rein <rick at openfortress.nl>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39637>
_______________________________________

From report at bugs.python.org  Sat Feb 15 08:26:09 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 15 Feb 2020 13:26:09 +0000
Subject: [issue39639] Remove Suite node from AST
In-Reply-To: <1581767209.41.0.653411841191.issue39639@roundup.psfhosted.org>
Message-ID: <1581773169.69.0.703047040833.issue39639@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I am not sure there have any relation with jython's python.asdl?

https://github.com/jythontools/jython/blob/master/ast/Python.asdl#L10

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39639>
_______________________________________

From report at bugs.python.org  Sat Feb 15 09:19:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Feb 2020 14:19:19 +0000
Subject: [issue39635] One paragraph of the doc is not translated in French
In-Reply-To: <1581764263.43.0.781386094953.issue39635@roundup.psfhosted.org>
Message-ID: <1581776359.71.0.915035561867.issue39635@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Translation related issues are tracked under separate GitHub repo. Please report at https://github.com/python/python-docs-fr

----------
nosy: +mdk, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39635>
_______________________________________

From report at bugs.python.org  Sat Feb 15 09:39:24 2020
From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0J/QsNGA0LjQtdCy?=)
Date: Sat, 15 Feb 2020 14:39:24 +0000
Subject: [issue39636] Can't change Treeview row color in Tkinter
In-Reply-To: <1581764507.66.0.693125881903.issue39636@roundup.psfhosted.org>
Message-ID: <1581777564.48.0.617170764196.issue39636@roundup.psfhosted.org>


???? ?????? <oleg.pariev at gmail.com> added the comment:

I noticed that the background does not change, but the foreground changes well

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39636>
_______________________________________

From report at bugs.python.org  Sat Feb 15 10:45:30 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 15 Feb 2020 15:45:30 +0000
Subject: [issue4080] unittest: display time used by each test case
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1581781530.09.0.69376438212.issue4080@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Sat Feb 15 12:18:48 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Feb 2020 17:18:48 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581787128.12.0.90641808115.issue39633@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Except that if there's a global other pythonX.Y of the different version, that would get run ... potentially even more confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sat Feb 15 12:23:21 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Feb 2020 17:23:21 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581787401.24.0.766462079649.issue12915@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> The regex looks too strict. Python 3 accepts non-ASCII module names.

Would adding the re.U flag be enough, or are you thinking of other possibilities?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Feb 15 12:33:13 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Feb 2020 17:33:13 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581787993.56.0.615972888613.issue12915@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

To be more precise, one could use

^(?!\d)(\w+)(\.(?!\d)(\w+))* for _DOTTED_WORDS and use the re.U flag when compiling the pattern. That should match any packages where segments start with a letter and continue with alphanumerics. Do you agree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Feb 15 12:35:23 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 15 Feb 2020 17:35:23 +0000
Subject: [issue39638] Keep ASDL signatures for AST nodes
In-Reply-To: <1581766346.86.0.0377348739096.issue39638@roundup.psfhosted.org>
Message-ID: <1581788123.79.0.268494875077.issue39638@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17892
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39638>
_______________________________________

From report at bugs.python.org  Sat Feb 15 12:52:59 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 15 Feb 2020 17:52:59 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581789179.8.0.206689552731.issue39633@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

You're right! That could be very confusing. But isn't this risk already there, since this could happen if one runs `python3.8 -m venv venv` and then `python3.7` with the venv activated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sat Feb 15 14:06:08 2020
From: report at bugs.python.org (George Melikov)
Date: Sat, 15 Feb 2020 19:06:08 +0000
Subject: [issue39640] fall back os.fdatasync() to fsync() on POSIX systems
 without fdatasync() support
Message-ID: <1581793568.31.0.586113837137.issue39640@roundup.psfhosted.org>


New submission from George Melikov <mail at gmelikov.ru>:

POSIX fdatasync() is similar to fsync() but it tries not to sync non-needed metadata. If POSIX OS doesn't have it - it's safe to use fsync() (If we need to sync data to disk - we have to use one of these functions).

This change will help to run code with fdatasync() on MacOS without fallbacks in Python code.

I'll propose a PR soon.

----------
components: IO
messages: 362025
nosy: gmelikov
priority: normal
severity: normal
status: open
title: fall back os.fdatasync() to fsync() on POSIX systems without fdatasync() support

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39640>
_______________________________________

From report at bugs.python.org  Sat Feb 15 14:25:47 2020
From: report at bugs.python.org (George Melikov)
Date: Sat, 15 Feb 2020 19:25:47 +0000
Subject: [issue39640] fall back os.fdatasync() to fsync() on POSIX systems
 without fdatasync() support
In-Reply-To: <1581793568.31.0.586113837137.issue39640@roundup.psfhosted.org>
Message-ID: <1581794747.79.0.388984308021.issue39640@roundup.psfhosted.org>


Change by George Melikov <mail at gmelikov.ru>:


----------
keywords: +patch
pull_requests: +17893
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18516

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39640>
_______________________________________

From report at bugs.python.org  Sat Feb 15 14:32:06 2020
From: report at bugs.python.org (Derek Wilson)
Date: Sat, 15 Feb 2020 19:32:06 +0000
Subject: [issue31116] base85 z85 variant encoding
In-Reply-To: <1581671887.19.0.997085751453.issue31116@roundup.psfhosted.org>
Message-ID: <CABTuCMsJXUTWJmNZGaB9vaMGOTFs+0mFY+4_SwsPb7Cvo_iD_Q@mail.gmail.com>


Derek Wilson <jderekwilson at gmail.com> added the comment:

z85 avoids all of:

` \ " ' _ , ;

Backtick and semicolon increase the number of places that z85 can be used
without issue over b85. All of these might not be as big an issue in python
as in other tools/languages but interoperability would still be improved
through the addition of z85.

- Derek

On Fri, Feb 14, 2020, 09:18 Dobatymo <report at bugs.python.org> wrote:

>
> Dobatymo <the-real-hazzard at outlook.com> added the comment:
>
> base64.b85encode does not use ", ' or \ as well.
>
> That's the _b85alphabet
>
> _b85alphabet = (b"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
>                 b"abcdefghijklmnopqrstuvwxyz!#$%&()*+-;<=>?@^_`{|}~")
>
> ----------
> nosy: +Dobatymo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31116>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31116>
_______________________________________

From report at bugs.python.org  Sat Feb 15 14:35:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Feb 2020 19:35:40 +0000
Subject: [issue39640] fall back os.fdatasync() to fsync() on POSIX systems
 without fdatasync() support
In-Reply-To: <1581793568.31.0.586113837137.issue39640@roundup.psfhosted.org>
Message-ID: <1581795340.27.0.98042771332.issue39640@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

fsync() may be slower than fdatasync(). There may be cases in which you prefer to not call fsync() or call it less often if POSIX fdatasync() is not available. To do this you should know whether Python fdatasync() calls POSIX fdatasync() or fsync(). The simplest way to provide this information to user is to not provide os.fdatasync() in the underlying system call is not available.

Note also that this change will not help to run code with fdatasync() on MacOS without fallbacks in Python code until you drop support of all Python versions older than 3.9.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39640>
_______________________________________

From report at bugs.python.org  Sat Feb 15 14:42:16 2020
From: report at bugs.python.org (George Melikov)
Date: Sat, 15 Feb 2020 19:42:16 +0000
Subject: [issue39640] fall back os.fdatasync() to fsync() on POSIX systems
 without fdatasync() support
In-Reply-To: <1581793568.31.0.586113837137.issue39640@roundup.psfhosted.org>
Message-ID: <1581795736.38.0.603257851146.issue39640@roundup.psfhosted.org>


George Melikov <mail at gmelikov.ru> added the comment:

If there is a way not to sync data - you should use neither fdatasync nor fsync.

So IMHO if someone wants to sync data and want to use fdatasync - I see the only way on MacOS is to use fsync().

> Note also that this change will not help to run code with fdatasync() on MacOS without fallbacks in Python code until you drop support of all Python versions older than 3.9.

I agree, but I propose to make this change in 3.9 to get it somewhere in future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39640>
_______________________________________

From report at bugs.python.org  Sat Feb 15 14:44:24 2020
From: report at bugs.python.org (George Melikov)
Date: Sat, 15 Feb 2020 19:44:24 +0000
Subject: [issue39640] fall back os.fdatasync() to fsync() on POSIX systems
 without fdatasync() support
In-Reply-To: <1581793568.31.0.586113837137.issue39640@roundup.psfhosted.org>
Message-ID: <1581795864.25.0.575004871539.issue39640@roundup.psfhosted.org>


George Melikov <mail at gmelikov.ru> added the comment:

I want to add that it's a usual practice:
- https://github.com/libuv/libuv/pull/1580/files/bdd987a9b4347164e31e22d2d5ce06fbb5ebc859
- https://rev.ng/gitlab/revng/qemu/commit/6f1953c4c14566d3303709869fd26201828b3ccf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39640>
_______________________________________

From report at bugs.python.org  Sat Feb 15 15:08:57 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 15 Feb 2020 20:08:57 +0000
Subject: [issue31116] base85 z85 variant encoding
In-Reply-To: <1501799542.97.0.652442678927.issue31116@psf.upfronthosting.co.za>
Message-ID: <1581797337.79.0.0116648057673.issue31116@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pitrou
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31116>
_______________________________________

From report at bugs.python.org  Sat Feb 15 15:51:59 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 15 Feb 2020 20:51:59 +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: <1581799919.51.0.0838929267122.issue39090@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

If we want something mnemonic, I'm sure nothing beats __abs__. (Hey, we have __truediv__ already!;)

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Sat Feb 15 16:23:34 2020
From: report at bugs.python.org (Ben Boeckel)
Date: Sat, 15 Feb 2020 21:23:34 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581801814.61.0.885259547338.issue39624@roundup.psfhosted.org>


Ben Boeckel <bugs.python at me.benboeckel.net> added the comment:

Should be replaced (using $prefix here, but equally viable for $exec_prefix). Each quoted line is a path using a raw string.

r"$prefix"
r"$prefix/foo"

and on Windows:

r"$prefix\bar"

These should *not* be replaced:

r"$prefixvar/subdir"
r"not/a/$prefix"
r"$prefix spacevar/subdir"

because here, the `$prefix` is part of another path component. This does leave the directory literally named "$prefix" in a bit of a pickle.

Like I said, it's niche, but if we're going to fix it, let's at least consider handling more cases properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Sat Feb 15 16:32:53 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Feb 2020 21:32:53 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581802373.51.0.624190418185.issue39633@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

In general, people should be working in venvs. That means that libraries should assume they are being installed into venvs. Therefore makefiles should be invoking plain "python" rather than "pythonX.Y", as they can never be sure which exact interpreter they're running under (you might have a newer one than the one in the Makefile - that shouldn't fail). Why not raise this as an issue with these projects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sat Feb 15 16:34:35 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 15 Feb 2020 21:34:35 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581802475.94.0.893629627194.issue39573@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

@vstinner would it be helpful if I went on a sweep looking for places we can use the new Py_IS_TYPE macro?

Getting away from Py_TYPE(op) would also mean a move to making the internals const-correct.

----------
nosy: +petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sat Feb 15 16:36:06 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 15 Feb 2020 21:36:06 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581802566.0.0.562077645883.issue39573@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

I'm hoping that a goal here is to make

static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type)

actually be

static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sat Feb 15 16:38:47 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 15 Feb 2020 21:38:47 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581802373.51.0.624190418185.issue39633@roundup.psfhosted.org>
Message-ID: <CANiJEH-Q+rGVGx12UFSYhcEvzZ6yBfNWhGtdov_iYK=QVK7E+w@mail.gmail.com>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

That's right. I'll do that then. Thanks for baring with me.

Should we update the docs to mentiom this or just close this issue?

On Sat, Feb 15, 2020, 22:33 Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> In general, people should be working in venvs. That means that libraries
> should assume they are being installed into venvs. Therefore makefiles
> should be invoking plain "python" rather than "pythonX.Y", as they can
> never be sure which exact interpreter they're running under (you might have
> a newer one than the one in the Makefile - that shouldn't fail). Why not
> raise this as an issue with these projects?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39633>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sat Feb 15 16:48:15 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 15 Feb 2020 21:48:15 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581803295.14.0.911252919512.issue12915@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +17895
pull_request: https://github.com/python/cpython/pull/18517

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Feb 15 18:24:12 2020
From: report at bugs.python.org (bruce blosser)
Date: Sat, 15 Feb 2020 23:24:12 +0000
Subject: [issue39641] concatenation of Tuples
Message-ID: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>


New submission from bruce blosser <bruce2 at mcn.org>:

The concatenation of two tuples into a third tuple, using the + command, causes an error if every member of each of the two tuples is NOT a string!  This does not appear to be documented ANYWHERE, and really causes a whole lot of head scratching and more than enough foul language!  :)

So how does one "add" two tuples together, to create a third tuple, if the members are not all strings?

----------
messages: 362036
nosy: bruceblosser
priority: normal
severity: normal
status: open
title: concatenation of Tuples
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sat Feb 15 18:29:55 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 15 Feb 2020 23:29:55 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581809395.69.0.0896531566009.issue39641@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

tuple + tuple is NOT tuple concatenation. It adds each individual member of the tuple. So for example

(a, b) + (c, d)

results in

(a + c, b + d)

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sat Feb 15 18:30:22 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 15 Feb 2020 23:30:22 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581809422.67.0.967290786546.issue39641@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
Removed message: https://bugs.python.org/msg362037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sat Feb 15 18:31:23 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 15 Feb 2020 23:31:23 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581809483.08.0.502689390966.issue39641@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Are you trying to concatenate a single string? If so keep in mind you need a trailing comma:

>>> (1, 2) + (3, 4) + ('a',)
(1, 2, 3, 4, 'a')
>>> (1, 2) + (3, 4) + ('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate tuple (not "str") to tuple

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sat Feb 15 19:31:24 2020
From: report at bugs.python.org (szb512)
Date: Sun, 16 Feb 2020 00:31:24 +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: <1581813084.54.0.066361619754.issue28859@roundup.psfhosted.org>


szb512 <magicman730 at hotmail.com> added the comment:

I am going to think maybe it was the "os.path.ismount" command that is causing the issue. Does the file exist?

----------
nosy: +sdcards

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28859>
_______________________________________

From report at bugs.python.org  Sat Feb 15 19:36:19 2020
From: report at bugs.python.org (szb512)
Date: Sun, 16 Feb 2020 00:36:19 +0000
Subject: [issue39625] Traceback needs more details
In-Reply-To: <1581595814.35.0.681093135233.issue39625@roundup.psfhosted.org>
Message-ID: <1581813379.78.0.0363636918678.issue39625@roundup.psfhosted.org>


szb512 <magicman730 at hotmail.com> added the comment:

I think it is the "C2" class. Traceback is probably refering to that class.

----------
nosy: +sdcards

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39625>
_______________________________________

From report at bugs.python.org  Sat Feb 15 19:52:16 2020
From: report at bugs.python.org (dHannasch)
Date: Sun, 16 Feb 2020 00:52:16 +0000
Subject: [issue17050] argparse.REMAINDER doesn't work as first argument
In-Reply-To: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>
Message-ID: <1581814336.66.0.635286544086.issue17050@roundup.psfhosted.org>


dHannasch <dahanna at sandia.gov> added the comment:

Okay. Would it be all right if I submit a fix to get it working at least in the subparser case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17050>
_______________________________________

From report at bugs.python.org  Sat Feb 15 22:00:03 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 16 Feb 2020 03:00:03 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581822003.1.0.483390002962.issue39641@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> The concatenation of two tuples into a third tuple, using the + command, causes an error if every member of each of the two tuples is NOT a string!

Works for me:

    py> ("Hello", 1, None) + (23, 19.5, "Goodbye")
    ('Hello', 1, None, 23, 19.5, 'Goodbye')

If you still think there is a bug here, please follow the advice given here

http://www.sscce.org/

before re-opening this ticket.

----------
nosy: +steven.daprano
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sat Feb 15 22:11:33 2020
From: report at bugs.python.org (Clinton Hunter)
Date: Sun, 16 Feb 2020 03:11:33 +0000
Subject: [issue39642] Behaviour of disabled widgets: widget.bind(func) -vs- w
 = widget(command=func)
Message-ID: <1581822693.94.0.0781458615006.issue39642@roundup.psfhosted.org>


New submission from Clinton Hunter <mrshr3d at gmail.com>:

Using the bind method, the event will still trigger when the widget is disabled.  However, if using "command=" it doesn't.  Wondering whether the behaviour between the two ways of setting up event handling should behave the same?  Not a major issue, easy enough to work around using an if.

Example:

Clicking the printBtn will still work despite being disabled.

self.printBtn = tkinter.Button(self.frame, text='Print')
self.printBtn['state'] = tkinter.DISABLED
self.printBtn.bind(sequence='<Button-1>', func=self.printBtn_onclick)
self.printBtn.pack()


Clicking on the save button, the event will not trigger (ie the disabled state attribute is honored)

self.saveBtn = tkinter.Button(self.frame, text='Save', command=self.saveBtn_onclick)
self.saveBtn['state'] = tkinter.DISABLED
self.saveBtn.pack()

----------
components: Tkinter
messages: 362043
nosy: mrshr3d
priority: normal
severity: normal
status: open
title: Behaviour of disabled widgets:   widget.bind(func)  -vs-  w = widget(command=func)
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39642>
_______________________________________

From report at bugs.python.org  Sat Feb 15 23:11:57 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 04:11:57 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1581826317.11.0.224760627596.issue39382@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sun Feb 16 00:41:42 2020
From: report at bugs.python.org (Ivan Babrou)
Date: Sun, 16 Feb 2020 05:41:42 +0000
Subject: [issue39643] Python calls newfstatat for "<frozen
 importlib._bootstrap>" in inspect
Message-ID: <1581831702.4.0.180608885783.issue39643@roundup.psfhosted.org>


New submission from Ivan Babrou <ivan at ivan.computer>:

I noticed that a program (SaltStack) is a lot slower under Python 3. After some stracing I was able to find that inspect module is to blame.

In strace output I can see a ton of calls like this:

05:31:56.698829 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4cf0, 0) = -1 ENOENT (No such file or directory) <0.000033>
05:31:56.699743 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4b70, 0) = -1 ENOENT (No such file or directory) <0.000061>
05:31:56.701328 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap_external>", 0x7ffff6bc4cf0, 0) = -1 ENOENT (No such file or directory) <0.000037>
05:31:56.702171 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap_external>", 0x7ffff6bc4b70, 0) = -1 ENOENT (No such file or directory) <0.000031>
05:31:56.703614 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4cf0, 0) = -1 ENOENT (No such file or directory) <0.000031>
05:31:56.704421 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4b70, 0) = -1 ENOENT (No such file or directory) <0.000028>
05:31:56.705751 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4cf0, 0) = -1 ENOENT (No such file or directory) <0.000039>
05:31:56.706691 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4b70, 0) = -1 ENOENT (No such file or directory) <0.000028>
05:31:56.708148 newfstatat(AT_FDCWD, "<frozen importlib._bootstrap>", 0x7ffff6bc4cf0, 0) = -1 ENOENT (No such file or directory) <0.000032>

This is the entrypoint from Salt:

* https://github.com/saltstack/salt/blob/9adc2214c3bb/salt/utils/decorators/__init__.py#L102

Execution with stock code:

$ time sudo salt-call --local test.ping
local:
    True

real	0m23.481s
user	0m22.845s
sys	0m0.649s

Speedup after not calling into inspect.stack():

$ time sudo salt-call --local test.ping
local:
    True

real	0m3.661s
user	0m3.253s
sys	0m0.423s

Stackoverflow suggests that frames with virtual importlib should be skipped:

* https://stackoverflow.com/questions/40945752/inspect-who-imported-me

----------
messages: 362044
nosy: Ivan Babrou
priority: normal
severity: normal
status: open
title: Python calls newfstatat for "<frozen importlib._bootstrap>" in inspect
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39643>
_______________________________________

From report at bugs.python.org  Sun Feb 16 01:23:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Feb 2020 06:23:46 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1581834226.88.0.0648437778252.issue39382@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/issue39382>
_______________________________________

From report at bugs.python.org  Sun Feb 16 01:46:13 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 06:46:13 +0000
Subject: [issue39644] Add Binary module.
Message-ID: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>


New submission from Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:

Add binary module that has binary operations like:

binary addition.
binary subtracion.
binary multiplication.
binary division.
compliment.
1's complement.
2's complement.
cconverting to various number system.
converting to BCD.
converting to grey code.
K-Map function

and so on..

----------
components: C API
messages: 362045
nosy: Ananthakrishnan
priority: normal
severity: normal
status: open
title: Add Binary module.
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 01:58:31 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 06:58:31 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581836311.12.0.638784839528.issue39644@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
nosy: +mark.dickinson, serhiy.storchaka, tim.peters -Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:04:57 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 07:04:57 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581836697.02.0.230086944961.issue39644@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:06:48 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 07:06:48 +0000
Subject: [issue39642] Behaviour of disabled widgets: widget.bind(func) -vs- w
 = widget(command=func)
In-Reply-To: <1581822693.94.0.0781458615006.issue39642@roundup.psfhosted.org>
Message-ID: <1581836808.81.0.430371830516.issue39642@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +gpolo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39642>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:12:29 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 07:12:29 +0000
Subject: [issue39625] Traceback needs more details
In-Reply-To: <1581595814.35.0.681093135233.issue39625@roundup.psfhosted.org>
Message-ID: <1581837149.43.0.649396374078.issue39625@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Interpreter Core
nosy: +vstinner
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39625>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:26:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 16 Feb 2020 07:26:49 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581838009.85.0.676853662155.issue39644@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

For binary addition and subtraction is it any different from https://docs.python.org/3/library/operator.html . Is there a PyPI package that implements these ideas to see how useful it already is?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:38:05 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 16 Feb 2020 07:38:05 +0000
Subject: [issue39645] Expand concurrent.futures.Future's public API
Message-ID: <1581838685.03.0.542500965222.issue39645@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

Based on the following python-ideas thread: https://mail.python.org/archives/list/python-ideas at python.org/thread/LMTQ2AI6A7UXEFVHRGHKWD33H24FGM6G/#ICJKHZ4BPIUMOPIT2TDTBIW2EH4CPNCP.

In the above ML thread, the author proposed adding a new cf.SerialExecutor class, which seems to be not a great fit for the standard library (based on the current state of the discussion, as of writing this). But, Guido mentioned the following:

> IOW I'm rather lukewarm about this -- even if you (Jonathan) have found use for it, I'm not sure how many other people would use it, so I doubt it's worth adding it to the stdlib. (The only thing the stdlib might grow could be a public API that makes implementing this feasible without overriding private methods.)

Specifically, the OPs proposal should be reasonably possible to implement (either just locally for themselves or a potential PyPI package) with a few minor additions to cf.Future's public API:

1) Add a means of *publicly* accessing the future's state (future._state) without going through the internal condition's RLock.

This would allow the developer to implement their own condition or other synchronization primitive to access the state of the future. IMO, this would best be implemented as a separate ``future.state()`` and ``future.set_state()``. 

2) Add a means of *publicly* accessing the future's result (future._result) without going through the internal condition's RLock.

This would be similar to the above, but since there's already a ``future.result()`` and ``future.set_result()``, I think it would be best implemented as an optional *sync* parameter that defaults to True. When set to False, it directly accesses future._result without the condition; when set to True, it has the current behavior. 

3) Add public global constants for the different possible future states: PENDING, RUNNING, CANCELLED, CANCELLED_AND_NOTIFIED, and FINISHED. 

This would be useful to serve as a template of possible future states for custom implementations. I also find that ``fut.set_state(cf.RUNNING)`` looks better than ``fut.state("running")`` from an API design perspective. 

Optional addition: To make ``fut.state()`` and ``fut.set_state()`` more useful for general purposes, it could have a single *sync* boolean parameter (feel free to bikeshed over the name), which changes whether it directly accesses future._state or does so safely through the condition. Presumably, the documentation would explicitly state that with sync=False, the future's state will not be synchronized across separate threads or processes. This would also allow it to have the same API as ``future.result()`` and ``future.set_result()``.

Also, as for my own personal motivation in expanding upon the public API for cf.Future, I've found that directly accessing the state of the future can be incredibly useful for debugging purposes. I made significant use of it while implementing the new *cancel_futures* parameter for executor.shutdown(). But, since future._state is a private member, there's no guarantee that it will continue to behave the same or that it can be relied upon in the long-term. This may not be a huge concern for quick debugging sessions, but could easily result in breakage when used in logging or unit tests.

----------
assignee: aeros
components: Library (Lib)
messages: 362047
nosy: aeros, bquinlan, gvanrossum, pitrou
priority: normal
severity: normal
status: open
title: Expand concurrent.futures.Future's public API
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39645>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:51:56 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 07:51:56 +0000
Subject: [issue39646] compile warning in unicodeobject.c
In-Reply-To: <1581839504.07.0.984464153298.issue39646@roundup.psfhosted.org>
Message-ID: <1581839516.8.0.533102927159.issue39646@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I will create PR later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39646>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:51:44 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 07:51:44 +0000
Subject: [issue39646] compile warning in unicodeobject.c
Message-ID: <1581839504.07.0.984464153298.issue39646@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Objects/unicodeobject.c: In function ?PyUnicode_IsIdentifier?:
./Include/cpython/unicodeobject.h:396:38: warning: ?data? may be used uninitialized in this function [-Wmaybe-uninitialized]
             ((const Py_UCS4 *)(data))[(index)] \
                                      ^
Objects/unicodeobject.c:12211:11: note: ?data? was declared here
     void *data;
           ^
In file included from ./Include/unicodeobject.h:1026:0,
                 from ./Include/Python.h:97,
                 from Objects/unicodeobject.c:42:
./Include/cpython/unicodeobject.h:391:6: warning: ?kind? may be used uninitialized in this function [-Wmaybe-uninitialized]
     ((Py_UCS4) \
      ^
Objects/unicodeobject.c:12210:9: note: ?kind? was declared here
     int kind;
         ^

----------
components: Interpreter Core
messages: 362048
nosy: shihai1991
priority: normal
severity: normal
status: open
title: compile warning in unicodeobject.c
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39646>
_______________________________________

From report at bugs.python.org  Sun Feb 16 02:53:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Feb 2020 07:53:55 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1581839635.31.0.00757326046815.issue39382@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report and patch. Agree that the code does not look safe. Do you mind to create a pull request?

Would be nice to add a test for it. The three references to the Python class are:

* the __dict__ descriptor
* the __weakref__ descriptor
* the __mro__ tuple

You can get rid of the first two by setting __slots__ = () in the class definition. But it is not so easy with the __mro__ tuple. I will try more.

----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:12:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Feb 2020 08:12:41 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581840761.17.0.0231870763766.issue39644@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is binary addition, how it differs from just addition, what type of objects it operates?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:31:53 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 16 Feb 2020 08:31:53 +0000
Subject: [issue39625] Traceback needs more details
In-Reply-To: <1581595814.35.0.681093135233.issue39625@roundup.psfhosted.org>
Message-ID: <1581841913.21.0.759013623858.issue39625@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

I don't know how common this situation is, the fact that all constructors go to __init__ here makes it a little tough in this case but normally you'd be able to tell by the function name.

One potential solution might be to show which file the error came from like this:

Traceback (most recent call last):
  File "D:\x.py", line 13, in <module>
    c = C(C1("C1"), C2("C2"))
TypeError: [D:\x.py:6] __init__() missing 1 required positional argument: 'p'

This is a pretty trivial change in ceval.c:3779 but might make the errors pretty long unless (especially now that co_filename is an absolute path) we chop them off to just the name of the file.

Including the frame information for the function about to be called would be much more difficult.

Overall this situation might not be worth improving because it's so rare but having the function location in the error might be worth having just as an extra information point.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39625>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:35:16 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 08:35:16 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581842116.09.0.642268645148.issue39644@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

It is "addition". I meant binary addition:

1110+1010=11000.
1111-1000=0111

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:36:41 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 08:36:41 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581842201.17.0.441280133965.issue39644@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

It operates only on 0 and 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:37:57 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 08:37:57 +0000
Subject: [issue39646] compile warning in unicodeobject.c
In-Reply-To: <1581839504.07.0.984464153298.issue39646@roundup.psfhosted.org>
Message-ID: <1581842277.7.0.144933186259.issue39646@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +17896
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18519

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39646>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:39:20 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 08:39:20 +0000
Subject: [issue39646] compile warning in unicodeobject.c
In-Reply-To: <1581839504.07.0.984464153298.issue39646@roundup.psfhosted.org>
Message-ID: <1581842360.31.0.0336275539344.issue39646@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I don't find a good idea so I just add init operation :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39646>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:45:26 2020
From: report at bugs.python.org (bruce blosser)
Date: Sun, 16 Feb 2020 08:45:26 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581842726.29.0.751162646788.issue39641@roundup.psfhosted.org>


bruce blosser <bruce2 at mcn.org> added the comment:

read the advice...
Yes this does work:

  ("Hello", 1, None) + (23, 19.5, "Goodbye")
    ('Hello', 1, None, 23, 19.5, 'Goodbye')
because you are not creating a 3rd string!

but try this, and it will NOT work:

FatThing= [(5, 4, "First Place"),
           (6, 6, "Fifer Place"),
           (2, 2, "Slowr Place")]
print(FatThing)  #this works

FFThing = FatThing + ('22', '32', '55')  #this causes an error!

however if you change all the members to strings, it will work!!!

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:52:53 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 16 Feb 2020 08:52:53 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581843173.69.0.199951636721.issue39633@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sun Feb 16 03:56:47 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 08:56:47 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581843407.53.0.777071030369.issue39641@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Bruce, error message says exactly why it doesn't work: you're trying to add a tuple to a list, and that doesn't work. There isn't a "third" string created anywhere, you're confused about the types of the objects. Also, please, do not re-open closed issues.

----------
nosy: +SilentGhost
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:00:25 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 09:00:25 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581843625.58.0.349741934798.issue39644@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Ananthakrishnan, you've marked this issue as belonging to C API component, why? Besides, all this functionality is already present in python, what is it you're actually interested in? What is not covered by the independent packages on pypi?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:01:37 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 09:01:37 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581843697.08.0.467324722991.issue39644@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
components: +Library (Lib) -C API

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:05:53 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 09:05:53 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581843953.2.0.841290847722.issue39644@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

I meant a module for "binary number".
It can do operations on binary number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:07:50 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 09:07:50 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581844070.18.0.933729037212.issue39644@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

>>> 0b1110 + 0b1010
24
>>> bin(0b1110 + 0b1010)
'0b11000'

Can you explain how this is not enough?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:14:00 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 09:14:00 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581844440.97.0.134913418953.issue39644@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

I think this is not present in python.
This module should contain operations that can be performed on binary numbers.
In the below examples a and b are binary numbers.

binary.add(a,b)
binary.sub(a,b)
binary.mul(a,b)
binary.div(a,b)
binary.ones_complement(a)    //returns 1's complement of a.
binary.twos_complement(a)    //returns 2's complement of a.
binary.dectobi(a)            //converts decimal "a" to binary of "a".
binary.bcd(a)                //returns bcd of a.
binary.gray(a)               //returns grey code of a.
binary.min()                 //minimizes.
binarybitodec                //converts binar "a" to decimal of "a".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:15:18 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 16 Feb 2020 09:15:18 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581844518.44.0.865063725852.issue39644@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm going to close this, for two reasons:

- It's not well-formed enough for a b.p.o. issue: there are too many details to be worked out and questions to be answered. As it stands, there's nothing actionable here.

- Adding a new module to the Python std. lib. would be a PEP-level change.

If you want to move this forward, please first take it to the python-ideas mailing list[1] for further discussion; it'll get a wider audience there than here, so that's a better place to hash out the details. Once the details are clearer, if people still think it's a good idea, then it would be time to start working on a PEP and reference implementation.

[1] https://mail.python.org/archives/list/python-ideas at python.org/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:15:31 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 16 Feb 2020 09:15:31 +0000
Subject: [issue39644] Add Binary module.
In-Reply-To: <1581835573.18.0.933405082879.issue39644@roundup.psfhosted.org>
Message-ID: <1581844531.36.0.788972764104.issue39644@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39644>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:35:59 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 16 Feb 2020 09:35:59 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581842726.29.0.751162646788.issue39641@roundup.psfhosted.org>
Message-ID: <20200216093552.GE3281@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

[Bruce]
> but try this, and it will NOT work:
> 
> FatThing= [(5, 4, "First Place"),
>            (6, 6, "Fifer Place"),
>            (2, 2, "Slowr Place")]
> print(FatThing)  #this works
> 
> FFThing = FatThing + ('22', '32', '55')  #this causes an error!

That is correct, it should cause an error because you are trying to 
concatenate a list and a tuple. This is an easier way to show the same 
behaviour:

    [] + ()  # fails with TypeError

[Bruce]
> however if you change all the members to strings, it will work!!!

I'm afraid you are mistaken. It still fails, as it should.

py> FatThing = [("a", "b", "First Place"),
...             ("c", "d", "Fifer Place"),
...             ("e", "f", "Slowr Place")]
py> FFThing = FatThing + ('22', '32', '55')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list

Please take more care when trying to report what you think is a bug. 
Remember that Python is about 30 years old and there are tens or 
hundreds of thousands of people using it every single day. 99% of the 
time, anything you, or I, find that looks like a bug, is a bug in *our* 
code, not Python. Especially when it is something as basic and 
fundamental as tuple concatenation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sun Feb 16 04:49:35 2020
From: report at bugs.python.org (bruce blosser)
Date: Sun, 16 Feb 2020 09:49:35 +0000
Subject: [issue39641] concatenation of Tuples
In-Reply-To: <1581809051.98.0.243817777705.issue39641@roundup.psfhosted.org>
Message-ID: <1581846575.64.0.588243832093.issue39641@roundup.psfhosted.org>


bruce blosser <bruce2 at mcn.org> added the comment:

ok -  well sorry, I am obviously in way over my head, and now very confused...  

I was just going by what was being said on a number of python web sites, including one where I am taking a class in intermediate python coding, and thought I was seeing a confiict between what i was being told, and what I was finding when running code.

so I will try not to come back here, unless I have some major problem, that seems more like a bug

thanks
bruce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39641>
_______________________________________

From report at bugs.python.org  Sun Feb 16 05:12:25 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 16 Feb 2020 10:12:25 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
In-Reply-To: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>
Message-ID: <1581847945.44.0.747313729685.issue39617@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

So, essentially, are you looking for a way to dynamically adjust ProcessPoolExecutor's (PPE) max_workers, rather than just upon initialization?

This seems like it would be a very reasonable enhancement to the Executor API. Specifically for PPE, it would involve expanding the call queue, which is where pending work items are moved to just before being executed by the subprocesses (and then moved to the results queue). In order for futures submitted to the executor to be cancel-able, it has to have a fixed upper limit based on the number of max_workers (but not too low so it doesn't have idle workers).

Fortunately, we are able to adjust the *maxsize* of the call queue in real-time since it's part of the public API for Queue (rather than having to create a new queue and copy all of the elements over to a new one). 

Also, in order for this to be of real benefit, we would have to join all of the processes that are no longer being used. This would likely take some time to implement properly, but without doing so, there wouldn't be a whole lot of real benefit from being able to dynamically adjust the max workers; you'd still be using up the resources to keep a bunch of idle processes alive.

I also suspect that it would require fairly extensive tests to ensure it's stability, and would be decently involved to implement it in a way that doesn't negatively impact or modify the existing behavior for ProcessPoolExecutor. But with some time and effort, I suspect it would be possible to implement this feature.

Assuming Antoine P. and Brian Q. (primary maintainers/experts for concurrent.futures) are on-board with implementing this feature, I would be willing to look into it working on it when I get the chance to.

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Sun Feb 16 05:12:42 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 16 Feb 2020 10:12:42 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
In-Reply-To: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>
Message-ID: <1581847962.19.0.944214759303.issue39617@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Sun Feb 16 05:52:39 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 10:52:39 +0000
Subject: [issue39647] Update doc of init_config.rst
Message-ID: <1581850359.34.0.448930293223.issue39647@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Due to issue36465, the desc of `dump_refs` in init_config.rst should be udpated.

----------
assignee: docs at python
components: Documentation
messages: 362066
nosy: docs at python, shihai1991, vstinner
priority: normal
severity: normal
status: open
title: Update doc of init_config.rst
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39647>
_______________________________________

From report at bugs.python.org  Sun Feb 16 05:53:59 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 10:53:59 +0000
Subject: [issue39647] Update doc of init_config.rst
In-Reply-To: <1581850359.34.0.448930293223.issue39647@roundup.psfhosted.org>
Message-ID: <1581850439.58.0.673197545912.issue39647@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +17897
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39647>
_______________________________________

From report at bugs.python.org  Sun Feb 16 07:49:33 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 16 Feb 2020 12:49:33 +0000
Subject: [issue4080] unittest: display time used by each test case
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1581857373.71.0.335796084372.issue4080@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I updated the PR for Python 3.9. I think it's ready to be merged. Can someone involved in unittest take a look at it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Sun Feb 16 07:56:28 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 16 Feb 2020 12:56:28 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581857788.5.0.779389096627.issue1635741@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Leave a note for myself:
I check the remaining object roughly(though dump_refs function), most of remaining object is 'str', such as:
'0x7f779cf88880 [13] str'->'0x7f779cf88880 [26] str'

So far, I don't know which file and fileno create those object. MAYBE I need find a hack way to sign this mallocing operation?(not sure)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Feb 16 08:38:42 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 13:38:42 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
Message-ID: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>


New submission from Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:

If we have to find the gcd of three or more numbers, now we should use 
gcd(a, gcd(b, gcd(c, gcd(d, e)))))
which will create lot of problems.

math.gcd should take "n" number of arguments,like:

gcd(a,b,c,....)

gcd(4,6,8)    //returns 2
gcd(2,5,8,6)    //returns 1
gcd(6,30,40,60,20,40)    //returns 2

----------
components: Library (Lib)
messages: 362069
nosy: Ananthakrishnan, mark.dickinson, serhiy.storchaka, steven.daprano
priority: normal
severity: normal
status: open
title: Update math.gcd() to accept "n" arguments.
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 08:41:44 2020
From: report at bugs.python.org (daniel hahler)
Date: Sun, 16 Feb 2020 13:41:44 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
Message-ID: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

It does:
```
        if '__args__' in frame.f_locals:
            args = frame.f_locals['__args__']
        else:
            args = None
        if args:
            s += reprlib.repr(args)
        else:
            s += '()'
```

However that appears to be wrong/unnecessary since the following likely, but
maybe also others:

    commit 75bb54c3d8
    Author: Guido van Rossum <guido at python.org>
    Date:   Mon Sep 28 15:33:38 1998 +0000

        Don't set a local variable named __args__; this feature no longer
        works and Greg Ward just reported a problem it caused...

    diff --git a/Lib/bdb.py b/Lib/bdb.py
    index 3ca25adbbf..f2cf4caa36 100644
    --- a/Lib/bdb.py
    +++ b/Lib/bdb.py
    @@ -46,7 +46,7 @@ def dispatch_line(self, frame):
                    return self.trace_dispatch

            def dispatch_call(self, frame, arg):
    -               frame.f_locals['__args__'] = arg
    +               # XXX 'arg' is no longer used
                    if self.botframe is None:
                            # First call of dispatch since reset()
                            self.botframe = frame

Code ref: https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/bdb.py#L551-L558.

So it should either get removed, or likely be replaced with actually displaying
the args.

For this the part could be factored out of `do_args` maybe, adjusting it for
handling non-current frames.

Of course somebody might inject/set `__args__` still (I've thought about doing that initially for pdb++, but will rather re-implement/override `format_stack_entry` instead), so support for this could be kept additionally.

----------
components: Library (Lib)
messages: 362070
nosy: blueyed
priority: normal
severity: normal
status: open
title: bdb.Bdb.format_stack_entry: checks for obsolete __args__
type: behavior
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/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 16 08:47:02 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 13:47:02 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1581860822.93.0.560725315737.issue39649@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +gvanrossum
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/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 16 08:50:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Feb 2020 13:50:53 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581861053.04.0.689541519639.issue39648@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What problems it will create?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 08:52:17 2020
From: report at bugs.python.org (Paul Marquess)
Date: Sun, 16 Feb 2020 13:52:17 +0000
Subject: [issue39650] Creating zip file where names in local header don't
 match with central header
Message-ID: <1581861137.0.0.439620748688.issue39650@roundup.psfhosted.org>


New submission from Paul Marquess <pmqs at outlook.com>:

Consider this code (based on code from an issue on StackOverflow)

import zipfile
import os

allFilesToZip = ["/tmp/tom"]

with zipfile.ZipFile(allZipPath, 'w') as allZip:
    for f in allFilesToZip:
        allZip.write(f, compress_type=zipfile.ZIP_DEFLATED)
    for zip_info in allZip.infolist():
        if zip_info.filename[-1] == '/':
            continue
        zip_info.filename = os.path.basename(zip_info.filename)

The intention of the code is to add a number of files without the path component. The problem is with the use of infolist. (Forget for now that there is an easier way to achieve the expected result.)

The code works in two steps. First it uses the zipfile.write method which will immediately writes the local file header data and the compressed payload to the zipfile on disk. Next the zipinfo entry is used to update the filename. That data gets written only to the central directory in the zip file.

The end result is a badly-formed zip file.

Here is what I see when I run the code above with both Python 2.7 & 3.7. First create the zip file

echo abcd >/tmp/tom
python zip.py

Unzip sees there is a problem

$ unzip -t abc.zip
Archive:  abc.zip
tom:  mismatching "local" filename (tmp/tom),
         continuing with "central" filename version
    testing: tom                      OK
At least one warning-error was detected in abc.zip.

Next dump the internal structure of the zip file - Note the different filename fields output

$ zipdetails abc.zip

0000 LOCAL HEADER #1       04034B50
0004 Extract Zip Spec      14 '2.0'
0005 Extract OS            00 'MS-DOS'
0006 General Purpose Flag  0000
     [Bits 1-2]            0 'Normal Compression'
0008 Compression Method    0008 'Deflated'
000A Last Mod Time         50487109 'Sat Feb  8 14:08:18 2020'
000E CRC                   2CA20FEB
0012 Compressed Length     000000D8
0016 Uncompressed Length   00000180
001A Filename Length       0007
001C Extra Length          0000
001E Filename              'tmp/tom'
0025 PAYLOAD               eP...0.....,m.F\?. .
                           888)RbM.b..$R.......YB./...Y...Nc...m{D.
                           ....pyi.I<......J..G......{:o..'?3.#E.u.
                           .).O.%d}V..0p....z......Z......r]Bc;.U.u
                           |:U.k.}.Zov..zU....h.....tm1...&P.N.....
                           i.8CUA6.&cBcMD.P#...?.A8z.......S..

00FD CENTRAL HEADER #1     02014B50
0101 Created Zip Spec      14 '2.0'
0102 Created OS            03 'Unix'
0103 Extract Zip Spec      14 '2.0'
0104 Extract OS            00 'MS-DOS'
0105 General Purpose Flag  0000
     [Bits 1-2]            0 'Normal Compression'
0107 Compression Method    0008 'Deflated'
0109 Last Mod Time         50487109 'Sat Feb  8 14:08:18 2020'
010D CRC                   00001234
0111 Compressed Length     000000D8
0115 Uncompressed Length   00000180
0119 Filename Length       0003
011B Extra Length          0000
011D Comment Length        0000
011F Disk Start            0000
0121 Int File Attributes   0000
     [Bit 0]               0 'Binary Data'
0123 Ext File Attributes   81B40000
0127 Local Header Offset   00000000
012B Filename              'tom'

012E END CENTRAL HEADER    06054B50
0132 Number of this disk   0000
0134 Central Dir Disk no   0000
0136 Entries in this disk  0001
0138 Total Entries         0001
013A Size of Central Dir   00000031
013E Offset to Central Dir 000000FD
0142 Comment Length        0000

Should zipfile allow the user to do this?

----------
components: Library (Lib)
messages: 362072
nosy: pmqs
priority: normal
severity: normal
status: open
title: Creating zip file where names in local header don't match with central header
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39650>
_______________________________________

From report at bugs.python.org  Sun Feb 16 08:59:15 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sun, 16 Feb 2020 13:59:15 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581861555.6.0.156182113381.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

It will take more time to write the statement itself and there are chances of getting mistakes as the statement is complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 09:00:28 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Feb 2020 14:00:28 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581861628.13.0.211301978347.issue39648@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

You could (should?) use reduce, then:

>>> functools.reduce(math.gcd, (6, 30, 40, 60, 20, 40))
2

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 09:44:48 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 16 Feb 2020 14:44:48 +0000
Subject: [issue39633] venv does not include python<major>.<minor> symlink by
 default
In-Reply-To: <1581689218.89.0.729047022428.issue39633@roundup.psfhosted.org>
Message-ID: <1581864288.48.0.396698759539.issue39633@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> That means that libraries should assume they are being installed into
> venvs. Therefore makefiles should be invoking plain "python" rather
> than "pythonX.Y"

In Unix, 3.x virtual environments include a "python3" symlink or copy, even if created with a "python" command. A makefile that needs Python 3 can rely on running "python3" -- but only in Unix. Though someone using Unix tools in Windows (not Cygwin or MSYS2) must already be prepared for this.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39633>
_______________________________________

From report at bugs.python.org  Sun Feb 16 10:05:06 2020
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 16 Feb 2020 15:05:06 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1581865506.91.0.716907275023.issue39010@roundup.psfhosted.org>


Ben Darnell <ben.darnell at gmail.com> added the comment:

I just spent some time digging into this. Each call to `run_forever` starts a call to `_loop_self_reading`, then attempts to cancel it before returning:

https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio/windows_events.py#L312-L325

The comment at line 321 is not entirely accurate: the future will not resolve in the future, but it may have *already* resolved, and added its callback to the call_soon queue. This callback will run if the event loop is restarted again. Since `_loop_self_reading` calls itself, this results in two copies of the "loop" running concurrently and stepping on each other's `_self_reading_futures`. 

This appears to be fairly harmless except for noise in the logs when only one of the loops is stopped cleanly.

I believe the simplest fix is for `_loop_self_reading` to compare its argument to `self._self_reading_future` to determine if it is the "current" loop and if not, don't reschedule anything.

----------
nosy: +Ben.Darnell

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Sun Feb 16 11:27:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 16 Feb 2020 16:27:31 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581870451.1.0.215679715275.issue39648@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1  This isn't hard for us to do and may be occasionally useful.

----------
nosy: +rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 11:41:58 2020
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 16 Feb 2020 16:41:58 +0000
Subject: [issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
Message-ID: <1581871318.96.0.350376923794.issue39651@roundup.psfhosted.org>


New submission from Ben Darnell <ben.darnell at gmail.com>:

Proactor and selector event loops behave differently when call_soon_threadsafe races with a concurrent call to loop.close(). In a selector event loop, call_soon_threadsafe will either succeed or raise a RuntimeError("Event loop is closed"). In a proactor event loop, it could raise this RuntimeError, but it can also raise an AttributeError due to an unguarded access to self._csock. 

https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio/proactor_events.py#L785-L787

Comments in BaseSelectorEventLoop._write_to_self indicate that this is deliberate, so the `csock is not None` check here should probably be copied to the proactor event loop version.

https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio/selector_events.py#L129-L136


I'd also accept an answer that the exact behavior of this race is undefined and it's up to the application to either arrange for all calls to call_soon_threadsafe to stop before closing the loop. However, I've had users of Tornado argue that they use the equivalent of call_soon_threadsafe in contexts where this coordination would be difficult, and I've decided that tornado's version of this method would never raise, even if there is a concurrent close. So if asyncio declines to specify which exceptions are allowed in this case, tornado will need to add a blanket `except Exception:` around calls to call_soon_threadsafe.

----------
components: asyncio
messages: 362078
nosy: Ben.Darnell, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Exceptions raised by EventLoop.call_soon_threadsafe
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:02:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Feb 2020 17:02:27 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581872547.04.0.282075746452.issue39648@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Should it take variable number of positional arguments or a single iterable argument as max() and min()?

What should it return for 0 arguments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:08:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 16 Feb 2020 17:08:16 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581872896.54.0.317089708053.issue39648@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Python as programming language provides builtin blocks. This is a good example of using functools.reduce().

But if you can provide an algorithm for calculating the GCD and LCM more efficient than sequential applying gcd() and lcm() for two arguments, it would be an argument for implementing it in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:10:07 2020
From: report at bugs.python.org (Simon Willison)
Date: Sun, 16 Feb 2020 17:10:07 +0000
Subject: [issue39652] sqlite3 bug handling column names that contain square
 braces
Message-ID: <1581873007.59.0.213823942208.issue39652@roundup.psfhosted.org>


New submission from Simon Willison <swillison at gmail.com>:

Bit of an obscure bug this one. SQLite allows column names to contain [ and ] characters, even though those are often used as delimiters in SQLite. Here's how to create such a database with bash:

```
sqlite3 /tmp/demo.db <<EOF
    BEGIN TRANSACTION;
    CREATE TABLE "data" (
        "MTU (CET)" TEXT,
        "Day-ahead Price [EUR/MWh]" TEXT
    );
    INSERT INTO "data" VALUES('01.01.2016 00:00 - 01.01.2016 01:00','23.86');
    COMMIT;
EOF
```

If you query that database from sqlite3 in Python, the `[Eur/MWh]` piece is removed from that column name:
```
In [1]: import sqlite3                                                                                                         
In [2]: conn = sqlite3.connect("/tmp/demo.db")                                                                                 
In [3]: cursor = conn.cursor()                                                                                                 
In [4]: cursor.execute("select * from data")                                                                                   
Out[4]: <sqlite3.Cursor at 0x10c70a0a0>
In [5]: cursor.fetchall()                                                                                                      
Out[5]: [('01.01.2016 00:00 - 01.01.2016 01:00', '23.86')]
In [6]: cursor.description                                                                                                     
Out[6]: 
(('MTU (CET)', None, None, None, None, None, None),
 ('Day-ahead Price', None, None, None, None, None, None))
In [7]: conn.row_factory = sqlite3.Row                                                                                         
In [8]: cursor = conn.cursor()                                                                                                 
In [9]: cursor.execute("select * from data")                                                                                   
Out[9]: <sqlite3.Cursor at 0x10c7a8490>
In [10]: row = cursor.fetchall()                                                                                                     
In [12]: row                                                                                                                   
Out[12]: <sqlite3.Row at 0x10c3fe670>
In [15]: row.keys()                                                                                                            
Out[15]: ['MTU (CET)', 'Day-ahead Price']
```
As you can see, it is missing from both `cursor.description` and from `row.keys()` here.

But... if you query that database using SQLite directly (with `.headers on` so you can see the name of the columns) it works as expected:
```
$ sqlite3 /tmp/demo.db 
SQLite version 3.24.0 2018-06-04 14:10:15
Enter ".help" for usage hints.
sqlite> .schema
CREATE TABLE IF NOT EXISTS "data" (
        "MTU (CET)" TEXT,
        "Day-ahead Price [EUR/MWh]" TEXT
    );
sqlite> .headers on
sqlite> select * from data;
MTU (CET)|Day-ahead Price [EUR/MWh]
01.01.2016 00:00 - 01.01.2016 01:00|23.86
sqlite> 
```
It looks to me like this is a bug in Python's SQLite3 module.

This was first reported here: https://github.com/simonw/sqlite-utils/issues/86

----------
components: Extension Modules
messages: 362081
nosy: simonw
priority: normal
severity: normal
status: open
title: sqlite3 bug handling column names that contain square braces
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/issue39652>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:10:39 2020
From: report at bugs.python.org (Simon Willison)
Date: Sun, 16 Feb 2020 17:10:39 +0000
Subject: [issue39652] sqlite3 bug handling column names that contain square
 braces
In-Reply-To: <1581873007.59.0.213823942208.issue39652@roundup.psfhosted.org>
Message-ID: <1581873039.73.0.751490047386.issue39652@roundup.psfhosted.org>


Change by Simon Willison <swillison at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39652>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:12:45 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 16 Feb 2020 17:12:45 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581873165.13.0.111239909804.issue39648@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Should it take variable number of positional arguments or a single iterable argument as max() and min()?

Good question: the obvious extension to the current function would be to allow it to take multiple scalar arguments. But I don't much like the mismatch that introduces with `sum` and `math.prod`, which accept a single iterable argument.

I *definitely* don't want to give `gcd` a combination API like the one `min` and `max` have.

> What should it return for 0 arguments?

That one's easy. It should return `0`. `0` is an identity for the binary `gcd` operation, and mathematically, the `gcd` is defined for *any* set of integers (finite or infinite), including the empty set. The gcd of the empty set is zero.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:13:57 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 16 Feb 2020 17:13:57 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581873237.99.0.426236696275.issue39648@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What's slightly more interesting is the return value for a single argument  `a`, where we should be careful to return `abs(a)` rather than simply `a`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:15:32 2020
From: report at bugs.python.org (Zachary)
Date: Sun, 16 Feb 2020 17:15:32 +0000
Subject: [issue39653] test_posix fails during make test
Message-ID: <1581873332.9.0.500912340754.issue39653@roundup.psfhosted.org>


New submission from Zachary <zrocks89 at gmail.com>:

Forgive me, for I am a newb and this is the first Python issue I have ever created.

My system:
Linux debian-thinkpad 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) x86_64 GNU/Linux

While attempting to run "make test" test_posix failed. As you can see in the output apparently test_posix.py can't find a directory.

I'm not sure if I can paste output here without it being illegible so I'm putting it in a paste:
https://pastebin.com/xfqEzKiw

----------
components: Installation
messages: 362084
nosy: jaguardown
priority: normal
severity: normal
status: open
title: test_posix fails during make test
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39653>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:22:25 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 17:22:25 +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: <1581873745.35.0.549518754976.issue27873@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Can this issue be closed, I see it was merged successfully?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27873>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:25:05 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 16 Feb 2020 17:25:05 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581873905.07.0.968832378463.issue39573@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17898
pull_request: https://github.com/python/cpython/pull/18521

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:32:33 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 17:32:33 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1581874353.09.0.882816176464.issue35885@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
keywords: +patch
pull_requests: +17899
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:33:02 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 17:33:02 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1581874382.24.0.472039806176.issue35885@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Created PR GH-18522

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:48:40 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 17:48:40 +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: <1581875320.23.0.86327056027.issue39128@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17900
pull_request: https://github.com/python/cpython/pull/18523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Sun Feb 16 12:49:29 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 17:49:29 +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: <1581875369.25.0.0239405987555.issue39128@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Created 2nd PR with the Algorithm documentation:
GH-18523

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:07:18 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 18:07:18 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1581876438.08.0.58230170318.issue10572@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17901
pull_request: https://github.com/python/cpython/pull/18524

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:09:29 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Feb 2020 18:09:29 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
In-Reply-To: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>
Message-ID: <1581876569.93.0.669544079327.issue39104@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a5cbab552d294d99fde864306632d7e511a75d3c by Thomas Moreau in branch 'master':
bpo-39104: Fix hanging ProcessPoolExecutor on shutdown nowait with pickling failure (GH-17670)
https://github.com/python/cpython/commit/a5cbab552d294d99fde864306632d7e511a75d3c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:10:37 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 16 Feb 2020 18:10:37 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
In-Reply-To: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>
Message-ID: <1581876637.16.0.126706075976.issue39104@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you Thomas. Ii'd rather not backport delicate changes, so closing now.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:17:09 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 16 Feb 2020 18:17:09 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1581877029.36.0.883482431088.issue27657@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
keywords: +patch
pull_requests: +17902
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/18525

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:19:45 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 16 Feb 2020 18:19:45 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1581877185.76.0.0275188156844.issue27657@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +17903
pull_request: https://github.com/python/cpython/pull/18526

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:21:28 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 18:21:28 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1581877288.82.0.107794915811.issue10572@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Moved all 6 modules tests under Lib/test/MODULE_NAME_test
Created this PR: GH-18524

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:51:00 2020
From: report at bugs.python.org (Hakan)
Date: Sun, 16 Feb 2020 18:51:00 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
Message-ID: <1581879060.98.0.6999975444.issue39654@roundup.psfhosted.org>


Change by Hakan <hakancelik96 at outlook.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, hakancelik
priority: normal
severity: normal
status: open
title: pyclbr: remove old references to class browser & add explain readmodule
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 16 13:57:24 2020
From: report at bugs.python.org (Hakan)
Date: Sun, 16 Feb 2020 18:57:24 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
Message-ID: <1581879444.43.0.421055981186.issue39654@roundup.psfhosted.org>


Change by Hakan <hakancelik96 at outlook.com>:


----------
keywords: +patch
pull_requests: +17904
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18528

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:01:03 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 16 Feb 2020 19:01:03 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
Message-ID: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

This is something revealed during issue 39411. As @terry.reedy commented pyclbr's scope is extended to functions and classes instead of just classes.

----------
nosy: +BTaskaya, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:04:57 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 16 Feb 2020 19:04:57 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581879897.18.0.551084050387.issue39648@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

This is almost all down to pragmatics for me.

For sum() and prod(), if there are only two operands then there are trivial other ways to spell that (+ and *).  So it makes most sense for them to accept iterables instead.  Essentially, e.g., nobody would ever _want_ to write sum(2, 3) instead of 2+3.

max() and min() differ in that there is no other simple way to write the 2-argument forms.  max(x, y) _is_ commonly wanted - but so is max(iterable).  It's a weird function signature, but nearly always does what's intended.

gcd() (and lcm()!) differ from both in that they're nearly always wanted with 2 arguments.  "0, 1, or >= 3 arguments" are possibilities, but rarely wanted.  It would be a PITA to need to write, e.g., gcd((x, y)) instead of gcd(x, y) for the overwhelmingly most common 2-argument case.  So they should be *args functions - provided we want to cater directly to "0, 1, or >= 3 arguments" at all.  Fine by me if we don't.  I'm only +0 on generalizing beyond "exactly 2 arguments".

For the rest, I agree with Mark.  In particular, gcd() must be 0.

Serhiy, a "bulk" gcd can be more efficient than nested function calls by exploiting a common case:  it can get out early when the gcd-so-far becomes 1 (since gcd(1, anything) == 1, it doesn't matter what the remaining arguments are).  For "random" integers, it's already the case that gcd(i, j) == 1 over 60% of the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:13:46 2020
From: report at bugs.python.org (Orwell)
Date: Sun, 16 Feb 2020 19:13:46 +0000
Subject: [issue39655] Shared_Memory attaching to incorrect Address in Windows
Message-ID: <1581880426.57.0.187010353913.issue39655@roundup.psfhosted.org>


New submission from Orwell <sticky.queue at gmail.com>:

Shared Memory is attaching to incorrect memory location ,
ex : retried the documentation example.

>>> import numpy as np
>>> a = np.array([1, 1, 2, 3, 5, 8])
>>> from multiprocessing import shared_memory
>>> shm = shared_memory.SharedMemory(create=True, size=a.nbytes)
>>> b = np.ndarray(a.shape, dtype=a.dtype, buffer=shm.buf)
>>> b[:] = a[:]
>>> b
array([1, 1, 2, 3, 5, 8])
>>> type(b)
<class 'numpy.ndarray'>
>>> type(a)
<class 'numpy.ndarray'>
>>> shm.name
'wnsm_62040dca'
>>> shm.buf
<memory at 0x000002AD10118DC0>

# In either the same shell or a new Python shell on the same machine

>>> import numpy as np
>>> from multiprocessing import shared_memory
>>> existing_shm = shared_memory.SharedMemory(name='wnsm_62040dca')
>>> c = np.ndarray((6,), dtype=np.int64, buffer=existing_shm.buf)
>>> c
array([ 4294967297, 12884901890, 34359738373,           0,           0,
                 0], dtype=int64)
>>> c[-1]
0
>>> existing_shm.buf
<memory at 0x000001CF627E8DC0>

----------
components: Windows
messages: 362093
nosy: OH, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Shared_Memory attaching to incorrect Address in Windows
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39655>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:18:07 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 16 Feb 2020 19:18:07 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1581880687.24.0.77709101035.issue37970@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset c33bdbb20cf55b3a2aa7a91bd3d91fcb59796fad by idomic in branch 'master':
bpo-37970: update and improve urlparse and urlsplit doc-strings (GH-16458)
https://github.com/python/cpython/commit/c33bdbb20cf55b3a2aa7a91bd3d91fcb59796fad


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:21:51 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 16 Feb 2020 19:21:51 +0000
Subject: [issue39656] shebanged scripts can escape from `venv` depending on
 how it was created
Message-ID: <1581880911.6.0.392245585345.issue39656@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

This is distilled from a larger example to be small/silly, however this caused real problems

A script which was intended for python3.6 exactly was written as follows:

```
#!/usr/bin/env python3.6
...
```

when creating a virtualenv with `python3.6 -m venv venv36` you end up with `python` / `python3` / `python3.6` executables in the venv

however, when creating a virtualenv with `python3 -m venv venv36` you only end up with `python` / `python3` executables

___

using `-mvirtualenv` (pypa/virtualenv) instead of venv, all three are reliably created

___

the fix is fairly straightforward, adding `f'python3.{sys.version_info[0]}'` to this tuple: https://github.com/python/cpython/blob/c33bdbb20cf55b3a2aa7a91bd3d91fcb59796fad/Lib/venv/__init__.py#L246

----------
components: Library (Lib)
messages: 362095
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: shebanged scripts can escape from `venv` depending on how it was created
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39656>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:22:23 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 16 Feb 2020 19:22:23 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1581880943.65.0.645737451667.issue37970@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Ido Michael's PR GH-16458, which I've just merged, addresses the issues brought up here regarding the doc-strings.

>From the discussion it seems that the documentation of these functions should be updated as well. I'll leave this issue open until that's done as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:24:12 2020
From: report at bugs.python.org (Orwell)
Date: Sun, 16 Feb 2020 19:24:12 +0000
Subject: [issue39655] Shared_Memory attaching to incorrect Address in Windows
 10
In-Reply-To: <1581880426.57.0.187010353913.issue39655@roundup.psfhosted.org>
Message-ID: <1581881052.53.0.00517720593353.issue39655@roundup.psfhosted.org>


Change by Orwell <sticky.queue at gmail.com>:


----------
title: Shared_Memory attaching to incorrect Address in Windows -> Shared_Memory attaching to incorrect Address in Windows 10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39655>
_______________________________________

From report at bugs.python.org  Sun Feb 16 14:34:16 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 16 Feb 2020 19:34:16 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
In-Reply-To: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>
Message-ID: <1581881656.07.0.864592604836.issue39244@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Good catch, Stefen!

This seems like we forgot to update multiprocessing.get_all_start_methods() when making the change to make "spawn" the default on macOS. I suggest updating it accordingly.

----------
keywords: +newcomer friendly
nosy: +taleinat
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Sun Feb 16 15:04:47 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 16 Feb 2020 20:04:47 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581883487.36.0.493268508164.issue39648@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I think the behavior of gcd() == 0 is correct, but it should be documented, because it isn't completely obvious.

Arguments for gcd() == 0:

- Preserves the invariant gcd(itertools.chain(iterables)) == gcd(itertools.starmap(gcd, iterables)) in the case that some iterables are empty.

- Return a "neutral element" (not technically true for negative integers because gcd(0, a) == abs(a) != a, but it does get "ignored")

Other considerations:

- The "common divisors" of the empty set are the integers d such that for all x in the empty set, d divides x, which is to say, all of the integers. Then there is no greatest of these common divisors. The same is true if we try gcd(0, 0, ... 0).

- The above is only fixed if we interpret "greatest" in the sense of divisibility, where 0 > everything because everything divides 0. In particular, we can say that g is a greatest common divisor of a_1, ..., a_n if g | a_i for all i, and for any d with d | a_i for all i, we also have d | g. Using this definition also requires that we specify that if there are two gcds, we return the positive one.
I believe this is the correct interpretation, but it may not be obvious, since it assumes that proof that such a number even exists.

- Another common definition of the greatest common divisor of {a_1, ..., a_n} is the smallest positive integer expressible as an integer linear combination x_1 a_1 + ... + x_1 a_2, where x_i are integers. But this definition breaks on gcd(), gcd(0), gcd(0, 0), etc, since no positive integers are expressible.

In short, while I agree with the behavior, I think there should be a clarifying sentence in the docs saying "returns 0 if all of the arguments are 0".

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 15:06:36 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 16 Feb 2020 20:06:36 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581883596.71.0.721876358666.issue39648@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Correction: gcd(itertools.chain(iterables)) == gcd(*map(gcd, iterables))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 15:26:50 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 16 Feb 2020 20:26:50 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581884810.12.0.331636760734.issue39648@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Correction correction: returning zero preserves the invariant below.

from math import gcd as GCD
from functools import reduce
from itertools import starmap, chain

def gcd(*args):
    return reduce(GCD, args, 0)

iterables = [[10, 20, 30],
             [],
             [0, 0, 0],
             [5],
             [-15, -10000000]]

a = gcd(*chain.from_iterable(iterables))
b = gcd(*starmap(gcd, iterables))
assert a == b == 5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 16 15:56:07 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 16 Feb 2020 20:56:07 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1581886567.16.0.0999640920668.issue10572@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

As noted in the review of the PR, keep in mind that tests are included in an installed Python instance; there is a list of test directories in the main Makefile (Makefile.pre.in) that is used by "make install".  Any movement of test directories thus needs to update the Makefile and test with an installed Python.

That said, I'm not sure what this buys us. And are any of the moved tests inherited from third-party packages that we've semi-vendorized into the cpython repo?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Sun Feb 16 15:56:53 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 20:56:53 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1581886613.01.0.405289270363.issue37970@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Tal, I can also fix that so we can close this issue.
Are you talking about the Doc/library/urllib.parse.rst file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:07:29 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 16 Feb 2020 21:07:29 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1581887249.24.0.399456331957.issue27657@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 505b6015a1579fc50d9697e4a285ecc64976397a by Senthil Kumaran in branch '3.7':
Revert "bpo-27657: Fix urlparse() with numeric paths (GH-661)" (#18526)
https://github.com/python/cpython/commit/505b6015a1579fc50d9697e4a285ecc64976397a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:10:23 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 21:10:23 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
In-Reply-To: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>
Message-ID: <1581887423.6.0.492991152093.issue39244@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
keywords: +patch
pull_requests: +17905
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18529

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:11:38 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 16 Feb 2020 21:11:38 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
In-Reply-To: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>
Message-ID: <1581887498.47.0.289747971382.issue39244@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Fixed the bug to default any macos into 'spawn'
PR: GH-18529

----------
nosy: +Ido Michael

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:19:34 2020
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Sun, 16 Feb 2020 21:19:34 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1581887974.74.0.390119267272.issue39382@roundup.psfhosted.org>


Change by Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:


----------
pull_requests: +17906
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:31:24 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 16 Feb 2020 21:31:24 +0000
Subject: [issue39655] Shared_Memory attaching to incorrect Address in Windows
 10
In-Reply-To: <1581880426.57.0.187010353913.issue39655@roundup.psfhosted.org>
Message-ID: <1581888684.34.0.742731994493.issue39655@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

shared_memory is not the problem here. Your example assumes that a.dtype is int64, but a numpy array defaults to "the minimum type required to hold the objects in the sequence", and the actual minimum depends on the size of the platform `long`. In Windows, a `long` is always 32-bit, regardless of whether the process is 32-bit or 64-bit. If [1, 1], [2, 3], and [5, 8]  are stored as int32 values, then we have the following values when unpacked as 64-bit:

    >>> int.from_bytes(b'\x01\x00\x00\x00\x01\x00\x00\x00', 'little')
    4294967297
    >>> int.from_bytes(b'\x02\x00\x00\x00\x03\x00\x00\x00', 'little')
    12884901890
    >>> int.from_bytes(b'\x05\x00\x00\x00\x08\x00\x00\x00', 'little')
    34359738373

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39655>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:40:39 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 16 Feb 2020 21:40:39 +0000
Subject: [issue39657] Bezout and Chinese Remainder Theorem in the Standard
 Library?
Message-ID: <1581889239.13.0.672135436609.issue39657@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

Should something like the following go in the standard library, most likely in the math module? I know I had to use such a thing before pow(a, -1, b) worked, but Bezout is more general. And many of the easy stackoverflow implementations of CRT congruence-combining neglect the case where the divisors are not coprime, so that's an easy thing to miss. 

def bezout(a, b):
    """
    Given integers a and b, return a tuple (x, y, g),
    where x*a + y*b == g == gcd(a, b).
    """
    # Apply the Extended Euclidean Algorithm:
    # use the normal Euclidean Algorithm on the RHS
    # of the equations
    #     u1*a + v1*b == r1
    #     u2*a + v2*b == r2
    # But carry the LHS along for the ride.
    u1, v1, r1 = 1, 0, a
    u2, v2, r2 = 0, 1, b

    while r2:
        q = r1 // r2
        u1, u2 = u2, u1-q*u2
        v1, v2 = v2, v1-q*v2
        r1, r2 = r2, r1-q*r2
        assert u1*a + v1*b == r1
        assert u2*a + v2*b == r2

    if r1 < 0:
        u1, v1, r1 = -u1, -v1, -r1

    # a_coefficient, b_coefficient, gcd
    return (u1, v1, r1)

def crt(cong1, cong2):
    """
    Apply the Chinese Remainder Theorem:
        If there are any integers x such that 
        x == a1 (mod n1) and x == a2 (mod n2),
        then there are integers a and n such that the
        above congruences both hold iff x == a (mod n)
    Given two compatible congruences (a1, n1), (a2, n2),
    return a single congruence (a, n) that is equivalent
    to both of the given congruences at the same time.
    
    Not all congruences are compatible. For example, there
    are no solutions to x == 1 (mod 2) and x == 2 (mod 4).
    For congruences (a1, n1), (a2, n2) to be compatible, it
    is sufficient, but not necessary, that gcd(n1, n2) == 1.
    """
    a1, n1 = cong1
    a2, n2 = cong2
    c1, c2, g = bezout(n1, n2)
    assert n1*c1 + n2*c2 == g
    
    if (a1 - a2) % g != 0:
        raise ValueError(f"Incompatible congruences {cong1} and {cong2}.")
    
    lcm = n1 // g * n2
    rem = (a1*c2*n2 + a2*c1*n1)//g
    return rem % lcm, lcm

assert crt((1,4),(2,3)) == (5, 12)
assert crt((1,6),(7,4)) == (7, 12)

----------
components: Library (Lib)
messages: 362106
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Bezout and Chinese Remainder Theorem in the Standard Library?
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39657>
_______________________________________

From report at bugs.python.org  Sun Feb 16 16:47:25 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 16 Feb 2020 21:47:25 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1581889645.22.0.624164330947.issue27657@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset ea316fd21527dec53e704a5b04833ac462ce3863 by Senthil Kumaran in branch '3.8':
Revert "[3.8] bpo-27657: Fix urlparse() with numeric paths (GH-16839)" (GH-18525)
https://github.com/python/cpython/commit/ea316fd21527dec53e704a5b04833ac462ce3863


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Sun Feb 16 17:12:28 2020
From: report at bugs.python.org (Luca)
Date: Sun, 16 Feb 2020 22:12:28 +0000
Subject: [issue39658] Include user scripts folder to PATH on Windows
Message-ID: <1581891148.96.0.449800548141.issue39658@roundup.psfhosted.org>


New submission from Luca <lucatrv at hotmail.com>:

When installing Python on Windows, and selecting the option ?Add Python to PATH?, the following folders are added to the "PATH" environment variable:
- C:\Users\[username]\AppData\Local\Programs\Python\Python38\Scripts\
- C:\Users\[username]\AppData\Local\Programs\Python\Python38\
However also the following folder should be added, _before_ the other two:
- C:\Users\[username]\AppData\Roaming\Python\Python38\Scripts\
This is needed to correctly expose scripts of packages installed with `pip install --user` (`pip` emits a warning when installing a script with `--user` flag if that folder is not in "PATH").

----------
components: Installation
messages: 362108
nosy: lucatrv
priority: normal
severity: normal
status: open
title: Include user scripts folder to PATH on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39658>
_______________________________________

From report at bugs.python.org  Sun Feb 16 17:21:25 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Feb 2020 22:21:25 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1581891685.4.0.995129450612.issue39649@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

That seems to be a correct observation. @blueyed, do you want to submit a PR to gt rid of the redundant check?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 16 17:33:33 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 16 Feb 2020 22:33:33 +0000
Subject: [issue39645] Expand concurrent.futures.Future's public API
In-Reply-To: <1581838685.03.0.542500965222.issue39645@roundup.psfhosted.org>
Message-ID: <1581892413.9.0.772125682111.issue39645@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I'll leave it to Brian and/or Antoine to review this. Good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39645>
_______________________________________

From report at bugs.python.org  Sun Feb 16 18:07:51 2020
From: report at bugs.python.org (daniel hahler)
Date: Sun, 16 Feb 2020 23:07:51 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1581894471.4.0.22120728971.issue39649@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
pull_requests: +17907
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18531

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 16 18:08:52 2020
From: report at bugs.python.org (daniel hahler)
Date: Sun, 16 Feb 2020 23:08:52 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1581894532.48.0.798232323504.issue39649@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

Sure: https://github.com/python/cpython/pull/18531

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 16 18:15:41 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 16 Feb 2020 23:15:41 +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: <1581894941.19.0.168445100702.issue27873@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> Can this issue be closed, I see it was merged successfully?

Yep, I'll go ahead and close the issue now. Thanks for the reminder; I got caught up in a few other projects.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27873>
_______________________________________

From report at bugs.python.org  Sun Feb 16 19:24:04 2020
From: report at bugs.python.org (sds)
Date: Mon, 17 Feb 2020 00:24:04 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
In-Reply-To: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>
Message-ID: <1581899044.55.0.467465583273.issue39617@roundup.psfhosted.org>


sds <sds at gnu.org> added the comment:

I don't think you need this complexity - just keep the pool max size and submit jobs only when the loadavg drops below the threshold.
See my implementation attached.

----------
Added file: https://bugs.python.org/file48898/run-at-load-avg.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Sun Feb 16 19:57:42 2020
From: report at bugs.python.org (Barney Gale)
Date: Mon, 17 Feb 2020 00:57:42 +0000
Subject: [issue39659] pathlib calls `os.getcwd()` without using accessor
Message-ID: <1581901062.0.0.795874471606.issue39659@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

Whereas most calls to `os` functions from `pathlib.Path` methods happen via `pathlib._Accessor` methods, retrieving the current working directory does not. This problem occurs when calling the `pathlib.Path.cwd()`, `~resolve()` and `~absolute()` methods.

----------
components: Library (Lib)
messages: 362114
nosy: barneygale
priority: normal
severity: normal
status: open
title: pathlib calls `os.getcwd()` without using accessor
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39659>
_______________________________________

From report at bugs.python.org  Sun Feb 16 21:57:16 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 17 Feb 2020 02:57:16 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1581908236.72.0.381380569432.issue38857@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

I think this deserves discussion :)

On one hand, it's a welcome change, on another it's kind of a regression.

Up until 3.8, our tests used to look like this:

---
# code under test

async def foo():
    return await bar()


# test

async def helper(value):
    return value


async def test_foo():
    with patch("bar", return_value=helper(42)):
        assert await foo() == 42
---

I feel that the default class `patch()` uses for `new` has crept in too quietly in 3.8.

At the same time, `helper` was only used because there was no `AsyncMock`.
(or at times, a 3rd party library, `asynctest` was used).



So, on one hand, it's a bit of a regression, but on the other, looking ahead, I would really like `unittest.mock` to do the right thing.



Can we have it both ways? If not, what way is a better way?

----------
nosy: +Dima.Tisnek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Sun Feb 16 22:27:53 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Feb 2020 03:27:53 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1581910073.76.0.0238413567012.issue38857@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/issue38857>
_______________________________________

From report at bugs.python.org  Sun Feb 16 23:21:55 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 17 Feb 2020 04:21:55 +0000
Subject: [issue39652] sqlite3 bug handling column names that contain square
 braces
In-Reply-To: <1581873007.59.0.213823942208.issue39652@roundup.psfhosted.org>
Message-ID: <1581913315.27.0.590391758591.issue39652@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17908
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18533

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39652>
_______________________________________

From report at bugs.python.org  Sun Feb 16 23:28:58 2020
From: report at bugs.python.org (Raul Gallegos)
Date: Mon, 17 Feb 2020 04:28:58 +0000
Subject: [issue39652] sqlite3 bug handling column names that contain square
 braces
In-Reply-To: <1581873007.59.0.213823942208.issue39652@roundup.psfhosted.org>
Message-ID: <1581913738.23.0.144043775718.issue39652@roundup.psfhosted.org>


Raul Gallegos <raul.ogh at gmail.com> added the comment:

Thanks for reporting this issue, I have a PR here https://github.com/python/cpython/pull/18533 but that still needs some clarification, because there were some tests that were actually testing that we were stripping everything after the square brackets.

P.D. this is my first contribution :)

----------
nosy: +elrull

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39652>
_______________________________________

From report at bugs.python.org  Mon Feb 17 00:44:47 2020
From: report at bugs.python.org (Leonard Lausen)
Date: Mon, 17 Feb 2020 05:44:47 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
Message-ID: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>


New submission from Leonard Lausen <leonard at lausen.nl>:

contextvars provide APIs to manage, store, and access context-local state.

Unfortunately, if Python is used as a frontend for a native libray (eg accessed via ctypes), and in case that the state of interest is managed in the native library, contextvar API is insufficient.

To support native libraries, instead of simply exposing the current state via `contextvar.get()`, contextvar API could allow specification of callbacks to update the state in the native library.

----------
messages: 362118
nosy: leezu
priority: normal
severity: normal
status: open
title: Contextvars: Optional callbacks on state change
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Mon Feb 17 01:40:35 2020
From: report at bugs.python.org (Simon Willison)
Date: Mon, 17 Feb 2020 06:40:35 +0000
Subject: [issue39652] sqlite3 bug handling column names that contain square
 braces
In-Reply-To: <1581873007.59.0.213823942208.issue39652@roundup.psfhosted.org>
Message-ID: <1581921635.89.0.833143521912.issue39652@roundup.psfhosted.org>


Simon Willison <swillison at gmail.com> added the comment:

Oh how interesting - yes it looks like this is deliberate behavior introduced in this commit: https://github.com/python/cpython/commit/0e3f591aeeef9ed715f8770320f4c4c7332a8794

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39652>
_______________________________________

From report at bugs.python.org  Mon Feb 17 01:44:14 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 17 Feb 2020 06:44:14 +0000
Subject: [issue33604] HMAC default to MD5 marked as to be removed in 3.6
In-Reply-To: <1527014760.1.0.682650639539.issue33604@psf.upfronthosting.co.za>
Message-ID: <1581921854.12.0.835869102229.issue33604@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Noted, but making it a keyword only argument would break a lot of existing code that has always just been passing three positional args.  Needless pain.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33604>
_______________________________________

From report at bugs.python.org  Mon Feb 17 02:04:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Feb 2020 07:04:52 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1581923092.87.0.0328524599232.issue39660@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:03:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Feb 2020 09:03:29 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1581930209.82.0.665437123876.issue32892@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 85a2eef473a2c9ed3ab9c6ee339891fe99adbbc9 by Serhiy Storchaka in branch 'master':
bpo-32892: Update the documentation for handling constants in AST. (GH-18514)
https://github.com/python/cpython/commit/85a2eef473a2c9ed3ab9c6ee339891fe99adbbc9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:03:52 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Feb 2020 09:03:52 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1581930232.37.0.352756364935.issue32892@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17910
pull_request: https://github.com/python/cpython/pull/18534

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:05:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:05:15 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1581930315.37.0.795759539522.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d83b6600b25487e4ebffd7949d0f478de9538875 by idomic in branch 'master':
bpo-38691 Added a switch to ignore PYTHONCASEOK when -E or -I flags passed (#18314)
https://github.com/python/cpython/commit/d83b6600b25487e4ebffd7949d0f478de9538875


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:06:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:06:53 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1581930413.93.0.339940288886.issue38691@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/issue38691>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:09:53 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Feb 2020 09:09:53 +0000
Subject: [issue32892] Remove specific constant AST types in favor of
 ast.Constant
In-Reply-To: <1519204597.27.0.467229070634.issue32892@psf.upfronthosting.co.za>
Message-ID: <1581930593.68.0.314573001621.issue32892@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 988aeba94bf1dab81dd52fc7b02dca7a57ea8ba0 by Miss Islington (bot) in branch '3.8':
bpo-32892: Update the documentation for handling constants in AST. (GH-18514)
https://github.com/python/cpython/commit/988aeba94bf1dab81dd52fc7b02dca7a57ea8ba0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32892>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:11:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:11:37 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581930697.98.0.135049590405.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b2b6e27bcab44e914d0a0b170e915d6f1604a76d by Hai Shi in branch 'master':
bpo-1635741: Port _crypt extension module to multiphase initialization (PEP 489) (GH-18404)
https://github.com/python/cpython/commit/b2b6e27bcab44e914d0a0b170e915d6f1604a76d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:13:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:13:56 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1581930836.17.0.729210445508.issue39453@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f64abd10563c25a94011f9e3335fd8a1cf47c205 by Dong-hee Na in branch '3.8':
[3.8] bpo-39453: Fix contains method of list to hold strong references (GH-18204)
https://github.com/python/cpython/commit/f64abd10563c25a94011f9e3335fd8a1cf47c205


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:14:05 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Feb 2020 09:14:05 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1581930845.54.0.670359308566.issue39453@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17911
pull_request: https://github.com/python/cpython/pull/18535

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:18:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:18:26 +0000
Subject: [issue36465] Make release and debug ABI compatible
In-Reply-To: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>
Message-ID: <1581931106.47.0.0726539089485.issue36465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a7847590f07655e794d7c62130aea245a110acef by Hai Shi in branch 'master':
bpo-36465: Update doc of init_config.rst (GH-18520)
https://github.com/python/cpython/commit/a7847590f07655e794d7c62130aea245a110acef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:18:43 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 17 Feb 2020 09:18:43 +0000
Subject: [issue36465] Make release and debug ABI compatible
In-Reply-To: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>
Message-ID: <1581931123.42.0.45491418714.issue36465@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17912
pull_request: https://github.com/python/cpython/pull/18520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:18:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:18:53 +0000
Subject: [issue39647] Update doc of init_config.rst
In-Reply-To: <1581850359.34.0.448930293223.issue39647@roundup.psfhosted.org>
Message-ID: <1581931133.64.0.936604979921.issue39647@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Make release and debug ABI compatible

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39647>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:28:47 2020
From: report at bugs.python.org (Patrick Buxton)
Date: Mon, 17 Feb 2020 09:28:47 +0000
Subject: [issue39098] OSError: handle closed,
 ProcessPoolExecutor shutdown(wait=False)
In-Reply-To: <1576761583.89.0.930155685361.issue39098@roundup.psfhosted.org>
Message-ID: <1581931727.29.0.602622762326.issue39098@roundup.psfhosted.org>


Patrick Buxton <patrick.buxton at tartansolutions.com> added the comment:

This should be fixed with https://github.com/python/cpython/pull/17670 for https://bugs.python.org/issue39104, but only for version 3.9 as no backport!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39098>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:30:48 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Feb 2020 09:30:48 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1581931848.75.0.58468840083.issue39453@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3c57ca699910be74e7cf67d747b24bbc486932f1 by Miss Islington (bot) in branch '3.7':
[3.8] bpo-39453: Fix contains method of list to hold strong references (GH-18204)
https://github.com/python/cpython/commit/3c57ca699910be74e7cf67d747b24bbc486932f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:37:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:37:52 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1581932272.5.0.339464110516.issue39453@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Dong-hee Na for the fix.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:39:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:39:57 +0000
Subject: [issue5537] LWPCookieJar cannot handle cookies with expirations of
 2038 or greater on 32-bit platforms
In-Reply-To: <1237744231.54.0.279066174651.issue5537@psf.upfronthosting.co.za>
Message-ID: <1581932397.16.0.540888968215.issue5537@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

@Paul Ganssle: it's a little sad that I have work around datetime.datetime.utcfromtimestamp() function to avoid an OverflowError exception: msg361972.

Should we fix utcfromtimestamp() internally to avoid the OverflowError, rather than only fixing the http.cookiejar module?

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5537>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:40:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:40:20 +0000
Subject: [issue34822] Simplify AST for slices
In-Reply-To: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>
Message-ID: <1581932420.48.0.177444810029.issue34822@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:43:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:43:11 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581932591.09.0.484523783044.issue39624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> These should *not* be replaced:
>
> r"not/a/$prefix"
> r"$prefix spacevar/subdir"

Honestly, I don't see an issue to replace $prefix in these examples.

These examples seem artificial. The paths are not user provided: they are hardcoded paths from the sysconfig module:

    if opts.ignore_dir:
        _prefix = sysconfig.get_path("stdlib")
        _exec_prefix = sysconfig.get_path("platstdlib")

I'm not even sure if it's worth it to fix this issue, it's unclear to me how you could get r"$prefixvar/subdir" from sysconfig.get_path("stdlib").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:46:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:46:55 +0000
Subject: [issue39625] Traceback needs more details
In-Reply-To: <1581595814.35.0.681093135233.issue39625@roundup.psfhosted.org>
Message-ID: <1581932815.63.0.567743346256.issue39625@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39625>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:48:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:48:51 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581932931.8.0.052770351438.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Getting away from Py_TYPE(op) would also mean a move to making the internals const-correct.

Would you mind to explain how it's an issue to modify PyObject* temporarily during a function call? It's common to increase the object reference count to ensure that it doesn't go even while we use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Mon Feb 17 04:46:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 09:46:33 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581932793.6.0.908311865843.issue12915@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue to discuss the non-ASCII identifiers.

Currently, the code uses [a-z_]\w*, but "?" is a valid Python module name for example:

$ echo 'print("here")' > ?.py
$ python3 -c 'import ?'
here

I'm not sure how to design the regex. I just reported a potential issue ;-) See the PEP 3131 and str.isidentifier() method:
https://docs.python.org/dev/library/stdtypes.html#str.isidentifier

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Mon Feb 17 05:09:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 10:09:24 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581934164.87.0.358351104649.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1b55b65638254aa78b005fbf0b71fb02499f1852 by Dong-hee Na in branch 'master':
bpo-39573: Clean up modules and headers to use Py_IS_TYPE() function (GH-18521)
https://github.com/python/cpython/commit/1b55b65638254aa78b005fbf0b71fb02499f1852


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Mon Feb 17 05:47:40 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 17 Feb 2020 10:47:40 +0000
Subject: [issue39657] Bezout and Chinese Remainder Theorem in the Standard
 Library?
In-Reply-To: <1581889239.13.0.672135436609.issue39657@roundup.psfhosted.org>
Message-ID: <1581936460.5.0.947870116998.issue39657@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Should something like the following go in the standard library, most likely in the math module?

I'm not keen. Granted that the math module has exceeded its original remit of "wrappers for libm", but even so, I'd prefer to try to limit it to a basic set of building blocks. For me, things like CRT and xgcd go beyond that.

I'd suggest that for now, the right place for this sort of thing would be a PyPI library for elementary number theory. That library could include probably primality testing, basic factoring, continued fractions, primitive root finding, and other elementary number theory topics.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39657>
_______________________________________

From report at bugs.python.org  Mon Feb 17 06:23:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 11:23: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: <1581938636.06.0.891182013353.issue37096@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close the issue. The test was fixed in bpo-39488:

commit b39fb8e847ac59b539ad7e93df91c1709815180e
Author: Giampaolo Rodola <g.rodola at gmail.com>
Date:   Wed Feb 5 18:20:52 2020 +0100

    bpo-39488: Skip test_largefile tests if not enough disk space (GH-18261)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37096>
_______________________________________

From report at bugs.python.org  Mon Feb 17 06:31:44 2020
From: report at bugs.python.org (Ben Boeckel)
Date: Mon, 17 Feb 2020 11:31:44 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581939104.78.0.251044352454.issue39624@roundup.psfhosted.org>


Ben Boeckel <bugs.python at me.benboeckel.net> added the comment:

> The paths are not user provided: they are hardcoded paths from the sysconfig module:

No, those paths are the *replacement* values, not the input. From the trace docs:

>   trace.py -c -f counts --ignore-dir '$prefix' spam.py eggs

This is the string where `$prefix` is replaced with the value retrieved from `sysconfig`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Mon Feb 17 07:05:30 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Mon, 17 Feb 2020 12:05:30 +0000
Subject: [issue39659] pathlib calls `os.getcwd()` without using accessor
In-Reply-To: <1581901062.0.0.795874471606.issue39659@roundup.psfhosted.org>
Message-ID: <1581941130.23.0.469983625126.issue39659@roundup.psfhosted.org>


Emmanuel Arias <eamanu at yaerobi.com> added the comment:

Sorry, I cannot catch what is the problem of not use _Accesor on PurePath class

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39659>
_______________________________________

From report at bugs.python.org  Mon Feb 17 07:17:27 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Mon, 17 Feb 2020 12:17:27 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581941847.84.0.561975028984.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

It should take variable number of positional arguments.
it should return:
>>math.gcd()
0
>>math.gcd(8)
8
>>math.gcd(-8)
8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:26:48 2020
From: report at bugs.python.org (Joe Cool)
Date: Mon, 17 Feb 2020 13:26:48 +0000
Subject: =?utf-8?q?=5Bissue39661=5D_TimedRotatingFileHandler_doesn=E2=80=99t_handl?=
 =?utf-8?q?e_DST_switch_with_daily_rollover?=
Message-ID: <1581946008.38.0.701805565144.issue39661@roundup.psfhosted.org>


New submission from Joe Cool <snoopyjc at gmail.com>:

TimedRotatingFileHandler doesn?t handle the switch to/from DST when using daily/midnight rotation. It does not adjust the rollover time so the rollover will be off by an hour. 

Parameters: when=?midnight?, utc=False

----------
components: Library (Lib)
messages: 362140
nosy: snoopyjc
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler doesn?t handle DST switch with daily rollover
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39661>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:41:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 13:41:22 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1581946882.27.0.411615763773.issue39500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3d235f5c5c5bce6e0caec44d2ce17f670c2ca2d7 by Hai Shi in branch 'master':
bpo-39500: Fix compile warnings in unicodeobject.c (GH-18519)
https://github.com/python/cpython/commit/3d235f5c5c5bce6e0caec44d2ce17f670c2ca2d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:42:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 13:42:15 +0000
Subject: [issue39646] compile warning in unicodeobject.c
In-Reply-To: <1581839504.07.0.984464153298.issue39646@roundup.psfhosted.org>
Message-ID: <1581946935.57.0.728995444421.issue39646@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Yeah, I saw the warning, but it's a false alarm. Values are always initialized. Anyway. Thanks for fixing them ;-)

----------
nosy: +vstinner
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Document PyUnicode_IsIdentifier() function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39646>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:49:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 13:49:33 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581947373.56.0.137938439113.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7d7956833cc37a9d42807cbfeb7dcc041970f579 by Hai Shi in branch 'master':
bpo-1635741: Port _contextvars module to multiphase initialization (PEP 489) (GH-18374)
https://github.com/python/cpython/commit/7d7956833cc37a9d42807cbfeb7dcc041970f579


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:50:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 13:50:39 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1581947439.4.0.520102714291.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4c1b6a6f4fc46add0097efb3026cf3f0c89f88a2 by Hai Shi in branch 'master':
bpo-1635741: Port _abc extension to multiphase initialization (PEP 489) (GH-18030)
https://github.com/python/cpython/commit/4c1b6a6f4fc46add0097efb3026cf3f0c89f88a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:51:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 17 Feb 2020 13:51:48 +0000
Subject: [issue39624] Trace greedy replaces $prefix and $exec_prefix
In-Reply-To: <1581583995.62.0.313310245437.issue39624@roundup.psfhosted.org>
Message-ID: <1581947508.86.0.516016342002.issue39624@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Do you want to propose to write a PR to fix this issue?

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39624>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:51:38 2020
From: report at bugs.python.org (=?utf-8?b?56aP5rC46Zm95bmz?=)
Date: Mon, 17 Feb 2020 13:51:38 +0000
Subject: [issue39662] Characters are garbled when displaying Byte data
Message-ID: <1581947498.56.0.86314760045.issue39662@roundup.psfhosted.org>


New submission from ???? <yohei.fukunaga at gmail.com>:

Hex data is garbled when displaying received data from serial.

--- code ---
recvMessage = serialPort.readline()
print(recvMessage, end="\r\n")
------------

--- result ---
b'ERXUDP FE80:0000:0000:0000:0280:8700:3015:64F5 FE80:0000:0000:0000:021D:1290:0003:8331 0E1A 0E1A 00808700301564F5 1 0012 \x10\x81\x00\x01\x02\x88\x01\x05\xff\x01r\x01\xe7\x04\x00\x00\x02\x04\r\n'
--------------

Mysterious value of 0x01r.
When the corresponding value is judged, it becomes 0x72.

The correct behavior is...
--- correct result ---
b'ERXUDP FE80:0000:0000:0000:0280:8700:3015:64F5 FE80:0000:0000:0000:021D:1290:0003:8331 0E1A 0E1A 00808700301564F5 1 0012 \x10\x81\x00\x01\x02\x88\x01\x05\xff\x72\x01\xe7\x04\x00\x00\x02\x04\r\n'
--------------

----------
components: IO
messages: 362145
nosy: ????
priority: normal
severity: normal
status: open
title: Characters are garbled when displaying Byte data
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39662>
_______________________________________

From report at bugs.python.org  Mon Feb 17 08:55:13 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 17 Feb 2020 13:55:13 +0000
Subject: [issue39646] compile warning in unicodeobject.c
In-Reply-To: <1581839504.07.0.984464153298.issue39646@roundup.psfhosted.org>
Message-ID: <1581947713.69.0.82209679973.issue39646@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

you are welcome ;0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39646>
_______________________________________

From report at bugs.python.org  Mon Feb 17 09:16:41 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 17 Feb 2020 14:16:41 +0000
Subject: [issue39662] Characters are garbled when displaying Byte data
In-Reply-To: <1581947498.56.0.86314760045.issue39662@roundup.psfhosted.org>
Message-ID: <1581949001.76.0.952484908107.issue39662@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

How do you know that isn't what is coming in over the serial port? I don't see any indication that this is a bug in python.

We can't really help you here with this sort of problem. I suggest you take this to the python-list mailing list: https://mail.python.org/mailman/listinfo/python-list

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39662>
_______________________________________

From report at bugs.python.org  Mon Feb 17 09:23:16 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 17 Feb 2020 14:23:16 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
Message-ID: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

Per msg313179, Terry asked to see tests for when the find_good_parse_start() call returns 0 instead of None.  There are two cases when a 0 might be returned:

1.  If the code is on the first line in the editor beginning with one of the matching keywords and ending in ":\n", such as "def spam():\n".
2.  If the code on the first line is entered as "def spam(", then the hyperparser adds the " \n" in its call to set_code and find_good_parse_start returns a 0.

----------
assignee: terry.reedy
components: IDLE
messages: 362149
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Add additional tests for pyparse
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 09:27:54 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 17 Feb 2020 14:27:54 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581949674.14.0.584418753653.issue39663@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +17913
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 11:20:31 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Feb 2020 16:20:31 +0000
Subject: =?utf-8?q?=5Bissue39661=5D_TimedRotatingFileHandler_doesn=E2=80=99t_handl?=
 =?utf-8?q?e_DST_switch_with_daily_rollover?=
In-Reply-To: <1581946008.38.0.701805565144.issue39661@roundup.psfhosted.org>
Message-ID: <1581956431.63.0.649345866785.issue39661@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39661>
_______________________________________

From report at bugs.python.org  Mon Feb 17 11:23:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Feb 2020 16:23:29 +0000
Subject: [issue39664] Improve test coverage for operator module
Message-ID: <1581956609.58.0.543593561813.issue39664@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

This ticket adds tests for operator module where some of the parts where not tested. Current coverage stands at 96.23% [0]. The added tests will get it closer to 100% and will help in testing the Python implementation of operator module.

[0] https://codecov.io/gh/python/cpython/branch/master/history/Lib/operator.py

----------
components: Tests
messages: 362150
nosy: xtreak
priority: normal
severity: normal
status: open
title: Improve test coverage for operator module
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39664>
_______________________________________

From report at bugs.python.org  Mon Feb 17 11:30:15 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Feb 2020 16:30:15 +0000
Subject: [issue39664] Improve test coverage for operator module
In-Reply-To: <1581956609.58.0.543593561813.issue39664@roundup.psfhosted.org>
Message-ID: <1581957015.06.0.321074555072.issue39664@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +17914
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18537

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39664>
_______________________________________

From report at bugs.python.org  Mon Feb 17 11:32:05 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Mon, 17 Feb 2020 16:32:05 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
 =?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
 =?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1581957125.6.0.80415429824.issue9182@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

Is this issue still needed?
Can I add a pull request for this.

----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Mon Feb 17 12:00:26 2020
From: report at bugs.python.org (ppperry)
Date: Mon, 17 Feb 2020 17:00:26 +0000
Subject: [issue39665] Cryptic error message when creating types that don't
 include themselves in their MRO
Message-ID: <1581958826.66.0.0275141327571.issue39665@roundup.psfhosted.org>


New submission from ppperry <mapreader at olum.org>:

I was trying to create a class that didn't have any references to itself to test issue39382 and ran the following code:

class Meta(type):
	def mro(cls):
		return type.mro(cls)[1:]
class X(metaclass=Meta):
	    pass

This produced an extremely cryptic error message:

Traceback (most recent call last):
  File "<pyshell#89>", line 1, in <module>
    class X(metaclass=Meta):
TypeError: super(type, obj): obj must be an instance or subtype of type

While what I am trying to do may well not be supported, the error message referencing the `super` function, which I didn't use, is not helpful.

----------
components: Build, Interpreter Core
messages: 362152
nosy: ppperry
priority: normal
severity: normal
status: open
title: Cryptic error message when creating types that don't include themselves in their MRO
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39665>
_______________________________________

From report at bugs.python.org  Mon Feb 17 13:12:00 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 17 Feb 2020 18:12:00 +0000
Subject: [issue39666] IDLE: Factor out similar code in editor and hyperparser
Message-ID: <1581963120.77.0.85896962977.issue39666@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

Under issue32989, there was discussion about refactoring duplicate code between hyperparser and editor.

> Perhaps separate issue: the 'if use_ps1' statements in editor and hyperparser, and a couple of lines before, is nearly identical, and could be factored into a separate editor method that returns a parser instance ready for analysis.  It could then be tested in isolation.  The method should return a parser instance ready for analysis.

----------
assignee: terry.reedy
components: IDLE
messages: 362153
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Factor out similar code in editor and hyperparser
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39666>
_______________________________________

From report at bugs.python.org  Mon Feb 17 13:25:16 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Mon, 17 Feb 2020 18:25:16 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1581963916.63.0.342189459554.issue36184@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
keywords: +patch
pull_requests: +17915
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18538

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36184>
_______________________________________

From report at bugs.python.org  Mon Feb 17 13:26:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Feb 2020 18:26:45 +0000
Subject: [issue39665] Cryptic error message when creating types that don't
 include themselves in their MRO
In-Reply-To: <1581958826.66.0.0275141327571.issue39665@roundup.psfhosted.org>
Message-ID: <1581964005.49.0.131155366169.issue39665@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, I got the same error message when tried to get such class.

super() is called implicitly by the type constructor to call __init_subclass__ on the parent of a newly generated type.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39665>
_______________________________________

From report at bugs.python.org  Mon Feb 17 13:31:02 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 17 Feb 2020 18:31:02 +0000
Subject: [issue39666] IDLE: Factor out similar code in editor and hyperparser
In-Reply-To: <1581963120.77.0.85896962977.issue39666@roundup.psfhosted.org>
Message-ID: <1581964262.56.0.30382085857.issue39666@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +17916
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18539

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39666>
_______________________________________

From report at bugs.python.org  Mon Feb 17 13:38:19 2020
From: report at bugs.python.org (ppperry)
Date: Mon, 17 Feb 2020 18:38:19 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1581964699.26.0.945152428818.issue39382@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

I posted a test on the PR

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Mon Feb 17 14:56:34 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 17 Feb 2020 19:56:34 +0000
Subject: [issue39662] Characters are garbled when displaying Byte data
In-Reply-To: <1581947498.56.0.86314760045.issue39662@roundup.psfhosted.org>
Message-ID: <1581969394.74.0.912859916777.issue39662@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39662>
_______________________________________

From report at bugs.python.org  Mon Feb 17 15:38:41 2020
From: report at bugs.python.org (Joe Cool)
Date: Mon, 17 Feb 2020 20:38:41 +0000
Subject: =?utf-8?q?=5Bissue39661=5D_TimedRotatingFileHandler_doesn=E2=80=99t_handl?=
 =?utf-8?q?e_DST_switch_with_daily_rollover?=
In-Reply-To: <1581946008.38.0.701805565144.issue39661@roundup.psfhosted.org>
Message-ID: <1581971921.2.0.483273194147.issue39661@roundup.psfhosted.org>


Joe Cool <snoopyjc at gmail.com> added the comment:

Never mind. I was looking for the DST code in computeRollover, and I found it in doRollover.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39661>
_______________________________________

From report at bugs.python.org  Mon Feb 17 16:41:00 2020
From: report at bugs.python.org (Barney Gale)
Date: Mon, 17 Feb 2020 21:41:00 +0000
Subject: [issue39659] pathlib calls `os.getcwd()` without using accessor
In-Reply-To: <1581901062.0.0.795874471606.issue39659@roundup.psfhosted.org>
Message-ID: <1581975660.72.0.0597977457178.issue39659@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Those methods are non-pure, i.e. part of `Path` but not `PurePath`. Only impure paths have accessors. The `_Accessor` docstring says: "an accessor implements a particular (system-specific or not) way of accessing paths on the filesystem". This abstraction is pretty pointless if covers `os.readlink()` but not `os.getcwd()`!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39659>
_______________________________________

From report at bugs.python.org  Mon Feb 17 17:34:41 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 17 Feb 2020 22:34:41 +0000
Subject: [issue39667] Update zipfile.Path with zipfile 3.0
Message-ID: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

zipp 3.0 includes enhanced support for the .open() method as well as performance improvements in 2.2.1 (https://zipp.readthedocs.io/en/latest/history.html).

----------
components: Library (Lib)
messages: 362158
nosy: jaraco
priority: normal
severity: normal
status: open
title: Update zipfile.Path with zipfile 3.0
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Mon Feb 17 17:34:57 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 17 Feb 2020 22:34:57 +0000
Subject: [issue39667] Update zipfile.Path with zipp 3.0
In-Reply-To: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>
Message-ID: <1581978897.81.0.758018603428.issue39667@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
title: Update zipfile.Path with zipfile 3.0 -> Update zipfile.Path with zipp 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Mon Feb 17 17:37:38 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 17 Feb 2020 22:37:38 +0000
Subject: [issue39667] Update zipfile.Path with zipp 3.0
In-Reply-To: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>
Message-ID: <1581979058.25.0.22868852339.issue39667@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +17917
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18540

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Mon Feb 17 17:47:13 2020
From: report at bugs.python.org (Bernardo Sulzbach)
Date: Mon, 17 Feb 2020 22:47:13 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1581979633.32.0.467665198165.issue39648@roundup.psfhosted.org>


Bernardo Sulzbach <bernardo at bernardosulzbach.com> added the comment:

I think this might make sense because gcd() could have some optimizations for n > 2, such as sorting the numbers and starting by the smallest elements.

However, I don't think gcd() and lcm() with more than two arguments are frequent use cases.

----------
nosy: +BernardoSulzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Mon Feb 17 17:59:03 2020
From: report at bugs.python.org (Jason Fried)
Date: Mon, 17 Feb 2020 22:59:03 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1581980343.37.0.269137342263.issue38857@roundup.psfhosted.org>


Jason Fried <me at jasonfried.info> added the comment:

Its not possible to have it both ways.  Also it stinks too much of trying to guess. 

The root of your issue is you want a normal MagicMock not an AsyncMock. Its the automatic behavior of patch to pick AsyncMock vs MagicMock that is the heart of your issue.  This bug fix doesn't involve that behavior at all, and AsyncMock was measurably broken without the fix, in an unavoidable way.  Your breakage is avoidable by changes to how you patch.  

 with patch("bar", return_value=42)

To still do it the old way you would have to pass new_callable=MagicMock to patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Mon Feb 17 18:05:18 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 17 Feb 2020 23:05:18 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1581980718.46.0.621873780179.issue12915@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> I'm not sure how to design the regex.

Did you not look at the PR I added to address this (Unicode chars), with a regex change? I added you as a reviewer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Mon Feb 17 18:14:15 2020
From: report at bugs.python.org (Caleb Hattingh)
Date: Mon, 17 Feb 2020 23:14:15 +0000
Subject: [issue39609] Set the thread_name_prefix for asyncio's default
 executor ThreadPoolExecutor
In-Reply-To: <1581420918.89.0.0710307394.issue39609@roundup.psfhosted.org>
Message-ID: <1581981255.9.0.0614061857943.issue39609@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

This change seems fine.

Markus,

I'm curious if there is a specific reason you prefer to use the default executor rather than replacing it with your own? Is it just convenience or are there other reasons?

----------
nosy: +cjrh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39609>
_______________________________________

From report at bugs.python.org  Mon Feb 17 18:22:57 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 17 Feb 2020 23:22:57 +0000
Subject: [issue39645] Expand concurrent.futures.Future's public API
In-Reply-To: <1581838685.03.0.542500965222.issue39645@roundup.psfhosted.org>
Message-ID: <1581981777.19.0.650939960277.issue39645@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Upon further consideration and based on recent developments in the python-ideas thread (mostly feedback from Antoine), I've decided to reduce the scope of this issue to remove future.set_state() and the *sync* parameters.

This leaves just future.state() and having the states as publicly accessible module-level constants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39645>
_______________________________________

From report at bugs.python.org  Mon Feb 17 18:33:17 2020
From: report at bugs.python.org (=?utf-8?q?Grzegorz_Kraso=C5=84?=)
Date: Mon, 17 Feb 2020 23:33:17 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
Message-ID: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>


New submission from Grzegorz Kraso? <grzegorz.krason at gmail.com>:

This causes segmentation fault:

list((lambda: None).__annotations__.__reversed__())

----------
components: Interpreter Core
messages: 362164
nosy: Grzegorz Kraso?
priority: normal
severity: normal
status: open
title: segmentation fault on calling __reversed__()
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Mon Feb 17 19:10:35 2020
From: report at bugs.python.org (Abhilash Raj)
Date: Tue, 18 Feb 2020 00:10:35 +0000
Subject: [issue39628] msg.walk memory leak?
In-Reply-To: <1581606328.48.0.533988298686.issue39628@roundup.psfhosted.org>
Message-ID: <1581984635.6.0.912566626545.issue39628@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/issue39628>
_______________________________________

From report at bugs.python.org  Mon Feb 17 19:33:14 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 18 Feb 2020 00:33:14 +0000
Subject: [issue38857] AsyncMock issue with awaitable
 return_value/side_effect/wraps
In-Reply-To: <1574204653.99.0.272373846707.issue38857@roundup.psfhosted.org>
Message-ID: <1581985994.37.0.416035953309.issue38857@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

Thank you for explanation, Jason!

I guess that the bug report and the patch were too technical for me to understand ?

I'm happy with the behaviour in Python 3.8.1 and now I know it's going to stay, I'll just change the tests in our code base.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38857>
_______________________________________

From report at bugs.python.org  Mon Feb 17 21:21:19 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 18 Feb 2020 02:21:19 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1581992479.99.0.293256342656.issue39573@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

> Would you mind to explain how it's an issue to modify PyObject* temporarily during a function call?

It's not a problem to modify the PyObject* during a function call.  However, many functions don't need to modify the object, but are still taking non-const PyObject* arguments.

For example if I have this code:

    if (Py_TYPE(deque) == &deque_type) {

That doesn't modify deque to check the type, but because Py_TYPE casts away the constness, deque can't be a const object.

However, with the new Py_IS_TYPE function:

    if (Py_IS_TYPE(deque, &deque_type)) {

and these two changes:

-static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type) {
+static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) {
     return ob->ob_type == type;
 }
-#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(_PyObject_CAST(ob), type)
+#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(((const PyObject*)(ob)), type)

the deque variable can be const.

Another example of a common pattern that I believe could benefit from this is Py_TYPE(ob)->tp_name.  That could be turned into Py_TYPE_NAME(ob) and that would allow the ob to be a const pointer. 

If we can keep functions that don't modify the object to accept const PyObject* it will help make things safer in the long run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Mon Feb 17 21:48:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Feb 2020 02:48:13 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581994093.42.0.546205721481.issue39663@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ffda25f6b825f3dee493b6f0746266a4dd6989f0 by Cheryl Sabella in branch 'master':
bpo-39663: IDLE: Add additional tests for pyparse (GH-18536)
https://github.com/python/cpython/commit/ffda25f6b825f3dee493b6f0746266a4dd6989f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 21:48:18 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 02:48:18 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581994098.46.0.580977220268.issue39663@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17918
pull_request: https://github.com/python/cpython/pull/18541

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 21:48:54 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 02:48:54 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581994134.62.0.446517618859.issue39663@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17919
pull_request: https://github.com/python/cpython/pull/18542

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:05:19 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 03:05:19 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581995119.16.0.598439613816.issue39663@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fde0041089de2d13e7c473200fb74d3956203987 by Miss Islington (bot) in branch '3.7':
bpo-39663: IDLE: Add additional tests for pyparse (GH-18536)
https://github.com/python/cpython/commit/fde0041089de2d13e7c473200fb74d3956203987


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:05:42 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 03:05:42 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581995142.93.0.538281492748.issue39663@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7fd752c1bc637aeca2bd122d07c0ebc379d0d8ca by Miss Islington (bot) in branch '3.8':
bpo-39663: IDLE: Add additional tests for pyparse (GH-18536)
https://github.com/python/cpython/commit/7fd752c1bc637aeca2bd122d07c0ebc379d0d8ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:24:38 2020
From: report at bugs.python.org (Michael Hall)
Date: Tue, 18 Feb 2020 03:24:38 +0000
Subject: [issue39651] Exceptions raised by EventLoop.call_soon_threadsafe
In-Reply-To: <1581871318.96.0.350376923794.issue39651@roundup.psfhosted.org>
Message-ID: <1581996278.7.0.573021167138.issue39651@roundup.psfhosted.org>


Change by Michael Hall <michael at michaelhall.tech>:


----------
nosy: +mikeshardmind

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39651>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:27:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Feb 2020 03:27:33 +0000
Subject: [issue39669] macOS test failures
Message-ID: <1581996453.92.0.653511763632.issue39669@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

macOS test failed twice for PR-18536, for reasons unrelated to the IDLE test additions.  Two pages gave completely different reasons.

https://github.com/python/cpython/pull/18536/checks?check_run_id=451798955

clang: warning: -framework Tk: 'linker' input unused [-Wunused-command-line-argument]
In file included from /Users/runner/runners/2.164.0/work/cpython/cpython/Modules/_tkinter.c:48:
/Applications/Xcode_11.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/tk.h:86:11: fatal error: 'X11/Xlib.h' file not found
#       include <X11/Xlib.h>
                ^~~~~~~~~~~~
1 error generated.

Python build finished successfully!

But no tests are listed.

>From clicking '...' on above page, View raw logs,
https://pipelines.actions.githubusercontent.com/E9sxbx8BNoRYbzXilV3t7ZRT2AjSeiVsTIIDUiDv0jTXfwuZPt/_apis/pipelines/1/runs/4122/signedlogcontent/6?urlExpires=2020-02-18T02%3A39%3A17.4773408Z&urlSigningMethod=HMACV1&urlSignature=ZpdM7bjMgqeUyUCyD4TLVZRYpMxqvYw%2BA9bEs0qCKfE%3D

2020-02-18T02:24:55.9857810Z ======================================================================
2020-02-18T02:24:55.9858110Z FAIL: test_case_insensitivity (test.test_importlib.extension.test_case_sensitivity.Source_ExtensionModuleCaseSensitivityTest)
2020-02-18T02:24:55.9858780Z ----------------------------------------------------------------------
2020-02-18T02:24:55.9858930Z Traceback (most recent call last):
2020-02-18T02:24:55.9859090Z   File "/Users/runner/runners/2.164.0/work/cpython/cpython/Lib/test/test_importlib/extension/test_case_sensitivity.py", line 36, in test_case_insensitivity
2020-02-18T02:24:55.9859680Z     self.assertTrue(hasattr(loader, 'load_module'))
2020-02-18T02:24:55.9859810Z AssertionError: False is not true

This happened with 2 subtests.
  
======================================================================
2020-02-18T02:24:55.9860160Z FAIL: test_insensitive (test.test_importlib.source.test_case_sensitivity.Frozen_CaseSensitivityTestPEP302)
2020-02-18T02:24:55.9860780Z ----------------------------------------------------------------------
2020-02-18T02:24:55.9860940Z Traceback (most recent call last):
2020-02-18T02:24:55.9861090Z   File "/Users/runner/runners/2.164.0/work/cpython/cpython/Lib/test/test_importlib/source/test_case_sensitivity.py", line 57, in test_insensitive
2020-02-18T02:24:55.9861400Z     self.assertIsNotNone(insensitive)
2020-02-18T02:24:55.9861530Z AssertionError: unexpectedly None

4 subtests failed.

----------
components: Tests, macOS
messages: 362170
nosy: lukasz.langa, ned.deily, ronaldoussoren, terry.reedy
priority: normal
severity: normal
status: open
title: macOS test failures
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39669>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:28:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Feb 2020 03:28:33 +0000
Subject: [issue39663] IDLE: Add additional tests for pyparse
In-Reply-To: <1581949396.83.0.321867900398.issue39663@roundup.psfhosted.org>
Message-ID: <1581996513.1.0.510705628485.issue39663@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for tracking this down.  The comment was on #32989.

----------
nosy:  -miss-islington
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39663>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:32:35 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 18 Feb 2020 03:32:35 +0000
Subject: [issue39669] macOS test failures
In-Reply-To: <1581996453.92.0.653511763632.issue39669@roundup.psfhosted.org>
Message-ID: <1581996755.42.0.0383644172388.issue39669@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Same failures for pr-18539.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39669>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:38:02 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 03:38:02 +0000
Subject: [issue39669] macOS test failures
In-Reply-To: <1581996453.92.0.653511763632.issue39669@roundup.psfhosted.org>
Message-ID: <1581997082.16.0.733207950213.issue39669@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/issue39669>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:44:43 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Feb 2020 03:44:43 +0000
Subject: [issue39669] macOS test failures
In-Reply-To: <1581996453.92.0.653511763632.issue39669@roundup.psfhosted.org>
Message-ID: <1581997483.57.0.698426811227.issue39669@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The importlib test failures have been showing up on the buildbots but haven't yet been triaged:

https://mail.python.org/archives/list/buildbot-status at python.org/thread/XMDX3AVR3HALZIPKBWB4WUV3FOAYHGUV/

It is referred here:
https://mail.python.org/archives/list/python-committers at python.org/message/7HTKJO4APMRTLGUB2N5TGJ6CJBVR3UZX/

The initial messages are a build warning just indicating that tkinter can't be built on this system with the current Apple-supplied Tk, a long-standing issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39669>
_______________________________________

From report at bugs.python.org  Mon Feb 17 22:49:55 2020
From: report at bugs.python.org (Michael Hall)
Date: Tue, 18 Feb 2020 03:49:55 +0000
Subject: [issue39232] asyncio crashes when tearing down the proactor event loop
In-Reply-To: <1578335360.75.0.333919607495.issue39232@roundup.psfhosted.org>
Message-ID: <1581997795.53.0.449843151163.issue39232@roundup.psfhosted.org>


Michael Hall <michael at michaelhall.tech> added the comment:

Linking out to a real-world example where this still manages to happen after running the event loop for an entire 2 seconds waiting for transports to close themselves after finishing everything else:

https://github.com/Cog-Creators/Red-DiscordBot/issues/3560

As well as what we're currently looking at for a temporary solution for this at this point:

https://github.com/Cog-Creators/Red-DiscordBot/pull/3566


I looked into what would need to change to handle this in CPython, but am not confident in my ability to make such a PR after doing so, at least not without more discussion about it.

The best solution I considered involves making the only public way to make transports be tied to an event loop which hasn't been closed yet, and ensuring the event loop keeps a reference to each of these so that it can deterministically close them at loop finalization. Searching GitHub alone found that this would break way too many things.

If this can't be fully fixed, a solution which at least ensures this can't cause an uncatchable exception would be appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39232>
_______________________________________

From report at bugs.python.org  Mon Feb 17 23:41:47 2020
From: report at bugs.python.org (Michael Hall)
Date: Tue, 18 Feb 2020 04:41:47 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1582000907.49.0.39181695508.issue37373@roundup.psfhosted.org>


Change by Michael Hall <michael at michaelhall.tech>:


----------
nosy: +mikeshardmind

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Tue Feb 18 00:24:56 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 18 Feb 2020 05:24:56 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
In-Reply-To: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>
Message-ID: <1582003496.0.0.310197734769.issue39668@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This works fine for me on macOS using the python.org 64-bit build.

What are you using?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Tue Feb 18 00:47:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 05:47:45 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
In-Reply-To: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>
Message-ID: <1582004865.16.0.730251034126.issue39668@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This could be fixed with 24dc2f8c56697f9ee51a4887cf0814b6600c1815 issue38525

?  cpython git:(24dc2f8c56) ./python.exe -c 'list((lambda: None).__annotations__.__reversed__())'
?  cpython git:(24dc2f8c56) git checkout HEAD~1
Previous HEAD position was 24dc2f8c56 bpo-38525: Fix a segmentation fault when using reverse iterators of empty dict (GH-16846)
HEAD is now at 88eeda6311 Remove doc reference to unmaitained Nose package (GH-16849)
?  cpython git:(88eeda6311) make -s -j4 2> /dev/null
?  cpython git:(88eeda6311) ./python.exe -c 'list((lambda: None).__annotations__.__reversed__())'
[1]    36178 segmentation fault  ./python.exe -c 'list((lambda: None).__annotations__.__reversed__())'

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Tue Feb 18 02:57:01 2020
From: report at bugs.python.org (Markus Mohrhard)
Date: Tue, 18 Feb 2020 07:57:01 +0000
Subject: [issue39609] Set the thread_name_prefix for asyncio's default
 executor ThreadPoolExecutor
In-Reply-To: <1581420918.89.0.0710307394.issue39609@roundup.psfhosted.org>
Message-ID: <1582012621.41.0.812496892946.issue39609@roundup.psfhosted.org>


Markus Mohrhard <markusm at dug.com> added the comment:

We have by now changed to a custom executor. Asyncio is used in some of our dependencies and therefore it took some work to figure out what is creating the thousands of threads that we were seeing.

This patch was part of the debuggin and we thought it would be useful for anyone else to immediately see what is creating the threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39609>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:10:39 2020
From: report at bugs.python.org (ilya)
Date: Tue, 18 Feb 2020 09:10:39 +0000
Subject: [issue39670] 2to3 fix_apply tries to fix user-defined apply function
 calls
Message-ID: <1582017039.66.0.352808121621.issue39670@roundup.psfhosted.org>


New submission from ilya <palachev.ilya at yandex.ru>:

Consider the following code:

def apply(a, b):
    print(a)
    print(b)

apply(1, 1)

2to3 suggests to fix it as follows:

--- a.py	(original)
+++ a.py	(refactored)
@@ -2,4 +2,4 @@
     print(a)
     print(b)
 
-apply(1, 1)
+(1)(*1)

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 362178
nosy: ilya
priority: normal
severity: normal
status: open
title: 2to3 fix_apply tries to fix user-defined apply function calls
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39670>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:16:20 2020
From: report at bugs.python.org (=?utf-8?q?Grzegorz_Kraso=C5=84?=)
Date: Tue, 18 Feb 2020 09:16:20 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
In-Reply-To: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>
Message-ID: <1582017380.35.0.809173141937.issue39668@roundup.psfhosted.org>


Grzegorz Kraso? <grzegorz.krason at gmail.com> added the comment:

Python 3.8.0 (default, Oct 23 2019, 18:51:26) [GCC 9.2.0] on linux
Linux anarchy 4.19.91-1-lts #1 SMP Sat, 21 Dec 2019 16:34:46 +0000 x86_64 GNU/Linux
Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:21:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 09:21:36 +0000
Subject: [issue21255] Attaching a PropertyMock records calls
In-Reply-To: <1397665155.65.0.579203534798.issue21255@psf.upfronthosting.co.za>
Message-ID: <1582017696.37.0.416615297068.issue21255@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/issue21255>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:31:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 09:31:52 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
In-Reply-To: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>
Message-ID: <1582018312.19.0.13710734189.issue39668@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please try and update to 3.8.1? It should be fixed there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:33:32 2020
From: report at bugs.python.org (Tom Pohl)
Date: Tue, 18 Feb 2020 09:33:32 +0000
Subject: [issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not
 guarantee the completion of no more than one task
Message-ID: <1582018412.2.0.458600281682.issue39671@roundup.psfhosted.org>


New submission from Tom Pohl <thomas.pohl at gmail.com>:

Currently, the documentation of asyncio.wait gives the impression that using FIRST_COMPLETED guarantees the completion of no more than one task. In reality, the number of completed task after asyncio.wait can be larger than one.

While this behavior (exactly one complete task if no error or cancellation occurred) would be ultimately desirable, a sentence describing the current behavior would be helpful for new users of asyncio.

----------
assignee: docs at python
components: Documentation
messages: 362181
nosy: docs at python, tom.pohl
priority: normal
severity: normal
status: open
title: Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39671>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:39:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 09:39:16 +0000
Subject: [issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not
 guarantee the completion of no more than one task
In-Reply-To: <1582018412.2.0.458600281682.issue39671@roundup.psfhosted.org>
Message-ID: <1582018756.97.0.473938095865.issue39671@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/issue39671>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:43:02 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 09:43:02 +0000
Subject: [issue39670] 2to3 fix_apply tries to fix user-defined apply function
 calls
In-Reply-To: <1582017039.66.0.352808121621.issue39670@roundup.psfhosted.org>
Message-ID: <1582018982.27.0.120795444739.issue39670@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

apply was a builtin in Python 2 and not sure 2to3 can differentiate between user defined functions that shadow builtins. https://docs.python.org/3.8/library/2to3.html#2to3fixer-apply .

Removes usage of apply(). For example apply(function, *args, **kwargs) is converted to function(*args, **kwargs).

You can skip the apply fixer: 2to3 -x apply /tmp/bar.py

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39670>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:49:07 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 09:49:07 +0000
Subject: [issue39546] argparse: allow_abbrev=False is ignored for alternative
 prefix characters
In-Reply-To: <1580760688.73.0.980793532046.issue39546@roundup.psfhosted.org>
Message-ID: <1582019347.17.0.843914369091.issue39546@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8edfc47baec7ff4cb1b9db83dd35c8ffc1d498a4 by Kyle Meyer in branch 'master':
bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337)
https://github.com/python/cpython/commit/8edfc47baec7ff4cb1b9db83dd35c8ffc1d498a4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39546>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:49:07 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 09:49:07 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1582019347.29.0.255905452477.issue26967@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8edfc47baec7ff4cb1b9db83dd35c8ffc1d498a4 by Kyle Meyer in branch 'master':
bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337)
https://github.com/python/cpython/commit/8edfc47baec7ff4cb1b9db83dd35c8ffc1d498a4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:49:13 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 09:49:13 +0000
Subject: [issue39546] argparse: allow_abbrev=False is ignored for alternative
 prefix characters
In-Reply-To: <1580760688.73.0.980793532046.issue39546@roundup.psfhosted.org>
Message-ID: <1582019353.55.0.0664182029715.issue39546@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17920
pull_request: https://github.com/python/cpython/pull/18543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39546>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:49:13 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 09:49:13 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1582019353.63.0.0486078499833.issue26967@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17921
pull_request: https://github.com/python/cpython/pull/18543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:50:42 2020
From: report at bugs.python.org (=?utf-8?q?Grzegorz_Kraso=C5=84?=)
Date: Tue, 18 Feb 2020 09:50:42 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
In-Reply-To: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>
Message-ID: <1582019442.04.0.0103320911131.issue39668@roundup.psfhosted.org>


Grzegorz Kraso? <grzegorz.krason at gmail.com> added the comment:

I confirm. 3.8.1 is fixed. Thank you and sorry for bothering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:51:02 2020
From: report at bugs.python.org (zd nex)
Date: Tue, 18 Feb 2020 09:51:02 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
Message-ID: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>


New submission from zd nex <zdnexnet at gmail.com>:

Hello,

so I was transferring some our old code from Python2.7 to new and find that new version seems to crash quite a lot. After some finding (good thing faulthandler) I think I tracked it down to to Shelve.__del__ method > going to C Pickle module (not python one). Here it is crash itself. Attached zip has 3 file. When shelve.close is used it does not seem to crash every time. 

$python3.8 -X faulthandler ce_test_2.py
start
end
Fatal Python error: Segmentation fault

Current thread 0x00007fb22e299740 (most recent call first):
  File "/usr/lib/python3.8/shelve.py", line 124 in __setitem__
  File "/usr/lib/python3.8/shelve.py", line 168 in sync
  File "/usr/lib/python3.8/shelve.py", line 144 in close
  File "/usr/lib/python3.8/shelve.py", line 162 in __del__
Neopr?vn?n? p??stup do pam?ti (SIGSEGV)


Code for crash is here:


import shelve
import material
data = shelve.open("test3", flag="c",writeback=True)

def test_shelve(data):
    for k,v in data.items():
        pass

print("start")
test_shelve(data)

#data.close() #fixes SIGSEGV at shutdown
#actually problem is in c pickle module; when Python pickle module is used it works

print("end")
#after this it is crash



Code just loads module and shelve and opens file. Then in another function it cycles through data and that creates crash in C pickle module at shutdown. Weird thing is that when cycle through data is not in function it does not crash. Also crash can be avoided when C Pickle is traded for Python Pickle.


In REPL it is quite similar just list on shelve.items() and exit makes Python crash.

Python 3.8.1 (default, Dec 22 2019, 08:15:39) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import shelve
>>> import material
>>> data = shelve.open("test3", flag="c",writeback=True)
>>> list(data.items())
[('H1615', Material(name='T?e?e? Romana', code='H1615', vars=0))]
>>> exit()
Fatal Python error: Segmentation fault

Current thread 0x00007f14a2546740 (most recent call first):
  File "/usr/lib/python3.8/shelve.py", line 124 in __setitem__
  File "/usr/lib/python3.8/shelve.py", line 168 in sync
  File "/usr/lib/python3.8/shelve.py", line 144 in close
  File "/usr/lib/python3.8/shelve.py", line 162 in __del__
Neopr?vn?n? p??stup do pam?ti (SIGSEGV)

Hopefully you can fix this.

----------
components: Library (Lib)
files: test_crash_shelve.zip
messages: 362186
nosy: zd nex
priority: normal
severity: normal
status: open
title: SIGSEGV crash on shutdown with shelve & c pickle
type: crash
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48899/test_crash_shelve.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:51:59 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 18 Feb 2020 09:51:59 +0000
Subject: [issue39673] TimeoutError
Message-ID: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

import os


try:
    no = -62
    raise OSError(-no, os.strerror(-no))
except TimeoutError:
    print('Success')
except OSError as e:
    print('Failed:', e)
    # Failed: [Errno 62] Timer expired


Shouldn't `TimeoutError` catch this error?

----------
messages: 362187
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: TimeoutError
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:56:10 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 09:56:10 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582019770.21.0.88811230513.issue39673@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't see why it would. You're raising OSError, which is not a subclass of TimeoutError, so the TimeoutError code is not executing. You don't say, but I assume this is what you think should happen.

The exception handling machinery does not look inside a raised exception to try to assign meaning to the values, so it doesn't know what errno=62 means. Nor should it: it's only based on the class of the exception, not its attributes.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 04:57:03 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 09:57:03 +0000
Subject: [issue39668] segmentation fault on calling __reversed__()
In-Reply-To: <1581982397.85.0.278174574567.issue39668@roundup.psfhosted.org>
Message-ID: <1582019823.52.0.942233034135.issue39668@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

No problem, closing it as duplicate of issue38525.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Strange reversed dict behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39668>
_______________________________________

From report at bugs.python.org  Tue Feb 18 05:04:36 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 18 Feb 2020 10:04:36 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582020276.7.0.349071052355.issue39673@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

Since I provide `OSError` with appropriate `errono`, it raises that error for example:

import os


try:
    no = -11
    raise OSError(-no, os.strerror(-no))
except BlockingIOError as e:
    print('Success:', e)
    # Success: [Errno 11] Resource temporarily unavailable
except OSError as e:
    print('Failed:', e)

should work the same to raise `TimeoutError` as well

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 05:23:40 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 10:23:40 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582021420.22.0.752527395232.issue39673@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

In both examples, what's being printed? It's not clear from your messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 05:28:33 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 18 Feb 2020 10:28:33 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582021713.61.0.117343372958.issue39673@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

First example prints
# Failed: [Errno 62] Timer expired

Second example prints
# Success: [Errno 11] Resource temporarily unavailable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:14:11 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 11:14:11 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1582024451.28.0.192922009833.issue26967@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e412cbba52e7cf6699720d99a4b88baef92db7b2 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337) (GH-18543)
https://github.com/python/cpython/commit/e412cbba52e7cf6699720d99a4b88baef92db7b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:14:11 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 11:14:11 +0000
Subject: [issue39546] argparse: allow_abbrev=False is ignored for alternative
 prefix characters
In-Reply-To: <1580760688.73.0.980793532046.issue39546@roundup.psfhosted.org>
Message-ID: <1582024451.17.0.84759582797.issue39546@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e412cbba52e7cf6699720d99a4b88baef92db7b2 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337) (GH-18543)
https://github.com/python/cpython/commit/e412cbba52e7cf6699720d99a4b88baef92db7b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39546>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:17:45 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 11:17:45 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1582024665.94.0.737950987798.issue1635741@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5d38517aa1836542a5417b724c093bcb245f0f47 by Hai Shi in branch 'master':
bpo-1635741: Port _bz2 extension module to multiphase initialization(PEP 489) (GH-18050)
https://github.com/python/cpython/commit/5d38517aa1836542a5417b724c093bcb245f0f47


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:26:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 11:26:29 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
Message-ID: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Following discussion on python-dev, I propose to revert the removal of a few deprecated functions to keep them in Python 3.9, and only remove them in Python 3.10. Please see the following email for the longer rationale, and the discussion for further details:

https://mail.python.org/archives/list/python-dev at python.org/thread/EYLXCGGJOUMZSE5X35ILW3UNTJM3MCRE/

With Python 3.8, it was possible to have a single code base working on Python 2.7 and 3.8. Some functions emits DeprecationWarning, but these warnings are ignored (silent) by default. With removed deprecated functions in Python 3.9, *new* code is required to support Python 2.7. The problem is that Python 2.7 is no longer supported. Adding new code to support Python 2.7 sounds painful. Dropping Python 2.7 support isn't free. Projects have to drop Python 2 code, drop CI tests on Python 2, warn users, etc.

The idea is to give maintainers one more year (until Python 3.10) to organize their project to schedule properly the removal of Python 2 support. The first motivation is to ease adoption of Python 3.9.

--

I propose to start with reverting the removal of collections aliases to Abstract Base Classes (ABC) like collections.Mapping alias to collections.abc.Mapping. Removing these aliases is the change which caused most issues when testing Python projects on Python 3.9.

I also propose to modify the What's New In Python 3.9 document to strongly suggest to test your applications with -W default or even -W error to see DeprecationWarning and PendingDeprecationWarning.

----------
components: Library (Lib)
messages: 362196
nosy: vstinner
priority: normal
severity: normal
status: open
title: Keep deprecated features in Python 3.9 to ease migration from Python 2.7, but remove in Python 3.10
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:27:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 11:27:29 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582025249.68.0.849016475191.issue39674@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/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:29:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 11:29:36 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1582025376.96.0.488853255889.issue25988@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17923
pull_request: https://github.com/python/cpython/pull/18545

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:29:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 11:29:36 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582025376.86.0.883826036311.issue39674@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17922
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18545

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:35:56 2020
From: report at bugs.python.org (gaborbernat)
Date: Tue, 18 Feb 2020 11:35:56 +0000
Subject: [issue39675] forked process in multiprocessing does not honour atexit
Message-ID: <1582025755.98.0.0767083175106.issue39675@roundup.psfhosted.org>


New submission from gaborbernat <gaborjbernat at gmail.com>:

I've talked with Pablo about this in person, and as advised opening the issue here now. 

I've discovered that forked processes do not honour atexit registrations. See the following example code:

from multiprocessing import Process, set_start_method
import time
import os
import atexit


def cleanup():
    print(f"cleanup {os.getpid()}")


atexit.register(cleanup)


def run():
    time.sleep(0.1)
    print(f"process done {os.getpid()}")
    # atexit._run_exitfuncs()


if __name__ == "__main__":
    set_start_method("fork")
    process = Process(target=run)
    process.start()
    process.join()
    print("app finished")

In case of a forked process childs the atexit is never executed (note it works if I ran them manually at the end of the child process; so they're registered correctly). Switching to spawn method makes it work as expected. The behaviour is the same even if you call register within the child process (as opposed to being inherited during forking). Also found this StackOverflow question that mentions this https://stackoverflow.com/a/26476585. At the very least the documentation should explain this; though I'd expect atexit to be called before finalization of the fork processes (assuming the child process exits with 0 exit code). d

----------
messages: 362197
nosy: davin, gaborbernat, pablogsal, pitrou
priority: normal
severity: normal
status: open
title: forked process in multiprocessing does not honour atexit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39675>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:47:08 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 18 Feb 2020 11:47:08 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1582026428.48.0.647067942658.issue39245@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Feb 18 06:55:05 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 11:55:05 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1582026905.28.0.856623392641.issue39432@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17924
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/18546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:10:14 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 18 Feb 2020 12:10:14 +0000
Subject: [issue39611] PyVectorcall_NARGS(): change return type to Py_ssize_t
In-Reply-To: <1581439802.08.0.269605929245.issue39611@roundup.psfhosted.org>
Message-ID: <1582027814.19.0.789498909219.issue39611@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The current return type already is Py_ssize_t, exactly for the reason you mention ? compatibility with all other "argument count" values in Python. (It would be more correct to use unsigned, but that ship has sailed.)

The *argument* type is unsigned size_t, though: unsigned is the correct type for for bit fields. Also, the "nargsf" value should never be directly used as argument count; making it a different type tends to trigger nice compiler warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39611>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:20:27 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 18 Feb 2020 12:20:27 +0000
Subject: [issue39611] PyVectorcall_NARGS(): change return type to Py_ssize_t
In-Reply-To: <1581439802.08.0.269605929245.issue39611@roundup.psfhosted.org>
Message-ID: <1582028427.4.0.474410465371.issue39611@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Closing; please reopen if we're somehow misunderstanding each other :)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39611>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:23:04 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 12:23:04 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582028584.88.0.114806973172.issue39673@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Ah, I see.

What platform are you on, and what's the value of errno.ETIMEDOUT?

On cygwin I get:
>>> errno.ETIMEDOUT
116

On a native Windows build I get:
>>> errno.ETIMEDOUT
10060

and on Fedora I get:
>>> errno.ETIMEDOUT
110

If you use errno.ETIMEDOUT instead of 62, do you get different behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:27:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 18 Feb 2020 12:27:16 +0000
Subject: [issue39675] forked process in multiprocessing does not honour atexit
In-Reply-To: <1582025755.98.0.0767083175106.issue39675@roundup.psfhosted.org>
Message-ID: <1582028836.27.0.70901210678.issue39675@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
assignee:  -> pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39675>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:27:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 18 Feb 2020 12:27:31 +0000
Subject: [issue39675] forked process in multiprocessing does not honour atexit
In-Reply-To: <1582025755.98.0.0767083175106.issue39675@roundup.psfhosted.org>
Message-ID: <1582028851.97.0.869880558662.issue39675@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39675>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:29:38 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 12:29:38 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1582028978.01.0.554340804513.issue39479@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
pull_requests: +17925
pull_request: https://github.com/python/cpython/pull/18547

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:37:25 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 18 Feb 2020 12:37:25 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582029445.67.0.091417415393.issue39673@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

I am on Linux 5.5.2-1-MANJARO

>>> sorted(errno.errorcode.items())
[(1, 'EPERM'), (2, 'ENOENT'), (3, 'ESRCH'), (4, 'EINTR'), (5, 'EIO'), (6, 'ENXIO'), (7, 'E2BIG'), (8, 'ENOEXEC'), (9, 'EBADF'), (10, 'ECHILD'), (11, 'EAGAIN'), (12, 'ENOMEM'), (13, 'EACCES'), (14, 'EFAULT'), (15, 'ENOTBLK'), (16, 'EBUSY'), (17, 'EEXIST'), (18, 'EXDEV'), (19, 'ENODEV'), (20, 'ENOTDIR'), (21, 'EISDIR'), (22, 'EINVAL'), (23, 'ENFILE'), (24, 'EMFILE'), (25, 'ENOTTY'), (26, 'ETXTBSY'), (27, 'EFBIG'), (28, 'ENOSPC'), (29, 'ESPIPE'), (30, 'EROFS'), (31, 'EMLINK'), (32, 'EPIPE'), (33, 'EDOM'), (34, 'ERANGE'), (35, 'EDEADLOCK'), (36, 'ENAMETOOLONG'), (37, 'ENOLCK'), (38, 'ENOSYS'), (39, 'ENOTEMPTY'), (40, 'ELOOP'), (42, 'ENOMSG'), (43, 'EIDRM'), (44, 'ECHRNG'), (45, 'EL2NSYNC'), (46, 'EL3HLT'), (47, 'EL3RST'), (48, 'ELNRNG'), (49, 'EUNATCH'), (50, 'ENOCSI'), (51, 'EL2HLT'), (52, 'EBADE'), (53, 'EBADR'), (54, 'EXFULL'), (55, 'ENOANO'), (56, 'EBADRQC'), (57, 'EBADSLT'), (59, 'EBFONT'), (60, 'ENOSTR'), (61, 'ENODATA'), (62, 'ETIME'), (63, 'ENOSR'), (64, 'ENONET'), (65, 'ENOPKG'), (66, 'EREMOTE'), (67, 'ENOLINK'), (68, 'EADV'), (69, 'ESRMNT'), (70, 'ECOMM'), (71, 'EPROTO'), (72, 'EMULTIHOP'), (73, 'EDOTDOT'), (74, 'EBADMSG'), (75, 'EOVERFLOW'), (76, 'ENOTUNIQ'), (77, 'EBADFD'), (78, 'EREMCHG'), (79, 'ELIBACC'), (80, 'ELIBBAD'), (81, 'ELIBSCN'), (82, 'ELIBMAX'), (83, 'ELIBEXEC'), (84, 'EILSEQ'), (85, 'ERESTART'), (86, 'ESTRPIPE'), (87, 'EUSERS'), (88, 'ENOTSOCK'), (89, 'EDESTADDRREQ'), (90, 'EMSGSIZE'), (91, 'EPROTOTYPE'), (92, 'ENOPROTOOPT'), (93, 'EPROTONOSUPPORT'), (94, 'ESOCKTNOSUPPORT'), (95, 'ENOTSUP'), (96, 'EPFNOSUPPORT'), (97, 'EAFNOSUPPORT'), (98, 'EADDRINUSE'), (99, 'EADDRNOTAVAIL'), (100, 'ENETDOWN'), (101, 'ENETUNREACH'), (102, 'ENETRESET'), (103, 'ECONNABORTED'), (104, 'ECONNRESET'), (105, 'ENOBUFS'), (106, 'EISCONN'), (107, 'ENOTCONN'), (108, 'ESHUTDOWN'), (109, 'ETOOMANYREFS'), (110, 'ETIMEDOUT'), (111, 'ECONNREFUSED'), (112, 'EHOSTDOWN'), (113, 'EHOSTUNREACH'), (114, 'EALREADY'), (115, 'EINPROGRESS'), (116, 'ESTALE'), (117, 'EUCLEAN'), (118, 'ENOTNAM'), (119, 'ENAVAIL'), (120, 'EISNAM'), (121, 'EREMOTEIO'), (122, 'EDQUOT'), (123, 'ENOMEDIUM'), (124, 'EMEDIUMTYPE'), (125, 'ECANCELED'), (126, 'ENOKEY'), (127, 'EKEYEXPIRED'), (128, 'EKEYREVOKED'), (129, 'EKEYREJECTED'), (130, 'EOWNERDEAD'), (131, 'ENOTRECOVERABLE'), (132, 'ERFKILL')]


Its an automated process the value is return by the C/kernel. I suppose its calling `ETIME`

ETIME - Timer expired (POSIX.1 (XSI STREAMS option)).
                      (POSIX.1 says "STREAM ioctl(2) timeout".)
ETIMEDOUT - Connection timed out (POSIX.1-2001).

These are both timeout errors but only `ETIMEDOUT` is accounted for?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 07:42:35 2020
From: report at bugs.python.org (Jason Madden)
Date: Tue, 18 Feb 2020 12:42:35 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582029755.94.0.120509861803.issue39674@roundup.psfhosted.org>


Change by Jason Madden <jason at nextthought.com>:


----------
nosy: +jmadden

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:00:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:00:01 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582030801.19.0.244539171703.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Tests fail on macOS:
https://buildbot.python.org/all/#/builders/275/builds/249

I reopen the issue. The issue should be fixed soon, or the change will be reverted to repair buildobts:
https://pythondev.readthedocs.io/ci.html#revert-on-fail

======================================================================
FAIL: test_case_insensitivity (test.test_importlib.extension.test_case_sensitivity.Frozen_ExtensionModuleCaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/extension/test_case_sensitivity.py", line 36, in test_case_insensitivity
    self.assertTrue(hasattr(loader, 'load_module'))
AssertionError: False is not true

======================================================================
FAIL: test_case_insensitivity (test.test_importlib.extension.test_case_sensitivity.Source_ExtensionModuleCaseSensitivityTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/extension/test_case_sensitivity.py", line 36, in test_case_insensitivity
    self.assertTrue(hasattr(loader, 'load_module'))
AssertionError: False is not true

======================================================================
FAIL: test_insensitive (test.test_importlib.source.test_case_sensitivity.Frozen_CaseSensitivityTestPEP302)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/source/test_case_sensitivity.py", line 57, in test_insensitive
    self.assertIsNotNone(insensitive)
AssertionError: unexpectedly None

======================================================================
FAIL: test_insensitive (test.test_importlib.source.test_case_sensitivity.Frozen_CaseSensitivityTestPEP451)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/source/test_case_sensitivity.py", line 57, in test_insensitive
    self.assertIsNotNone(insensitive)
AssertionError: unexpectedly None

======================================================================
FAIL: test_insensitive (test.test_importlib.source.test_case_sensitivity.Source_CaseSensitivityTestPEP302)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/source/test_case_sensitivity.py", line 57, in test_insensitive
    self.assertIsNotNone(insensitive)
AssertionError: unexpectedly None

======================================================================
FAIL: test_insensitive (test.test_importlib.source.test_case_sensitivity.Source_CaseSensitivityTestPEP451)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.billenstein-macos/build/Lib/test/test_importlib/source/test_case_sensitivity.py", line 57, in test_insensitive
    self.assertIsNotNone(insensitive)
AssertionError: unexpectedly None

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:01:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:01:52 +0000
Subject: [issue39676] test_shutil fails with OSError: [Errno 28] No space left
 on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
Message-ID: <1582030912.19.0.281317890533.issue39676@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

PPC64LE Fedora Stable LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/449/builds/31

Example:

======================================================================
ERROR: test_big_chunk (test.test_shutil.TestZeroCopySendfile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/test/test_shutil.py", line 2405, in test_big_chunk
    shutil._fastcopy_sendfile(src, dst)
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/shutil.py", line 163, in _fastcopy_sendfile
    raise err from None
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-ppc64le.lto-pgo/build/Lib/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 28] No space left on device: '@test_3252264_tmp' -> '@test_3252264_tmp2'

----------
components: Tests
messages: 362203
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_shutil fails with OSError: [Errno 28] No space left on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39676>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:03:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 13:03:06 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582030986.37.0.502233671606.issue39673@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> These are both timeout errors but only `ETIMEDOUT` is accounted for?

Yes, only ETIMEDOUT is accounted for in Objects/exceptions.c. There's precedent for mapping multiple errnos to the same exception:

    ADD_ERRNO(BlockingIOError, EAGAIN);
    ADD_ERRNO(BlockingIOError, EALREADY);
    ADD_ERRNO(BlockingIOError, EINPROGRESS);
    ADD_ERRNO(BlockingIOError, EWOULDBLOCK);

You should probably raise this on python-ideas. I don't know if ETIME has some other accepted meaning. It's not mapped to any other exception, so it could be easily added. The only thing it would affect are people who are catching OSError and TimeoutError and are expecting ETIME to give an OSError, which seems a pretty niche case. Or I guess people who only catch TimeoutError and want to not catch the case where errno==ETIME.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:11:47 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Tue, 18 Feb 2020 13:11:47 +0000
Subject: [issue39673] TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582031507.3.0.313513104632.issue39673@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

If nothing else, it could be a feature of next Python release as its appropriate that `TimeoutError` catches both `ETIME` and `ETIMEDOUT`.

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:14:47 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 18 Feb 2020 13:14:47 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1582031687.13.0.101333542149.issue39432@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 5bf58cef151249f1cca92166d1b70693348da9d8 by Miss Islington (bot) in branch '3.8':
bpo-39432: Implement PEP-489 algorithm for non-ascii "PyInit_*" symbol names in distutils (GH-18150) (GH-18546)
https://github.com/python/cpython/commit/5bf58cef151249f1cca92166d1b70693348da9d8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:14:49 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 13:14:49 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1582031689.94.0.184944550577.issue36347@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 24bba8cf5b8db25c19bcd1d94e8e356874d1c723 by Jeroen Demeyer in branch 'master':
bpo-36347: stop using RESTRICTED constants (GH-12684)
https://github.com/python/cpython/commit/24bba8cf5b8db25c19bcd1d94e8e356874d1c723


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:17:31 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 18 Feb 2020 13:17:31 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1582031851.35.0.547543518352.issue39432@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:20:52 2020
From: report at bugs.python.org (thautwarm)
Date: Tue, 18 Feb 2020 13:20:52 +0000
Subject: [issue39677] 3.6+ documentation for MAKE_FUNCTION
Message-ID: <1582032052.37.0.86110712101.issue39677@roundup.psfhosted.org>


New submission from thautwarm <yaoxiansamma at gmail.com>:

LINK: https://docs.python.org/3.6/library/dis.html?highlight=bytecode#opcode-MAKE_FUNCTION

To avoid being confusing, MAKE_FUNCTION(argc) shall be MAKE_FUNCTION(flag), since 3.6 the operand of MAKE_FUNCTION never means `argcount`.

----------
assignee: docs at python
components: Documentation
messages: 362208
nosy: docs at python, thautwarm
priority: normal
severity: normal
status: open
title: 3.6+ documentation for MAKE_FUNCTION
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39677>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:31:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Feb 2020 13:31:56 +0000
Subject: [issue39677] 3.6+ documentation for MAKE_FUNCTION
In-Reply-To: <1582032052.37.0.86110712101.issue39677@roundup.psfhosted.org>
Message-ID: <1582032716.98.0.372026446367.issue39677@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Agree. Do you want to provide a PR?

Although it may be too later for 3.6 which only takes security fixes.

----------
keywords: +easy
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39677>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:35:53 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 13:35:53 +0000
Subject: [issue39673] Map errno==ETIME to TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582032953.25.0.351614309263.issue39673@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
title: TimeoutError -> Map errno==ETIME to TimeoutError
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:36:07 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 13:36:07 +0000
Subject: [issue39673] Map errno==ETIME to TimeoutError
In-Reply-To: <1582019519.42.0.474248510986.issue39673@roundup.psfhosted.org>
Message-ID: <1582032967.31.0.00884320016045.issue39673@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39673>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:36:41 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 13:36:41 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1582033001.7.0.458446806745.issue39555@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17926
pull_request: https://github.com/python/cpython/pull/18548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39555>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:37:13 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 13:37:13 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1582033033.38.0.144623470554.issue39555@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17927
pull_request: https://github.com/python/cpython/pull/18546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39555>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:45:02 2020
From: report at bugs.python.org (Rebecca Morgan)
Date: Tue, 18 Feb 2020 13:45:02 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1582033502.85.0.48260438464.issue38860@roundup.psfhosted.org>


Rebecca Morgan <beccamorgan92 at gmail.com> added the comment:

I would still be interested in this, with some clarity on the testing/expected behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:47:55 2020
From: report at bugs.python.org (thautwarm)
Date: Tue, 18 Feb 2020 13:47:55 +0000
Subject: [issue39677] 3.6+ documentation for MAKE_FUNCTION
In-Reply-To: <1582032052.37.0.86110712101.issue39677@roundup.psfhosted.org>
Message-ID: <1582033675.0.0.815814033167.issue39677@roundup.psfhosted.org>


thautwarm <yaoxiansamma at gmail.com> added the comment:

Okay, I'll make a PR. It's okay because users will always check docs of version 3 instead of a specific version like 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39677>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:50:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:50:56 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1582033856.07.0.196388142079.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> If we can keep functions that don't modify the object to accept const PyObject* it will help make things safer in the long run.

In my experience, trying to add "const" is quite painful, since the "const" has to be propagated to all functions called by the modified function. Python never used "const" with "PyObject*" because they are *so many* functions which really modify objects on purpose.

I don't see how adding "const" would help this issue "Make PyObject an opaque structure in the limited C API". If you consider that something should be changed, please open a *separated* issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:51:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:51:45 +0000
Subject: [issue39669] macOS test failures
In-Reply-To: <1581996453.92.0.653511763632.issue39669@roundup.psfhosted.org>
Message-ID: <1582033905.28.0.406070061258.issue39669@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's bpo-38691. Let's discuss it there.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [easy] importlib: PYTHONCASEOK should be ignored when using python3 -E

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39669>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:52:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:52:54 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1582033974.96.0.91437959444.issue39555@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue is related to bpo-39432.

commit 9538bc9185e934bee2bd5ae2cda2b2e92a61906d
Author: Stefan Behnel <stefan_ml at behnel.de>
Date:   Tue Feb 4 16:24:30 2020 +0100

    bpo-39432: Implement PEP-489 algorithm for non-ascii "PyInit_*" symbol names in distutils (GH-18150)
    
    
    
    Make it export the correct init symbol also on Windows.
    
    
    
    https://bugs.python.org/issue39432

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39555>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:53:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:53:46 +0000
Subject: [issue39676] test_shutil fails with OSError: [Errno 28] No space left
 on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
In-Reply-To: <1582030912.19.0.281317890533.issue39676@roundup.psfhosted.org>
Message-ID: <1582034026.71.0.278171758862.issue39676@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39676>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:55:42 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 13:55:42 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1582034142.8.0.357669098028.issue39432@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17928
pull_request: https://github.com/python/cpython/pull/18548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:56:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:56:40 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1582034200.13.0.183297258053.issue37373@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Tue Feb 18 08:58:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 13:58:06 +0000
Subject: [issue39611] PyVectorcall_NARGS(): change return type to Py_ssize_t
In-Reply-To: <1581439802.08.0.269605929245.issue39611@roundup.psfhosted.org>
Message-ID: <1582034286.53.0.506319037729.issue39611@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Alright, I was confused by how PyVectorcall_NARGS() is supposed to be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39611>
_______________________________________

From report at bugs.python.org  Tue Feb 18 09:06:07 2020
From: report at bugs.python.org (thautwarm)
Date: Tue, 18 Feb 2020 14:06:07 +0000
Subject: [issue39677] 3.6+ documentation for MAKE_FUNCTION
In-Reply-To: <1582032052.37.0.86110712101.issue39677@roundup.psfhosted.org>
Message-ID: <1582034767.45.0.114593046704.issue39677@roundup.psfhosted.org>


Change by thautwarm <yaoxiansamma at gmail.com>:


----------
keywords: +patch
pull_requests: +17929
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18549

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39677>
_______________________________________

From report at bugs.python.org  Tue Feb 18 09:22:36 2020
From: report at bugs.python.org (thautwarm)
Date: Tue, 18 Feb 2020 14:22:36 +0000
Subject: [issue39677] 3.6+ documentation for MAKE_FUNCTION
In-Reply-To: <1582032052.37.0.86110712101.issue39677@roundup.psfhosted.org>
Message-ID: <1582035756.48.0.618487420928.issue39677@roundup.psfhosted.org>


Change by thautwarm <yaoxiansamma at gmail.com>:


----------
pull_requests: +17930
pull_request: https://github.com/python/cpython/pull/18550

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39677>
_______________________________________

From report at bugs.python.org  Tue Feb 18 09:38:54 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 18 Feb 2020 14:38:54 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1582036734.22.0.755330617592.issue39573@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

All I'm saying is that I think Py_IS_TYPE is a great idea, and that Py_IS_TYPE should take const arguments, since its arguments are not modified.  If you think that should go in a different ticket, then I can make that happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Tue Feb 18 09:56:12 2020
From: report at bugs.python.org (thautwarm)
Date: Tue, 18 Feb 2020 14:56:12 +0000
Subject: [issue32352] `inspect.getfullargspec` doesn't work fine for some
 builtin callable objects
In-Reply-To: <1513518429.74.0.213398074469.issue32352@psf.upfronthosting.co.za>
Message-ID: <1582037772.52.0.804367538019.issue32352@roundup.psfhosted.org>


Change by thautwarm <yaoxiansamma at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32352>
_______________________________________

From report at bugs.python.org  Tue Feb 18 09:59:35 2020
From: report at bugs.python.org (Henning von Bargen)
Date: Tue, 18 Feb 2020 14:59:35 +0000
Subject: [issue37921] Improve zipfile: add support for symlinks
In-Reply-To: <1566508476.42.0.582332769766.issue37921@roundup.psfhosted.org>
Message-ID: <1582037975.32.0.0629925769226.issue37921@roundup.psfhosted.org>


Henning von Bargen <h.vonbargen at gmail.com> added the comment:

If I understand correctly, 
this bug is about supporting symlinks on *creating* ZIP files.

Please see also https://bugs.python.org/issue27318 for a proposal to support symlinks while *unpacking* ZIP files.

Maybe a preserve_symlinks optional argument should be added to the `extract` and `extractall` method as well (the same argument name is used in `distutils.dir_util.copy_tree`).

Anyway, I think symlink support should be added for packing *and* unpacking or not at all.

----------
nosy: +Henning.von.Bargen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37921>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:13:01 2020
From: report at bugs.python.org (Thomas Moreau)
Date: Tue, 18 Feb 2020 15:13:01 +0000
Subject: [issue39678] RFC improve readability of _queue_management_worker for
 ProcessPoolExecutor
Message-ID: <1582038781.26.0.540574827732.issue39678@roundup.psfhosted.org>


New submission from Thomas Moreau <thomas.moreau.2010 at gmail.com>:

As discussed in GH#17670, the the `_queue_management_worker` function has grown quite long and complicated.
It could be turned into an object with a bunch of short and readable helper methods.

----------
components: Library (Lib)
messages: 362218
nosy: pitrou, tomMoral
priority: normal
severity: normal
status: open
title: RFC improve readability of _queue_management_worker for ProcessPoolExecutor
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39678>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:13:24 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Feb 2020 15:13:24 +0000
Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(),
 list() and dict()
In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org>
Message-ID: <1582038804.2.0.18433895336.issue37207@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6e35da976370e7c2e028165c65d7d7d42772a71f by Petr Viktorin in branch 'master':
bpo-37207: Use vectorcall for range() (GH-18464)
https://github.com/python/cpython/commit/6e35da976370e7c2e028165c65d7d7d42772a71f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37207>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:15:10 2020
From: report at bugs.python.org (Thomas Moreau)
Date: Tue, 18 Feb 2020 15:15:10 +0000
Subject: [issue39678] RFC improve readability of _queue_management_worker for
 ProcessPoolExecutor
In-Reply-To: <1582038781.26.0.540574827732.issue39678@roundup.psfhosted.org>
Message-ID: <1582038910.3.0.2514265552.issue39678@roundup.psfhosted.org>


Change by Thomas Moreau <thomas.moreau.2010 at gmail.com>:


----------
keywords: +patch
pull_requests: +17931
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39678>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:25:11 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 18 Feb 2020 15:25:11 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582039511.72.0.454155021803.issue39674@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yes please.

I have one exception. I f we manage to get the new parser (pegen) in, we have to remove the old parser module.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:29:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 15:29:01 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582039741.15.0.142574420441.issue39674@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset af5ee3ff610377ef446c2d88bbfcbb3dffaaf0c9 by Victor Stinner in branch 'master':
bpo-39674: Revert "bpo-25988: Do not expose abstract collection classes in the collections module. (GH-10596)" (GH-18545)
https://github.com/python/cpython/commit/af5ee3ff610377ef446c2d88bbfcbb3dffaaf0c9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:29:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 15:29:00 +0000
Subject: [issue25988] collections.abc.Indexable
In-Reply-To: <1451686739.56.0.219134772531.issue25988@psf.upfronthosting.co.za>
Message-ID: <1582039740.98.0.723490700936.issue25988@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset af5ee3ff610377ef446c2d88bbfcbb3dffaaf0c9 by Victor Stinner in branch 'master':
bpo-39674: Revert "bpo-25988: Do not expose abstract collection classes in the collections module. (GH-10596)" (GH-18545)
https://github.com/python/cpython/commit/af5ee3ff610377ef446c2d88bbfcbb3dffaaf0c9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25988>
_______________________________________

From report at bugs.python.org  Tue Feb 18 10:36:18 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 15:36:18 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582040178.18.0.0968739725865.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

Can I put together a PR for this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:13:04 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 18 Feb 2020 16:13:04 +0000
Subject: [issue34822] Simplify AST for slices
In-Reply-To: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>
Message-ID: <1582042384.45.0.58890653474.issue34822@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I wrote some AST analyzers, and this would have simplified my code. So I welcome it. :-)

However, it means people might be tempted to write 

    a[b:c, d]    as    a[(b:c, d)]

(or at least expect it to work -- same as `a[b, c]` can now be written as `a[(b, c)]`). We aren't going to allow this?

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:14:02 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 16:14:02 +0000
Subject: [issue39635] One paragraph of the doc is not translated in French
In-Reply-To: <1581764263.43.0.781386094953.issue39635@roundup.psfhosted.org>
Message-ID: <1582042442.91.0.365417774124.issue39635@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
keywords: +patch
pull_requests: +17932
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/1153

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39635>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:18:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Feb 2020 16:18:16 +0000
Subject: [issue39635] One paragraph of the doc is not translated in French
In-Reply-To: <1581764263.43.0.781386094953.issue39635@roundup.psfhosted.org>
Message-ID: <1582042696.7.0.950222529318.issue39635@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -17932

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39635>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:32:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 16:32:17 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582043537.27.0.959248561612.issue39674@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17933
pull_request: https://github.com/python/cpython/pull/18552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:33:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 16:33:19 +0000
Subject: [issue39674] Keep deprecated features in Python 3.9 to ease migration
 from Python 2.7, but remove in Python 3.10
In-Reply-To: <1582025189.05.0.731615044433.issue39674@roundup.psfhosted.org>
Message-ID: <1582043599.7.0.657386686533.issue39674@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR 18552 adds a section to What's New In Python 3.9 to strongly advice to check for DeprecationWarning in your Python projects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39674>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:41:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 16:41:23 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582044083.59.0.598808628788.issue38691@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17934
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18553

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:42:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 16:42:34 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582044154.13.0.106171065259.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm unable to debug the issue on macOS. I prepared PR 18553 to revert the change, just to give more time to fix the issue. It's to repair the CI, so we can notice other regressions.

----------
keywords:  -newcomer friendly
title: [easy] importlib: PYTHONCASEOK should be ignored when using python3 -E -> importlib: PYTHONCASEOK should be ignored when using python3 -E

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Tue Feb 18 11:44:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 18 Feb 2020 16:44:47 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582044287.3.0.656313842232.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Tests fail on macOS: https://buildbot.python.org/all/#/builders/275/builds/249

Tests are run with "./python.exe  ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=900 -j2 --junit-xml test-results.xml" which runs tests with "./python.exe -E": ignore PYTHON* environment variables. Maybe the test should just take that in account.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Tue Feb 18 12:05:42 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 17:05:42 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582045542.96.0.166261827498.issue39572@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

https://stackoverflow.com/questions/58427394/what-is-the-meaning-of-total-dunder-attribute-in-python-3

questions about this.

----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 12:31:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 18 Feb 2020 17:31:56 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582047116.09.0.141643267894.issue39572@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 12:49:03 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 17:49:03 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582048143.73.0.517281907349.issue39572@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

It will be usefull if we document _total_ argument also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 13:04:11 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 18 Feb 2020 18:04:11 +0000
Subject: [issue39635] One paragraph of the doc is not translated in French
In-Reply-To: <1581764263.43.0.781386094953.issue39635@roundup.psfhosted.org>
Message-ID: <1582049051.0.0.193669353921.issue39635@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

This has been resolved in https://github.com/python/python-docs-fr/pull/1153 I bet Fr?d?ric is the author so thank you for the PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39635>
_______________________________________

From report at bugs.python.org  Tue Feb 18 13:17:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 18 Feb 2020 18:17:37 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582049857.48.0.938127090762.issue39572@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

There's no __total__ argument, but there is a __total__ attribute. There are also (new in 3.9) __required_keys__ and __total_keys__ attributes.

Are you interested in submitting a PR with the needed doc changes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 13:19:10 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 18:19:10 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582049950.81.0.743891111593.issue39572@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

yes,I'm interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 13:21:44 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Tue, 18 Feb 2020 18:21:44 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582050104.45.0.858465831158.issue39572@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
keywords: +patch
pull_requests: +17935
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 14:16:15 2020
From: report at bugs.python.org (Viktor Roytman)
Date: Tue, 18 Feb 2020 19:16:15 +0000
Subject: [issue39679] functools: singledispatchmethod doesn't work with
 classmethod
Message-ID: <1582053375.25.0.178240077179.issue39679@roundup.psfhosted.org>


New submission from Viktor Roytman <viktor.roytman at gmail.com>:

I couldn't get the example given for the interaction between @singledispatchmethod and @classmethod to work https://docs.python.org/3/library/functools.html?highlight=singledispatch#functools.singledispatchmethod

    from functools import singledispatchmethod
    
    
    class Negator:
        @singledispatchmethod
        @classmethod
        def neg(cls, arg):
            raise NotImplementedError("Cannot negate a")
    
        @neg.register
        @classmethod
        def _(cls, arg: int):
            return -arg
    
        @neg.register
        @classmethod
        def _(cls, arg: bool):
            return not arg
    
    
    if __name__ == "__main__":
        print(Negator.neg(0))
        print(Negator.neg(False))

Leads to

    $ python -m bad_classmethod_as_documented
    Traceback (most recent call last):
      File "/usr/lib/python3.8/runpy.py", line 193, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/usr/lib/python3.8/runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "/home/viktor/scratch/bad_classmethod_as_documented.py", line 4, in <module>
        class Negator:
      File "/home/viktor/scratch/bad_classmethod_as_documented.py", line 12, in Negator
        def _(cls, arg: int):
      File "/usr/lib/python3.8/functools.py", line 906, in register
        return self.dispatcher.register(cls, func=method)
      File "/usr/lib/python3.8/functools.py", line 848, in register
        raise TypeError(
    TypeError: Invalid first argument to `register()`: <classmethod object at 0x7f37d1469070>. Use either `@register(some_class)` or plain `@register` on an annotated function.

Curiously, @staticmethod does work, but not as documented (don't decorate the actual implementations):

    from functools import singledispatchmethod
    
    
    class Negator:
        @singledispatchmethod
        @staticmethod
        def neg(arg):
            raise NotImplementedError("Cannot negate a")
    
        @neg.register
        def _(arg: int):
            return -arg
    
        @neg.register
        def _(arg: bool):
            return not arg
    
    
    if __name__ == "__main__":
        print(Negator.neg(0))
        print(Negator.neg(False))

Leads to

    $ python -m good_staticmethod
    0
    True

Removing @classmethod from the implementation methods doesn't work, though

    Traceback (most recent call last):
      File "/usr/lib/python3.8/runpy.py", line 193, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/usr/lib/python3.8/runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "/home/viktor/scratch/bad_classmethod_alternative.py", line 20, in <module>
        print(Negator.neg(0))
      File "/usr/lib/python3.8/functools.py", line 911, in _method
        return method.__get__(obj, cls)(*args, **kwargs)
    TypeError: _() missing 1 required positional argument: 'arg'

----------
components: Library (Lib)
messages: 362233
nosy: Viktor Roytman
priority: normal
severity: normal
status: open
title: functools: singledispatchmethod doesn't work with classmethod
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39679>
_______________________________________

From report at bugs.python.org  Tue Feb 18 15:33:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Feb 2020 20:33:25 +0000
Subject: [issue34822] Simplify AST for slices
In-Reply-To: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>
Message-ID: <1582058005.51.0.7281329576.issue34822@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, this PR does not change the Python syntax. It only changes the AST representation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34822>
_______________________________________

From report at bugs.python.org  Tue Feb 18 15:48:18 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 18 Feb 2020 20:48:18 +0000
Subject: [issue39662] Characters are garbled when displaying Byte data
In-Reply-To: <1581947498.56.0.86314760045.issue39662@roundup.psfhosted.org>
Message-ID: <1582058898.93.0.718942651984.issue39662@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this. But if you have additional information that points to this being a bug in python, we can re-open it.

----------
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39662>
_______________________________________

From report at bugs.python.org  Tue Feb 18 16:39:31 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 18 Feb 2020 21:39:31 +0000
Subject: [issue39555] test_distutils fails for Windows debug build
In-Reply-To: <1580878757.67.0.288943612022.issue39555@roundup.psfhosted.org>
Message-ID: <1582061971.61.0.247212326912.issue39555@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset d77e77116fa7a9fc85be1d9f417c7e9e33fe1296 by Miss Islington (bot) in branch '3.8':
bpo-39555: Fix distutils test to handle _d suffix on Windows debug build (GH-18357) (GH-18548)
https://github.com/python/cpython/commit/d77e77116fa7a9fc85be1d9f417c7e9e33fe1296


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39555>
_______________________________________

From report at bugs.python.org  Tue Feb 18 18:04:21 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 18 Feb 2020 23:04:21 +0000
Subject: [issue9056] Adding additional level of bookmarks and section numbers
 in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1582067061.14.0.901035887675.issue9056@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Merged Cheryl's patch (thanks Cheryl!).

pengyu.ut if you want to test it you'll be able to see generated PDF in a maximum of 24h from now on [1].

Don't hesitate to ask if you need them for 3.8 we can backport it.

[1]: https://docs.python.org/dev/

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9056>
_______________________________________

From report at bugs.python.org  Tue Feb 18 18:05:18 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 18 Feb 2020 23:05:18 +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: <1582067118.74.0.845707270286.issue28859@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I am going to think maybe it was the "os.path.ismount" command that is causing the issue. Does the file exist?

If the file does not exist, it is definitely not a mount point. So the function should return False instead of raising an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28859>
_______________________________________

From report at bugs.python.org  Tue Feb 18 18:17:06 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Tue, 18 Feb 2020 23:17:06 +0000
Subject: [issue39603] [security] http.client: HTTP Header Injection in the
 HTTP method
In-Reply-To: <1581362975.61.0.33794022777.issue39603@roundup.psfhosted.org>
Message-ID: <1582067826.25.0.273144177126.issue39603@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

Hey, it's been a week since the last activity here...
Amir, if you are not working on it I'd be glad to work on it as well :)

----------
nosy: +kmaork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39603>
_______________________________________

From report at bugs.python.org  Tue Feb 18 19:50:24 2020
From: report at bugs.python.org (Ido Michael)
Date: Wed, 19 Feb 2020 00:50:24 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582073424.62.0.407182990229.issue38691@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Yes I saw those in the morning, thanks for patching it up. I will debug this over the weekend and will update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Tue Feb 18 19:56:00 2020
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 19 Feb 2020 00:56:00 +0000
Subject: [issue39680] datetime.astimezone() method does not handle invalid
 local times as required by PEP 495
Message-ID: <1582073760.64.0.932670669115.issue39680@roundup.psfhosted.org>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Let g be a an invalid time in New York spring-forward gap:

>>> g = datetime(2020, 3, 8, 2, 30)

According to PEP 495, conversion of such instance to UTC should return a value that corresponds to a valid local time greater than g, but

>>> print(g.astimezone(timezone.utc).astimezone())
2020-03-08 01:30:00-05:00

Also, conversion of the same instance with fold=1 to UTC and back should produce a lesser time, but

>>> print(g.replace(fold=1).astimezone(timezone.utc).astimezone())
2020-03-08 03:30:00-04:00

Note that conversion to and from timestamp works correctly:

>>> print(datetime.fromtimestamp(g.timestamp()))
2020-03-08 03:30:00
>>> print(datetime.fromtimestamp(g.replace(fold=1).timestamp()))
2020-03-08 01:30:00

----------
assignee: belopolsky
messages: 362241
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: datetime.astimezone() method does not handle invalid local times as required by PEP 495
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39680>
_______________________________________

From report at bugs.python.org  Tue Feb 18 20:04:49 2020
From: report at bugs.python.org (Nathan Goldbaum)
Date: Wed, 19 Feb 2020 01:04:49 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
Message-ID: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>


New submission from Nathan Goldbaum <nathan12343 at gmail.com>:

As of https://github.com/python/cpython/pull/7076, it looks like at least the C implementation of pickle.load expects the file argument to implement readinto:

https://github.com/python/cpython/blob/ffd9753a944916ced659b2c77aebe66a6c9fbab5/Modules/_pickle.c#L1617-L1622

This is a change in behavior relative to previous versions of Python and I don't see it mentioned in PEP 574 or in the pull request so I'm not sure why it was changed.

This change breaks some PyTorch tests (see https://github.com/pytorch/pytorch/issues/32289) and, at least one PyTorch user, although I don't have full details there.

I can try to fix this on the PyTorch side but I first want to check that this was an intentional change on the Python side of things.

----------
components: Library (Lib)
messages: 362242
nosy: Nathan.Goldbaum
priority: normal
severity: normal
status: open
title: pickle.load expects an object that implements readinto
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Tue Feb 18 20:24:40 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 01:24:40 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582075480.12.0.663867177877.issue39681@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Tue Feb 18 21:08:27 2020
From: report at bugs.python.org (ilya)
Date: Wed, 19 Feb 2020 02:08:27 +0000
Subject: [issue39670] 2to3 fix_apply tries to fix user-defined apply function
 calls
In-Reply-To: <1582017039.66.0.352808121621.issue39670@roundup.psfhosted.org>
Message-ID: <1582078106.99.0.400267554291.issue39670@roundup.psfhosted.org>


ilya <palachev.ilya at yandex.ru> added the comment:

> apply was a builtin in Python 2 and not sure 2to3 can differentiate between user defined functions that shadow builtins. https://docs.python.org/3.8/library/2to3.html#2to3fixer-apply .

> Removes usage of apply(). For example apply(function, *args, **kwargs) is converted to function(*args, **kwargs).

> You can skip the apply fixer: 2to3 -x apply /tmp/bar.py

The problem is that the code is valid both for Python2 and Python3 (for Python3, there is even no builtin shadowing, because there is no apply builtin actually), and fix_apply breaks it.
I'm testing the quality of 2to3 fixers and found this issue.
I know that it's possible to switch this fixer off, but it doesn't seem to be a proper solution because any other bug could have the same answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39670>
_______________________________________

From report at bugs.python.org  Tue Feb 18 21:10:35 2020
From: report at bugs.python.org (Barney Gale)
Date: Wed, 19 Feb 2020 02:10:35 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
Message-ID: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>


New submission from Barney Gale <barney.gale at gmail.com>:

`pathlib.Path` objects can be used as context managers, but this functionality is undocumented and makes little sense. Example:

>>> import pathlib
>>> root = pathlib.Path("/")
>>> with root:
...     print(1)
... 
1
>>> with root:
...     print(2)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/barney/.pyenv/versions/3.7.3/lib/python3.7/pathlib.py", line 1028, in __enter__
    self._raise_closed()
  File "/home/barney/.pyenv/versions/3.7.3/lib/python3.7/pathlib.py", line 1035, in _raise_closed
    raise ValueError("I/O operation on closed path")
ValueError: I/O operation on closed path

`Path` objects don't acquire any resources on __new__/__init__/__enter__, nor do they release any resources on __exit__. The whole notion of the path being `_closed` seems to exist purely to make impure `Path` methods unusable after exiting from the context manager. I can't personally think of a compelling use case for this, and suggest that it be removed.

----------
components: Library (Lib)
messages: 362244
nosy: barneygale
priority: normal
severity: normal
status: open
title: pathlib.Path objects can be used as context managers
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39682>
_______________________________________

From report at bugs.python.org  Tue Feb 18 21:18:46 2020
From: report at bugs.python.org (ilya)
Date: Wed, 19 Feb 2020 02:18:46 +0000
Subject: [issue39683] 2to3 fix_exitfunc suggests duplicated import of atexit
 module
Message-ID: <1582078726.23.0.378327205623.issue39683@roundup.psfhosted.org>


New submission from ilya <palachev.ilya at yandex.ru>:

Consider the following code:

import sys

def foo():
    print(1)

def bar():
    print(2)

if input("case: ") == 1:
    sys.exitfunc = foo
else:
    sys.exitfunc = bar

2to3 -f exitfunc suggests to fix it as follows:

--- a.py	(original)
+++ a.py	(refactored)
@@ -1,4 +1,6 @@
 import sys
+import atexit
+import atexit
 
 def foo():
     print(1)
@@ -7,6 +9,6 @@
     print(2)
 
 if input("case: ") == 1:
-    sys.exitfunc = foo
+    atexit.register(foo)
 else:
-    sys.exitfunc = bar
+    atexit.register(bar)

So it seems that it produces one import of atexit module per each use of sys.exitfunc.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 362245
nosy: ilya
priority: normal
severity: normal
status: open
title: 2to3 fix_exitfunc suggests duplicated import of atexit module
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39683>
_______________________________________

From report at bugs.python.org  Tue Feb 18 22:46:55 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 03:46:55 +0000
Subject: [issue39670] 2to3 fix_apply tries to fix user-defined apply function
 calls
In-Reply-To: <1582017039.66.0.352808121621.issue39670@roundup.psfhosted.org>
Message-ID: <1582084015.02.0.844775891753.issue39670@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The fixers are supposed to be executed on Python 2 files where apply was a builtin and was shadowed. So from the context of the fixer it tries to make the modification and it cannot distinguish that it's a builtin or user-defined call. In Python 3 the apply function can be defined by the user and 2to3 fixer doesn't make sense to be executed on Python 3 files. filter is another example where the call is transformed into a list comprehension by 2to3 but by the issue it shouldn't be done because filter is a user-defined function though it's a builtin in Python 2.

def filter(func, iterable):
    pass

filter(lambda x: x % 2 == 0, range(10))

RefactoringTool: Refactored /tmp/foo.py
--- /tmp/foo.py	(original)
+++ /tmp/foo.py	(refactored)
@@ -1,4 +1,4 @@
 def filter(func, iterable):
     pass

-filter(lambda x: x % 2 == 0, range(10))
+[x for x in range(10) if x % 2 == 0]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39670>
_______________________________________

From report at bugs.python.org  Tue Feb 18 22:50:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 03:50:24 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1582084224.5.0.198919322343.issue39682@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/issue39682>
_______________________________________

From report at bugs.python.org  Tue Feb 18 22:54:23 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 03:54:23 +0000
Subject: [issue39679] functools: singledispatchmethod doesn't work with
 classmethod
In-Reply-To: <1582053375.25.0.178240077179.issue39679@roundup.psfhosted.org>
Message-ID: <1582084463.52.0.512286776863.issue39679@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39679>
_______________________________________

From report at bugs.python.org  Tue Feb 18 23:33:13 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 19 Feb 2020 04:33:13 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582086793.05.0.79453591063.issue39572@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset ab6423fe2de0ed5f8a0dc86a9c7070229326b0f0 by ananthan-123 in branch 'master':
bpo-39572: Document ?total? flag of TypedDict (GH-18554)
https://github.com/python/cpython/commit/ab6423fe2de0ed5f8a0dc86a9c7070229326b0f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Tue Feb 18 23:46:34 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 19 Feb 2020 04:46:34 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1582087594.59.0.207986199492.issue38860@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Justin Capella wrote:
> Is there a better forum for discussion about design/behavior, maybe the more generic issue of GenericPyCData_new using tp_alloc instead of tp_new

Rebecca Morgan wrote:
> I would still be interested in this, with some clarity on the testing/expected behavior.

I'm not personally active on the capi-sig mailing list, but it seems like it would be a suitable location for discussing the behavior of GenericPyCData_new. If you don't receive a response in capi-sig, you could also try python-dev to bring some attention to the issue since most of the core developers actively check there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:06:05 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Feb 2020 05:06:05 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582088765.56.0.995109679818.issue39572@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17936
pull_request: https://github.com/python/cpython/pull/18556

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:12:14 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 19 Feb 2020 05:12:14 +0000
Subject: [issue17050] argparse.REMAINDER doesn't work as first argument
In-Reply-To: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>
Message-ID: <1582089134.74.0.141075334722.issue17050@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> Okay. Would it be all right if I submit a fix to get it working at least in the subparser case?

Hi, dHannasch. According raymond and paul's opinion, you could try to create a PR to update argparse's doc.

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17050>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:14:59 2020
From: report at bugs.python.org (Andy Lester)
Date: Wed, 19 Feb 2020 05:14:59 +0000
Subject: [issue39684] PyUnicode_IsIdentifier has two if/thens that can be
 combined
Message-ID: <1582089299.55.0.574843604033.issue39684@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

These two code if/thens can be combined

    if (ready) {
        kind = PyUnicode_KIND(self);
        data = PyUnicode_DATA(self);
    }
    else {
        wstr = _PyUnicode_WSTR(self);
    }

    Py_UCS4 ch;
    if (ready) {
        ch = PyUnicode_READ(kind, data, 0);
    }
    else {
        ch = wstr[0];
    }

----------
components: Interpreter Core
messages: 362250
nosy: petdance
priority: normal
severity: normal
status: open
title: PyUnicode_IsIdentifier has two if/thens that can be combined

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39684>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:21:35 2020
From: report at bugs.python.org (Andy Lester)
Date: Wed, 19 Feb 2020 05:21:35 +0000
Subject: [issue39684] PyUnicode_IsIdentifier has two if/thens that can be
 combined
In-Reply-To: <1582089299.55.0.574843604033.issue39684@roundup.psfhosted.org>
Message-ID: <1582089695.49.0.781854472664.issue39684@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17937
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18557

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39684>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:24:57 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Feb 2020 05:24:57 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582089897.61.0.461940575663.issue39572@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 44c690112d96a81fe02433de7900a4f8f9457012 by Miss Islington (bot) in branch '3.8':
bpo-39572: Document ?total? flag of TypedDict (GH-18554)
https://github.com/python/cpython/commit/44c690112d96a81fe02433de7900a4f8f9457012


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:28:20 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 19 Feb 2020 05:28:20 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582090100.38.0.874722100923.issue39572@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Separately, would you also be interested in writing docs for the `__total__` class attribute of TypedDict subclasses (3.8 and 3.9) and for the `__required_keys__` and `__total_keys__` attributes (only in 3.9)? (Sorry, there's no document you can crib these from. :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:36:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 05:36:16 +0000
Subject: [issue39679] functools: singledispatchmethod doesn't work with
 classmethod
In-Reply-To: <1582053375.25.0.178240077179.issue39679@roundup.psfhosted.org>
Message-ID: <1582090576.86.0.973261276625.issue39679@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess the method checks for annotation on cls [0] which will be classmethod/staticmethod object in the report and won't have annotations. The annotations should be looked up in the function the classmethod/staticmethod decorator wraps around as in cls.__func__ . Something like below so that the right annotations are picked up. In addition to this the registry should store the type annotation as key to cls or cls.__func__ depending on normal method or classmethod/staticmethod.

diff --git Lib/functools.py Lib/functools.py
index 050bec8605..a66711208d 100644
--- Lib/functools.py
+++ Lib/functools.py
@@ -1073,24 +1073,33 @@ def singledispatch(func):
         if func is None:
             if isinstance(cls, type):
                 return lambda f: register(cls, f)
-            ann = getattr(cls, '__annotations__', {})
+            if isinstance(cls, (classmethod, staticmethod)):
+                ann = getattr(cls.__func__, '__annotations__', {})
+                func = cls.__func__
+            else:
+                ann = getattr(cls, '__annotations__', {})
+                func = cls

[0] https://github.com/python/cpython/blob/ab6423fe2de0ed5f8a0dc86a9c7070229326b0f0/Lib/functools.py#L1076

----------
nosy: +levkivskyi, ncoghlan, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39679>
_______________________________________

From report at bugs.python.org  Wed Feb 19 00:45:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 05:45:21 +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: <1582091121.24.0.402857333143.issue39139@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The removal in 3.9 was reverted and postponed to 3.10 in issue39674.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39139>
_______________________________________

From report at bugs.python.org  Wed Feb 19 01:07:40 2020
From: report at bugs.python.org (Brian May)
Date: Wed, 19 Feb 2020 06:07:40 +0000
Subject: [issue39685] Python 3.8 regression Socket operation on non-socket
Message-ID: <1582092460.6.0.713532643736.issue39685@roundup.psfhosted.org>


New submission from Brian May <brian at linuxpenguins.xyz>:

After upgrading to Python 3.8, users of sshuttle report seeing this error:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "assembler.py", line 38, in <module>
  File "sshuttle.server", line 298, in main
  File "/usr/lib/python3.8/socket.py", line 544, in fromfd
    return socket(family, type, proto, nfd)
  File "/usr/lib/python3.8/socket.py", line 231, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
OSError: [Errno 88] Socket operation on non-socket

https://github.com/sshuttle/sshuttle/issues/381

The cause of the error is this line: 
https://github.com/sshuttle/sshuttle/blob/6ad4473c87511bcafaec3d8d0c69dfcb166b48ed/sshuttle/server.py#L297 which does:

socket.fromfd(sys.stdin.fileno(), socket.AF_INET, socket.SOCK_STREAM)
socket.fromfd(sys.stdout.fileno(), socket.AF_INET, socket.SOCK_STREAM)

Where sys.stdin and sys.stdout are stdin/stdout provided by the ssh server when it ran our remote ssh process.

I believe this change in behavior is as a result of a fix for the following bug: https://bugs.python.org/issue35415

I am wondering if this is a bug in Python for causing such a regression, or a bug in sshuttle. Possibly sshuttle is using socket.fromfd in a way that was never intended?

Would appreciate an authoritative answer on this.

Thanks

----------
components: IO
messages: 362255
nosy: brian
priority: normal
severity: normal
status: open
title: Python 3.8 regression Socket operation on non-socket
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39685>
_______________________________________

From report at bugs.python.org  Wed Feb 19 01:23:22 2020
From: report at bugs.python.org (Richard K)
Date: Wed, 19 Feb 2020 06:23:22 +0000
Subject: [issue39686] add dump_json to ast module
Message-ID: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>


New submission from Richard K <qpotizo at gmail.com>:

Currently within the ast module, `dump` generates a string representation of the AST for example,

>>> ast.dump(node)
'Module(body=[], type_ignores=[])'


The proposed enhancement would provide a complementary function, `dump_json` as in a json representation of the ast. 
This would be useful for those who would like to benefit from the utilities of the json module for formatting, pretty-printing, and the like.  
It would also be useful for those who want to serialize the AST or export it in a form that can be consumed in an other programming language.
A simplified example, 


>>> import ast
>>> node = ast.parse('')
>>> ast.dump_json(node)
{'Module': {'body': [], 'type_ignores': []}}


A simplified example of using `ast.dump_json` with the json module,

>>> import json
>>> json.dumps(ast.dump_json(node))
'{"Module": {"body": [], "type_ignores": []}}'

----------
components: Library (Lib)
messages: 362256
nosy: sparverius
priority: normal
severity: normal
status: open
title: add dump_json to ast module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 01:34:30 2020
From: report at bugs.python.org (Richard K)
Date: Wed, 19 Feb 2020 06:34:30 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582094069.99.0.755202578538.issue39686@roundup.psfhosted.org>


Change by Richard K <qpotizo at gmail.com>:


----------
keywords: +patch
pull_requests: +17938
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18558

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 01:44:08 2020
From: report at bugs.python.org (zd nex)
Date: Wed, 19 Feb 2020 06:44:08 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582094648.85.0.213821982906.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

So I was trying to figure out what is crash it self and it looks to me that it is related to import. Do you know how I can properly debug this crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Wed Feb 19 02:06:35 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 19 Feb 2020 07:06:35 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582095995.71.0.0885817267149.issue38691@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

>From what I can tell, the regression seems like it could be fixed by adding "@unittest.skipIf(sys.flags.ignore_environment)" to the following tests in python/cpython/Lib/test/test_importlib/source/test_case_sensitivity.py that modify "PYTHONCASEOK":

CaseSensitivityTest.test_sensitive
CaseSensitivityTest.test_insensitive

Those tests seem ultimately pointless if environmental variables are being ignored (-E or -I), so I think in this case it's a misleading test failure, no?

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Wed Feb 19 04:06:47 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 19 Feb 2020 09:06:47 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582103207.56.0.975014625104.issue39681@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Right, I think at some point during the PEP 574 implementation review, we decided that the input object had to be a proper file implementation
(for example, deriving from io.BufferedIOBase).

I think it should be easy for PyTorch to fix this internally (by deriving from the proper io base class), but we can also add a fix to pickle.

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Wed Feb 19 04:24:53 2020
From: report at bugs.python.org (Henning von Bargen)
Date: Wed, 19 Feb 2020 09:24:53 +0000
Subject: [issue22213] Make pyvenv style virtual environments easier to
 configure when embedding Python
In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>
Message-ID: <1582104293.0.0.357420170774.issue22213@roundup.psfhosted.org>


Change by Henning von Bargen <h.vonbargen at gmail.com>:


----------
nosy: +Henning.von.Bargen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________

From report at bugs.python.org  Wed Feb 19 04:45:23 2020
From: report at bugs.python.org (Henning von Bargen)
Date: Wed, 19 Feb 2020 09:45:23 +0000
Subject: [issue22213] Make pyvenv style virtual environments easier to
 configure when embedding Python
In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>
Message-ID: <1582105523.42.0.85204280535.issue22213@roundup.psfhosted.org>


Henning von Bargen <h.vonbargen at gmail.com> added the comment:

As a side-note:
In my case I am embedding Python in a C program for several reasons:
- Added an additional module (generated with SWIG)
- This module needs a licence key, which I supply in the C program (to make it more difficult to extract it).
- I need a different executable name (python is too unspecific) to identify the running program in things like Windows TaskManager, Posix ps,  Oracle V$SESSION.

I'm using virtual environments only in the Linux version, the Windows version uses the embeddable ZIP distribution.

The Linux version was working with Python 2.7 and "virtualenv".
Now I'm updating to Python 3.6 and "venv" and running into this issue.

It seems like virtualenv can handle the situation, but venv can't.
Maybe it is worth looking at what virtualenv does differently?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________

From report at bugs.python.org  Wed Feb 19 05:15:17 2020
From: report at bugs.python.org (Alex Hall)
Date: Wed, 19 Feb 2020 10:15:17 +0000
Subject: [issue13672] Add co_qualname attribute in code objects
In-Reply-To: <1325100000.16.0.854542819355.issue13672@psf.upfronthosting.co.za>
Message-ID: <1582107317.31.0.47770677597.issue13672@roundup.psfhosted.org>


Alex Hall <alex.mojaki at gmail.com> added the comment:

I think this would be very useful in tracebacks. If a traceback line had a more useful name like `MyClass.__init__` instead of just `__init__` or `my_decorator.<locals>.wrapper` instead of just `wrapper` it would provide useful context to the frame.

----------
nosy: +alexmojaki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13672>
_______________________________________

From report at bugs.python.org  Wed Feb 19 05:30:36 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Wed, 19 Feb 2020 10:30:36 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1581019680.46.0.628292741765.issue39572@roundup.psfhosted.org>
Message-ID: <1582108236.91.0.814120423173.issue39572@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

yes,I'm interested in writing docs for the `__required_keys__` and `__total_keys__` attributes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Wed Feb 19 06:11:02 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Wed, 19 Feb 2020 11:11:02 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582110662.26.0.97188013563.issue17422@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
pull_requests: +17939
pull_request: https://github.com/python/cpython/pull/18559

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Wed Feb 19 06:21:24 2020
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 19 Feb 2020 11:21:24 +0000
Subject: [issue39676] test_shutil fails with OSError: [Errno 28] No space left
 on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
In-Reply-To: <1582030912.19.0.281317890533.issue39676@roundup.psfhosted.org>
Message-ID: <1582111284.02.0.471449358516.issue39676@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

The issue has been fixed. root was 15GB, but there was still 30GB of un-allocated space in the volume group, so just expanded the logical volume.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39676>
_______________________________________

From report at bugs.python.org  Wed Feb 19 06:40:24 2020
From: report at bugs.python.org (Yves)
Date: Wed, 19 Feb 2020 11:40:24 +0000
Subject: [issue39687] re.sub behaves inconsistent between versions with *
 repetition qualifier
Message-ID: <1582112424.4.0.996005066696.issue39687@roundup.psfhosted.org>


New submission from Yves <uves at spline.de>:

On different platforms and versions the following expression has different results:

  python -c 'import re; print(re.compile("(.*)", 0).sub("a\\1", "bc"))'

As far is I observed:

  Linux/Python 3.6.9   => abc
  MacOS/Python 3.7.1   => abca
  Repl.it/Python 3.8.1 => abca
  MacOS/Python 2.7.17  => abc
  Linux/Python 2.7.17  => abc

According the the documentation I would guess that "abc" is the correct return value.

The issues also occurs without compiling or capture group:

 re.sub(".*", "a", "cb")  a vs aa

----------
components: Regular Expressions
messages: 362264
nosy: ezio.melotti, mrabarnett, slomo
priority: normal
severity: normal
status: open
title: re.sub behaves inconsistent between versions with * repetition qualifier
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39687>
_______________________________________

From report at bugs.python.org  Wed Feb 19 06:47:33 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 19 Feb 2020 11:47:33 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
 =?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
 =?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1582112853.65.0.185534009808.issue9182@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

It exists in master, so it still need a patch.

----------
nosy: +rhettinger, shihai1991
versions: +Python 3.9 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Wed Feb 19 07:21:29 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Wed, 19 Feb 2020 12:21:29 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1582114889.48.0.0486701507802.issue39623@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

> This could sometimes make the output verbose

We could limit the length of the recursive __repr__ functions, and display partial reprs suffixed with ..., like in numpy for example.

We can define that the maximum wanted length of a task repr would be, say, 80 characters, get the reprs of all task arguments, and if the sum length is more than the maximum we can trim the longest ones and suffix with a '...'.

Maybe this restriction shouldn't be applied if python is built in debug mode.

----------
nosy: +kmaork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Wed Feb 19 07:22:47 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Wed, 19 Feb 2020 12:22:47 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582114967.2.0.98465097412.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

On which OS did that happen?

----------
nosy: +kmaork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Wed Feb 19 07:28:50 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 19 Feb 2020 12:28:50 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582115330.26.0.747185930791.issue39686@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 08:10:04 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 19 Feb 2020 13:10:04 +0000
Subject: [issue39676] test_shutil fails with OSError: [Errno 28] No space left
 on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
In-Reply-To: <1582030912.19.0.281317890533.issue39676@roundup.psfhosted.org>
Message-ID: <1582117804.24.0.528041468162.issue39676@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Indeed, builds are green: https://buildbot.python.org/all/#/builders/449

Thanks Victor for reporting and Harris for fixing this.

----------
nosy: +petr.viktorin
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39676>
_______________________________________

From report at bugs.python.org  Wed Feb 19 08:23:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Feb 2020 13:23:59 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582118639.39.0.698019567368.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4dee92b0ad9f4e3ea2fbbbb5253340801bb92dc7 by Victor Stinner in branch 'master':
Revert "bpo-38691 Added a switch to ignore PYTHONCASEOK when -E or -I flags passed (#18314)" (GH-18553)
https://github.com/python/cpython/commit/4dee92b0ad9f4e3ea2fbbbb5253340801bb92dc7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Wed Feb 19 08:24:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Feb 2020 13:24:51 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582118691.78.0.304512961899.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Yes I saw those in the morning, thanks for patching it up. I will debug this over the weekend and will update.

Ok, perfect. In the meanwhile, as announced, I reverted the change to be able to notify other regressions.

Once we get a fix, we can reapply the change with the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Wed Feb 19 08:24:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Feb 2020 13:24:52 +0000
Subject: [issue39687] re.sub behaves inconsistent between versions with *
 repetition qualifier
In-Reply-To: <1582112424.4.0.996005066696.issue39687@roundup.psfhosted.org>
Message-ID: <1582118692.07.0.121010831272.issue39687@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is correct and documented behavior. ".*" matches two substrings: the whole string "bc" and an empty string at the end of the string.

See https://docs.python.org/3/library/re.html#re.sub and https://docs.python.org/3/whatsnew/3.7.html#changes-in-the-python-api.

The behavior before 3.7 was incorrect.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39687>
_______________________________________

From report at bugs.python.org  Wed Feb 19 08:34:53 2020
From: report at bugs.python.org (Nicolas Dessart)
Date: Wed, 19 Feb 2020 13:34:53 +0000
Subject: [issue39632] variadic function call broken on armhf when passing a
 float argument
In-Reply-To: <1581674608.19.0.403543141988.issue39632@roundup.psfhosted.org>
Message-ID: <1582119293.08.0.938939897743.issue39632@roundup.psfhosted.org>


Change by Nicolas Dessart <nicolas.dessart at gmail.com>:


----------
pull_requests: +17940
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39632>
_______________________________________

From report at bugs.python.org  Wed Feb 19 08:59:02 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Wed, 19 Feb 2020 13:59:02 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582120742.45.0.27502221419.issue17422@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

I just addded a PR for this issue.

----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Wed Feb 19 09:00:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 19 Feb 2020 14:00:14 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582120814.83.0.0937208131203.issue39686@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> The proposed enhancement would provide a complementary function, `dump_json` as in a json representation of the ast. 

IMHO this is not a feature that has a general usage. If you want, as far as I can see, there are some packages for doing that in PyPI already. Also, the patch looks small so you can just add this to the required project.

> This would be useful for those who would like to benefit from the utilities of the json module for formatting, pretty-printing, and the like.  

ast.dump now can dump in pretty-printed way.

> It would also be useful for those who want to serialize the AST or export it in a form that can be consumed in an other programming language.

As I said, serializing/exporting the AST isn't a common use case. It is a very specific goal.

In general, I'm -1 on this.

----------
nosy: +benjamin.peterson, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 09:19:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 19 Feb 2020 14:19:42 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582121982.56.0.223359028552.issue39686@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks, Richard for your proposal. I concur with Batuhan: I am -1 as well on this addition. Echoing some of the same ideas, I think this is specialized enough that does not make sense to have it in the standard library, especially if a Pypi package already exists. Additionally, this is straightforward to implement for very simple cases but PR18558 will fail for very generic ASTs if they are deep enough (it uses recursion).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 09:24:42 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Feb 2020 14:24:42 +0000
Subject: [issue35081] Move internal headers to Include/internal/
In-Reply-To: <1540600944.05.0.788709270274.issue35081@psf.upfronthosting.co.za>
Message-ID: <1582122282.96.0.428730073928.issue35081@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/issue35081>
_______________________________________

From report at bugs.python.org  Wed Feb 19 09:34:50 2020
From: report at bugs.python.org (Valentin Samir)
Date: Wed, 19 Feb 2020 14:34:50 +0000
Subject: [issue39688] tarfile: GNU sparse 1.0 pax tar header offset not
 properly computed
Message-ID: <1582122890.87.0.720726833574.issue39688@roundup.psfhosted.org>


New submission from Valentin Samir <valentin.samir at crans.org>:

When tarfile open a tar containing a sparse file where actual data is bigger than 0o77777777777 bytes (~8GB), it fails listing members after this file. As so, it is impossible to access/extract files located after a such file inside the archive.

A tar file presenting the issue is available at https://genua.fr/sample.tar.xz
Uncompressed the file is ~16GB.
It containes two files:
* disk.img a 50GB sparse file containing ~16GB of data
* README.txt a simple text file containing "This last file is not properly listed"

disk.img was generated using the folowing python script:

GB = 1024**3
buf = b"\xFF" * 1024**2
with open('disk.img', 'wb') as f:
    f.seek(10 * GB)
    wrotten = 0
    while wrotten < 0o77777777777:
        wrotten += f.write(buf)
        f.flush()
        print(wrotten/0o77777777777 * 100, '%')
    f.seek(50 * GB - 1)
    f.write(b'\0')

sample.tar was generated using GNU tar 1.30 on a Debian 10 with the following command:

tar --format pax -cvSf sample.tar disk.img README.txt

The following script expose the issue:

import tarfile
t = tarfile.open('sample.tar')
print('members', t.getmembers())
print('offset', t.offset)

Its output is:

members [<TarInfo 'disk.img' at 0x7f5b14242b38>]
offset 17179806208

members should also list README.txt.


I think I have found the root cause of the bug: Because the file is bigger than 0o77777777777, it's size cannot be specified inside the tar ustar header, so a "size" pax extented header is generated. This header contain the full size of the file block in the tar.

As the file is sparse, as of sparse format 1.0, the file block contains first a sparse mapping, then the file data. So this block size is the size of the mapping added to the size of the data.

Because the file is sparse, a GNU.sparse.realsize header is also added containing the full expanded file size (here 50GB).

Here https://github.com/python/cpython/blob/4dee92b0ad9f4e3ea2fbbbb5253340801bb92dc7/Lib/tarfile.py#L1350 tarfile set the tarinfo size to GNU.sparse.realsize  (50GB),then, in this block https://github.com/python/cpython/blob/4dee92b0ad9f4e3ea2fbbbb5253340801bb92dc7/Lib/tarfile.py#L1297 the file offset is moved forward from GNU.sparse.realsize (50GB) instead of pax_headers["size"]. Moreover, the move is done from next.offset_data which is set at https://github.com/python/cpython/blob/master/Lib/tarfile.py#L1338 to after the sparse mapping.
The move forward in the sparse file should be made from next.offset + BLOCKSIZE.

----------
components: Library (Lib)
messages: 362275
nosy: Nit
priority: normal
severity: normal
status: open
title: tarfile: GNU sparse 1.0 pax tar header offset not properly computed
type: behavior
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/issue39688>
_______________________________________

From report at bugs.python.org  Wed Feb 19 09:41:18 2020
From: report at bugs.python.org (Nicolas Dessart)
Date: Wed, 19 Feb 2020 14:41:18 +0000
Subject: [issue39632] variadic function call broken on armhf when passing a
 float argument
In-Reply-To: <1581674608.19.0.403543141988.issue39632@roundup.psfhosted.org>
Message-ID: <1582123278.51.0.413456475158.issue39632@roundup.psfhosted.org>


Change by Nicolas Dessart <nicolas.dessart at gmail.com>:


----------
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/issue39632>
_______________________________________

From report at bugs.python.org  Wed Feb 19 09:57:29 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 19 Feb 2020 14:57:29 +0000
Subject: [issue39572] [typing] TypedDict's 'total' argument is undocumented
In-Reply-To: <1582108236.91.0.814120423173.issue39572@roundup.psfhosted.org>
Message-ID: <CAP7+vJLTuvJS1rnarVUSLEAinZ6f=vEr7x=KzxGrOC7ELMnU2A@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Go for it. Use the same bug number.

On Wed, Feb 19, 2020 at 02:30 Ananthakrishnan <report at bugs.python.org>
wrote:

>
> Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:
>
> yes,I'm interested in writing docs for the `__required_keys__` and
> `__total_keys__` attributes.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39572>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39572>
_______________________________________

From report at bugs.python.org  Wed Feb 19 10:01:49 2020
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 19 Feb 2020 15:01:49 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
Message-ID: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

The clang build was recently added for that buildbot and it seems on that particular architecture, test_struct fails with:

======================================================================
FAIL: test_bool (test.test_struct.StructTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-rawhide-z.clang-ubsan/build/Lib/test/test_struct.py", line 520, in test_bool
    self.assertTrue(struct.unpack('>?', c)[0])
AssertionError: False is not true

https://buildbot.python.org/all/#/builders/488/builds/6

Fedora rawhide recently upgraded Clang to version 10. The rest of the architectures seem fine.

----------
components: Tests
messages: 362277
nosy: cstratak, vstinner
priority: normal
severity: normal
status: open
title: test_struct failure on s390x Fedora Clang buildbot
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Wed Feb 19 10:04:18 2020
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 19 Feb 2020 15:04:18 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582124658.7.0.173299883619.issue39689@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

Failed assertion here: https://github.com/python/cpython/blob/master/Lib/test/test_struct.py#L520

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Wed Feb 19 10:29:13 2020
From: report at bugs.python.org (Valentin Samir)
Date: Wed, 19 Feb 2020 15:29:13 +0000
Subject: [issue39688] tarfile: GNU sparse 1.0 pax tar header offset not
 properly computed
In-Reply-To: <1582122890.87.0.720726833574.issue39688@roundup.psfhosted.org>
Message-ID: <1582126153.84.0.528601252872.issue39688@roundup.psfhosted.org>


Valentin Samir <valentin.samir at crans.org> added the comment:

This commit fix the issue https://github.com/nitmir/cpython/commit/50c1f686054e41738f14de453ede30e942064200

I am currently unable to create pull request on github (error 500)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39688>
_______________________________________

From report at bugs.python.org  Wed Feb 19 10:43:48 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Wed, 19 Feb 2020 15:43:48 +0000
Subject: [issue39560] PyUnicode_FromKindAndData kind transformation is not
 documented
In-Reply-To: <1580907133.21.0.114993814029.issue39560@roundup.psfhosted.org>
Message-ID: <1582127028.06.0.451122851681.issue39560@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

Can i add  a pull request for this.

----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39560>
_______________________________________

From report at bugs.python.org  Wed Feb 19 10:50:39 2020
From: report at bugs.python.org (Nathan Goldbaum)
Date: Wed, 19 Feb 2020 15:50:39 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582127439.15.0.990157199509.issue39681@roundup.psfhosted.org>


Nathan Goldbaum <nathan12343 at gmail.com> added the comment:

In this case the tests are explicitly testing that a file-like object that does not implement readinto works with torch.load (which is using pickles under the hood). See https://github.com/pytorch/pytorch/blob/master/test/test_serialization.py#L416-L429, in particular the usage of FilelikeMock with has_readinto set to False.

This goes back to https://github.com/pytorch/pytorch/pull/5466, however I'm not sure offhand why it was decided to explicitly test file-like objects that don't implement readinto. I don't know how many consumers there are for this API in pytorch, but there is at least one user who has reported an error traceback caused by this change. I'm hoping to hear more to see whether there are any libraries that depend on pytorch and are implicitly depending on this functionality.

Googling the error message that Python3.8 emits in this situation also leads me to this bug report in a different library: https://github.com/web2py/py4web/issues/77

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Wed Feb 19 10:51:55 2020
From: report at bugs.python.org (Valentin Samir)
Date: Wed, 19 Feb 2020 15:51:55 +0000
Subject: [issue39688] tarfile: GNU sparse 1.0 pax tar header offset not
 properly computed
In-Reply-To: <1582122890.87.0.720726833574.issue39688@roundup.psfhosted.org>
Message-ID: <1582127515.17.0.448094059259.issue39688@roundup.psfhosted.org>


Valentin Samir <valentin.samir at crans.org> added the comment:

hum trying to be clever and I am doing mistakes.

This commit is simpler and effectively fixes the issue https://github.com/nitmir/cpython/commit/682138a3544a2d7de457c88712e738938568f908

tarinfo.offset_data is where tarfile start reading the file data and thus must be set to the beginning of the actual data for a sparse file even if the data block starts before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39688>
_______________________________________

From report at bugs.python.org  Wed Feb 19 11:08:37 2020
From: report at bugs.python.org (Simon)
Date: Wed, 19 Feb 2020 16:08:37 +0000
Subject: [issue39589] Logging QueueListener should support context manager
In-Reply-To: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>
Message-ID: <1582128517.71.0.784549990628.issue39589@roundup.psfhosted.org>


Simon <sfbbrugman at gmail.com> added the comment:

The QueueListener in the logging library starts a background thread to monitor the log event queue. The context manager support is ideal in this case, making the code simpler, more consistent with other classes (e.g. multiprocessing.Pool) and prompts stopping the thread.

Without support for the context manager we need the following code:

```
queue_listener = QueueListener(queue, handler)
queue_listener.start()
# queue messages
queue_listener.stop()
```

adding context manager support would result in the following equivalent code:

```
with QueueListener(queue, handler) as queue_listener:
    # queue messages
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39589>
_______________________________________

From report at bugs.python.org  Wed Feb 19 11:16:39 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Wed, 19 Feb 2020 16:16:39 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1582128999.26.0.050944379966.issue39379@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
keywords: +patch
pull_requests: +17941
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18561

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Wed Feb 19 11:28:30 2020
From: report at bugs.python.org (Valentin Samir)
Date: Wed, 19 Feb 2020 16:28:30 +0000
Subject: [issue39688] tarfile: GNU sparse 1.0 pax tar header offset not
 properly computed
In-Reply-To: <1582122890.87.0.720726833574.issue39688@roundup.psfhosted.org>
Message-ID: <1582129710.01.0.640148965228.issue39688@roundup.psfhosted.org>


Change by Valentin Samir <valentin.samir at crans.org>:


----------
keywords: +patch
pull_requests: +17942
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18562

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39688>
_______________________________________

From report at bugs.python.org  Wed Feb 19 11:32:41 2020
From: report at bugs.python.org (Simon)
Date: Wed, 19 Feb 2020 16:32:41 +0000
Subject: [issue39589] Logging QueueListener should support context manager
In-Reply-To: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>
Message-ID: <1582129961.29.0.901026741912.issue39589@roundup.psfhosted.org>


Change by Simon <sfbbrugman at gmail.com>:


----------
pull_requests: +17944
pull_request: https://github.com/python/cpython/pull/18563

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39589>
_______________________________________

From report at bugs.python.org  Wed Feb 19 11:36:35 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Feb 2020 16:36:35 +0000
Subject: [issue39589] Logging QueueListener should support context manager
In-Reply-To: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>
Message-ID: <1582130195.95.0.976230806751.issue39589@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39589>
_______________________________________

From report at bugs.python.org  Wed Feb 19 13:02:17 2020
From: report at bugs.python.org (Richard K)
Date: Wed, 19 Feb 2020 18:02:17 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582135337.87.0.157084707534.issue39686@roundup.psfhosted.org>


Richard K <qpotizo at gmail.com> added the comment:

Batuhan & Pablo thank you for your thoughts! Just wanted to reply to a few of the comments to clarify my position on the issue.


> IMHO this is not a feature that has a general usage. If you want, as far as I can see, there are some packages for doing that in PyPI already. Also, the patch looks small so you can just add this to the required project.


There seems to be movement towards a general usage. For instance, take a look at clang, in particular the flag '-ast-dump=json'.

$ clang -cc1 -ast-dump=json foo.cc


> ast.dump now can dump in pretty-printed way.

Indeed however, there is not much one can do further with the output of ast.dump. With ast.dump_json one would benefit from programmer-centric functionality.

-- 

> Thanks, Richard for your proposal. I concur with Batuhan: I am -1 as well on this addition. Echoing some of the same ideas, I think this is specialized enough that does not make sense to have it in the standard library, especially if a Pypi package already exists. 


After just browsing the the pypi package/s you may be referring to, it appears that they do so in non-standard ways.


> Additionally, this is straightforward to implement for very simple cases but PR18558 will fail for very generic ASTs if they are deep enough (it uses recursion).


The implementation of ast.dump also uses recursion. I have tested ast.dump_json on sufficiently large source files and have not run into recursion depth exceeded issues.


Thanks again for your perspective!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 13:15:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 19 Feb 2020 18:15:31 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582136131.74.0.0244035045054.issue39686@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> There seems to be movement towards a general usage. For instance, take a look at clang, in particular the flag '-ast-dump=json'.

I don't think the clang argument holds because clang is a command-line tool after all and it makes sense that it can produce several outputs while the ast module is exposes APIs that you can further process inside the language. Having json from the clang output will require more than one tool if clang does not support it while doing it in Python only requires Python.

> it appears that they do so in non-standard ways.

Can you clarify what do you mean with that? 

> The implementation of ast.dump also uses recursion. I have tested ast.dump_json on sufficiently large source files and have not run into recursion depth exceeded issues.

This is not the primary argumet as by itself is weaker because this is an edge case but for instance, here is an example of ast.dump succeeding and your tool failing:


>>> x = ast.List()
>>> for _ in range(1010):
    ...:     x = ast.List(x)
    ...:

>>> ast.dump(x)
'List(elts=List(elts=List(elts=List(elts=List(elts=L......

>>> dump_json(x)
---------------------------------------------------------------------------
RecursionError                            Traceback (most recent call last)
<ipython-input-22-fadef4fb6a0d> in <module>
RecursionError: maximum recursion depth exceeded while calling a Python object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 13:17:10 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 19 Feb 2020 18:17:10 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582136230.43.0.587485225902.issue39686@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Just to clarify: ast.dump *will* fail with a more deph object as well, I am not claiming that ast.dump will parse everything because of course suffers the same problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 13:21:51 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Feb 2020 18:21:51 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1582136511.37.0.408847404807.issue39479@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:


New changeset f2ee21d858bc03dd801b97afe60ee2ea289e2fe9 by ananthan-123 in branch 'master':
bpo-39479:Add math.lcm() function: Least Common Multiple (#18547)
https://github.com/python/cpython/commit/f2ee21d858bc03dd801b97afe60ee2ea289e2fe9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Wed Feb 19 13:22:25 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Feb 2020 18:22:25 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1582136545.78.0.463736628564.issue39479@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Wed Feb 19 14:27:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Feb 2020 19:27:32 +0000
Subject: [issue39690] Compiler warnings in unicodeobject.c
Message-ID: <1582140452.34.0.85531597667.issue39690@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Objects/clinic/unicodeobject.c.h: In function ?unicode_isidentifier?:
Objects/unicodeobject.c:12245:22: warning: ?wstr? may be used uninitialized in this function [-Wmaybe-uninitialized]
             ch = wstr[i];
                  ~~~~^~~
Objects/unicodeobject.c:12212:14: note: ?wstr? was declared here
     wchar_t *wstr;
              ^~~~
Objects/unicodeobject.c: In function ?PyUnicode_IsIdentifier?:
Objects/unicodeobject.c:12245:22: warning: ?wstr? may be used uninitialized in this function [-Wmaybe-uninitialized]
             ch = wstr[i];
                  ~~~~^~~

----------
components: Interpreter Core
messages: 362288
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compiler warnings in unicodeobject.c
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39690>
_______________________________________

From report at bugs.python.org  Wed Feb 19 14:46:38 2020
From: report at bugs.python.org (Richard K)
Date: Wed, 19 Feb 2020 19:46:38 +0000
Subject: [issue39686] add dump_json to ast module
In-Reply-To: <1582093402.26.0.349380477656.issue39686@roundup.psfhosted.org>
Message-ID: <1582141598.56.0.284566138891.issue39686@roundup.psfhosted.org>


Richard K <qpotizo at gmail.com> added the comment:

> I don't think the clang argument holds because clang is a command-line tool after all and it makes sense that it can produce several outputs while the ast module is exposes APIs that you can further process inside the language. Having json from the clang output will require more than one tool if clang does not support it while doing it in Python only requires Python.

I see what you mean. I was just trying to illustrate that such a feature is desired by some. 

Perhaps 'Python only requires Python' means that Python _could_ be the first widely used language with such a superior meta-programming feature with respect to AST analysis/code generation. 


> > it appears that they do so in non-standard ways.

> Can you clarify what do you mean with that? 

By non-standard I mean that the resulting json does not follow the structure of the tree explicitly. For example with ast2json, '"_type": "Print"' includes a (somewhat misleading) key that is not represented in the actual AST. 

Example of ast2json output (example found here, https://github.com/YoloSwagTeam/ast2json#example),

{
    "body": [
        {
            "_type": "Print",
            "nl": true,
            "col_offset": 0,
            "dest": null,
            "values": [
                {
                    "s": "Hello World!",
                    "_type": "Str",
                    "lineno": 1,
                    "col_offset": 6
                }
            ],
            "lineno": 1
        }
    ],
    "_type": "Module"
}


> Just to clarify: ast.dump *will* fail with a more deph object as well, I am not claiming that ast.dump will parse everything because of course suffers the same problem.

Makes sense. As you mentioned, these are edge cases which I assume will not be an issue for those seeking to gain the benefits of 'ast.dump_json'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39686>
_______________________________________

From report at bugs.python.org  Wed Feb 19 14:56:30 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Feb 2020 19:56:30 +0000
Subject: [issue39540] Logging docs don't address the creation of multiple
 loggers when a hierarchy is provided
In-Reply-To: <1580732994.06.0.683672257184.issue39540@roundup.psfhosted.org>
Message-ID: <1582142190.43.0.33515972663.issue39540@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39540>
_______________________________________

From report at bugs.python.org  Wed Feb 19 14:57:49 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Feb 2020 19:57:49 +0000
Subject: [issue39589] Logging QueueListener should support context manager
In-Reply-To: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>
Message-ID: <1582142269.5.0.741805363599.issue39589@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

See my comments on the PR. I think this issue and the PR should be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39589>
_______________________________________

From report at bugs.python.org  Wed Feb 19 15:33:35 2020
From: report at bugs.python.org (Andy Lester)
Date: Wed, 19 Feb 2020 20:33:35 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582144415.27.0.765182610044.issue38691@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy: +petdance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Wed Feb 19 16:44:28 2020
From: report at bugs.python.org (Nathan Goldbaum)
Date: Wed, 19 Feb 2020 21:44:28 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582148668.53.0.428067131933.issue39681@roundup.psfhosted.org>


Nathan Goldbaum <nathan12343 at gmail.com> added the comment:

So I *think* I've pieced together what caused the user crash that originated in the flair library. It turns out that pickle.load, via torch.load, is getting passed an mmap.mmap. 

https://github.com/flairNLP/flair/blob/1d44abf35f1122d1e146c9a219b2cb5f98b41b40/flair/file_utils.py#L25-L36

https://github.com/flairNLP/flair/blob/1d44abf35f1122d1e146c9a219b2cb5f98b41b40/flair/nn.py#L85-L86

Since mmap doesn't implement readinto, pickle.load objects as of Python 3.8. This is new behavior in Python3.8, it used to be possible to load a memory-mapped pickle file.

Short repro script:

import pickle
import mmap
data = "some data"

with open('my_data.pkl', 'wb') as f:
    pickle.dump(data, f)

with open("my_data.pkl", "r+b") as f_in:
    mm = mmap.mmap(f_in.fileno(), 0)

print(pickle.load(mm))

On Python3.8, this script prints an error, on Python3.7 it prints "some data".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Wed Feb 19 18:02:30 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Wed, 19 Feb 2020 23:02:30 +0000
Subject: [issue39691] Allow passing Pathlike objects to io.open_code
Message-ID: <1582153350.45.0.111444771925.issue39691@roundup.psfhosted.org>


New submission from Maor Kleinberger <kmaork at gmail.com>:

As in many functions in python3, io.open_code should probably accept pathlike objects and not just path strings.

Below is  open_code's docstring:
> Opens the provided file with the intent to import the contents.
> This may perform extra validation beyond open(), but is otherwise interchangeable with calling open(path, 'rb').

The second bit is not entirely true, as open accepts pathlike objects and open_code doesn't.
Fixing this will help solve future bugs and existing bugs like https://bugs.python.org/issue39517

I'd be happy to open a pull request if it is agreed that this should be changed.

----------
components: Library (Lib)
messages: 362292
nosy: kmaork
priority: normal
severity: normal
status: open
title: Allow passing Pathlike objects to io.open_code
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39691>
_______________________________________

From report at bugs.python.org  Wed Feb 19 18:04:17 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Wed, 19 Feb 2020 23:04:17 +0000
Subject: [issue39517] runpy calls open_code with Path object
In-Reply-To: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>
Message-ID: <1582153457.79.0.134949840711.issue39517@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

Not a direct solution, but I have offered that io.open_code should be changed to support pathlike objects: https://bugs.python.org/issue39691

----------
nosy: +kmaork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39517>
_______________________________________

From report at bugs.python.org  Wed Feb 19 18:21:10 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Wed, 19 Feb 2020 23:21:10 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1582154470.76.0.767193931909.issue39298@roundup.psfhosted.org>


Change by Maor Kleinberger <kmaork at gmail.com>:


----------
nosy: +kmaork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Wed Feb 19 19:11:43 2020
From: report at bugs.python.org (Niklas Smedemark-Margulies)
Date: Thu, 20 Feb 2020 00:11:43 +0000
Subject: [issue39692] Subprocess using list vs string
Message-ID: <1582157503.62.0.284670711586.issue39692@roundup.psfhosted.org>


New submission from Niklas Smedemark-Margulies <niklas.sm at gmail.com>:

Most (all?) of the functions in subprocess (run, Popen, etc) are supposed to accept either list or string, but the behavior when passing a list differs (and appears to be wrong).

For example, see below - invoking the command "exit 1" should give a return code of 1, but when using a list, the return code is 0.


```
>>> import subprocess


>>> # Example using run
>>> res1 = subprocess.run('exit 1', shell=True)
>>> res1.returncode
1
>>> res2 = subprocess.run('exit 1'.split(), shell=True)
>>> res2.returncode
0


>>> # Example using Popen
>>> p1 = subprocess.Popen('exit 1', shell=True)
>>> p1.communicate()
(None, None)
>>> p1.returncode
1
>>> p2 = subprocess.Popen('exit 1'.split(), shell=True)
>>> p2.communicate()
(None, None)
>>> p2.returncode
0
```

----------
messages: 362294
nosy: nik-sm
priority: normal
severity: normal
status: open
title: Subprocess using list vs string
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39692>
_______________________________________

From report at bugs.python.org  Wed Feb 19 20:39:33 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 20 Feb 2020 01:39:33 +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: <1582162773.56.0.076278684346.issue29298@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +17945
pull_request: https://github.com/python/cpython/pull/18564

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29298>
_______________________________________

From report at bugs.python.org  Wed Feb 19 20:39:34 2020
From: report at bugs.python.org (Zhibin Dong)
Date: Thu, 20 Feb 2020 01:39:34 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582162774.65.0.879365193093.issue39622@roundup.psfhosted.org>


Zhibin Dong <developerdong at gmail.com> added the comment:

Ubuntu 18.04.4 with kernel 5.3.0-28-generic. Additionally Python version is 3.7.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Wed Feb 19 21:01:47 2020
From: report at bugs.python.org (Ben Sokol)
Date: Thu, 20 Feb 2020 02:01:47 +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: <1582164107.39.0.928556495522.issue29298@roundup.psfhosted.org>


Change by Ben Sokol <python at bensokol.com>:


----------
type: behavior -> crash
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29298>
_______________________________________

From report at bugs.python.org  Wed Feb 19 21:22:41 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 20 Feb 2020 02:22:41 +0000
Subject: [issue39684] PyUnicode_IsIdentifier has two if/thens that can be
 combined
In-Reply-To: <1582089299.55.0.574843604033.issue39684@roundup.psfhosted.org>
Message-ID: <1582165361.31.0.744207791747.issue39684@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +17947
pull_request: https://github.com/python/cpython/pull/18565

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39684>
_______________________________________

From report at bugs.python.org  Wed Feb 19 21:37:19 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 20 Feb 2020 02:37:19 +0000
Subject: [issue39684] PyUnicode_IsIdentifier has two if/thens that can be
 combined
In-Reply-To: <1582089299.55.0.574843604033.issue39684@roundup.psfhosted.org>
Message-ID: <1582166239.21.0.940311443364.issue39684@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -17937

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39684>
_______________________________________

From report at bugs.python.org  Wed Feb 19 22:52:09 2020
From: report at bugs.python.org (Henry Royal)
Date: Thu, 20 Feb 2020 03:52:09 +0000
Subject: [issue26532] sanitizer
In-Reply-To: <1457640165.38.0.124294976796.issue26532@psf.upfronthosting.co.za>
Message-ID: <1582170729.6.0.324551209878.issue26532@roundup.psfhosted.org>


Change by Henry Royal <henry>:


----------
title: build fails with address sanitizer -> sanitizer
versions: +Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26532>
_______________________________________

From report at bugs.python.org  Wed Feb 19 22:52:56 2020
From: report at bugs.python.org (Henry Royal)
Date: Thu, 20 Feb 2020 03:52:56 +0000
Subject: [issue26532] build fails with address sanitizer
In-Reply-To: <1457640165.38.0.124294976796.issue26532@psf.upfronthosting.co.za>
Message-ID: <1582170776.75.0.881246915941.issue26532@roundup.psfhosted.org>


Change by Henry Royal <henry>:


----------
title: sanitizer -> build fails with address sanitizer
versions: +Python 3.6, Python 3.7 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26532>
_______________________________________

From report at bugs.python.org  Wed Feb 19 22:53:21 2020
From: report at bugs.python.org (Henry Royal)
Date: Thu, 20 Feb 2020 03:53:21 +0000
Subject: [issue26532] build fails with address sanitizer
In-Reply-To: <1457640165.38.0.124294976796.issue26532@psf.upfronthosting.co.za>
Message-ID: <1582170801.1.0.272520354597.issue26532@roundup.psfhosted.org>


Change by Henry Royal <henry>:


----------
versions: +Python 3.5 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26532>
_______________________________________

From report at bugs.python.org  Wed Feb 19 23:45:06 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Thu, 20 Feb 2020 04:45:06 +0000
Subject: [issue38872] Document exec symbol for codeop.compile_command
In-Reply-To: <1574298846.26.0.835938077059.issue38872@roundup.psfhosted.org>
Message-ID: <1582173906.37.0.194819350863.issue38872@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

code.compile_command takes _exec_
as symbol.As it is not documented or mentioned anywhere I can't find any details about that.Can anyone please tell me what it does?

----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38872>
_______________________________________

From report at bugs.python.org  Thu Feb 20 02:12:11 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 20 Feb 2020 07:12:11 +0000
Subject: [issue39693] tarfile's extractfile documentation is misleading
Message-ID: <1582182731.51.0.0387908483587.issue39693@roundup.psfhosted.org>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

The documentation for extractfile ( https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractfile ) says:

"Extract a member from the archive as a file object. member may be a filename or a TarInfo object. If member is a regular file or a link, an io.BufferedReader object is returned. Otherwise, None is returned."

Before reading further, answer for yourself: What do you think happens when a provided filename doesn't exist, based on that documentation?

In teaching a Python class that uses tarfile in the final project, and expects students to catch predictable errors (e.g. a random tarball being provided, rather than one produced by a different mode of the program with specific expected files) and convert them to user-friendly error messages, I've found this documentation to confuse students repeatedly (if they actually read it, rather than just guessing and checking interactively).

Specifically, the documentation:

1. Says nothing about what happens if member doesn't exist (TarFile.getmember does mention KeyError, but extractfile doesn't describe itself in terms of getmember)
2. Loosely implies that it should return None in such a scenario "If member is a regular file or a link, an io.BufferedReader object is returned. Otherwise, None is returned." The intent is likely to mean "all other member types are None, and we're saying nothing about non-existent members", but everyone I've taught who has read the docs came away with a different impression until they tested it.

Perhaps just reword from:

"If member is a regular file or a link, an io.BufferedReader object is returned. Otherwise, None is returned."

to:

"If member is a regular file or a link, an io.BufferedReader object is returned. For all other existing members, None is returned. If member does not appear in the archive, KeyError is raised."

Similar adjustments may be needed for extract, and/or both of them could be adjusted to explicitly refer to getmember by stating that filenames are converted to TarInfo objects via getmember.

----------
assignee: docs at python
components: Documentation, Library (Lib)
keywords: easy, newcomer friendly
messages: 362298
nosy: docs at python, josh.r
priority: normal
severity: normal
status: open
title: tarfile's extractfile documentation is misleading
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39693>
_______________________________________

From report at bugs.python.org  Thu Feb 20 02:20:48 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Thu, 20 Feb 2020 07:20:48 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1582183248.92.0.533645729851.issue6083@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

I want to do a PR,if this is still needeed.

----------
nosy: +Ananthakrishnan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Feb 20 02:33:22 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Feb 2020 07:33:22 +0000
Subject: [issue39693] tarfile's extractfile documentation is misleading
In-Reply-To: <1582182731.51.0.0387908483587.issue39693@roundup.psfhosted.org>
Message-ID: <1582184002.45.0.923556106171.issue39693@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/issue39693>
_______________________________________

From report at bugs.python.org  Thu Feb 20 02:39:32 2020
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 20 Feb 2020 07:39:32 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1582184372.18.0.968017148602.issue35943@roundup.psfhosted.org>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I have been experiencing what I thought was this issue in my embedded Python code. We have been using Python 3.7, so I thought upgrading to 3.8.1 would fix it, but it doesn't seem to have made any difference.

My C++ code essentially can call PyImport_GetModule() from two threads simultaneously on the same module A. The symptoms I see are that one of them then gets a stacktrace in module B (imported by A), saying that some symbol defined near the end of B does not exist.

I've also noticed that this happens far more often on deployed code (where Python modules end up in a zip file) than when run directly in development (where the modules are just normal files). I can't see any difference in the frequency between 3.7.5 and 3.8.1.

Any ideas? Should I reopen this?

----------
nosy: +gjb1002

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Thu Feb 20 02:42:06 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2020 07:42:06 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1582184526.62.0.227745257425.issue39660@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Unfortunately, if Python is used as a frontend for a native libray (eg accessed via ctypes), and in case that the state of interest is managed in the native library, contextvar API is insufficient.

Please elaborate with a clearer example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 02:51:55 2020
From: report at bugs.python.org (Tal Einat)
Date: Thu, 20 Feb 2020 07:51:55 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1582185115.43.0.608255805597.issue6083@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Please do, Ananthakrishnan!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Feb 20 03:00:19 2020
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 20 Feb 2020 08:00:19 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1582185619.01.0.653235200524.issue35943@roundup.psfhosted.org>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Oops, I mean we call PyImport_ImportModule and get these issues when the files are zipped. Unless that calls PyImport_GetModule internally I guess it's not related to this then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Thu Feb 20 05:03:23 2020
From: report at bugs.python.org (Akos Kiss)
Date: Thu, 20 Feb 2020 10:03:23 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
Message-ID: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>


New submission from Akos Kiss <akosthekiss at gmail.com>:

My understanding was that in function calls, the keys in an **expression had to be strings. However, str.format seems to deviate from that and allows non-string keys in the mapping (and silently ignores them).

Please, see the transcript below:

>>> def f(): pass
... 
>>> def g(): pass
... 
>>> x = {None: ''}
>>> y = {1: ''}
>>> f(**x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() keywords must be strings
>>> f(**y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() keywords must be strings
>>> g(**x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: g() keywords must be strings
>>> g(**y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: g() keywords must be strings
>>> ''.format(**x)
''
>>> ''.format(**y)
''

I could reproduce this (incorrect?) behavior on macOS with python 3.4-3.7 and on Ubuntu 18.04 with python 3.6.

----------
messages: 362304
nosy: Akos Kiss
priority: normal
severity: normal
status: open
title: Incorrect dictionary unpacking when calling str.format
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 05:19:25 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 20 Feb 2020 10:19:25 +0000
Subject: [issue39690] Compiler warnings in unicodeobject.c
In-Reply-To: <1582140452.34.0.85531597667.issue39690@roundup.psfhosted.org>
Message-ID: <1582193965.93.0.961496922454.issue39690@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

issue39684 has a PR for this.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39690>
_______________________________________

From report at bugs.python.org  Thu Feb 20 05:20:05 2020
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 20 Feb 2020 10:20:05 +0000
Subject: [issue29842] Make Executor.map work with infinite/large inputs
 correctly
In-Reply-To: <1489800776.56.0.575396558681.issue29842@psf.upfronthosting.co.za>
Message-ID: <1582194005.04.0.422637214428.issue29842@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
keywords: +patch
pull_requests: +17948
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18566

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29842>
_______________________________________

From report at bugs.python.org  Thu Feb 20 05:48:15 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 10:48:15 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582195695.97.0.848798276338.issue39694@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Can re-create, this is because the **kwargs handling inside unicode format only performs a lookup when needed https://github.com/python/cpython/blob/c4cacc8c5eab50db8da3140353596f38a01115ca/Objects/stringlib/unicode_format.h#L393-L424 and doesn't eagerly check it like here https://github.com/python/cpython/blob/ffd9753a944916ced659b2c77aebe66a6c9fbab5/Objects/call.c#L985-L1010

This might not be worth fixing though because of the very common pattern of 

  "{abcd}".format(**locals())

This would take a pretty dramatic performance hit for a relatively uncommon edge case.

----------
nosy: +ammar2, eric.smith, serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 05:59:27 2020
From: report at bugs.python.org (Nicolas Dessart)
Date: Thu, 20 Feb 2020 10:59:27 +0000
Subject: [issue39632] variadic function call broken on armhf when passing a
 float argument
In-Reply-To: <1581674608.19.0.403543141988.issue39632@roundup.psfhosted.org>
Message-ID: <1582196367.35.0.594997677218.issue39632@roundup.psfhosted.org>


Nicolas Dessart <nicolas.dessart at gmail.com> added the comment:

As I said in the associated PR, the build is failing on macOS because ctypes uses an obsolete libffi version bundled into Modules/_ctypes/libffi_osx for this platform. This old version of libffi is missing ffi_prep_cif_var.

There is an open issue that propose to remove the bundled libffi for OSX.
https://bugs.python.org/issue28491

----------
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39632>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:02:16 2020
From: report at bugs.python.org (sinoroc)
Date: Thu, 20 Feb 2020 11:02:16 +0000
Subject: [issue31542] pth files in site-packages of venvs are executed twice
In-Reply-To: <1505986898.8.0.276227616013.issue31542@psf.upfronthosting.co.za>
Message-ID: <1582196536.0.0.52921578274.issue31542@roundup.psfhosted.org>


sinoroc <sinoroc.code+python at gmail.com> added the comment:

https://stackoverflow.com/a/60169657/11138259

----------
nosy: +sinoroc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31542>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:19:12 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 11:19:12 +0000
Subject: [issue39695] Failed to build _uuid module, but libraries was installed
Message-ID: <1582197552.83.0.93580426376.issue39695@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

When I first done `make` to compile Python 3.9, I did not installed some debian development packages, like `uuid-dev`. So `_uuid` module was not built.

After installed the debian package I re-run `make`, but it failed to build `_uuid` module. I had to edit manually `Modules/_uuidmodule.c` and remove all the `#ifdef` directives and leave only `#include <uuid/uuid.h>`

Maybe `HAVE_UUID_UUID_H` and `HAVE_UUID_H` are created at `configure` phase only?

----------
components: Build
messages: 362309
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Failed to build _uuid module, but libraries was installed
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39695>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:22:17 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 11:22:17 +0000
Subject: [issue39695] Failed to build _uuid module, but libraries was installed
In-Reply-To: <1582197552.83.0.93580426376.issue39695@roundup.psfhosted.org>
Message-ID: <1582197737.29.0.498387251774.issue39695@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Is this still a problem after you run configure again?

As pointed out in https://devguide.python.org/setup/#unix

> If you decide to Install dependencies, you will need to re-run both configure and make.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39695>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:25:22 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 11:25:22 +0000
Subject: [issue39696] Failed to build _ssl module, but libraries was installed
Message-ID: <1582197921.98.0.104383393376.issue39696@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

Similarly to enhancement request #39695, I missed to install the debian package with the include files for SSL, before compiling Python 3.9.

After installed it, `make` continued to not find the libraries and skipped the creation of module _ssl.

Searching on internet, I found that doing:

make clean
./configure etc
make

works.

Maybe the SSL library check is done only at configure phase?

----------
components: Build
messages: 362311
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Failed to build _ssl module, but libraries was installed
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39696>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:27:02 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 11:27:02 +0000
Subject: [issue39696] Failed to build _ssl module, but libraries was installed
In-Reply-To: <1582197921.98.0.104383393376.issue39696@roundup.psfhosted.org>
Message-ID: <1582198022.45.0.369087184057.issue39696@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

As pointed out in your other issue:

https://devguide.python.org/setup/#unix

> If you decide to Install dependencies, you will need to re-run both configure and make.

----------
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39696>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:37:58 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 11:37:58 +0000
Subject: [issue39697] Failed to build with --with-cxx-main=g++-9.2.0
Message-ID: <1582198678.47.0.589589124523.issue39697@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

I tried to compile Python 3.9 with:


CC=gcc-9.2.0  ./configure --enable-optimizations --with-lto --with-cxx-main=g++-9.2.0
make -j 2

I got this error:

g++-9.2.0 -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall    -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-generate -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Programs/_testembed.o ./Programs/_testembed.c
cc1plus: warning: ?-Werror=? argument ?-Werror=implicit-function-declaration? is not valid for C++
cc1plus: warning: command line option ?-std=c99? is valid for C/ObjC but not for C++
sed -e "s, at EXENAME@,/usr/local/bin/python3.9," < ./Misc/python-config.in >python-config.py
LC_ALL=C sed -e 's,\$(\([A-Za-z0-9_]*\)),\$\{\1\},g' < Misc/python-config.sh >python-config
gcc-9.2.0 -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall    -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-generate -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE \
      -DGITVERSION="\"`LC_ALL=C git --git-dir ./.git rev-parse --short HEAD`\"" \
      -DGITTAG="\"`LC_ALL=C git --git-dir ./.git describe --all --always --dirty`\"" \
      -DGITBRANCH="\"`LC_ALL=C git --git-dir ./.git name-rev --name-only HEAD`\"" \
      -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
In file included from ./Include/internal/pycore_atomic.h:15,
                 from ./Include/internal/pycore_gil.h:11,
                 from ./Include/internal/pycore_pystate.h:11,
                 from ./Programs/_testembed.c:10:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdatomic.h:40:9: error: ?_Atomic? does not name a type

I suppose simply `Programs/_testembed.c` is a C source file and must not be compiled with g++

PS: as a workaround, `--with-cxx-main=gcc-9.2.0` works, but probably it's not optimal.

----------
components: Build
messages: 362313
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Failed to build with --with-cxx-main=g++-9.2.0
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39697>
_______________________________________

From report at bugs.python.org  Thu Feb 20 06:44:23 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 11:44:23 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
Message-ID: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

Python 3.9.0a3+ (heads/master-dirty:f2ee21d858, Feb 19 2020, 23:19:22) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.sleep(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: sleep length must be non-negative
>>> import asyncio
>>> async def f():
...     await asyncio.sleep(-1)
...     print("no exception")
... 
>>> asyncio.run(f())
no exception

I think that also `asyncio.sleep()` should raise `ValueError` if the argument is less than zero.

----------
components: asyncio
messages: 362314
nosy: Marco Sulla, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Thu Feb 20 07:08:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Feb 2020 12:08:36 +0000
Subject: [issue39697] Failed to build with --with-cxx-main=g++-9.2.0
In-Reply-To: <1582198678.47.0.589589124523.issue39697@roundup.psfhosted.org>
Message-ID: <1582200516.71.0.834515607601.issue39697@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue23644

----------
nosy: +vstinner, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39697>
_______________________________________

From report at bugs.python.org  Thu Feb 20 07:23:26 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 12:23:26 +0000
Subject: [issue39699] Ubuntu Github action not fully running build process
Message-ID: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

I think the Github action for building CPython on Ubuntu is accidentally caching the built Python files.

If we take a look at: https://github.com/python/cpython/runs/455936632#step:7:1
and
https://github.com/python/cpython/pull/18567/checks?check_run_id=457662461#step:8:1

It seems like it's running way too fast (and producing too little output) to actually be building all of CPython.

Adding Steve who originally authored the action to the nosy list to see if they might have any insight.

----------
components: Build
messages: 362316
nosy: ammar2, steve.dower
priority: normal
severity: normal
status: open
title: Ubuntu Github action not fully running build process
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Thu Feb 20 08:00:09 2020
From: report at bugs.python.org (David)
Date: Thu, 20 Feb 2020 13:00:09 +0000
Subject: [issue39700] asyncio.selector_events._SelectorTransport: Add logging
 when sock.getpeername() fails
Message-ID: <1582203609.18.0.700176939953.issue39700@roundup.psfhosted.org>


New submission from David <dsternlicht at infinidat.com>:

`sock.getpeername` can fail for multiple reasons (see https://pubs.opengroup.org/onlinepubs/7908799/xns/getpeername.html) but in  `asyncio.selector_events._SelectorTransport` it's try/excepted without any logging of the error:

```
        if 'peername' not in self._extra:
            try:
                self._extra['peername'] = sock.getpeername()
            except socket.error:
                self._extra['peername'] = None
```

This makes it very difficult to debug. Would it be OK if I added here a log with information on the error?

Thanks!

----------
components: asyncio
messages: 362317
nosy: asvetlov, dsternlicht, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.selector_events._SelectorTransport: Add logging when sock.getpeername() fails
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39700>
_______________________________________

From report at bugs.python.org  Thu Feb 20 09:04:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 20 Feb 2020 14:04:57 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582207497.45.0.157319768605.issue39694@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Is this causing some practical problem? I can't think of any way to reference non-string kwargs in a format string, but maybe I'm not being creative enough. And if there is such a way, then changing this wouldn't be backward compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 09:11:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Feb 2020 14:11:07 +0000
Subject: [issue39699] Ubuntu Github action not fully running build process
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582207867.85.0.418674361579.issue39699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

46s seems okay to me, especially since the 23s for autoconf is separate.

Try introducing a warning/error into the source code and see if it breaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Thu Feb 20 09:16:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Feb 2020 14:16:16 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582208176.47.0.37195478105.issue39694@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See similar issue for SimpleNamespace: https://bugs.python.org/issue31655.

We should add a similar check in str.format(). Accepting a non-string keys is an implementation detail. There is no guarantee that it works in other implementations.

It should not hit performance, because the kwargs dict is usually small, the check is cheap, and formatting itself can be expensive. For the case when you need to pass a huge dict and use only few items from it, you can use str.format_map().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 09:23:47 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 20 Feb 2020 14:23:47 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582208627.25.0.0452097211588.issue39698@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The ship has sailed, this change breaks a lot of existing code without a strong reason.
I recall very many cases in third-party libraries and commercial applications where a negative argument for asyncio.sleep() is processed as asyncio.sleep(0) without failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Thu Feb 20 09:43:09 2020
From: report at bugs.python.org (Akos Kiss)
Date: Thu, 20 Feb 2020 14:43:09 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582209789.4.0.00693960395508.issue39694@roundup.psfhosted.org>


Akos Kiss <akosthekiss at gmail.com> added the comment:

Re: Eric

I had a code where `'sometemplate'.format()` got a dictionary from outside (as a parameter, not from `locals()`), and that dictionary had `None` as a key. Actually, I wasn't even aware of that `None` key until I tried to execute the same code in PyPy where it failed with a `TypeError`. That's when I started to dig down to the root of the incompatibility.

Now, my code has a workaround to have an `if key is not None` filter in the comprehension that constructs the dict. (I'm not sure whether it can be called a workaround, since this is how it should have been written in the first place. It turns out I was just (ab)using an implementation detail / deviation.)

So much about real-world use cases.

There is one more use case that comes to my mind, but it is admittedly theoretical (for now, at least). If I ever wanted to patch/wrap/mock `str.format` then the wrapped version would behave differently from the built-in version (throw an error when the original does not). But this is hypothetical at the moment because I "can't set attributes of built-in/extension type 'str'" and don't have the time to experiment with complex mocking/patching/wrapping approaches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 10:36:59 2020
From: report at bugs.python.org (David)
Date: Thu, 20 Feb 2020 15:36:59 +0000
Subject: [issue39700] asyncio.selector_events._SelectorTransport: Add logging
 when sock.getpeername() fails
In-Reply-To: <1582203609.18.0.700176939953.issue39700@roundup.psfhosted.org>
Message-ID: <1582213019.77.0.440886908018.issue39700@roundup.psfhosted.org>


Change by David <dsternlicht at infinidat.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file48900/log-peername-and-sockname-errors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39700>
_______________________________________

From report at bugs.python.org  Thu Feb 20 10:39:50 2020
From: report at bugs.python.org (Jonny Weese)
Date: Thu, 20 Feb 2020 15:39:50 +0000
Subject: [issue39692] Subprocess using list vs string
In-Reply-To: <1582157503.62.0.284670711586.issue39692@roundup.psfhosted.org>
Message-ID: <1582213190.21.0.249466271694.issue39692@roundup.psfhosted.org>


Jonny Weese <jweese at gmail.com> added the comment:

I believe this behavior is expected (at least in posix-land).

Lib/subprocess.py L1702 shows that whenever shell=True, the args that are constructed are [unix_shell, "-c"] + args.

And so we can reproduce your behavior just using a regular shell. (This is Darwin but with a recent bash from homebrew):

$ bash -c 'exit 1'  # like subprocess string case
$ echo $?
1
$ bash -c exit 1  # like subprocess list case (note args are separated)
$ echo $?
0

----------
nosy: +jweese

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39692>
_______________________________________

From report at bugs.python.org  Thu Feb 20 10:53:06 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 20 Feb 2020 15:53:06 +0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1582213986.37.0.285255671498.issue1294959@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Why "sys.python_libdir"?  Isn't that too public? A lot of similar path-related info is in sysconfig; why shouldn't it be there?
How does "sys.python_libdir" work on other platforms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Thu Feb 20 10:54:32 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 15:54:32 +0000
Subject: [issue39701] Azure Pipelines PR  broken
Message-ID: <1582214072.19.0.00954727477072.issue39701@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy: skrah
priority: normal
severity: normal
status: open
title: Azure Pipelines PR  broken

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 10:57:00 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 15:57:00 +0000
Subject: [issue39701] Azure Pipelines PR  broken
Message-ID: <1582214220.59.0.59152238753.issue39701@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

There is no status report, no details link and manually committing is prohibited:

https://github.com/python/cpython/pull/18569

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 10:57:34 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 20 Feb 2020 15:57:34 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582214254.94.0.982714879896.issue39694@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Okay, then I agree with Serhiy on the change.

And I agree that .format(**locals()) is an anti-pattern, and should use .format_map(locals()) instead. Not that it's related directly to this issue, I just like to point it out where I can.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:02:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Feb 2020 16:02:49 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582214569.04.0.392518318541.issue39694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm with Eric and don't see this as a problem in practice.

Also, the kwarg handling for functions is fundamentally different because all arguments need to be matched.  In contrast, the kwargs for format() are only used on-demand:

    >>> '{found}'.format(found='used', not_found='ignored')
    'used'

I recommend this be left as-is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:12:25 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 20 Feb 2020 16:12:25 +0000
Subject: [issue39702] PEP 614: Relaxing Grammar Restrictions On Decorators
Message-ID: <1582215145.16.0.34815642768.issue39702@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

The attached PR implements PEP 614's revised grammar for decorators, with tests. In short:

decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE

becomes

decorator: '@' namedexpr_test NEWLINE

I'm marking it as DO-NOT-MERGE until the PEP is accepted, but code review is still appreciated. Discussion of the PEP itself should go to the Python-Dev thread:

https://mail.python.org/archives/list/python-dev at python.org/thread/SLKFAR56RA6A533O5ZOZ7XTJ764EMB7I

----------
assignee: brandtbucher
components: Interpreter Core
messages: 362328
nosy: brandtbucher, gvanrossum
priority: normal
severity: normal
status: open
title: PEP 614: Relaxing Grammar Restrictions On Decorators
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39702>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:14:09 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 20 Feb 2020 16:14:09 +0000
Subject: [issue39702] PEP 614: Relaxing Grammar Restrictions On Decorators
In-Reply-To: <1582215145.16.0.34815642768.issue39702@roundup.psfhosted.org>
Message-ID: <1582215249.09.0.958967777662.issue39702@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +17949
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18570

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39702>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:17:39 2020
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Thu, 20 Feb 2020 16:17:39 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1582215459.12.0.534028617047.issue35943@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

@gjb1002: see also https://bugs.python.org/issue38884, which demonstrates that concurrent imports are not thread-safe on Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:20:23 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 20 Feb 2020 16:20:23 +0000
Subject: [issue37196] Allowing arbitrary expressions in the @expression syntax
In-Reply-To: <1559916315.57.0.952678742799.issue37196@roundup.psfhosted.org>
Message-ID: <1582215623.02.0.938327059042.issue37196@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher
resolution:  -> duplicate
status: open -> closed
superseder:  -> PEP 614: Relaxing Grammar Restrictions On Decorators

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37196>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:20:55 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 20 Feb 2020 16:20:55 +0000
Subject: [issue19660] decorator syntax: allow testlist instead of just
 dotted_name
In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za>
Message-ID: <1582215655.16.0.195829125731.issue19660@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> PEP 614: Relaxing Grammar Restrictions On Decorators

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:25:56 2020
From: report at bugs.python.org (Kostis Gourgoulias)
Date: Thu, 20 Feb 2020 16:25:56 +0000
Subject: [issue39703] Floor division operator and floats
Message-ID: <1582215956.02.0.936078092318.issue39703@roundup.psfhosted.org>


New submission from Kostis Gourgoulias <kgourgoulias at gmail.com>:

This was brought to my attention by a colleague, Albert B.

When considering the floor division // operator, 1//0.01 should return 100.0, but instead returns 99.0. My understanding is that this is because 0.01 is represented by 

Decimal('0.01000000000000000020816681711721685132943093776702880859375')

which is greater than 0.01.

math.floor(1/0.01) correctly outputs 100. Shouldn't the two approaches provide the same answer?

----------
components: macOS
messages: 362330
nosy: Kostis Gourgoulias, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Floor division operator and floats
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39703>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:29:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Feb 2020 16:29:47 +0000
Subject: [issue39701] Azure Pipelines PR  broken
In-Reply-To: <1582214220.59.0.59152238753.issue39701@roundup.psfhosted.org>
Message-ID: <1582216187.08.0.86720180433.issue39701@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 11:30:09 2020
From: report at bugs.python.org (Akos Kiss)
Date: Thu, 20 Feb 2020 16:30:09 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582216209.62.0.920728055343.issue39694@roundup.psfhosted.org>


Akos Kiss <akosthekiss at gmail.com> added the comment:

I couldn't find any discussion in the language reference about fundamental differences between calls to built-in functions and user-defined functions. (I tried to read Sections 6.3.4. "Calls" and 8.6. "Function definitions" carefully.) Until now I had the impression that built-in and user-defined functions should be as similar as possible.

BTW, a user-defined function can also implement support for unused/excess keyword arguments (or arguments used on-demand): it only has to add **kwargs at the end of its signature. And that's exactly how the documentation specifies the signature of format: str.format(*args, **kwargs). That API documentation signals (to me at least) that this function should be called just like any other function that has a (*args, **kwargs) signature, be it built-in of user-defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:07:59 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Feb 2020 17:07:59 +0000
Subject: [issue39703] Floor division operator and floats
In-Reply-To: <1582215956.02.0.936078092318.issue39703@roundup.psfhosted.org>
Message-ID: <1582218479.3.0.648816560311.issue39703@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Shouldn't the two approaches provide the same answer?

In a word, no. :-)

math.floor(1/0.01) involves *two* operations, and there's an intermediate rounding step which happens to round the true mathematical result of 1/0.01 up to 100.0. Taking the floor of that then (of course) gives 100.0.

1//0.01 is the single-operation equivalent, that doesn't include an intermediate round.

There are lots of other cases where a combination of two or more operations is mathematically equivalent to a single operation, but produces a different result due to an intermediate round; for example, things like `log(n) / log(2)` versus `log2(n)`, or `round(x, 2)` versus `round(100.0*x)/100.0`.

There's unfortunately no way to square the circle here that doesn't cause surprises in at least some corner cases.

I'm almost sure this issue is a duplicate, but I haven't found a good target for that duplicate yet. I'll continue searching.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39703>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:09:17 2020
From: report at bugs.python.org (Niklas Smedemark-Margulies)
Date: Thu, 20 Feb 2020 17:09:17 +0000
Subject: [issue39692] Subprocess using list vs string
In-Reply-To: <1582157503.62.0.284670711586.issue39692@roundup.psfhosted.org>
Message-ID: <1582218557.12.0.939078411221.issue39692@roundup.psfhosted.org>


Niklas Smedemark-Margulies <niklas.sm at gmail.com> added the comment:

Thanks very much for getting back to me so quickly, and for identifying the reason for the difference in behavior.

Sorry to harp on a relatively small behavior, but it cost me a few hours and it might cause confusion for others as well.

It still seems like an oversight that the body of a program invoked by `bash -c` would not be quoted. Consider the following two examples:

$ bash -c echo my critical data > file.txt
$ cat file.txt 

$ # My data was lost!

Or again in Python:

>>> import subprocess
>>> res1 = subprocess.run(['echo', 'my', 'critical', 'data', '>', 'file.txt'], shell=True, capture_output=True)
>>> res1.returncode
0
>>> exit()
$ cat file.txt
cat: file.txt: No such file or directory
$ # The file is not even created!



I know that the subsequent args are stored as bash arguments to the first executable/quoted program, for example:

$ bash -c 'echo $0' foo
foo

or

>>> res1 = subprocess.run(['echo $0', 'foo'], shell=True, capture_output=True)
>>> res1.stdout
b'foo\n'


However, it seems strange/wrong to invoke an executable via "bash -c executable arg1 arg2", rather than just "executable arg1 arg2"! In other words, the combination of `shell=True` with a sequence of args appears to behave surprisingly/wrong.


---


Here's the only part of the docs I could find that discuss the interaction between `shell=True` and args.:
"""
The shell argument (which defaults to False) specifies whether to use the shell as the program to execute. If shell is True, it is recommended to pass args as a string rather than as a sequence.
"""



I think there are ~2 cases here:

1) If there exist use cases for setting `shell=True` and doing "bash -c my_executable arg2 arg3", then the documentation should say something like the following:
"""
Using `shell=True` invokes the sequence of args via `bash -c`. In this case, the first argument MUST be an executable, and the subsequent arguments will be stored as bash parameters for that executable (`$0`, `$1`, etc).
"""

2) The body of the program invoked with `bash -c` should always be quoted. In this case, there should either be a code fix to quote the body, or a `ValueError` when `shell=True` and args is a sequence.


How does this sound from your perspective?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39692>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:10:10 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Feb 2020 17:10:10 +0000
Subject: [issue39703] Floor division operator and floats
In-Reply-To: <1582215956.02.0.936078092318.issue39703@roundup.psfhosted.org>
Message-ID: <1582218610.64.0.925098992545.issue39703@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, found the duplicate (or at least one of them): https://bugs.python.org/issue27463

----------
components: +Interpreter Core -macOS
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Floor division is not the same as the floor of division

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39703>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:12:01 2020
From: report at bugs.python.org (Kostis Gourgoulias)
Date: Thu, 20 Feb 2020 17:12:01 +0000
Subject: [issue39703] Floor division operator and floats
In-Reply-To: <1582215956.02.0.936078092318.issue39703@roundup.psfhosted.org>
Message-ID: <1582218721.05.0.35502638259.issue39703@roundup.psfhosted.org>


Kostis Gourgoulias <kgourgoulias at gmail.com> added the comment:

Aha, I see! Thanks and apologies for missing the duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39703>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:13:04 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Feb 2020 17:13:04 +0000
Subject: [issue39703] Floor division operator and floats
In-Reply-To: <1582215956.02.0.936078092318.issue39703@roundup.psfhosted.org>
Message-ID: <1582218784.18.0.75609516067.issue39703@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Thanks and apologies for missing the duplicate.

Not a problem: much better to have a potential bug reported twice than not at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39703>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:39:45 2020
From: report at bugs.python.org (Jonny Weese)
Date: Thu, 20 Feb 2020 17:39:45 +0000
Subject: [issue39692] Subprocess using list vs string
In-Reply-To: <1582157503.62.0.284670711586.issue39692@roundup.psfhosted.org>
Message-ID: <1582220385.13.0.0723106966125.issue39692@roundup.psfhosted.org>


Jonny Weese <jweese at gmail.com> added the comment:

> it seems strange/wrong to invoke an executable via "bash -c executable arg1 arg2", rather than just "executable arg1 arg2"!

I agree it's strange to invoke a single executable that way, but remember that -c allows a string of arbitrary bash code. (It just happens that bash code that consists of a single executable calls it -- useful behavior in a shell.)

Consider:

$ bash -c 'f() { printf "%s\n" "$@"; }; f "$@"' - foo bar baz
foo
bar
baz

> 1) If there exist use cases for setting `shell=True` and doing "bash -c my_executable arg2 arg3", then the documentation should say something like the following:
> """
> Using `shell=True` invokes the sequence of args via `bash -c`. In this case, the first argument MUST be an executable, and the subsequent arguments will be stored as bash parameters for that executable (`$0`, `$1`, etc).
> """

I'd be okay with clearer docs, but the given language is not quite right. For example, the actual shell call is /bin/sh (and depends on the platform). And, as described above, I think it would be too restrictive to say the first argument must be a single executable.

On the other hand, I disagree with option 2. I think raising an error would be very restrictive, and secretly quoting the argument could be surprising for (the few) people who understand the underlying shell mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39692>
_______________________________________

From report at bugs.python.org  Thu Feb 20 12:45:32 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 20 Feb 2020 17:45:32 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1582220732.99.0.983271927711.issue39660@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/issue39660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:13:17 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 18:13:17 +0000
Subject: [issue39701] Azure Pipelines PR  broken
In-Reply-To: <1582214220.59.0.59152238753.issue39701@roundup.psfhosted.org>
Message-ID: <1582222397.51.0.909116999233.issue39701@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Closing and reopening the PR helped.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:34:45 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 18:34:45 +0000
Subject: [issue39701] Azure Pipelines PR  broken
In-Reply-To: <1582214220.59.0.59152238753.issue39701@roundup.psfhosted.org>
Message-ID: <1582223685.43.0.774568961793.issue39701@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Re-opening this issue, Azure fails too often:

https://github.com/python/cpython/pull/18577

https://dev.azure.com/Python/cpython/_build/results?buildId=58220&view=logs&j=c83831cd-3752-5cc7-2f01-8276919eb334

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:35:22 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 18:35:22 +0000
Subject: [issue39701] Azure Pipelines PR  broken
In-Reply-To: <1582214220.59.0.59152238753.issue39701@roundup.psfhosted.org>
Message-ID: <1582223722.09.0.494949272369.issue39701@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:35:47 2020
From: report at bugs.python.org (Niklas Smedemark-Margulies)
Date: Thu, 20 Feb 2020 18:35:47 +0000
Subject: [issue39692] Subprocess using list vs string
In-Reply-To: <1582157503.62.0.284670711586.issue39692@roundup.psfhosted.org>
Message-ID: <1582223747.93.0.587274684946.issue39692@roundup.psfhosted.org>


Niklas Smedemark-Margulies <niklas.sm at gmail.com> added the comment:

Good point - the phrasing I suggested there is not accurate, and there is more complicated behavior available than simply specifying a single executable. Here's the bash manual's info about "-c" flag:

"""
If the -c option is present, then commands are read from the first non-option argument command_string.   If  there  are arguments  after  the  command_string, the first argument is assigned to $0 and any remaining arguments are assigned to the positional parameters.  The assignment to $0 sets the name of the shell, which is used in warning  and  error  messages.
"""

So the command_string provided (the first word or the first quoted expression) is interpreted as a shell program, and this program is invoked with the remaining words as its arguments. As you point out, this command_string can be a terminal expression like `true`, a function definition like you provided, an executable, or other possibilities, but in any case it will be executed with the remaining args.

(This also matches how the library code assigns `executable`: https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1707)

As you say, simply slapping quotes around all the args produces a subtle difference: the arg in the position of `$0` is used as an actual positional parameter in one case, and as the shell name in the other case:

$ bash -c 'f() { printf "%s\n" "$@"; }; f "$@"' - foo bar baz
foo
bar
baz
 $ bash -c 'f() { printf "%s\n" "$@"; }; f "$@" - foo bar baz'
-
foo
bar
baz

(Unless I am misunderstanding the behavior here).

It's a bit frustrating that this approach would not work to simplify the usage, but (assuming my explanation is correct) I concede that code might certainly be depending on this behavior and setting the shell name with args[1] (and they would not want this to become a positional parameter instead).


Improving on my first attempt, here's another possible phrasing for the docs:
"""
Using `shell=True` invokes the sequence of args via `<SHELL> -c` where <SHELL> is the chosen system shell (described elsewhere on this page). In this case, the item at args[0] is a shell program, that will be invoked on the subsequent args. The item at args[1] will be stored in the shell variable `$0`, and used as the name of the shell. The subsequent items at args[2:] will be stored as shell parameters (`$1`, `$2`, etc) and available as positional parameters (e.g. using `echo $@`).
"""

I would certainly be happy to defer on giving a precise and thorough statement for the docs, but clarifying/highlighting this behavior definitely seems useful.

Thanks again

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39692>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:42:39 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 20 Feb 2020 18:42:39 +0000
Subject: [issue39589] Logging QueueListener should support context manager
In-Reply-To: <1581219088.53.0.399327051816.issue39589@roundup.psfhosted.org>
Message-ID: <1582224159.23.0.197081294472.issue39589@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39589>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:43:19 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Thu, 20 Feb 2020 18:43:19 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582224199.15.0.32507397438.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

This behaved similarly on my machine, also ubuntu. But it also happened (less often) with small numbers, like sleep(0.0000000000000000000001).

Also, I tried it on my windows 10 and experienced another unexpected behavior - only when using sleep(0), Ctrl-C would not work *at all* from time to time. Most of the times it would stop the program immediately. This also happened when using 0.0000000000000000000001 instead of 0.

Unless 0.0000000000000000000001 turns into 0 somewhere along the way, I'd suspect that there is a piece of code inside asyncio's core that doesn't handle interrupting correctly (both on linux and windows), and using sleep with small numbers just makes it much more probable for this piece of code to be running when the Ctrl-C signal is sent.

I'll try to dig in more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:46:18 2020
From: report at bugs.python.org (Jonny Weese)
Date: Thu, 20 Feb 2020 18:46:18 +0000
Subject: [issue39692] Subprocess using list vs string
In-Reply-To: <1582157503.62.0.284670711586.issue39692@roundup.psfhosted.org>
Message-ID: <1582224378.4.0.954203381457.issue39692@roundup.psfhosted.org>


Jonny Weese <jweese at gmail.com> added the comment:

> So the command_string provided (the first word or the first quoted expression) is interpreted as a shell program, and this program is invoked with the remaining words as its arguments.

Correct.

> As you say, simply slapping quotes around all the args produces a subtle difference: the arg in the position of `$0` is used as an actual positional parameter in one case, and as the shell name in the other case

It is not quite just a shifting of the positional args.

$ bash -c 'f() { printf "%s\n"; }; f "$@"' - foo bar baz
=> "From a string, read this bash script, which defines a function f and then invokes f on all of its arguments. Now invoke that script with an executable name of "-" and the arguments "foo" "bar" and "baz".

$ bash -c 'f() { printf "%s\n"; }; f "$@" - foo bar baz'
=> "From a string, read this bash script, which defines f and then invokes f on all the script arguments as well as "-" "foo" "bar" and "baz". Then invoke that script with no other arguments."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39692>
_______________________________________

From report at bugs.python.org  Thu Feb 20 13:49:36 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 20 Feb 2020 18:49:36 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582224576.03.0.913229484536.issue39648@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Ananthakrishnan: Sure, go ahead.

Let's make the process a bit more streamlined than last time around: see if you can put together a PR that passes all the CI checks before asking for review. If you get stuck, make a work-in-progress PR and ask for help in a comment on that PR rather than via email.

A couple of pointers:

- Take a look at the existing math.hypot implementation to see how to deal with multiple arguments. (Note that argument clinic doesn't currently work for *args functions.)

- For the first working version, don't bother making special cases for the zero-argument or one-argument gcd (or even the case of two arguments). You just want the equivalent of the following Python code, which is perfectly general:

    def gcd(*args):
        g = 0
        for arg in args:
            g = gcd_2arg(g, operator.index(arg))
        return g

where gcd_2arg is the original 2-argument gcd (in C, _PyLong_GCD). We can always optimise later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Thu Feb 20 14:00:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Feb 2020 19:00:07 +0000
Subject: [issue39701] Azure Pipelines PR  broken
In-Reply-To: <1582214220.59.0.59152238753.issue39701@roundup.psfhosted.org>
Message-ID: <1582225207.01.0.568682643914.issue39701@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Looks like the get_externals.py script needs to be made a bit more robust - downloading from GitHub hasn't been very reliable this week.

----------
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39701>
_______________________________________

From report at bugs.python.org  Thu Feb 20 14:17:33 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2020 19:17:33 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582226253.56.0.296721885569.issue39698@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> The ship has sailed, this change breaks a lot of existing code without a strong reason.

Yes.

It's a common thing to compute asyncio.sleep delay and sometimes it goes negative. The current behavior is part of our API now.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Thu Feb 20 15:20:31 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Thu, 20 Feb 2020 20:20:31 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582230031.07.0.406418708052.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

I wrote a small script that checks the behavior of asyncio.sleep when called with small amounts of time (starting from 0). For each amount I checked 500 times whether SleepTest has stopped when interrupted with SIGINT. Below are the results:

SLEEP TIME  SIGINT FAILURE PERCENT
0           26.6%
1e-06       9.8%
2e-06       11.8%
3e-06       11.2%
4e-06       9.6%
5e-06       13.8%
6e-06       5.6%
7e-06       2.6%
8e-06       1.4%
9e-06       1.6%
1e-05       2.2%
1.1e-05     2.2%
1.2e-05     2.0%
1.3e-05     1.8%
1.4e-05     0.8%

It is worth mentioning that the failure amount increased when my CPU was busier. Maybe it is because of false positives in my script (although I think I used relatively generous timeouts when waiting for the ioloop to start running and for the process to die after a SIGINT) and maybe it is because of the nature of the bug in asyncio. I didn't put a lot of effort into distinguishing between the two, as increasing the timeouts also made my CPU less busy.

Anyway, there is definitely a weird behavior here, and I still think there is a specific piece of code in asyncio that's causing it. Maybe I'll look at the code a bit, or try to think of other ways to approach this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Thu Feb 20 15:22:19 2020
From: report at bugs.python.org (Geoffrey Bache)
Date: Thu, 20 Feb 2020 20:22:19 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1582230139.29.0.898443307845.issue35943@roundup.psfhosted.org>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

@Valentyn Tymofieiev - true, and thanks for the tip, though the symptoms described there are somewhat different from what I'm observing. Also, my problem seems to be dependent on zipping the Python code, which that one isn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Thu Feb 20 15:50:19 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 20 Feb 2020 20:50:19 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1582231819.24.0.217831448289.issue39623@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Not so easy to find a satisfactory generic approach.
An argument can also be 10 MiB length bytes array, a dictionary with 10,000 elements, HTML page, name it.
All these objects are printable but their representation is too verbose.
Task can have a dozen of arguments, only the latest may be meaningful for logically separating one task from others.

Task has a name exactly for the purpose of distinguishing similar but different tasks, please use it. Only the task creator knows how to name it better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 20 15:52:40 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 20:52:40 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582231960.78.0.614242096373.issue39698@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> I recall very many cases in third-party libraries and commercial applications

Source?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Thu Feb 20 15:57:25 2020
From: report at bugs.python.org (wim glenn)
Date: Thu, 20 Feb 2020 20:57:25 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1582232245.33.0.621184380415.issue17005@roundup.psfhosted.org>


Change by wim glenn <wim.glenn at gmail.com>:


----------
nosy: +wim.glenn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Feb 20 16:00:21 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Thu, 20 Feb 2020 21:00:21 +0000
Subject: [issue39557] ThreadPoolExecutor is busy-waiting when idle.
In-Reply-To: <1580888299.0.0.965711454165.issue39557@roundup.psfhosted.org>
Message-ID: <1582232421.31.0.282697875861.issue39557@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

> If I understand the following code correctly, there seems to be a busy loop waiting for the SimpleQueue.put to signal that an item was entered to queue.

This is not a busywait. Actually, the loop you specified will never repeat more than twice. At the first iteration, the queue's lock is acquired. At the second iteration, the loop waits for the lock to be released (by trying to acquire the lock again, which is not busywait). The lock is only released when something is put into the queue, so at that point the loop exits and the function returns.

Avraham, could you provide a minimal python script that will reproduce the CPU usage spike?

----------
nosy: +kmaork

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39557>
_______________________________________

From report at bugs.python.org  Thu Feb 20 16:02:20 2020
From: report at bugs.python.org (sds)
Date: Thu, 20 Feb 2020 21:02:20 +0000
Subject: [issue39617] max_workers argument to
 concurrent.futures.ProcessPoolExecutor is not flexible enough
In-Reply-To: <1581528064.43.0.461449541499.issue39617@roundup.psfhosted.org>
Message-ID: <1582232540.23.0.935301777743.issue39617@roundup.psfhosted.org>


sds <sds at gnu.org> added the comment:

On a closer observation, I think you are eminently right.
Idle workers take far far far too much RAM.
In fact, I would like to be able to specify that the workers are to be spinned up on demand only and terminated immediately when they they are done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39617>
_______________________________________

From report at bugs.python.org  Thu Feb 20 16:02:54 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 21:02:54 +0000
Subject: [issue39695] Failed to build _uuid module, but libraries was installed
In-Reply-To: <1582197552.83.0.93580426376.issue39695@roundup.psfhosted.org>
Message-ID: <1582232574.74.0.882860061216.issue39695@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Well, the fact is, basically, for the other libraries you have not to re-run `configure`. You have to install only the missing C libraries and redo `make`. This works, for example, for zlib, lzma, ctypes, sqlite3, readline, bzip2.

Furthermore, it happened to me that I re-run `configure` without a `make clean` before: the `make` process stopped because configuration was changed, and I have to do a `make clean`. A big waste of time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39695>
_______________________________________

From report at bugs.python.org  Thu Feb 20 16:41:12 2020
From: report at bugs.python.org (Matej Cepl)
Date: Thu, 20 Feb 2020 21:41:12 +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: <1582234872.73.0.411265636066.issue38576@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

Just to say this is reproducible only on rather old enterprise Linux distributions, where CVE-2016-10739 bug in glibc has not been fixed. I believe it means RHEL-6, SUSE SLE-10, 11, 12 (not sure whether it applies to some old Debian as well).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:04:38 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 22:04:38 +0000
Subject: [issue39699] Ubuntu Github action not fully running build process
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582236278.89.0.540155824718.issue39699@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Aah sorry. This was my mistake, I didn't notice that we're passing `-s` (silent) to make. It is actually performing the build underneath, just not with the outputs that get produced form other CIs.

Steve, is there a reason the Github action and Azure pipelines:

* https://github.com/python/cpython/blob/1246d892038a693304549f8574e6c2784b91589a/.azure-pipelines/posix-steps.yml#L23

* https://github.com/python/cpython/blob/1246d892038a693304549f8574e6c2784b91589a/.github/workflows/build.yml#L58

both pass `-s` to make but Travis doesn't? It seems like it might potentially hide useful information about the build.

* https://github.com/python/cpython/blob/1246d892038a693304549f8574e6c2784b91589a/.travis.yml#L170

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:05:43 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Feb 2020 22:05:43 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1582236343.0.0.207421177787.issue39184@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17950
pull_request: https://github.com/python/cpython/pull/18580

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:17:46 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 22:17:46 +0000
Subject: [issue39695] Failed to build _uuid module, but libraries was installed
In-Reply-To: <1582197552.83.0.93580426376.issue39695@roundup.psfhosted.org>
Message-ID: <1582237066.07.0.187887664641.issue39695@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Sorry about your experience Marco but I think the dev guide is pretty clear on all these steps (including having to redo `make clean`). You can find some discussion on the build system here https://discuss.python.org/t/is-there-prior-discussion-around-the-build-system-of-cpython-itself/2813 but for now I'm going to close this as "not-a-bug" because the dev guide covers it.

If your proposal is to make dependent modules build without re-configuring, please contribute to that discussion or bring it up on the ideas forum.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39695>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:23:10 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 22:23:10 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582237390.6.0.543761750029.issue39576@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
keywords: +patch
pull_requests: +17951
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18581

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:23:29 2020
From: report at bugs.python.org (Leonard Lausen)
Date: Thu, 20 Feb 2020 22:23:29 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1582237409.79.0.805661860096.issue39660@roundup.psfhosted.org>


Leonard Lausen <leonard at lausen.nl> added the comment:

Consider a `lib = ctypes.CDLL(lib_path, ctypes.RTLD_LOCAL)` which provides APIs `lib.compute`, `lib.set_state` and a Python interface wrapping both in `def compute`, `def set_state`. Let's assume `lib.set_state` sets a thread-local state in the library implementation and further  that the behaviour of `lib.compute` depends on the last call to `lib.set_state`. 

Users of the Python interface may call `set_state` and `compute` concurrently in coroutines. Thereby one coroutine may change the state in the library, prior to another coroutine calling `compute`. This leads to a wrong result.

If `set_state` and `compute` were pure python functions, `contextvars` could be used to implement set_state and provide context-local state.

Is there any existing API that can be used to call `lib.set_state` on context changes? If so, please let me know. If not, would it make sense to extend `contexvars` to allow users to configure that `lib.set_state` is called on context change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:24:50 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Feb 2020 22:24:50 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1582237490.95.0.382572636197.issue39184@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6c444d0dab8f06cf304263b34beb299101cef3de by Steve Dower in branch 'master':
bpo-39184: Fix incorrect return value (GH-18580)
https://github.com/python/cpython/commit/6c444d0dab8f06cf304263b34beb299101cef3de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:25:00 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Feb 2020 22:25:00 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1582237500.16.0.855270460706.issue39184@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17952
pull_request: https://github.com/python/cpython/pull/18582

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:40:57 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 20 Feb 2020 22:40:57 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1582238457.8.0.181897319916.issue39537@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39537>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:44:53 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Feb 2020 22:44:53 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1582238693.32.0.373554243782.issue39184@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d0a464e31ac67685ef8ad35ecd993f17dfd6ab35 by Miss Islington (bot) in branch '3.8':
bpo-39184: Fix incorrect return value (GH-18580)
https://github.com/python/cpython/commit/d0a464e31ac67685ef8ad35ecd993f17dfd6ab35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39184>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:44:54 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2020 22:44:54 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1582238694.14.0.30732630205.issue39660@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Is there any existing API that can be used to call `lib.set_state` on context changes?

No, but there's C API that you can use to get/set contextvars. If a C library is hard coded to use threadlocals I'm afraid there's nothing we can do about it except fixing their C code to make state storage pluggable.

What library do you have in mind?

> If not, would it make sense to extend `contexvars` to allow users to configure that `lib.set_state` is called on context change?

Theoretically yes, for debug purposes at least.  But I still fail to see how you could use that API even if it existed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:45:19 2020
From: report at bugs.python.org (Marco Sulla)
Date: Thu, 20 Feb 2020 22:45:19 +0000
Subject: [issue39695] Failed to build _uuid module, but libraries was installed
In-Reply-To: <1582197552.83.0.93580426376.issue39695@roundup.psfhosted.org>
Message-ID: <1582238719.62.0.624194390175.issue39695@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Ah, well, this is not possible. I was banned from the mailing list. I wrote my "defense" to conduct-wg at python.org in date 2019-12-29, and I'm still waiting for a response...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39695>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:52:00 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 20 Feb 2020 22:52:00 +0000
Subject: [issue39699] Ubuntu Github action not fully running build process
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582239120.34.0.841660626284.issue39699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Probably just where I copied it from. PRs welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:54:33 2020
From: report at bugs.python.org (Andrew Bartlett)
Date: Thu, 20 Feb 2020 22:54:33 +0000
Subject: [issue37330] open(): remove 'U' mode, deprecated since Python 3.3
In-Reply-To: <1560872905.7.0.609892598407.issue37330@roundup.psfhosted.org>
Message-ID: <1582239273.97.0.307743305027.issue37330@roundup.psfhosted.org>


Andrew Bartlett <abartlet at samba.org> added the comment:

This breaks Samba's build:

https://bugzilla.samba.org/show_bug.cgi?id=14266

While we are of course able to patch new versions of Samba, this will make it harder to bisect back though Samba history.  It would be really great if this kind of change could be reverted or at least deferred so Samba can rely on a stable language platform for it's build system.

----------
nosy: +abartlet

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37330>
_______________________________________

From report at bugs.python.org  Thu Feb 20 17:55:12 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Thu, 20 Feb 2020 22:55:12 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1582239312.44.0.267525680456.issue39623@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

> Not so easy to find a satisfactory generic approach.
I agree, but wouldn't you agree that some information is better than no information?

>Task has a name exactly for the purpose of distinguishing similar but different tasks
But in case the same task is run many times with different arguments, the task's name by itself doesn't provide very useful information...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:06:57 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 23:06:57 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582240017.22.0.59294110725.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Fortunately libmpdec raises MemoryError almost instantaneously, so the PR retries 
the affected operations with estimated upper bounds for exact results without 
slowing down the common case.

The docs still need updating because people will still wonder why 1 / Decimal(3)
freezes the Linux machine at MAX_PREC. ;)


The Python implementation cannot use this approach because memory grows slowly.  
I'm not sure though if anyone _would_ run _pydecimal at MAX_PREC.

----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:21:09 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 23:21:09 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582240869.18.0.402011088053.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

BTW, this PR implements the invariant:

"If there exists an exact result at a lower precision, this
result should also be returned at MAX_PREC (without MemoryError)".

So non-integer powers are left out, since _decimal has no notion
of exact non-integer powers yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:27:45 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2020 23:27:45 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1582241265.05.0.82733619157.issue39623@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I agree, but wouldn't you agree that some information is better than no information?

We do agree with that. Making it work in the way that does not disturb people when a 10mb bytes string is passed is challenging. We could just cut everything after 100 characters, but it's not an ideal solution either.

> But in case the same task is run many times with different arguments, the task's name by itself doesn't provide very useful information...

So make it useful. You can concatenate critical arguments reprs to task names or make them informative in other way.  If you're working with a third-party library that doesn't use task names consider making a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:33:57 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 23:33:57 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582241637.65.0.47987039014.issue39699@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open
title: Ubuntu Github action not fully running build process -> Some CIs silence potentially useful output from make
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:34:57 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 20 Feb 2020 23:34:57 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582241697.48.0.0150251281549.issue39699@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +17953
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18583

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:38:42 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 20 Feb 2020 23:38:42 +0000
Subject: [issue39704] Disable code coverage
Message-ID: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

The automated code coverage on GitHub is quite inaccurate and needlessly flags PRs as red.

I'd prefer to make this opt-in.

----------
messages: 362367
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable code coverage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:40:40 2020
From: report at bugs.python.org (Leonard Lausen)
Date: Thu, 20 Feb 2020 23:40:40 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1582242040.82.0.373221291672.issue39660@roundup.psfhosted.org>


Leonard Lausen <leonard at lausen.nl> added the comment:

> No, but there's C API that you can use to get/set contextvars. If a C library
> is hard coded to use threadlocals I'm afraid there's nothing we can do about
> it except fixing their C code to make state storage pluggable.

I agree the C library could check the Python state. On the other hand, the Python frontend may be just one of multiple supported language frontends of the library. So it seems preferable if Python could tell the library when to change state.

> What library do you have in mind?

MXNet has such a thread-local C API to enable / disable recording for autograd. https://github.com/apache/incubator-mxnet/blob/9b38df0622fec677e6b4891dfc4c10295359996d/include/mxnet/c_api.h#L1260-L1266

> Theoretically yes, for debug purposes at least. But I still fail to see how
> you could use that API even if it existed.

Consider we are in "context 1". When we change the state in the C library by calling `old_state = lib.set_state(new_state)`, we get to know the prior state. When switching to "context 2", `lib.set_state(old_state)` should be called. When switching back to "context 1", `lib.set_state(new_state)` should be called again. It's analogous to contextvars.

Would there be too much overhead if allowing specification of a python function that contextvars calls on context changes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:49:15 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Thu, 20 Feb 2020 23:49:15 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1582242555.96.0.445031648531.issue39623@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

Oh I just learned that since python3.8 you can name individual tasks. Sorry for the confusion :)
It does seem like a good solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:51:07 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2020 23:51:07 +0000
Subject: [issue39660] Contextvars: Optional callbacks on state change
In-Reply-To: <1581918287.85.0.898283372496.issue39660@roundup.psfhosted.org>
Message-ID: <1582242667.43.0.000461209476582.issue39660@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Would there be too much overhead if allowing specification of a python function that contextvars calls on context changes?

Potentially yes, especially if we allow more than one context change callback.  Allowing just one makes the API inflexible (what if you want to use two libraries from PyPI that both want to use the callback).  Allowing multiple context change callbacks leads to complicated API.

For extra context: context switches occur on every callback invocation in asyncio and there can be thousands of them per seconds (or even more). Adding any extra code to context switching code will noticeably degrade the performance.

In general, I'd suggest patching the C library to make state management customizable (like CPython allows you to customize which memory allocator to use)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39660>
_______________________________________

From report at bugs.python.org  Thu Feb 20 18:52:20 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Feb 2020 23:52:20 +0000
Subject: [issue39623] __str__ and __repr__ for asyncio.Task still omit arg
 values
In-Reply-To: <1581581975.12.0.0633437109598.issue39623@roundup.psfhosted.org>
Message-ID: <1582242740.94.0.519453178706.issue39623@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> It does seem like a good solution.

Great. I'll close this issue then as the proposed solution is actually not as straightforward as it seems. Task names exist specifically to solve this case.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39623>
_______________________________________

From report at bugs.python.org  Thu Feb 20 19:17:34 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 21 Feb 2020 00:17:34 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582244254.7.0.205390774021.issue39704@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Agreed, it's way too noisy. This PR which touches absolutely no code https://github.com/python/cpython/pull/18583#issuecomment-589432937

claims to "increase coverage by 1.01%."

This doesn't really add much value and only adds noise in the pull requests.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 20 19:52:51 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 00:52:51 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582246371.31.0.924864054756.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 90930e65455f60216f09d175586139242dbba260 by Stefan Krah in branch 'master':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581)
https://github.com/python/cpython/commit/90930e65455f60216f09d175586139242dbba260


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 19:54:47 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 00:54:47 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582246487.75.0.70401120783.issue39576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17954
pull_request: https://github.com/python/cpython/pull/18584

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 19:55:00 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 00:55:00 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582246500.06.0.615233705285.issue39576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17955
pull_request: https://github.com/python/cpython/pull/18585

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 19:57:14 2020
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 21 Feb 2020 00:57:14 +0000
Subject: [issue35950] io.BufferedReader.writabe is False,
 but io.BufferedReader.truncate does not raise OSError
In-Reply-To: <1549719382.2.0.923720230511.issue35950@roundup.psfhosted.org>
Message-ID: <1582246634.3.0.809028719109.issue35950@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
pull_requests: +17956
pull_request: https://github.com/python/cpython/pull/18586

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35950>
_______________________________________

From report at bugs.python.org  Thu Feb 20 20:15:48 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 01:15:48 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582247748.2.0.0484233242579.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset c6f95543b4832c3f0170179da39bcf99b40a7aa8 by Miss Islington (bot) in branch '3.7':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581) (#18585)
https://github.com/python/cpython/commit/c6f95543b4832c3f0170179da39bcf99b40a7aa8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 20:16:49 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 01:16:49 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582247809.66.0.876620992422.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset b6271025c640c228505dc9f194362a0c2ab81c61 by Miss Islington (bot) in branch '3.8':
bpo-39576: Prevent memory error for overly optimistic precisions (GH-18581) (#18584)
https://github.com/python/cpython/commit/b6271025c640c228505dc9f194362a0c2ab81c61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 20:57:08 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 21 Feb 2020 01:57:08 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582250228.4.0.298778190635.issue39576@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Hm... is "exact result" a technical term that's defined somewhere? Because to me it seems that this

> "If there exists an exact result at a lower precision, this
result should also be returned at MAX_PREC (without MemoryError)".

is a mathematical statement, and surely for Decimal('0.07776') ** Decimal('0.2') _there exists_ an exact result at a lower precision. Maybe this should be reworded as "If there exists ... _and an implementation knows about it_, it should also be returned ..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Thu Feb 20 21:38:46 2020
From: report at bugs.python.org (Zhibin Dong)
Date: Fri, 21 Feb 2020 02:38:46 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582252726.5.0.898915229404.issue39622@roundup.psfhosted.org>


Zhibin Dong <developerdong at gmail.com> added the comment:

Thank you for your investigation, I will also try to see what went wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Thu Feb 20 23:48:07 2020
From: report at bugs.python.org (Gustavo)
Date: Fri, 21 Feb 2020 04:48:07 +0000
Subject: [issue39598] ERR_CACHE_MISS
In-Reply-To: <1581337438.53.0.0366477237465.issue39598@roundup.psfhosted.org>
Message-ID: <1582260487.4.0.0915203427117.issue39598@roundup.psfhosted.org>


Gustavo <augussee at yahoo.com> added the comment:

If you need more help on this issue, you can try the following guide: https://chromenotopening.com

----------
nosy: +gustavoxo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39598>
_______________________________________

From report at bugs.python.org  Thu Feb 20 23:52:00 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 21 Feb 2020 04:52:00 +0000
Subject: [issue39684] PyUnicode_IsIdentifier has two if/thens that can be
 combined
In-Reply-To: <1582089299.55.0.574843604033.issue39684@roundup.psfhosted.org>
Message-ID: <1582260720.46.0.446873219219.issue39684@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 933fc53f3f9c64ffa703b1f23a93bec560faea57 by Andy Lester in branch 'master':
closes bpo-39684: Combine two if/thens and squash uninit var warning. (GH-18565)
https://github.com/python/cpython/commit/933fc53f3f9c64ffa703b1f23a93bec560faea57


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39684>
_______________________________________

From report at bugs.python.org  Fri Feb 21 00:53:19 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 05:53:19 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1582264399.27.0.297033322435.issue38657@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 424e5686d82235e08f8108b8bbe034bc91421689 by Pete Wicken in branch 'master':
bpo-38657: Clarify numeric padding behaviour in string formatting (GH-17036)
https://github.com/python/cpython/commit/424e5686d82235e08f8108b8bbe034bc91421689


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Feb 21 00:53:28 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 05:53:28 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1582264408.46.0.327103658588.issue38657@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17957
pull_request: https://github.com/python/cpython/pull/18587

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Feb 21 00:53:35 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 05:53:35 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1582264415.29.0.211651282626.issue38657@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17958
pull_request: https://github.com/python/cpython/pull/18588

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Feb 21 01:06:04 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 06:06:04 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1582265164.48.0.939818943859.issue38657@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 09db1da63f866afff8a64ae3c60acdcd6bc80501 by Miss Islington (bot) in branch '3.7':
bpo-38657: Clarify numeric padding behaviour in string formatting (GH-17036)
https://github.com/python/cpython/commit/09db1da63f866afff8a64ae3c60acdcd6bc80501


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Feb 21 01:06:21 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 06:06:21 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1582265181.77.0.983462487749.issue38657@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a2075121217e809c9a5511f6ca225c12f340de0c by Miss Islington (bot) in branch '3.8':
bpo-38657: Clarify numeric padding behaviour in string formatting (GH-17036)
https://github.com/python/cpython/commit/a2075121217e809c9a5511f6ca225c12f340de0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Fri Feb 21 01:41:40 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Fri, 21 Feb 2020 06:41:40 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582267300.85.0.976877475485.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

This is my code for math.gcd:

static PyObject *
math_gcd(PyObject *module, PyObject *args, Py_ssize_t n)
{
    PyObject *g = 0, *item, *in;
    
    Py_ssize_t i;
    for (i = 0; i < n; i++) {
        item = args[i];
        in = PyNumber_Index(item);
        if (in == NULL) {
            return NULL;
        }
        g = _PyLong_GCD(g, in);
    }
    Py_DECREF(in);
    return g;
}



This is showing an error:

error: incompatible types when assigning to type ?PyObject * {aka struct _object *}? from type ?PyObject {aka struct _object}?
       item = args[i];
           ^^^

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Fri Feb 21 02:37:28 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 07:37:28 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582270648.41.0.556956736131.issue39704@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 21 02:45:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Feb 2020 07:45:50 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582271150.23.0.244667201899.issue39704@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Just to clarify is it about just disabling the automatic comment about code coverage on PRs or the code coverage build itself?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 21 02:52:32 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 21 Feb 2020 07:52:32 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582271552.08.0.271653076194.issue39648@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Ananthakrishnan: Do you know how arrays and pointers work in C?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:34:42 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 08:34:42 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582274082.77.0.433058067846.issue39704@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I'd definitely disable the automatic comment and prefer that the build
happens on buildbot.python.org rather than affecting the GitHub build
status.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:42:40 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Feb 2020 08:42:40 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582274560.43.0.40303160141.issue39704@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the clarification, I agree on disabling automatic coverage comments. Aren't these builds already optional in Travis marked as allow failures and status is reported once the required builds pass though the coverage builds keep running?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:48:25 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 08:48:25 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582274905.83.0.0246853493689.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Vedran, msg362365 is meant to say:

"This PR implements $SOMEWHAT_MATHEMATICAL_SPEC except for inexact power."

Had I put the caveat inside the statement as well, the message would have been:

"This PR implements $SOMEWHAT_MATHEMATICAL_SPEC_EXCEPT_FOR_INEXACT_POWER except for inexact power."


Bur GNU is not UNIX and all that... ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:48:43 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 21 Feb 2020 08:48:43 +0000
Subject: [issue9495] argparse unittest tracebacks are confusing if an error is
 raised when not expected
In-Reply-To: <1280852518.56.0.709280463518.issue9495@psf.upfronthosting.co.za>
Message-ID: <1582274923.53.0.511611836055.issue9495@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset d4331c56b4f6fe6f18caf19fc1ecf9fec14f7066 by alclarks in branch 'master':
bpo-9495: avoid confusing chained exception in argparse test (GH-17120)
https://github.com/python/cpython/commit/d4331c56b4f6fe6f18caf19fc1ecf9fec14f7066


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9495>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:49:27 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 21 Feb 2020 08:49:27 +0000
Subject: [issue9495] argparse unittest tracebacks are confusing if an error is
 raised when not expected
In-Reply-To: <1280852518.56.0.709280463518.issue9495@psf.upfronthosting.co.za>
Message-ID: <1582274967.19.0.584904914605.issue9495@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for the PR, Alex!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9495>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:53:08 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Fri, 21 Feb 2020 08:53:08 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582275188.34.0.452493945206.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

Yes I know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Fri Feb 21 03:58:54 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 21 Feb 2020 08:58:54 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582275534.25.0.412072282207.issue39576@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Well, it all depends on how do you intend to read it. To me, the closing quote and "So non-integer powers are left out" after it suggested that the non-integer powers being left out is somehow a consequence of the above paragraph. When in fact instead of "so" I think "except" or "alas":-) should have been.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:11:19 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 09:11:19 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582276279.54.0.490607084792.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

"So non-integer powers are left out" in isolation would indeed be
wrong, but actual sentence is unambiguously qualified with:

"... since _decimal has no notion of exact non-integer powers yet.",
which clearly states that exact non-integer powers exist and
_decimal does not recognize them (it usually produces exact results
in the respective cases but still sets Inexact).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:24:31 2020
From: report at bugs.python.org (Mirwi)
Date: Fri, 21 Feb 2020 09:24:31 +0000
Subject: [issue39705] Tutorial, 5.6 Looping Techniques, sorted() example
Message-ID: <1582277071.44.0.766763125418.issue39705@roundup.psfhosted.org>


New submission from Mirwi <mirwi at binary-kitchen.de>:

>>> basket = ['apple', 'orange', 'apple', 'pear', 'orange', 'banana']
>>> for f in sorted(set(basket)):
...     print(f)
...
apple
banana
orange
pear

Shouldn't 'apple' appear two times as basket is a list that allows duplicates, not a set?

I'm just doing my first steps into Python and may be mislead. In that case, sorry for the fuzz.

----------
assignee: docs at python
components: Documentation
messages: 362395
nosy: docs at python, mirwi
priority: normal
severity: normal
status: open
title: Tutorial, 5.6 Looping Techniques, sorted() example
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39705>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:33:08 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Feb 2020 09:33:08 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1582277588.19.0.217790842087.issue35727@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset c2ac4cf040ea950bf552d1e77bea613a1a5474fe by Christopher Hunt in branch 'master':
bpo-35727: Use exit code 0 on sys.exit() in multiprocessing.Process. (GH-11538)
https://github.com/python/cpython/commit/c2ac4cf040ea950bf552d1e77bea613a1a5474fe


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:34:23 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Feb 2020 09:34:23 +0000
Subject: [issue35727] sys.exit() in a multiprocessing.Process does not align
 with Python behavior
In-Reply-To: <1547321617.14.0.566390882886.issue35727@roundup.psfhosted.org>
Message-ID: <1582277663.65.0.34491907915.issue35727@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry for the delay.  I've now merged the PR for 3.9.  Since this is a slight behaviour change, and the original issue was easy to workaround, I won't backport it.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35727>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:35:41 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 21 Feb 2020 09:35:41 +0000
Subject: [issue39705] Tutorial, 5.6 Looping Techniques, sorted() example
In-Reply-To: <1582277071.44.0.766763125418.issue39705@roundup.psfhosted.org>
Message-ID: <1582277741.95.0.505952344817.issue39705@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The code is converting to a set first, then calls sorted() on that set. So "apple" is removed when the set is created.

I'm not sure the example should throw in creating a set while it's talking about sorting.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39705>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:35:47 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Fri, 21 Feb 2020 09:35:47 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582277747.75.0.78804130723.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

Thanks for the hint.Made changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Fri Feb 21 04:38:27 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Fri, 21 Feb 2020 09:38:27 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582277907.92.0.234212945273.issue39648@roundup.psfhosted.org>


Change by Ananthakrishnan <ananthakrishnan15.2001 at gmail.com>:


----------
keywords: +patch
pull_requests: +17959
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18590

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Fri Feb 21 05:04:16 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Feb 2020 10:04:16 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582279456.26.0.555819543891.issue39681@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, in the mmap case, this is trivially fixed by writing:
```
with open("my_data.pkl", "r+b") as f_in:
    mm = mmap.mmap(f_in.fileno(), 0)

print(pickle.loads(memoryview(mm)))
```

It will also be faster this way, since the pickle will be read directly from memory instead of going through read() calls.

This makes me think that perhaps this issue isn't as bad: it forces people to abandon bad idioms :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Fri Feb 21 05:08:22 2020
From: report at bugs.python.org (Marco)
Date: Fri, 21 Feb 2020 10:08:22 +0000
Subject: [issue39628] msg.walk memory leak?
In-Reply-To: <1581606328.48.0.533988298686.issue39628@roundup.psfhosted.org>
Message-ID: <1582279702.78.0.802017058531.issue39628@roundup.psfhosted.org>


Marco <m.faverof at gmail.com> added the comment:

uhm, no.
I can no more reproduce this. I was wrong. Sorry for the noise.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39628>
_______________________________________

From report at bugs.python.org  Fri Feb 21 05:12:48 2020
From: report at bugs.python.org (Andrey Moiseev)
Date: Fri, 21 Feb 2020 10:12:48 +0000
Subject: [issue39706] unittest.IsolatedAsyncioTestCase hangs on
 asyncio.CancelledError
Message-ID: <1582279968.65.0.00583544355873.issue39706@roundup.psfhosted.org>


New submission from Andrey Moiseev <o2g.org.ru at gmail.com>:

The following code hangs:

import asyncio
import unittest


class TestCancellation(unittest.IsolatedAsyncioTestCase):

    async def test_works(self):
        raise asyncio.CancelledError()


if __name__ == '__main__':
    unittest.main()

----------
components: asyncio
messages: 362402
nosy: Andrey Moiseev, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: unittest.IsolatedAsyncioTestCase hangs on asyncio.CancelledError
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39706>
_______________________________________

From report at bugs.python.org  Fri Feb 21 05:59:10 2020
From: report at bugs.python.org (Arn Vollebregt (KPN))
Date: Fri, 21 Feb 2020 10:59:10 +0000
Subject: [issue39707] Abstract property setter/deleter implementation not
 enforced.
Message-ID: <1582282750.75.0.718234610951.issue39707@roundup.psfhosted.org>


New submission from Arn Vollebregt (KPN) <kpn.arn.vollebregt at gmail.com>:

When concretely implementing an abstract ABC class with an abstract property getter, setter and deleter it is not enfored that the setter and deleter are implemented. Instead, the property is treated as a read-only property (as would normally be the case without a setter/deleter definition for a property) and the setter/deleter code from the abstract class is not present in the child class.

I would expect a TypeError exception when an abstract property is defined with a getter, setter and deleter but only the getter is implemented in a subclass (as is the case when not implementing the property getter). As a fallback, I would find it acceptable the code from the abstract class to be present in the child class, so at least the code that is defined there (in this case raising a NotImplementedError exception) would be executed.

An interactive interpreter session to replicate this behavior:

arn at hacktop:~$ python3
Python 3.7.5 (default, Nov 20 2019, 09:21:52)
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import abc
>>>
>>> # Define the (abstract) interface.
... class MyInterface(abc.ABC):
...
...     # Property getter.
...     @property
...     @abc.abstractmethod
...     def myProperty(self) -> str:
...         raise NotImplementedError
...
...     # Property setter.
...     @myProperty.setter
...     @abc.abstractmethod
...     def myProperty(self, value: str) -> None:
...         raise NotImplementedError
...
...     # Property deleter.
...     @myProperty.deleter
...     @abc.abstractmethod
...     def myProperty(self) -> None:
...         raise NotImplementedError
...
>>> # Implemented the interface.
... class MyImplementation(MyInterface):
...     
...     # No abstract method implementation(s).
...     pass
...
>>> # Creation of MyImplementation object raises TypeError as expected.
... obj = MyImplementation()
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: Can't instantiate abstract class MyImplementation with abstract methods myProperty
>>> import dis
>>> # The property getter code would raise an exception as defined in MyInterface.
... dis.dis(MyImplementation.myProperty.fget.__code__.co_code)
          0 LOAD_GLOBAL              0 (0)
          2 RAISE_VARARGS            1
          4 LOAD_CONST               0 (0)
          6 RETURN_VALUE
>>> # The property setter code would raise an exception as defined in MyInterface.
... dis.dis(MyImplementation.myProperty.fset.__code__.co_code)
          0 LOAD_GLOBAL              0 (0)
          2 RAISE_VARARGS            1
          4 LOAD_CONST               0 (0)
          6 RETURN_VALUE
>>> # The property deleter code would raise an exception as defined in MyInterface.
... dis.dis(MyImplementation.myProperty.fdel.__code__.co_code)
          0 LOAD_GLOBAL              0 (0)
          2 RAISE_VARARGS            1
          4 LOAD_CONST               0 (0)
          6 RETURN_VALUE
>>> # Let's reimplement with only the property getter.
... class MyImplementation(MyInterface):
...
...     # Only implement abstract property getter.
...     @property
...     def myProperty(self) -> str:
...         return "foobar"
...
>>> # Object can be created (against expectations).
... obj = MyImplementation()
>>> # The property getter works as defined.
... obj.myProperty
'foobar'
>>> # The property cannot be set (read-only).
... obj.myProperty = "barfoo"
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
AttributeError: can't set attribute
>>> # The property cannot be deleted (read-only).
... del obj.myProperty
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
AttributeError: can't delete attribute
>>> # The property getter code returns a string as defined in MyImplementation.
... type(MyImplementation.myProperty.fget)
<class 'function'>
>>> dis.dis(MyImplementation.myProperty.fget.__code__.co_code)
          0 LOAD_CONST               1 (1)
          2 RETURN_VALUE
>>> # The property setter code however does not exist, although defined in MyInterface.
... type(MyImplementation.myProperty.fset)
<class 'NoneType'>
>>> # Nor does the property deleter code, although defined in MyInterface.
... type(MyImplementation.myProperty.fdel)
<class 'NoneType'>

----------
messages: 362403
nosy: arn.vollebregt.kpn
priority: normal
severity: normal
status: open
title: Abstract property setter/deleter implementation not enforced.
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39707>
_______________________________________

From report at bugs.python.org  Fri Feb 21 07:03:28 2020
From: report at bugs.python.org (Akos Kiss)
Date: Fri, 21 Feb 2020 12:03:28 +0000
Subject: [issue39694] Incorrect dictionary unpacking when calling str.format
In-Reply-To: <1582193003.32.0.513659901276.issue39694@roundup.psfhosted.org>
Message-ID: <1582286608.63.0.458269464753.issue39694@roundup.psfhosted.org>


Akos Kiss <akosthekiss at gmail.com> added the comment:

I've come up with some extra examples (use cases?):

```py
import collections

class str2(str):
    def format(self, *args, **kwargs):
        return super().format(*args, **kwargs)

def unpacknonekey(s):
    print('input:', type(s), s)
    try:
        print('str key:', s.format(**{'bar': 'qux'}))
        print('none key:', s.format(**{'bar': 'qux', None: ''}))
    except TypeError as e:
        print('error:', e)

template = 'foo {bar} baz'
unpacknonekey(template)
unpacknonekey(str2(template))
unpacknonekey(collections.UserString(template))
```

The above script gives the following output:

```
input: <class 'str'> foo {bar} baz
str key: foo qux baz
none key: foo qux baz
input: <class '__main__.str2'> foo {bar} baz
str key: foo qux baz
error: format() keywords must be strings
input: <class 'collections.UserString'> foo {bar} baz
str key: foo qux baz
error: format() keywords must be strings
```

This shows inconsistency between `format` of `str` and subclasses of `str` or the standard library's `UserString`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39694>
_______________________________________

From report at bugs.python.org  Fri Feb 21 08:00:20 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Feb 2020 13:00:20 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582290020.52.0.285968191577.issue39681@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
pull_requests: +17960
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18592

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Fri Feb 21 08:01:01 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Feb 2020 13:01:01 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582290061.77.0.150796666773.issue39681@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> pitrou
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Fri Feb 21 09:09:02 2020
From: report at bugs.python.org (Dennis Clarke)
Date: Fri, 21 Feb 2020 14:09:02 +0000
Subject: [issue39708] final link stage in compile fails for 3.8.1 with missing
 CFLAGS
Message-ID: <1582294142.91.0.373502818362.issue39708@roundup.psfhosted.org>


New submission from Dennis Clarke <dclarke at blastwave.org>:

During compile after a sucessful configure the final link stage fails : 

/opt/developerstudio12.6/bin/cc -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib    -o python Programs/python.o -Wl,-R,/usr/local/lib -L. -lpython3.8d -lsocket -lnsl -lintl -lrt -ldl -lsendfile  -lm   -lm 
ld: fatal: file /opt/developerstudio12.6/lib/compilers/crti.o: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to python
gmake: *** [Makefile:578: python] Error 2

real 107.96
user 100.96
sys 21.96
alpha$

Easily done manually : 

alpha$ $CC $CFLAGS -R/usr/local/lib -L/usr/local/lib \
> -o python Programs/python.o \
> -Wl,-R,/usr/local/lib -L. -lpython3.8d -lsocket -lnsl -lintl -lrt -ldl -lsendfile  -lm
alpha$ 

alpha$ file python 
python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
alpha$

----------
components: Build
messages: 362405
nosy: blastwave
priority: normal
severity: normal
status: open
title: final link stage in compile fails for 3.8.1 with missing CFLAGS
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39708>
_______________________________________

From report at bugs.python.org  Fri Feb 21 09:17:18 2020
From: report at bugs.python.org (Dennis Clarke)
Date: Fri, 21 Feb 2020 14:17:18 +0000
Subject: [issue39709] missing CFLAGS during make tests results in test and
 compile failure
Message-ID: <1582294638.45.0.102142275523.issue39709@roundup.psfhosted.org>


New submission from Dennis Clarke <dclarke at blastwave.org>:

Seems to be an error in the Makefile(s) in that the "make test" can
 not compile some code for the correct architecture : 

The process seems to begin well and fine : 

alpha$ LD_LIBRARY_PATH=`pwd` /usr/local/bin/gmake test 2>&1 | tee ../python_3.8.1_SunOS5.10_sparc64vii+.003.test.log
LD_LIBRARY_PATH=/usr/local/build/python_3.8.1_SunOS5.10_sparc64vii+.003 ./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
/opt/developerstudio12.6/bin/cc -c -xcode=pic32   -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -D_REENTRANT -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib    -I../Python-3.8.1/Include/internal -IObjects -IInclude -IPython -I. -I../Python-3.8.1/Include -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 -xcode=pic32 -DPy_BUILD_CORE -o Modules/_math.o ../Python-3.8.1/Modules/_math.c
cc: Warning: multiple use of -Q option, previous one discarded.
LD_LIBRARY_PATH=/usr/local/build/python_3.8.1_SunOS5.10_sparc64vii+.003 CC='/opt/developerstudio12.6/bin/cc' LDSHARED='/opt/developerstudio12.6/bin/cc -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -G -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib  ' OPT=''         _TCLTK_INCLUDES='' _TCLTK_LIBS=''       ./python -E ../Python-3.8.1/setup.py  build
running build
running build_ext
building '_struct' extension
creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr
creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local
creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build
creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build/Python-3.8.1
creating build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build/Python-3.8.1/Modules
.
.
.
/opt/developerstudio12.6/bin/cc -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -G -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 build/temp.solaris-2.10-sun4u.64bit-3.8-pydebug/usr/local/build/Python-3.8.1/Modules/_uuidmodule.o -L. -L/usr/local/lib -R/usr/local/lib -luuid -o build/lib.solaris-2.10-sun4u.64bit-3.8-pydebug/_uuid.so
cc: Warning: multiple use of -Q option, previous one discarded.
*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4u.64bit-3.8-pydebug/_curses.so: symbol acs32map: referenced symbol not found
*** WARNING: renaming "_curses_panel" since importing it failed: No module named '_curses'
INFO: Could not locate ffi libs and/or headers

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_gdbm                 ossaudiodev                              
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd                
time                                                           


Failed to build these modules:
_ctypes                                                        


Following modules built successfully but were removed because they could not be imported:
_curses               _curses_panel                            

running build_scripts
creating build/scripts-3.8
copying and adjusting /usr/local/build/Python-3.8.1/Tools/scripts/pydoc3 -> build/scripts-3.8
copying and adjusting /usr/local/build/Python-3.8.1/Tools/scripts/idle3 -> build/scripts-3.8
copying and adjusting /usr/local/build/Python-3.8.1/Tools/scripts/2to3 -> build/scripts-3.8
changing mode of build/scripts-3.8/pydoc3 from 644 to 755
changing mode of build/scripts-3.8/idle3 from 644 to 755
changing mode of build/scripts-3.8/2to3 from 644 to 755
renaming build/scripts-3.8/pydoc3 to build/scripts-3.8/pydoc3.8
renaming build/scripts-3.8/idle3 to build/scripts-3.8/idle3.8
renaming build/scripts-3.8/2to3 to build/scripts-3.8/2to3-3.8
../Python-3.8.1/install-sh -c -m 644 ../Python-3.8.1/Tools/gdb/libpython.py python-gdb.py
/opt/developerstudio12.6/bin/cc -c   -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib -D_REENTRANT -std=iso9899:2011 -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -L/usr/local/lib -R/usr/local/lib    -I../Python-3.8.1/Include/internal -IObjects -IInclude -IPython -I. -I../Python-3.8.1/Include -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 -I/usr/local/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=600 -xcode=pic32 -DPy_BUILD_CORE -o Programs/_testembed.o ../Python-3.8.1/Programs/_testembed.c
cc: Warning: multiple use of -Q option, previous one discarded.
/opt/developerstudio12.6/bin/cc -R/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib    -o Programs/_testembed Programs/_testembed.o -Wl,-R,/usr/local/lib -L. -lpython3.8d -lsocket -lnsl -lintl -lrt -ldl -lsendfile  -lm   -lm 
ld: fatal: file /opt/developerstudio12.6/lib/compilers/crti.o: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to Programs/_testembed
gmake: *** [Makefile:709: Programs/_testembed] Error 2
alpha$ 

Manual intervention required : 

alpha$ 
alpha$ $CC $CFLAGS -R/usr/local/lib -L/usr/local/lib -o Programs/_testembed \
> Programs/_testembed.o -Wl,-R,/usr/local/lib -L. -lpython3.8d \
> -lsocket -lnsl -lintl -lrt -ldl -lsendfile -lm
alpha$ 

Then one may continue and the tests begin to run.

----------
components: Tests
messages: 362406
nosy: blastwave
priority: normal
severity: normal
status: open
title: missing CFLAGS during make tests results in test and compile failure
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39709>
_______________________________________

From report at bugs.python.org  Fri Feb 21 09:26:15 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 14:26:15 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582295175.39.0.531433664787.issue39576@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
pull_requests: +17961
pull_request: https://github.com/python/cpython/pull/18594

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 09:33:04 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 21 Feb 2020 14:33:04 +0000
Subject: [issue39537] Change line number table format
In-Reply-To: <1580724394.63.0.487397350613.issue39537@roundup.psfhosted.org>
Message-ID: <1582295584.03.0.309543469854.issue39537@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Serhiy,

Although the code generator is syntax directed, not all code has an explicit piece of syntax attached.

For example in the following code:
```
def foo():
    if x:
        print("yes")
    else:
        print("no")
```
the compiler emits code to return from the function (LOAD_CONST None; RETURN_VALUE), but there is no explicit return, and no meaningful line number for the return.

Also consider, the artificial try-except block generated for async for loops and the cleanup code for named exception variables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39537>
_______________________________________

From report at bugs.python.org  Fri Feb 21 09:55:33 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 14:55:33 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582296933.55.0.07178327926.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Updated docs:

https://github.com/python/cpython/pull/18594

The PR uses some of Tim's suggestions while also explaining how to
calculate the amount of memory used in a single large decimal.

Hopefully it isn't too much information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 10:39:00 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 15:39:00 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582299540.65.0.839245434301.issue39704@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

They are allowed failures but the build is still marked in red:

https://github.com/python/cpython/pull/18567


So if you look at the front page you have to click through red results
only to find that the reason is code coverage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 21 10:58:28 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 21 Feb 2020 15:58:28 +0000
Subject: [issue39710] "will be returned as unicode" reminiscent from Python 2
Message-ID: <1582300708.21.0.335550003251.issue39710@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In https://docs.python.org/3/library/calendar.html#calendar.LocaleTextCalendar I read "If this locale includes an encoding all strings containing month and weekday names will be returned as unicode."

`unicode` here is a mention of the `unicode` type from Python 2 which does no longer exists, so the whole sentence can just be removed.

It happen also in the next paragraph, and twice in Lib/calendar.py.

In Python 2:

>>> print type(calendar.LocaleTextCalendar(locale="C").formatmonth(2020, 1))
<type 'str'>
>>> print type(calendar.LocaleTextCalendar(locale="en_US.UTF8").formatmonth(2020, 1))
<type 'unicode'>

In Python 3:

>>> print(type(calendar.LocaleTextCalendar(locale="C").formatmonth(2020, 1)))
<class 'str'>
>>> print(type(calendar.LocaleTextCalendar(locale="en_US.UTF8").formatmonth(2020, 1)))
<class 'str'>

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 362410
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: "will be returned as unicode" reminiscent from Python 2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39710>
_______________________________________

From report at bugs.python.org  Fri Feb 21 11:11:52 2020
From: report at bugs.python.org (Dennis Clarke)
Date: Fri, 21 Feb 2020 16:11:52 +0000
Subject: [issue39711] SIGBUS and core dumped during tests of 3.8.1
Message-ID: <1582301512.94.0.0314211324749.issue39711@roundup.psfhosted.org>


New submission from Dennis Clarke <dclarke at blastwave.org>:

The testsuite fails badly with a SIGBUS thus : 

.
.
.
0:01:37 load avg: 2.81 [ 26/423/1] test_frozen passed
0:01:40 load avg: 2.77 [ 27/423/1] test_eof passed -- running: test_importlib (31.7 sec), test_socket (31.2 sec)
0:01:41 load avg: 2.75 [ 28/423/1] test_poplib passed -- running: test_importlib (32.8 sec), test_socket (32.2 sec)
0:01:45 load avg: 2.71 [ 29/423/1] test_aifc passed -- running: test_importlib (37.2 sec), test_socket (36.7 sec)
0:01:46 load avg: 2.71 [ 30/423/1] test_unicode_file_functions passed -- running: test_importlib (37.8 sec), test_socket (37.2 sec)
0:01:51 load avg: 2.71 [ 31/423/1] test_listcomps passed -- running: test_importlib (42.9 sec), test_socket (42.4 sec)
0:01:54 load avg: 2.75 [ 32/423/1] test_asdl_parser passed -- running: test_importlib (46.0 sec), test_socket (45.4 sec)
0:01:57 load avg: 2.77 [ 33/423/1] test_richcmp passed -- running: test_importlib (49.1 sec), test_socket (48.6 sec)
0:02:01 load avg: 2.78 [ 34/423/1] test_importlib passed (48.3 sec) -- running: test_socket (51.8 sec)
0:02:04 load avg: 2.76 [ 35/423/1] test_rlcompleter passed -- running: test_socket (55.6 sec)
0:02:08 load avg: 2.75 [ 36/423/1] test_sys_setprofile passed -- running: test_socket (59.0 sec)
0:02:16 load avg: 2.72 [ 37/423/1] test_tuple passed -- running: test_socket (1 min 7 sec), test_capi (31.0 sec)
0:02:39 load avg: 2.73 [ 38/423/1] test_c_locale_coercion passed -- running: test_ast (31.4 sec), test_socket (1 min 30 sec), test_capi (53.8 sec)
0:02:44 load avg: 2.76 [ 39/423/1] test_symtable passed -- running: test_ast (36.6 sec), test_socket (1 min 35 sec), test_capi (58.9 sec)
0:03:01 load avg: 2.88 [ 40/423/1] test_ast passed (51.2 sec) -- running: test_socket (1 min 52 sec), test_capi (1 min 15 sec)
0:03:04 load avg: 2.89 [ 41/423/1] test_pow passed -- running: test_socket (1 min 55 sec), test_capi (1 min 18 sec)
0:03:19 load avg: 2.90 [ 42/423/1] test_http_cookiejar passed -- running: test_socket (2 min 10 sec), test_capi (1 min 33 sec)
0:03:21 load avg: 2.88 [ 43/423/1] test_defaultdict passed -- running: test_socket (2 min 12 sec), test_capi (1 min 36 sec)
0:03:24 load avg: 2.86 [ 44/423/1] test_winconsoleio skipped -- running: test_socket (2 min 15 sec), test_capi (1 min 38 sec)
test_winconsoleio skipped -- test only relevant on win32
0:03:34 load avg: 2.77 [ 45/423/1] test_cprofile passed -- running: test_socket (2 min 25 sec), test_capi (1 min 48 sec)
0:03:37 load avg: 2.75 [ 46/423/1] test_nntplib passed -- running: test_socket (2 min 28 sec), test_capi (1 min 51 sec)
0:03:42 load avg: 2.74 [ 47/423/1] test_xml_dom_minicompat passed -- running: test_socket (2 min 33 sec), test_capi (1 min 56 sec)
0:03:46 load avg: 2.77 [ 48/423/1] test_pkgimport passed -- running: test_socket (2 min 37 sec), test_capi (2 min)
0:04:00 load avg: 2.80 [ 49/423/1] test_timeout passed -- running: test_socket (2 min 51 sec), test_capi (2 min 14 sec)
0:04:04 load avg: 2.78 [ 50/423/1] test_pkg passed -- running: test_socket (2 min 54 sec), test_capi (2 min 18 sec)
0:04:09 load avg: 2.79 [ 51/423/1] test_mimetypes passed -- running: test_support (34.9 sec), test_socket (2 min 59 sec), test_capi (2 min 23 sec)
0:04:18 load avg: 2.85 [ 52/423/1] test_base64 passed -- running: test_support (44.1 sec), test_socket (3 min 9 sec), test_capi (2 min 32 sec)
0:04:23 load avg: 2.88 [ 53/423/1] test_metaclass passed -- running: test_support (48.9 sec), test_socket (3 min 13 sec), test_capi (2 min 37 sec)
0:04:24 load avg: 2.89 [ 54/423/2] test_timeit crashed (Exit code 1) -- running: test_support (50.4 sec), test_socket (3 min 15 sec), test_capi (2 min 38 sec)
Traceback (most recent call last):
  File "/usr/local/build/Python-3.8.1/Lib/runpy.py", line 193, in _run_module_as_main
  File "/usr/local/build/Python-3.8.1/Lib/runpy.py", line 86, in _run_code
  File "/usr/local/build/Python-3.8.1/Lib/test/regrtest.py", line 14, in <module>
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/__init__.py", line 1, in <module>
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/cmdline.py", line 4, in <module>
  File "/usr/local/build/Python-3.8.1/Lib/test/support/__init__.py", line 6, in <module>
  File "/usr/local/build/Python-3.8.1/Lib/asyncio/__init__.py", line 8, in <module>
  File "/usr/local/build/Python-3.8.1/Lib/asyncio/base_events.py", line 45, in <module>
  File "/usr/local/build/Python-3.8.1/Lib/asyncio/staggered.py", line 10, in <module>
  File "<frozen importlib._bootstrap>", line 991, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 779, in exec_module
  File "<frozen importlib._bootstrap_external>", line 874, in get_code
  File "<frozen importlib._bootstrap_external>", line 972, in get_data
MemoryError
Warning -- regrtest worker thread failed: Traceback (most recent call last):
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest_mp.py", line 264, in run
    mp_result = self._runtest(test_name)
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest_mp.py", line 229, in _runtest
    retcode, stdout, stderr = self._run_process(test_name)
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest_mp.py", line 174, in _run_process
    popen = run_test_in_subprocess(test_name, self.ns)
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest_mp.py", line 62, in run_test_in_subprocess
    return subprocess.Popen(cmd,
  File "/usr/local/build/Python-3.8.1/Lib/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/build/Python-3.8.1/Lib/subprocess.py", line 1637, in _execute_child
    self.pid = _posixsubprocess.fork_exec(
OSError: [Errno 12] Not enough space

Kill <TestWorkerProcess #1 running test=test_support pid=5376 time=50.4 sec>
Kill <TestWorkerProcess #3 running test=test_socket pid=5242 time=3 min 15 sec>
Kill <TestWorkerProcess #4 running test=test_capi pid=5258 time=2 min 38 sec>

== Tests result: FAILURE ==

369 tests omitted:
    test___all__ test___future__ test__locale test__opcode
    test__osx_support test__xxsubinterpreters test_abc
    test_abstract_numbers test_argparse test_array test_asyncgen
    test_asynchat test_asyncio test_asyncore test_atexit test_audioop
    test_audit test_augassign test_baseexception test_bdb
    test_bigaddrspace test_binascii test_binhex test_binop test_bisect
    test_bool test_buffer test_bufio test_builtin test_bytes test_bz2
    test_calendar test_call test_capi test_cgi test_charmapcodec
    test_class test_clinic test_cmath test_cmd test_cmd_line
    test_cmd_line_script test_code_module test_codeccallbacks
    test_codecencodings_cn test_codecencodings_hk
    test_codecencodings_iso2022 test_codecencodings_jp
    test_codecencodings_kr test_codecencodings_tw test_codecmaps_cn
    test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr
    test_codecmaps_tw test_codecs test_codeop test_collections
    test_colorsys test_compare test_compile test_compileall
    test_concurrent_futures test_configparser test_contains
    test_context test_contextlib test_contextlib_async test_copy
    test_copyreg test_coroutines test_crashers test_crypt test_csv
    test_ctypes test_curses test_dataclasses test_datetime test_dbm
    test_dbm_dumb test_dbm_gnu test_dbm_ndbm test_decimal
    test_decorators test_deque test_descr test_devpoll
    test_dict_version test_dictcomps test_dictviews test_difflib
    test_distutils test_doctest test_doctest2 test_docxmlrpc
    test_dtrace test_dummy_thread test_dummy_threading test_dynamic
    test_dynamicclassattribute test_eintr test_email test_embed
    test_enum test_enumerate test_epoll test_exception_hierarchy
    test_exception_variations test_exceptions test_extcall
    test_faulthandler test_fcntl test_file test_file_eintr
    test_filecmp test_fileinput test_fileio test_finalization
    test_float test_flufl test_fnmatch test_fork1 test_format
    test_fractions test_frame test_fstring test_ftplib test_functools
    test_future test_future3 test_future4 test_future5 test_gc
    test_gdb test_generator_stop test_generators test_genericclass
    test_genericpath test_genexps test_getargs2 test_getopt
    test_gettext test_glob test_global test_grammar test_grp test_gzip
    test_hash test_heapq test_hmac test_html test_htmlparser
    test_http_cookies test_httplib test_httpservers test_idle
    test_imaplib test_imghdr test_imp test_import test_index
    test_inspect test_int test_int_literal test_io test_ioctl
    test_ipaddress test_isinstance test_iter test_iterlen
    test_itertools test_json test_keyword test_keywordonlyarg
    test_kqueue test_largefile test_lib2to3 test_linecache test_list
    test_lltrace test_locale test_logging test_long test_lzma
    test_mailbox test_mailcap test_marshal test_math test_memoryio
    test_memoryview test_minidom test_mmap test_module
    test_modulefinder test_multibytecodec test_multiprocessing_fork
    test_multiprocessing_forkserver test_multiprocessing_main_handling
    test_multiprocessing_spawn test_named_expressions test_netrc
    test_nis test_normalization test_ntpath test_numeric_tower
    test_opcodes test_openpty test_ordered_dict test_os
    test_ossaudiodev test_osx_env test_parser test_pathlib test_pdb
    test_peepholer test_pickle test_picklebuffer test_pickletools
    test_pipes test_pkgutil test_platform test_plistlib test_poll
    test_popen test_positional_only_arg test_posix test_posixpath
    test_pprint test_print test_profile test_property test_pstats
    test_pty test_pulldom test_pwd test_py_compile test_pyclbr
    test_pydoc test_pyexpat test_queue test_quopri test_raise
    test_random test_range test_re test_readline test_regrtest
    test_repl test_reprlib test_resource test_robotparser test_sax
    test_sched test_scope test_secrets test_select test_selectors
    test_setcomps test_shelve test_shutil test_signal test_site
    test_slice test_smtpd test_smtplib test_smtpnet test_sndhdr
    test_socket test_socketserver test_sort test_source_encoding
    test_sqlite test_ssl test_startfile test_statistics test_strftime
    test_string test_string_literals test_stringprep test_strptime
    test_strtod test_struct test_structmembers test_structseq
    test_subclassinit test_subprocess test_sunau test_sundry
    test_super test_support test_symbol test_syntax test_sys
    test_sys_settrace test_sysconfig test_syslog test_tabnanny
    test_tarfile test_tcl test_telnetlib test_textwrap test_thread
    test_threaded_import test_threadedtempfile test_threading
    test_threading_local test_threadsignals test_time test_tix test_tk
    test_tokenize test_tools test_trace test_traceback
    test_tracemalloc test_ttk_guionly test_ttk_textonly test_turtle
    test_type_comments test_typechecks test_typing test_ucn test_unary
    test_unicode test_unicode_file test_unicode_identifiers
    test_unicodedata test_unittest test_univnewlines test_unpack
    test_unpack_ex test_urllib test_urllib2 test_urllib2_localnet
    test_urllib2net test_urllib_response test_urllibnet test_urlparse
    test_userdict test_userlist test_userstring test_utf8_mode
    test_utf8source test_uu test_venv test_wait3 test_wait4
    test_warnings test_wave test_weakref test_weakset test_webbrowser
    test_winreg test_winsound test_with test_wsgiref test_xdrlib
    test_xml_etree test_xml_etree_c test_xmlrpc test_xmlrpc_net
    test_xxtestfuzz test_yield_from test_zipapp test_zipfile
    test_zipfile64 test_zipimport test_zipimport_support test_zlib

50 tests OK.

2 tests failed:
    test_hashlib test_timeit

2 tests skipped:
    test_msilib test_winconsoleio
0:04:25 load avg: 2.89
0:04:25 load avg: 2.89 Re-running failed tests in verbose mode
0:04:25 load avg: 2.89 Re-running test_hashlib in verbose mode
test_algorithms_available (test.test_hashlib.HashLibTestCase) ... ok
test_algorithms_guaranteed (test.test_hashlib.HashLibTestCase) ... ok
test_blake2b (test.test_hashlib.HashLibTestCase) ... Fatal Python error: Bus error

Current thread 0x0000000000000001 (most recent call first):
  File "/usr/local/build/Python-3.8.1/Lib/test/test_hashlib.py", line 570 in check_blake2
  File "/usr/local/build/Python-3.8.1/Lib/test/test_hashlib.py", line 647 in test_blake2b
  File "/usr/local/build/Python-3.8.1/Lib/unittest/case.py", line 633 in _callTestMethod
  File "/usr/local/build/Python-3.8.1/Lib/unittest/case.py", line 676 in run
  File "/usr/local/build/Python-3.8.1/Lib/unittest/case.py", line 736 in __call__
  File "/usr/local/build/Python-3.8.1/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/build/Python-3.8.1/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/build/Python-3.8.1/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/build/Python-3.8.1/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/build/Python-3.8.1/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/build/Python-3.8.1/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/build/Python-3.8.1/Lib/unittest/runner.py", line 176 in run
  File "/usr/local/build/Python-3.8.1/Lib/test/support/__init__.py", line 2030 in _run_suite
  File "/usr/local/build/Python-3.8.1/Lib/test/support/__init__.py", line 2126 in run_unittest
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/main.py", line 691 in _main
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/main.py", line 634 in main
  File "/usr/local/build/Python-3.8.1/Lib/test/libregrtest/main.py", line 712 in main
  File "/usr/local/build/Python-3.8.1/Lib/test/__main__.py", line 2 in <module>
  File "/usr/local/build/Python-3.8.1/Lib/runpy.py", line 86 in _run_code
  File "/usr/local/build/Python-3.8.1/Lib/runpy.py", line 193 in _run_module_as_main
Bus Error - core dumped
gmake: *** [Makefile:1130: test] Error 138
alpha$ 
alpha$ LD_LIBRARY_PATH=`pwd` dbx ./python time_1582294871-pid_2858-uid_16411-gid_20002-fid_python.per-process-core
Reading python
core file header read successfully
Reading ld.so.1
Reading libpython3.8d.so.1.0
Reading libsocket.so.1
Reading libnsl.so.1
Reading libintl.so.8.1.6
Reading librt.so.1
Reading libdl.so.1
Reading libsendfile.so.1
Reading libm.so.2
Reading libc.so.1
Reading libiconv.so.2.6.1
Reading libaio.so.1
Reading libmd.so.1
Reading libc_psr.so.1
Reading en_US.UTF-8.so.3
Reading methods_unicode.so.3
Reading _heapq.so
Reading zlib.so
Reading libz.so.1.2.11
Reading libmp.so.2
Reading libscf.so.1
Reading libdoor.so.1
Reading libuutil.so.1
Reading libgen.so.1
Reading _bz2.so
Reading _lzma.so
Reading liblzma.so.5.2.4
Reading libpthread.so.1
Reading grp.so
Reading _socket.so
Reading math.so
Reading select.so
Reading _posixsubprocess.so
Reading _ssl.so
Reading libssl.so.1.1
Reading libcrypto.so.1.1
Reading _struct.so
Reading binascii.so
Reading _opcode.so
Reading _contextvars.so
Reading _asyncio.so
Reading _hashlib.so
Reading _blake2.so
Reading _sha3.so
Reading _pickle.so
Reading _queue.so
Reading _datetime.so
Reading _bisect.so
Reading _sha512.so
Reading _random.so
Reading _elementtree.so
Reading pyexpat.so
Reading array.so
Reading resource.so
Reading _multiprocessing.so
Reading _json.so
Reading _md5.so
Reading _sha1.so
Reading _sha256.so
t at 1 (l at 1) program terminated by signal BUS (Bus Error)
0xffffffff7d3dccbc: __lwp_kill+0x0008:  bcc,a,pt  %icc,__lwp_kill+0x18  ! 0xffffffff7d3dcccc
Current function is faulthandler_fatal_error
  361       raise(signum);
(dbx) where                                                                                                                      
current thread: t at 1
  [1] __lwp_kill(0x0, 0xa, 0x10010bc20, 0xffffffff7e9c2190, 0xffffffff7d700200, 0x0), at 0xffffffff7d3dccbc 
  [2] raise(0xa, 0xffffffff7d54f7b4, 0x0, 0xffffffff7ea8f985, 0xa, 0x80808080), at 0xffffffff7d3744d4 
=>[3] faulthandler_fatal_error(signum = 10), line 361 in "faulthandler.c"
  [4] __sighndlr(0xa, 0x0, 0x10015a020, 0xffffffff7e9c1f30, 0x0, 0x0), at 0xffffffff7d3d8d6c 
  ---- called from signal handler with signal 10 (SIGBUS) ------
  [5] blake2b_increment_counter(S = 0xffffffff7ffc304a, inc = 0), line 77 in "blake2b-ref.c"
  [6] PyBlake2_blake2b_final(S = 0xffffffff7ffc304a, out = 0xffffffff7ffc31b0 "????w??
 ????w??^P????wq\x9b?????|P", outlen = 64U), line 339 in "blake2b-ref.c"
  [7] _blake2_blake2b_hexdigest_impl(self = 0xffffffff71535220), line 332 in "blake2b_impl.c"
  [8] _blake2_blake2b_hexdigest(self = 0xffffffff71535220, _unused_ignored = (nil)), line 262 in "blake2b_impl.c.h"
  [9] method_vectorcall_NOARGS(func = 0xffffffff77a1e830, args = 0x10046a118, nargsf = 9223372036854775809U, kwnames = (nil)), line 393 in "descrobject.c"
  [10] _PyObject_Vectorcall(callable = 0xffffffff77a1e830, args = 0x10046a118, nargsf = 9223372036854775809U, kwnames = (nil)), line 127 in "abstract.h"
  [11] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffc5000, oparg = 1, kwnames = (nil)), line 4987 in "ceval.c"
  [12] _PyEval_EvalFrameDefault(f = 0x100469f40, throwflag = 0), line 3486 in "ceval.c"
  [13] PyEval_EvalFrameEx(f = 0x100469f40, throwflag = 0), line 741 in "ceval.c"
  [14] function_code_fastcall(co = 0xffffffff72d19ee0, args = 0xffffffff715327e0, nargs = 7, globals = 0xffffffff72d03bf0), line 283 in "call.c"
  [15] _PyFunction_Vectorcall(func = 0xffffffff72b12190, stack = 0xffffffff715327a8, nargsf = 9223372036854775815U, kwnames = (nil)), line 410 in "call.c"
  [16] _PyObject_Vectorcall(callable = 0xffffffff72b12190, args = 0xffffffff715327a8, nargsf = 9223372036854775815U, kwnames = (nil)), line 127 in "abstract.h"
  [17] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffc7130, oparg = 7, kwnames = (nil)), line 4987 in "ceval.c"
  [18] _PyEval_EvalFrameDefault(f = 0xffffffff71532620, throwflag = 0), line 3486 in "ceval.c"
  [19] PyEval_EvalFrameEx(f = 0xffffffff71532620, throwflag = 0), line 741 in "ceval.c"
  [20] function_code_fastcall(co = 0xffffffff72d0b1e0, args = 0xffffffff7152fbf0, nargs = 1, globals = 0xffffffff72d03bf0), line 283 in "call.c"
  [21] _PyFunction_Vectorcall(func = 0xffffffff72b122d0, stack = 0xffffffff7152fbe8, nargsf = 1U, kwnames = (nil)), line 410 in "call.c"
  [22] _PyObject_Vectorcall(callable = 0xffffffff72b122d0, args = 0xffffffff7152fbe8, nargsf = 1U, kwnames = (nil)), line 127 in "abstract.h"
  [23] method_vectorcall(method = 0xffffffff72805650, args = 0xffffffff7152fbf0, nargsf = 9223372036854775808U, kwnames = (nil)), line 60 in "classobject.c"
  [24] _PyObject_Vectorcall(callable = 0xffffffff72805650, args = 0xffffffff7152fbf0, nargsf = 9223372036854775808U, kwnames = (nil)), line 127 in "abstract.h"
  [25] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffc94e0, oparg = 0, kwnames = (nil)), line 4987 in "ceval.c"
  [26] _PyEval_EvalFrameDefault(f = 0xffffffff7152fa70, throwflag = 0), line 3500 in "ceval.c"
  [27] PyEval_EvalFrameEx(f = 0xffffffff7152fa70, throwflag = 0), line 741 in "ceval.c"
  [28] function_code_fastcall(co = 0xffffffff73915520, args = 0x10048e990, nargs = 2, globals = 0xffffffff73902290), line 283 in "call.c"
  [29] _PyFunction_Vectorcall(func = 0xffffffff73816730, stack = 0x10048e980, nargsf = 9223372036854775810U, kwnames = (nil)), line 410 in "call.c"
  [30] _PyObject_Vectorcall(callable = 0xffffffff73816730, args = 0x10048e980, nargsf = 9223372036854775810U, kwnames = (nil)), line 127 in "abstract.h"
  [31] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffcb610, oparg = 2, kwnames = (nil)), line 4987 in "ceval.c"
  [32] _PyEval_EvalFrameDefault(f = 0x10048e7a0, throwflag = 0), line 3486 in "ceval.c"
  [33] PyEval_EvalFrameEx(f = 0x10048e7a0, throwflag = 0), line 741 in "ceval.c"
  [34] _PyEval_EvalCodeWithName(_co = 0xffffffff73915790, globals = 0xffffffff73902290, locals = (nil), args = 0xffffffff7ffcbf30, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffcbf40, kwcount = 0, kwstep = 1, defs = 0xffffffff7391e838, defcount = 1, kwdefs = (nil), closure = (nil), name = 0xffffffff7c412450, qualname = 0xffffffff73914d60), line 4298 in "ceval.c"
  [35] _PyFunction_Vectorcall(func = 0xffffffff73816910, stack = 0xffffffff7ffcbf30, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [36] _PyObject_Vectorcall(callable = 0xffffffff73816910, args = 0xffffffff7ffcbf30, nargsf = 2U, kwnames = (nil)), line 127 in "abstract.h"
  [37] method_vectorcall(method = 0xffffffff7b5162f0, args = 0xffffffff72b0a068, nargsf = 1U, kwnames = (nil)), line 89 in "classobject.c"
  [38] PyVectorcall_Call(callable = 0xffffffff7b5162f0, tuple = 0xffffffff72b0a050, kwargs = 0xffffffff72b16050), line 199 in "call.c"
  [39] PyObject_Call(callable = 0xffffffff7b5162f0, args = 0xffffffff72b0a050, kwargs = 0xffffffff72b16050), line 227 in "call.c"
  [40] do_call_core(tstate = 0x10010bc20, func = 0xffffffff7b5162f0, callargs = 0xffffffff72b0a050, kwdict = 0xffffffff72b16050), line 5034 in "ceval.c"
  [41] _PyEval_EvalFrameDefault(f = 0xffffffff71531220, throwflag = 0), line 3559 in "ceval.c"
  [42] PyEval_EvalFrameEx(f = 0xffffffff71531220, throwflag = 0), line 741 in "ceval.c"
  [43] _PyEval_EvalCodeWithName(_co = 0xffffffff73915a00, globals = 0xffffffff73902290, locals = (nil), args = 0xffffffff7ffce700, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffce710, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0xffffffff7c501340, qualname = 0xffffffff73914f40), line 4298 in "ceval.c"
  [44] _PyFunction_Vectorcall(func = 0xffffffff73816af0, stack = 0xffffffff7ffce700, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [45] _PyObject_FastCallDict(callable = 0xffffffff73816af0, args = 0xffffffff7ffce700, nargsf = 2U, kwargs = (nil)), line 96 in "call.c"
  [46] _PyObject_Call_Prepend(callable = 0xffffffff73816af0, obj = 0xffffffff72b175a0, args = 0xffffffff72b0a4b0, kwargs = (nil)), line 889 in "call.c"
  [47] slot_tp_call(self = 0xffffffff72b175a0, args = 0xffffffff72b0a4b0, kwds = (nil)), line 6521 in "typeobject.c"
  [48] _PyObject_MakeTpCall(callable = 0xffffffff72b175a0, args = 0xffffffff7152ed98, nargs = 1, keywords = (nil)), line 159 in "call.c"
  [49] _PyObject_Vectorcall(callable = 0xffffffff72b175a0, args = 0xffffffff7152ed98, nargsf = 9223372036854775809U, kwnames = (nil)), line 125 in "abstract.h"
  [50] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffd05a0, oparg = 1, kwnames = (nil)), line 4987 in "ceval.c"
  [51] _PyEval_EvalFrameDefault(f = 0xffffffff7152ebf0, throwflag = 0), line 3500 in "ceval.c"
  [52] PyEval_EvalFrameEx(f = 0xffffffff7152ebf0, throwflag = 0), line 741 in "ceval.c"
  [53] _PyEval_EvalCodeWithName(_co = 0xffffffff73926930, globals = 0xffffffff739020b0, locals = (nil), args = 0xffffffff7ffd0ec0, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffd0ed0, kwcount = 0, kwstep = 1, defs = 0xffffffff738198d8, defcount = 1, kwdefs = (nil), closure = (nil), name = 0xffffffff7c412450, qualname = 0xffffffff7381adc0), line 4298 in "ceval.c"
  [54] _PyFunction_Vectorcall(func = 0xffffffff7381cb90, stack = 0xffffffff7ffd0ec0, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [55] _PyObject_Vectorcall(callable = 0xffffffff7381cb90, args = 0xffffffff7ffd0ec0, nargsf = 2U, kwnames = (nil)), line 127 in "abstract.h"
  [56] method_vectorcall(method = 0xffffffff79c0d6b0, args = 0xffffffff72616108, nargsf = 1U, kwnames = (nil)), line 89 in "classobject.c"
  [57] PyVectorcall_Call(callable = 0xffffffff79c0d6b0, tuple = 0xffffffff726160f0, kwargs = 0xffffffff7152acb0), line 199 in "call.c"
  [58] PyObject_Call(callable = 0xffffffff79c0d6b0, args = 0xffffffff726160f0, kwargs = 0xffffffff7152acb0), line 227 in "call.c"
  [59] do_call_core(tstate = 0x10010bc20, func = 0xffffffff79c0d6b0, callargs = 0xffffffff726160f0, kwdict = 0xffffffff7152acb0), line 5034 in "ceval.c"
  [60] _PyEval_EvalFrameDefault(f = 0xffffffff72822d00, throwflag = 0), line 3559 in "ceval.c"
  [61] PyEval_EvalFrameEx(f = 0xffffffff72822d00, throwflag = 0), line 741 in "ceval.c"
  [62] _PyEval_EvalCodeWithName(_co = 0xffffffff7390ce10, globals = 0xffffffff739020b0, locals = (nil), args = 0xffffffff7ffd3690, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffd36a0, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0xffffffff7c501340, qualname = 0xffffffff7381aa60), line 4298 in "ceval.c"
  [63] _PyFunction_Vectorcall(func = 0xffffffff7381ca50, stack = 0xffffffff7ffd3690, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [64] _PyObject_FastCallDict(callable = 0xffffffff7381ca50, args = 0xffffffff7ffd3690, nargsf = 2U, kwargs = (nil)), line 96 in "call.c"
  [65] _PyObject_Call_Prepend(callable = 0xffffffff7381ca50, obj = 0xffffffff72b0aaa0, args = 0xffffffff76e21dc0, kwargs = (nil)), line 889 in "call.c"
  [66] slot_tp_call(self = 0xffffffff72b0aaa0, args = 0xffffffff76e21dc0, kwds = (nil)), line 6521 in "typeobject.c"
  [67] _PyObject_MakeTpCall(callable = 0xffffffff72b0aaa0, args = 0xffffffff7152eba8, nargs = 1, keywords = (nil)), line 159 in "call.c"
  [68] _PyObject_Vectorcall(callable = 0xffffffff72b0aaa0, args = 0xffffffff7152eba8, nargsf = 9223372036854775809U, kwnames = (nil)), line 125 in "abstract.h"
  [69] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffd5530, oparg = 1, kwnames = (nil)), line 4987 in "ceval.c"
  [70] _PyEval_EvalFrameDefault(f = 0xffffffff7152ea00, throwflag = 0), line 3500 in "ceval.c"
  [71] PyEval_EvalFrameEx(f = 0xffffffff7152ea00, throwflag = 0), line 741 in "ceval.c"
  [72] _PyEval_EvalCodeWithName(_co = 0xffffffff73926930, globals = 0xffffffff739020b0, locals = (nil), args = 0xffffffff7ffd5e50, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffd5e60, kwcount = 0, kwstep = 1, defs = 0xffffffff738198d8, defcount = 1, kwdefs = (nil), closure = (nil), name = 0xffffffff7c412450, qualname = 0xffffffff7381adc0), line 4298 in "ceval.c"
  [73] _PyFunction_Vectorcall(func = 0xffffffff7381cb90, stack = 0xffffffff7ffd5e50, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [74] _PyObject_Vectorcall(callable = 0xffffffff7381cb90, args = 0xffffffff7ffd5e50, nargsf = 2U, kwnames = (nil)), line 127 in "abstract.h"
  [75] method_vectorcall(method = 0xffffffff72c18410, args = 0xffffffff77c16978, nargsf = 1U, kwnames = (nil)), line 89 in "classobject.c"
  [76] PyVectorcall_Call(callable = 0xffffffff72c18410, tuple = 0xffffffff77c16960, kwargs = 0xffffffff7152abf0), line 199 in "call.c"
  [77] PyObject_Call(callable = 0xffffffff72c18410, args = 0xffffffff77c16960, kwargs = 0xffffffff7152abf0), line 227 in "call.c"
  [78] do_call_core(tstate = 0x10010bc20, func = 0xffffffff72c18410, callargs = 0xffffffff77c16960, kwdict = 0xffffffff7152abf0), line 5034 in "ceval.c"
  [79] _PyEval_EvalFrameDefault(f = 0xffffffff72822b30, throwflag = 0), line 3559 in "ceval.c"
  [80] PyEval_EvalFrameEx(f = 0xffffffff72822b30, throwflag = 0), line 741 in "ceval.c"
  [81] _PyEval_EvalCodeWithName(_co = 0xffffffff7390ce10, globals = 0xffffffff739020b0, locals = (nil), args = 0xffffffff7ffd8620, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffd8630, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0xffffffff7c501340, qualname = 0xffffffff7381aa60), line 4298 in "ceval.c"
  [82] _PyFunction_Vectorcall(func = 0xffffffff7381ca50, stack = 0xffffffff7ffd8620, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [83] _PyObject_FastCallDict(callable = 0xffffffff7381ca50, args = 0xffffffff7ffd8620, nargsf = 2U, kwargs = (nil)), line 96 in "call.c"
  [84] _PyObject_Call_Prepend(callable = 0xffffffff7381ca50, obj = 0xffffffff78e17280, args = 0xffffffff77d30230, kwargs = (nil)), line 889 in "call.c"
  [85] slot_tp_call(self = 0xffffffff78e17280, args = 0xffffffff77d30230, kwds = (nil)), line 6521 in "typeobject.c"
  [86] _PyObject_MakeTpCall(callable = 0xffffffff78e17280, args = 0xffffffff7152e9b8, nargs = 1, keywords = (nil)), line 159 in "call.c"
  [87] _PyObject_Vectorcall(callable = 0xffffffff78e17280, args = 0xffffffff7152e9b8, nargsf = 9223372036854775809U, kwnames = (nil)), line 125 in "abstract.h"
  [88] call_function(tstate = 0x10010bc20, pp_stack = 0xffffffff7ffda4c0, oparg = 1, kwnames = (nil)), line 4987 in "ceval.c"
  [89] _PyEval_EvalFrameDefault(f = 0xffffffff7152e810, throwflag = 0), line 3500 in "ceval.c"
  [90] PyEval_EvalFrameEx(f = 0xffffffff7152e810, throwflag = 0), line 741 in "ceval.c"
  [91] _PyEval_EvalCodeWithName(_co = 0xffffffff73926930, globals = 0xffffffff739020b0, locals = (nil), args = 0xffffffff7ffdade0, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffdadf0, kwcount = 0, kwstep = 1, defs = 0xffffffff738198d8, defcount = 1, kwdefs = (nil), closure = (nil), name = 0xffffffff7c412450, qualname = 0xffffffff7381adc0), line 4298 in "ceval.c"
  [92] _PyFunction_Vectorcall(func = 0xffffffff7381cb90, stack = 0xffffffff7ffdade0, nargsf = 2U, kwnames = (nil)), line 441 in "call.c"
  [93] _PyObject_Vectorcall(callable = 0xffffffff7381cb90, args = 0xffffffff7ffdade0, nargsf = 2U, kwnames = (nil)), line 127 in "abstract.h"
  [94] method_vectorcall(method = 0xffffffff76d07c50, args = 0xffffffff76e27ec8, nargsf = 1U, kwnames = (nil)), line 89 in "classobject.c"
  [95] PyVectorcall_Call(callable = 0xffffffff76d07c50, tuple = 0xffffffff76e27eb0, kwargs = 0xffffffff7152ab30), line 199 in "call.c"
  [96] PyObject_Call(callable = 0xffffffff76d07c50, args = 0xffffffff76e27eb0, kwargs = 0xffffffff7152ab30), line 227 in "call.c"
  [97] do_call_core(tstate = 0x10010bc20, func = 0xffffffff76d07c50, callargs = 0xffffffff76e27eb0, kwdict = 0xffffffff7152ab30), line 5034 in "ceval.c"
  [98] _PyEval_EvalFrameDefault(f = 0xffffffff72822960, throwflag = 0), line 3559 in "ceval.c"
  [99] PyEval_EvalFrameEx(f = 0xffffffff72822960, throwflag = 0), line 741 in "ceval.c"
  [100] _PyEval_EvalCodeWithName(_co = 0xffffffff7390ce10, globals = 0xffffffff739020b0, locals = (nil), args = 0xffffffff7ffdd5b0, argcount = 2, kwnames = (nil), kwargs = 0xffffffff7ffdd5c0, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0xffffffff7c501340, qualname = 0xffffffff7381aa60), line 4298 in "ceval.c"
(dbx) regs
current thread: t at 1
current frame:  [3]
g0-g1    0x0000000000000000 0x00000000000000a3
g2-g3    0x0000000000000000 0x0000000000000000
g4-g5    0xffffffff7e9c1f30 0xffffffffff7fffff
g6-g7    0x0000000000000000 0xffffffff7d700200
o0-o1    0x000000000000000a 0xffffffff7d54f7b4
o2-o3    0x0000000000000000 0xffffffff7ea8f985
o4-o5    0x000000000000000a 0x0000000080808080
o6-o7    0x00000001001593d1 0xffffffff7e9c2190
l0-l1    0xffffffff7eb915d8 0x0000000000000000
l2-l3    0x0000000000000000 0x0000000000000000
l4-l5    0x0000000000000000 0x0000000000000000
l6-l7    0x0000000000000000 0x0000000000000000
i0-i1    0x000000000000000a 0x0000000000000000
i2-i3    0x000000010015a020 0x0000000040000000
i4-i5    0xcdcdcdcdcdcdcdcd 0xcdcdcdcdcdcdcdcd
i6-i7    0x00000001001594d1 0xffffffff7d3d8d6c
y        0x0000000000000000
ccr      0x0000000000000098
pc       0xffffffff7e9c2190:faulthandler_fatal_error+0x260    call     _PROCEDURE_LINKAGE_TABLE_+0xc440 [PLT]   ! 0xffffffff7eba5440
npc      0xffffffff7d3dccc0:__lwp_kill+0xc    clr      %o0
(dbx) quit
alpha$ 

At this time version 3.8.1 looks to not be portable to big endian risc 
architectures such as Solaris 10 on Fujitsu SPARC-VII+ and perhaps other
systems. I can try on IBM 64-bit Power with FreeBSD and see what happens.

----------
components: Tests
messages: 362411
nosy: blastwave
priority: normal
severity: normal
status: open
title: SIGBUS and core dumped during tests of 3.8.1
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39711>
_______________________________________

From report at bugs.python.org  Fri Feb 21 11:16:33 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 21 Feb 2020 16:16:33 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582301793.77.0.811165358595.issue39704@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Also just to clarify, the actual coverage build which measures the build. That is:

https://github.com/python/cpython/blob/d4d17fd2cf69e7c8f4cd03fbf2d575370945b952/.travis.yml#L75-L114

is fine. The build succeeds and the coverage can be seen online at https://codecov.io/gh/python/cpython to get a high-level overview of coverage.

The integration with codecov as a status check and it's comments are the real nuisance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 21 11:55:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 16:55:49 +0000
Subject: [issue39707] Abstract property setter/deleter implementation not
 enforced.
In-Reply-To: <1582282750.75.0.718234610951.issue39707@roundup.psfhosted.org>
Message-ID: <1582304149.64.0.504332247328.issue39707@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Off-hand, I don't see how this can be easily fixed because the setters and deleters are all part of a single property object.  

When the subclass defines a property without a getter and setter, the inherited abstract property (that does have a getter and setter) is masked.

Right now, ABCMeta only looks at the concrete property.  It would have to be modified to scan the next in MRO for an abstract property and the pick apart its component fget, fset, and fdel.  That would be a significant jump in complexity with only a minimal payoff.

----------
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39707>
_______________________________________

From report at bugs.python.org  Fri Feb 21 11:57:39 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 21 Feb 2020 16:57:39 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
Message-ID: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

In the doc for `-X` options (https://docs.python.org/3/using/cmdline.html#id5), when an option can be triggered through an equivalent environment variable, that variable is mentioned.

An exception to that is `-X dev`, which can also be triggered by the PYTHONDEVMODE variable, but that isn't mentioned in the CLI doc.

Other missing environment variables in the CLI doc are PYTHONFAULTHANDLER and PYTHONTRACEMALLOC.

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 362414
nosy: docs at python, eric.araujo, ezio.melotti, mdk, pitrou, vstinner, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc for `-X dev` option should mention PYTHONDEVMODE
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Fri Feb 21 12:00:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 17:00:16 +0000
Subject: [issue39705] Tutorial, 5.6 Looping Techniques, sorted() example
In-Reply-To: <1582277071.44.0.766763125418.issue39705@roundup.psfhosted.org>
Message-ID: <1582304416.23.0.438118759181.issue39705@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I prefer to keep the example as-is.  It is an idiomatic way to loop over sets.  The introductory text can be modified to explain that sets eliminate duplicates, that sets are ordered, and that sorted() puts them back in a deterministic order.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39705>
_______________________________________

From report at bugs.python.org  Fri Feb 21 12:43:03 2020
From: report at bugs.python.org (Ananth Vijalapuram)
Date: Fri, 21 Feb 2020 17:43:03 +0000
Subject: [issue39713] ElementTree limitation
Message-ID: <1582306983.7.0.277512488596.issue39713@roundup.psfhosted.org>


New submission from Ananth Vijalapuram <ananthsayan at gmail.com>:

I am trying to parse a very large XML file. Here is the output:

/usr/intel/bin/python3.7.4 crif_parser.py
Retrieved 3593891712 characters <- this is printed from my script
Traceback (most recent call last):
  File "crif_parser.py", line 9, in <module>
    tree = ET.fromstring(data)
  File "/usr/intel/pkgs/python3/3.7.4/lib/python3.7/xml/etree/ElementTree.py", line 1315, in XML
    parser.feed(text)
OverflowError: size does not fit in an int

----------
components: XML
messages: 362416
nosy: Ananth Vijalapuram
priority: normal
severity: normal
status: open
title: ElementTree limitation
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39713>
_______________________________________

From report at bugs.python.org  Fri Feb 21 12:57:21 2020
From: report at bugs.python.org (Ananth Vijalapuram)
Date: Fri, 21 Feb 2020 17:57:21 +0000
Subject: [issue39713] ElementTree limitation
In-Reply-To: <1582306983.7.0.277512488596.issue39713@roundup.psfhosted.org>
Message-ID: <1582307841.74.0.0487124998134.issue39713@roundup.psfhosted.org>


Change by Ananth Vijalapuram <ananthsayan at gmail.com>:


----------
resolution:  -> later
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39713>
_______________________________________

From report at bugs.python.org  Fri Feb 21 12:57:33 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 17:57:33 +0000
Subject: [issue35950] io.BufferedReader.writabe is False,
 but io.BufferedReader.truncate does not raise OSError
In-Reply-To: <1549719382.2.0.923720230511.issue35950@roundup.psfhosted.org>
Message-ID: <1582307853.23.0.144002484287.issue35950@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fd5116c0e77aec05f67fb24f10562ac920648035 by Berker Peksag in branch 'master':
bpo-35950: Raise UnsupportedOperation in BufferedReader.truncate() (GH-18586)
https://github.com/python/cpython/commit/fd5116c0e77aec05f67fb24f10562ac920648035


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35950>
_______________________________________

From report at bugs.python.org  Fri Feb 21 12:59:58 2020
From: report at bugs.python.org (Ananth Vijalapuram)
Date: Fri, 21 Feb 2020 17:59:58 +0000
Subject: [issue39714] ElementTree limitation
Message-ID: <1582307998.92.0.808661201788.issue39714@roundup.psfhosted.org>


New submission from Ananth Vijalapuram <ananthsayan at gmail.com>:

I am trying to parse a very large XML file. Here is the output:

python3.7.4 crif_parser.py
Retrieved 3593891712 characters <- this is printed from my script
Traceback (most recent call last):
  File "crif_parser.py", line 9, in <module>
    tree = ET.fromstring(data)
  File "python3/3.7.4/lib/python3.7/xml/etree/ElementTree.py", line 1315, in XML
    parser.feed(text)
OverflowError: size does not fit in an int

----------
components: XML
messages: 362418
nosy: Ananth Vijalapuram
priority: normal
severity: normal
status: open
title: ElementTree limitation
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39714>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:01:25 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 21 Feb 2020 18:01:25 +0000
Subject: [issue35950] io.BufferedReader.writabe is False,
 but io.BufferedReader.truncate does not raise OSError
In-Reply-To: <1549719382.2.0.923720230511.issue35950@roundup.psfhosted.org>
Message-ID: <1582308085.81.0.424593571029.issue35950@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/issue35950>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:05:03 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 21 Feb 2020 18:05:03 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
Message-ID: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I was playing with the `ast` library today, and it's frustrating to see objects like these:

    [<_ast.Import object at 0x00000000033FB048>,
     <_ast.Import object at 0x00000000033FB0F0>,
     <_ast.ImportFrom object at 0x00000000033FB160>,
     <_ast.Import object at 0x00000000033FB1D0>,
     <_ast.Assign object at 0x00000000033FB240>,
     <_ast.If object at 0x00000000033FB630>]

A little bit more information about each object in the `__repr__` would make this module much easier to work with.

----------
components: Library (Lib)
messages: 362419
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement __repr__ methods for AST classes
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39715>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:05:42 2020
From: report at bugs.python.org (Manjusaka)
Date: Fri, 21 Feb 2020 18:05:42 +0000
Subject: [issue38342] ImportError: cannot import name 'MetadataPathFinder'
 from 'importlib.metadata'
In-Reply-To: <1569968531.94.0.379845933414.issue38342@roundup.psfhosted.org>
Message-ID: <1582308342.82.0.939273730729.issue38342@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

Hello Mariatta

I have tested the code below on 3.8.1 what's installed by pyenv on my Mac 

from importlib.metadata import version, requires, files
version('requests')

it works correctly.

I think it depends on the tool what's used to install python

----------
nosy: +Manjusaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38342>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:20:54 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 21 Feb 2020 18:20:54 +0000
Subject: [issue39716] argparse.ArgumentParser does not raise on duplicated
 subparsers, even though it does on duplicated flags
Message-ID: <1582309254.51.0.588412851994.issue39716@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

If one tries to add twice the same flag to an ArgumentParser, one gets a helpful exception:

    from argparse import ArgumentParser
    p = ArgumentParser()
    p.add_argument("--foo")
    p.add_argument("--foo")

results in

    argparse.ArgumentError: argument --foo: conflicting option string: --foo

However, adding twice the same subparser raises no exception:

    from argparse import ArgumentParser
    p = ArgumentParser()
    sp = p.add_subparsers()
    sp.add_parser("foo")
    sp.add_parser("foo")

even though the two subparsers shadow one another in the same way as two identical flags.

----------
components: Library (Lib)
messages: 362421
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser does not raise on duplicated subparsers, even though it does on duplicated flags
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39716>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:22:02 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 21 Feb 2020 18:22:02 +0000
Subject: [issue39705] Tutorial, 5.6 Looping Techniques, sorted() example
In-Reply-To: <1582277071.44.0.766763125418.issue39705@roundup.psfhosted.org>
Message-ID: <1582309322.1.0.0601845381293.issue39705@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

That sounds like a good improvement, Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39705>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:40:20 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Feb 2020 18:40:20 +0000
Subject: [issue39716] argparse.ArgumentParser does not raise on duplicated
 subparsers, even though it does on duplicated flags
In-Reply-To: <1582309254.51.0.588412851994.issue39716@roundup.psfhosted.org>
Message-ID: <1582310420.93.0.732491301614.issue39716@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/issue39716>
_______________________________________

From report at bugs.python.org  Fri Feb 21 13:41:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Feb 2020 18:41:10 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
In-Reply-To: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>
Message-ID: <1582310470.56.0.617030903248.issue39715@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39715>
_______________________________________

From report at bugs.python.org  Fri Feb 21 14:11:18 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 21 Feb 2020 19:11:18 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
In-Reply-To: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>
Message-ID: <1582312278.22.0.513070940083.issue39715@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

What kind of repr do you have in your mind? If the repr you are thinking contains field information, it would be no-go. Fields of AST objects can contain other objects and fields of that objects can contain more objects (this goes up to the recursion limit where the child can not be no longer calculated). This is why we have ast.dump instead. For small debuggings there are 3rd party libraries (e.g: asteria) which adds __repr__ on runtime for working on nodes, but on a real application this can cause more problem then it benefits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39715>
_______________________________________

From report at bugs.python.org  Fri Feb 21 14:20:01 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 21 Feb 2020 19:20:01 +0000
Subject: [issue39717] Fix exception causes in tarfile module
Message-ID: <1582312801.89.0.445859390391.issue39717@roundup.psfhosted.org>


Change by Ram Rachum <ram at rachum.com>:


----------
components: Library (Lib)
nosy: cool-RR
priority: normal
pull_requests: 17962
severity: normal
status: open
title: Fix exception causes in tarfile module
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 21 14:26:21 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 21 Feb 2020 19:26:21 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
In-Reply-To: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>
Message-ID: <1582313181.26.0.857371445204.issue39715@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

I understand that we have to be really careful in including information that could have unlimited size. But I think we have lots of information that isn't that way.

For example, for ClassDef and FunctionDef objects, we could include the name. For Assign, we could include the lhs. For Import, we could include the module name, etc.

And for all objects, we could include the number of descendants that they have, so people could more easily understand which are tiny and which are huge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39715>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:00:32 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 20:00:32 +0000
Subject: [issue39717] Fix exception causes in tarfile module
Message-ID: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

What do you think it is necessary to switch from implicit chaining to explicit chaining?

If anyone is currently relying on __context__ vs __cause__, this patch will break their code.

In a traceback, the only visible difference is in the text between the exceptions:

- During handling of the above exception, another exception occurred:
+ The above exception was the direct cause of the following exception:

While we haven't been 100% consistent about this, the norm has been to either use implicit chaining or use "from None" to turn-off chaining.  The "from e" approach can be used to alter the explicit chain, perhaps skipping over one or more exceptions, but that isn't the case here.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:01:25 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 20:01:25 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
In-Reply-To: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>
Message-ID: <1582315285.67.0.416059167829.issue39715@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39715>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:27:44 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 20:27:44 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582316864.61.0.166200973473.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset a025d4ca99fb4c652465368e0b4eb03cf4b316b9 by Stefan Krah in branch 'master':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic (#18594)
https://github.com/python/cpython/commit/a025d4ca99fb4c652465368e0b4eb03cf4b316b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:28:14 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 20:28:14 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582316894.15.0.515337174399.issue39576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17963
pull_request: https://github.com/python/cpython/pull/18596

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:28:25 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Feb 2020 20:28:25 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582316905.33.0.478826061618.issue39576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17964
pull_request: https://github.com/python/cpython/pull/18597

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:28:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 20:28:49 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582316929.71.0.79543808677.issue39717@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If this were new code, there would be a better case for the direct-cause style even though it is more cluttered and a bit slower.

I'm only questioning whether it make sense to change it in already deployed code, possibly risking breakage.  AFAICT, nothing is currently broken and the minor change in traceback wording would not confer a real benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:34:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 20:34:23 +0000
Subject: [issue39716] argparse.ArgumentParser does not raise on duplicated
 subparsers, even though it does on duplicated flags
In-Reply-To: <1582309254.51.0.588412851994.issue39716@roundup.psfhosted.org>
Message-ID: <1582317263.25.0.570051674731.issue39716@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Would you like to work-up a patch to fix this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39716>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:36:05 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 20:36:05 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582317365.92.0.633231346759.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 00e45877e33d32bb61aa13a2033e3bba370bda4d by Miss Islington (bot) in branch '3.7':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic (GH-18594) (#18596)
https://github.com/python/cpython/commit/00e45877e33d32bb61aa13a2033e3bba370bda4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:36:46 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 20:36:46 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582317406.38.0.84107960512.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset d6965ff026f35498e554bc964ef2be8f4d80eb7f by Miss Islington (bot) in branch '3.8':
bpo-39576: docs: set context for decimal arbitrary precision arithmetic (GH-18594) (#18597)
https://github.com/python/cpython/commit/d6965ff026f35498e554bc964ef2be8f4d80eb7f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:46:11 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 21 Feb 2020 20:46:11 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582317971.52.0.698907964593.issue39717@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

> What do you think it is necessary to switch from implicit chaining to explicit chaining?

I didn't say it's necessary, but I think it's beneficial. I find that message between exceptions useful when I'm debugging and I'd like to keep it accurate in as many places as I can. 

I think that the more accurate it is, the more people will learn to trust that it has meaning and understand it. 

> If anyone is currently relying on __context__ vs __cause__, this patch will break their code.

I think that the standard you're setting for backward compatibility is unreasonably high.

The only code I can think of that inspects `__context__` and `__cause__` is code that formats exceptions to be shown to the user, such as Django's debug page, Wing IDE's Exceptions pane, whatever's going on in PyCharm etc. That kind of code is responsible for checking for both `__context__` and `__cause__` and showing the correct message.

If you've seen code outside of the category above that uses `__context__`, I'd be curious to see it.

Fortunately, this point is moot since using `raise foo from bar` sets the `__context__ = __cause__ = bar`, so the `__context__` will not be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:47:25 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 20:47:25 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582318045.7.0.854444051135.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

libmpdec and the docs are done, the question remains what to do with
decimal.py.

It has the same behavior, but I don't think users are running
decimal.py with very large precisions.


Anyway, unassigning myself in case anyone else wants to work on a patch.

----------
assignee: skrah -> 
resolution:  -> fixed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 15:50:15 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 21 Feb 2020 20:50:15 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582318215.91.0.121264026032.issue39576@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 16:02:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Feb 2020 21:02:12 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
In-Reply-To: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>
Message-ID: <1582318932.2.0.927047840761.issue39715@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For more informative representation you can use ast.dump().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39715>
_______________________________________

From report at bugs.python.org  Fri Feb 21 16:21:43 2020
From: report at bugs.python.org (Viktor Roytman)
Date: Fri, 21 Feb 2020 21:21:43 +0000
Subject: [issue39679] functools: singledispatchmethod doesn't work with
 classmethod
In-Reply-To: <1582053375.25.0.178240077179.issue39679@roundup.psfhosted.org>
Message-ID: <1582320103.6.0.588155685636.issue39679@roundup.psfhosted.org>


Viktor Roytman <viktor.roytman at gmail.com> added the comment:

I tried to apply this change but it didn't work, failing with this error

    $ ~/.pyenv/versions/3.8.1/bin/python -m bad_classmethod_as_documented
    Traceback (most recent call last):
      File "/home/viktor/.pyenv/versions/3.8.1/lib/python3.8/runpy.py", line 193, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/home/viktor/.pyenv/versions/3.8.1/lib/python3.8/runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "/home/viktor/scratch/bad_classmethod_as_documented.py", line 4, in <module>
        class Negator:
      File "/home/viktor/scratch/bad_classmethod_as_documented.py", line 12, in Negator
        def _(cls, arg: int):
      File "/home/viktor/.pyenv/versions/3.8.1/lib/python3.8/functools.py", line 1006, in register
        return self.dispatcher.register(cls, func=method)
      File "/home/viktor/.pyenv/versions/3.8.1/lib/python3.8/functools.py", line 959, in register
        argname, cls = next(iter(get_type_hints(func).items()))
      File "/home/viktor/.pyenv/versions/3.8.1/lib/python3.8/typing.py", line 1252, in get_type_hints
        raise TypeError('{!r} is not a module, class, method, '
    TypeError: <classmethod object at 0x7f84e1e69c40> is not a module, class, method, or function.

After digging around a bit, this diff seems to work (not sure if there's a better way to do it) (also this one doesn't seem to care whether @staticmethod is applied to the implementation methods):

$ diff -u functools-orig.py functools.py
--- functools-orig.py	2020-02-21 16:14:56.141934001 -0500
+++ functools.py	2020-02-21 16:17:19.959905849 -0500
@@ -843,14 +843,18 @@
         if func is None:
             if isinstance(cls, type):
                 return lambda f: register(cls, f)
-            ann = getattr(cls, '__annotations__', {})
+            if isinstance(cls, (classmethod, staticmethod)):
+                ann = getattr(cls.__func__, '__annotations__', {})
+                func = cls.__func__
+            else:
+                ann = getattr(cls, '__annotations__', {})
+                func = cls
             if not ann:
                 raise TypeError(
                     f"Invalid first argument to `register()`: {cls!r}. "
                     f"Use either `@register(some_class)` or plain `@register` "
                     f"on an annotated function."
                 )
-            func = cls
 
             # only import typing if annotation parsing is necessary
             from typing import get_type_hints
@@ -908,6 +912,8 @@
     def __get__(self, obj, cls=None):
         def _method(*args, **kwargs):
             method = self.dispatcher.dispatch(args[0].__class__)
+            if isinstance(self.func, classmethod):
+                return method.__get__(obj, cls)(cls, *args, **kwargs)
             return method.__get__(obj, cls)(*args, **kwargs)
 
         _method.__isabstractmethod__ = self.__isabstractmethod__

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39679>
_______________________________________

From report at bugs.python.org  Fri Feb 21 16:38:17 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 21 Feb 2020 21:38:17 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582321097.64.0.991532866975.issue39576@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Thanks, Stefan!  This turned out better than I expected ;-)

I'm closing the report, under the likely assumption that nobody cares enough about obscure inelegancies in the Python version to bother.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Fri Feb 21 17:01:40 2020
From: report at bugs.python.org (Shantanu)
Date: Fri, 21 Feb 2020 22:01:40 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
Message-ID: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

Changed in version 3.8 section of https://docs.python.org/3/library/token.html should mention the addition of TYPE_IGNORE and COLONEQUAL

----------
assignee: docs at python
components: Documentation
messages: 362436
nosy: docs at python, hauntsaninja
priority: normal
severity: normal
status: open
title: TYPE_IGNORE, COLONEQUAL missing from py38 changes in token docs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 21 17:02:32 2020
From: report at bugs.python.org (Shantanu)
Date: Fri, 21 Feb 2020 22:02:32 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
In-Reply-To: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>
Message-ID: <1582322552.2.0.760945593363.issue39718@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +17965
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18598

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 21 17:32:08 2020
From: report at bugs.python.org (Shantanu)
Date: Fri, 21 Feb 2020 22:32:08 +0000
Subject: [issue39719] tempfile.SpooledTemporaryFile still has softspace
 property
Message-ID: <1582324328.38.0.787053917409.issue39719@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

The softspace attribute of files was removed in Python 3 (mentioned in https://raw.githubusercontent.com/python/cpython/master/Misc/HISTORY)

However, tempfile.SpooledTemporaryFile still has a softspace property that attempts to return read the softspace attribute.

```
In [23]: t = tempfile.SpooledTemporaryFile()                                    

In [24]: t.softspace                                                            
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-24-72e5af9f6ded> in <module>
----> 1 t.softspace

/usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/tempfile.py in softspace(self)
    749     @property
    750     def softspace(self):
--> 751         return self._file.softspace
    752 
    753     def tell(self):

AttributeError: '_io.BytesIO' object has no attribute 'softspace'
```

----------
messages: 362437
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: tempfile.SpooledTemporaryFile still has softspace property

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39719>
_______________________________________

From report at bugs.python.org  Fri Feb 21 17:33:28 2020
From: report at bugs.python.org (Shantanu)
Date: Fri, 21 Feb 2020 22:33:28 +0000
Subject: [issue39719] tempfile.SpooledTemporaryFile still has softspace
 property
In-Reply-To: <1582324328.38.0.787053917409.issue39719@roundup.psfhosted.org>
Message-ID: <1582324408.54.0.684082726824.issue39719@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +17966
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18599

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39719>
_______________________________________

From report at bugs.python.org  Fri Feb 21 17:37:11 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 21 Feb 2020 22:37:11 +0000
Subject: [issue39707] Abstract property setter/deleter implementation not
 enforced.
In-Reply-To: <1582282750.75.0.718234610951.issue39707@roundup.psfhosted.org>
Message-ID: <1582324631.35.0.302368413493.issue39707@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I agree with Raymond here. This is a job for a static type checker like mypy. Closing.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39707>
_______________________________________

From report at bugs.python.org  Fri Feb 21 17:41:33 2020
From: report at bugs.python.org (Frazer McLean)
Date: Fri, 21 Feb 2020 22:41:33 +0000
Subject: [issue39720] Signature.bind TypeErrors could be more helpful
Message-ID: <1582324893.03.0.384494522706.issue39720@roundup.psfhosted.org>


New submission from Frazer McLean <frazer at frazermclean.co.uk>:

Signature.bind does not tell you if a missing argument is keyword-only for example. I created the following snippet to examine the differences:

    import inspect
    
    def run(f):
        try:
            f()
        except TypeError as exc:
            print(exc.args[0])
        else:
            raise RuntimeError('Expected to raise!')
        sig = inspect.signature(f)
        try:
            sig.bind()
        except TypeError as exc:
            print(exc.args[0])
        else:
            raise RuntimeError('Expected to raise!')
        print()
    
    @run
    def f1(pos_only, /): ...
    
    @run
    def f2(pos_or_kw): ...
    
    @run
    def f3(*, kw_only): ...

Output on current 3.9 master:

    f1() missing 1 required positional argument: 'pos_only'
    missing a required argument: 'pos_only'
    
    f2() missing 1 required positional argument: 'pos_or_kw'
    missing a required argument: 'pos_or_kw'
    
    f3() missing 1 required keyword-only argument: 'kw_only'
    missing a required argument: 'kw_only'

I am willing to create a PR so that the TypeError for f3 says "missing a required keyword-only argument: 'kw_only'", if this would be accepted.

----------
components: Library (Lib)
messages: 362439
nosy: RazerM
priority: normal
severity: normal
status: open
title: Signature.bind TypeErrors could be more helpful
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39720>
_______________________________________

From report at bugs.python.org  Fri Feb 21 18:59:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Feb 2020 23:59:54 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582329594.0.0.512572376261.issue39717@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ethan, would you make the call on this?  My recommendation is to close because we usually don't churn APIs unless there is a demonstrable benefit.  Also, the current code reflects the dominant practice in the standard library which is both faster and more concise.

----------
assignee:  -> ethan.furman
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 21 19:25:34 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 22 Feb 2020 00:25:34 +0000
Subject: [issue39721] Fix constness of members of tok_state struct.
Message-ID: <1582331134.81.0.179748951937.issue39721@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

The function PyTokenizer_FromUTF8 from Parser/tokenizer.c had a comment:

    /* XXX: constify members. */

This patch addresses that.

In the tok_state struct:
    * end and start were non-const but could be made const
    * str and input were const but should have been non-const

Changes to support this include:
    * decode_str() now returns a char * since it is allocated.
    * PyTokenizer_FromString() and PyTokenizer_FromUTF8() each creates a
        new char * for an allocate string instead of reusing the input
        const char *.
    * PyTokenizer_Get() and tok_get() now take const char ** arguments.
    * Various local vars are const or non-const accordingly.

I was able to remove five casts that cast away constness.

----------
components: Interpreter Core
messages: 362441
nosy: petdance
priority: normal
severity: normal
status: open
title: Fix constness of members of tok_state struct.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39721>
_______________________________________

From report at bugs.python.org  Fri Feb 21 19:28:35 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 22 Feb 2020 00:28:35 +0000
Subject: [issue39721] Fix constness of members of tok_state struct.
In-Reply-To: <1582331134.81.0.179748951937.issue39721@roundup.psfhosted.org>
Message-ID: <1582331315.92.0.593905136161.issue39721@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +17967
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18600

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39721>
_______________________________________

From report at bugs.python.org  Fri Feb 21 20:16:11 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Feb 2020 01:16:11 +0000
Subject: [issue39679] functools: singledispatchmethod doesn't work with
 classmethod
In-Reply-To: <1582053375.25.0.178240077179.issue39679@roundup.psfhosted.org>
Message-ID: <1582334171.71.0.866214643048.issue39679@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, I had the part only to detect annotations attached. My part is something similar to yours except it stores the appropriate function in the registry itself instead of passing the arguments at __get__ .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39679>
_______________________________________

From report at bugs.python.org  Fri Feb 21 20:18:00 2020
From: report at bugs.python.org (Shantanu)
Date: Sat, 22 Feb 2020 01:18:00 +0000
Subject: [issue39722] decimal differs between pure Python and C implementations
Message-ID: <1582334280.84.0.579040712908.issue39722@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

The dunder methods on decimal.Decimal accept an extra context argument in the pure Python version which the C version does not (violating PEP 399).

This came up in https://github.com/python/typeshed/pull/3633, where Sebastian provided the following summary of the issue:
```
Python 3.8.1 (default, Jan 14 2020, 19:41:43) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from _decimal import Decimal as CDecimal
>>> from _pydecimal import Decimal as PyDecimal
>>> PyDecimal(1).__abs__(None)
Decimal('1')
>>> CDecimal(1).__abs__(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected 0 arguments, got 1
```

----------
components: Library (Lib)
messages: 362443
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: decimal differs between pure Python and C implementations

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39722>
_______________________________________

From report at bugs.python.org  Fri Feb 21 21:02:36 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Feb 2020 02:02:36 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582336956.89.0.506193413857.issue39717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I know we are not in the habit of making large-scale changes to take advantage of new features and enhancements, but I think this may be one of the few exceptions to the rule, and it has to do with what the text between the two tracebacks means:

-----
"During handling of the above exception, another exception occurred:"

-> there is a bug in the exception handler.
-----

-----
"The above exception was the direct cause of the following exception:"

-> the first error is the cause and the second error is what we want the user to pay attention to.
-----

Whether or not the stdlib is buggy is a pretty big distinction.

If this is a change worth making the follow-on question is should we be raising from the previous exception, or from None?  How much value is the previous exception adding?

In cases where the new exception contains the text of the old one I think `from None` should be preferred; in cases where import errors get translated into CompressionErrors those import errors are sometimes useful and sometimes just noise -- perhaps including `str(e)` in the new exception is the best way there as well.

I'll need to do some research before I decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 21 21:34:55 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Feb 2020 02:34:55 +0000
Subject: [issue39722] decimal differs between pure Python and C implementations
In-Reply-To: <1582334280.84.0.579040712908.issue39722@roundup.psfhosted.org>
Message-ID: <1582338895.61.0.363142530087.issue39722@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39722>
_______________________________________

From report at bugs.python.org  Fri Feb 21 23:44:36 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 22 Feb 2020 04:44:36 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1582346676.59.0.385510616304.issue39573@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +17968
pull_request: https://github.com/python/cpython/pull/18601

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Fri Feb 21 23:45:50 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 22 Feb 2020 04:45:50 +0000
Subject: [issue39573] Make PyObject an opaque structure in the limited C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1582346750.92.0.673916139359.issue39573@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Just added a new PR to finish off the remaining places to use Py_IS_TYPE()

https://github.com/python/cpython/pull/18601

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Sat Feb 22 00:43:48 2020
From: report at bugs.python.org (Shantanu)
Date: Sat, 22 Feb 2020 05:43:48 +0000
Subject: [issue39723] io.open_code should accept PathLike objects
Message-ID: <1582350228.37.0.922225151662.issue39723@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

Currently io.open_code (added in Python 3.8) only accepts str arguments. As per PEP 519, it should probably also accept PathLike. It might be worth extending it to accept bytes as well, both for convenience and because documentation claims it should be interchangeable with ``open(path, 'rb')``.

https://github.com/python/cpython/blob/3.8/Modules/_io/_iomodule.c#L510

----------
components: Library (Lib)
messages: 362446
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: io.open_code should accept PathLike objects
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39723>
_______________________________________

From report at bugs.python.org  Sat Feb 22 00:52:36 2020
From: report at bugs.python.org (Martin Panter)
Date: Sat, 22 Feb 2020 05:52:36 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582350756.03.0.149307878547.issue39717@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Please don?t use ?from None? in library code. It hides exceptions raised by the calling application that would help debugging. E.g. <https://bugs.python.org/issue30097#msg293185>

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Sat Feb 22 01:16:52 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Feb 2020 06:16:52 +0000
Subject: [issue39636] Can't change Treeview row color in Tkinter
In-Reply-To: <1581764507.66.0.693125881903.issue39636@roundup.psfhosted.org>
Message-ID: <1582352212.26.0.64331325155.issue39636@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

What OS, what Python version, what tk version?  For the latter, start IDLE and go to Help - About IDLE.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39636>
_______________________________________

From report at bugs.python.org  Sat Feb 22 01:24:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Feb 2020 06:24:31 +0000
Subject: [issue39653] test_posix fails during make test
In-Reply-To: <1581873332.9.0.500912340754.issue39653@roundup.psfhosted.org>
Message-ID: <1582352671.68.0.0750423606922.issue39653@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

======================================================================
ERROR: test_no_such_executable (test.test_posix.TestPosixSpawnP)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/zachary/Python-3.8.1/Lib/test/test_posix.py", line 1529, in test_no_such_executable
    pid = self.spawn_func(no_such_executable,
NotADirectoryError: [Errno 20] Not a directory: 'no_such_executable'

is all that is needed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39653>
_______________________________________

From report at bugs.python.org  Sat Feb 22 01:33:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Feb 2020 06:33:36 +0000
Subject: [issue39723] io.open_code should accept PathLike objects
In-Reply-To: <1582350228.37.0.922225151662.issue39723@roundup.psfhosted.org>
Message-ID: <1582353216.19.0.524672752788.issue39723@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/issue39723>
_______________________________________

From report at bugs.python.org  Sat Feb 22 01:34:58 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Feb 2020 06:34:58 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582353298.82.0.70388339028.issue39704@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The recently reinstated long 30+ line reports are useless nuisance for me.  I delete them.  A single line line to a report, without flagging, would be OK.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Sat Feb 22 01:54:22 2020
From: report at bugs.python.org (Shantanu)
Date: Sat, 22 Feb 2020 06:54:22 +0000
Subject: [issue39723] io.open_code should accept PathLike objects
In-Reply-To: <1582350228.37.0.922225151662.issue39723@roundup.psfhosted.org>
Message-ID: <1582354462.56.0.26395593072.issue39723@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +17969
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18602

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39723>
_______________________________________

From report at bugs.python.org  Sat Feb 22 02:18:38 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 22 Feb 2020 07:18:38 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582355918.13.0.623417363202.issue39717@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

I'm also strongly against using `from None`. When I'm debugging, I'm like a man who got lost in the desert and is about to die of thirst. Any possible insight into what happened is like an oasis, even if there are just a few drops of water there.

Also, some tools like Django and Sentry show you all the local variables for your stacktraces, which is a godsend. These often have important information that sheds light on what went wrong, and if you remove the traceback they'll be gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Sat Feb 22 02:19:05 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 22 Feb 2020 07:19:05 +0000
Subject: [issue35950] io.BufferedReader.writabe is False,
 but io.BufferedReader.truncate does not raise OSError
In-Reply-To: <1549719382.2.0.923720230511.issue35950@roundup.psfhosted.org>
Message-ID: <1582355945.85.0.0316881472272.issue35950@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35950>
_______________________________________

From report at bugs.python.org  Sat Feb 22 02:30:36 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 22 Feb 2020 07:30:36 +0000
Subject: [issue39721] Fix constness of members of tok_state struct.
In-Reply-To: <1582331134.81.0.179748951937.issue39721@roundup.psfhosted.org>
Message-ID: <1582356636.36.0.998465256323.issue39721@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +serhiy.storchaka, vstinner
type:  -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39721>
_______________________________________

From report at bugs.python.org  Sat Feb 22 02:33:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Feb 2020 07:33:57 +0000
Subject: [issue39722] decimal differs between pure Python and C implementations
In-Reply-To: <1582334280.84.0.579040712908.issue39722@roundup.psfhosted.org>
Message-ID: <1582356837.76.0.731155522427.issue39722@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I wouldn't worry about this.  The context argument for the dunder methods isn't part of the public API.  It is just an internal implementation detail that was necessary for the Python implementation but would make no sense at all for the C implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39722>
_______________________________________

From report at bugs.python.org  Sat Feb 22 02:45:45 2020
From: report at bugs.python.org (Shantanu)
Date: Sat, 22 Feb 2020 07:45:45 +0000
Subject: [issue39722] decimal differs between pure Python and C implementations
In-Reply-To: <1582334280.84.0.579040712908.issue39722@roundup.psfhosted.org>
Message-ID: <1582357545.46.0.922038189876.issue39722@roundup.psfhosted.org>


Shantanu <hauntsaninja at gmail.com> added the comment:

Sounds good, thought I'd check! :-) Definitely looks annoying to remove from the Python version too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39722>
_______________________________________

From report at bugs.python.org  Sat Feb 22 02:57:38 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 22 Feb 2020 07:57:38 +0000
Subject: [issue39722] decimal differs between pure Python and C implementations
In-Reply-To: <1582334280.84.0.579040712908.issue39722@roundup.psfhosted.org>
Message-ID: <1582358258.6.0.575733803324.issue39722@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for double checking.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39722>
_______________________________________

From report at bugs.python.org  Sat Feb 22 03:17:22 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 22 Feb 2020 08:17:22 +0000
Subject: [issue39723] io.open_code should accept PathLike objects
In-Reply-To: <1582350228.37.0.922225151662.issue39723@roundup.psfhosted.org>
Message-ID: <1582359442.93.0.63263814962.issue39723@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +steve.dower
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39723>
_______________________________________

From report at bugs.python.org  Sat Feb 22 04:58:27 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Feb 2020 09:58:27 +0000
Subject: [issue39723] io.open_code should accept PathLike objects
In-Reply-To: <1582350228.37.0.922225151662.issue39723@roundup.psfhosted.org>
Message-ID: <1582365507.85.0.57218592319.issue39723@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to be a duplicate of https://bugs.python.org/issue39691

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39723>
_______________________________________

From report at bugs.python.org  Sat Feb 22 05:29:37 2020
From: report at bugs.python.org (John Smith)
Date: Sat, 22 Feb 2020 10:29:37 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
Message-ID: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>


New submission from John Smith <js5136317 at gmail.com>:

preamble: I am aware that I am not the first to encounter this issue but neither I could identify a preexisting ticket which fully matches nor is the commonly recommended "solution" (stay away from IDLE) satisfying.

environment: win10, python 3.7 (tested with 32 and 64 bit version)

description: If the attached script is started from IDLE the "alive" only shows up once for every input, while the script output "alive" frequently if ran from the terminal with python. So there is a discrepancy between the behavior of IDLE and "plain" python, which can lead to serious "irritations". If the print is replaced with logging.info and the logging is setup to write into a file everything works as expected and equal in both environments.

thoughts: the input call seems to block access to stdout(?) in "IDLE mode". I noticed that there are several topics/post regarding IDLE's stdout/in behavior but I was unabled to find a (convinient) solution besides "just quit using IDLE". It feels strange that the editor bundled with python has such a reputation and features such a deviation in behavior from "plain" python.

----------
assignee: terry.reedy
components: IDLE
messages: 362456
nosy: John Smith, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE threading + stdout/stdin observed blocking behavior
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sat Feb 22 05:54:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 10:54:53 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582368893.39.0.222705522961.issue39648@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry, Ananthakrishnan, but I think this problem is too difficult to you. Adding math.lcm() taken 2 weeks and produced 200 messages. It is simpler to implement this feature myself to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sat Feb 22 05:55:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 10:55:32 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582368932.79.0.643389208074.issue39648@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +17970
pull_request: https://github.com/python/cpython/pull/18604

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sat Feb 22 06:04:01 2020
From: report at bugs.python.org (Antony Lee)
Date: Sat, 22 Feb 2020 11:04:01 +0000
Subject: [issue39716] argparse.ArgumentParser does not raise on duplicated
 subparsers, even though it does on duplicated flags
In-Reply-To: <1582309254.51.0.588412851994.issue39716@roundup.psfhosted.org>
Message-ID: <1582369441.78.0.0476821757004.issue39716@roundup.psfhosted.org>


Change by Antony Lee <anntzer.lee at gmail.com>:


----------
keywords: +patch
pull_requests: +17971
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18605

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39716>
_______________________________________

From report at bugs.python.org  Sat Feb 22 06:04:34 2020
From: report at bugs.python.org (Antony Lee)
Date: Sat, 22 Feb 2020 11:04:34 +0000
Subject: [issue39716] argparse.ArgumentParser does not raise on duplicated
 subparsers, even though it does on duplicated flags
In-Reply-To: <1582309254.51.0.588412851994.issue39716@roundup.psfhosted.org>
Message-ID: <1582369474.55.0.838790030082.issue39716@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

Sure, https://github.com/python/cpython/pull/18605 it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39716>
_______________________________________

From report at bugs.python.org  Sat Feb 22 06:11:39 2020
From: report at bugs.python.org (Ananthakrishnan)
Date: Sat, 22 Feb 2020 11:11:39 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582369899.76.0.742418024074.issue39648@roundup.psfhosted.org>


Ananthakrishnan <ananthakrishnan15.2001 at gmail.com> added the comment:

>>Sorry, Ananthakrishnan, but I think this problem is too difficult to you. Adding math.lcm() taken 2 weeks and produced 200 messages. It is simpler to implement this feature myself to me.


I'm a beginner.Not everyone is perfect at begenning.
I am starting this.So I took some problems myself as i saw the problems here are difficult.You should have given me a chance.

I think you should have at the same situations once,like the situations that I'm facing now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sat Feb 22 06:20:43 2020
From: report at bugs.python.org (Pedro Algarvio)
Date: Sat, 22 Feb 2020 11:20:43 +0000
Subject: [issue38263] [Windows] multiprocessing: DupHandle.detach() race
 condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
In-Reply-To: <1569321399.19.0.207011593125.issue38263@roundup.psfhosted.org>
Message-ID: <1582370443.36.0.0456624958014.issue38263@roundup.psfhosted.org>


Pedro Algarvio <pedro at algarvio.me> added the comment:

Any possible workaround for this issue?
I seem to be consistingly hitting this issue.

----------
nosy: +s0undt3ch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38263>
_______________________________________

From report at bugs.python.org  Sat Feb 22 06:29:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 11:29:44 +0000
Subject: [issue39648] Update math.gcd() to accept "n" arguments.
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582370984.53.0.376103593747.issue39648@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I'm always ready to help a beginner, but this is the first time that it takes so much effort. It would be easier if you started with the simple problems you could handle. Even in simple cases you would be able to get tips that you can understand and gradually improve your skills.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sat Feb 22 06:39:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 11:39:22 +0000
Subject: [issue39648] Expand math.gcd() and math.lcm() to accept multiple
 arguments
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582371562.8.0.314968996931.issue39648@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If expand math.gcd() to accept multiple arguments, it is worth to do the same with math.lcm().

----------
title: Update math.gcd() to accept "n" arguments. -> Expand math.gcd() and math.lcm() to accept multiple arguments

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sat Feb 22 08:11:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 13:11:55 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1582377115.83.0.733474284999.issue39382@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1c56f8ffad44478b4214a2bf8eb7cf51c28a347a by Yonatan Goldschmidt in branch 'master':
bpo-39382: Avoid dangling object use in abstract_issubclass() (GH-18530)
https://github.com/python/cpython/commit/1c56f8ffad44478b4214a2bf8eb7cf51c28a347a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Feb 22 08:16:25 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 13:16:25 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1582377385.83.0.630362567598.issue39382@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17972
pull_request: https://github.com/python/cpython/pull/18606

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Feb 22 08:16:32 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 13:16:32 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1582377392.64.0.293531982903.issue39382@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17973
pull_request: https://github.com/python/cpython/pull/18607

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Feb 22 08:32:39 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 13:32:39 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1582378359.96.0.553948863331.issue39382@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 43a0137c87b997c6ba8b23cc3281ce2de18f008a by Miss Islington (bot) in branch '3.7':
bpo-39382: Avoid dangling object use in abstract_issubclass() (GH-18530)
https://github.com/python/cpython/commit/43a0137c87b997c6ba8b23cc3281ce2de18f008a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Feb 22 08:34:09 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 13:34:09 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1582378449.73.0.581795880193.issue39382@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0c1827e70c1c05ce1982a34380cea7d391904293 by Miss Islington (bot) in branch '3.8':
bpo-39382: Avoid dangling object use in abstract_issubclass() (GH-18530)
https://github.com/python/cpython/commit/0c1827e70c1c05ce1982a34380cea7d391904293


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Feb 22 08:44:17 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 22 Feb 2020 13:44:17 +0000
Subject: [issue38263] [Windows] multiprocessing: DupHandle.detach() race
 condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
In-Reply-To: <1569321399.19.0.207011593125.issue38263@roundup.psfhosted.org>
Message-ID: <1582379057.06.0.632585173597.issue38263@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I seem to be consistingly hitting this issue.

It will help with test development if you can provide a minimal example that reliably reproduces the problem. 

In msg353064 I see DuplicateHandle calls failing with ERROR_ACCESS_DENIED (5). Assuming the process handles have the required PROCESS_DUP_HANDLE access, it's most likely the case that the underlying NtDuplicateObject system call is failing with STATUS_PROCESS_IS_TERMINATING (0xC000010A). For example:

    import ctypes
    ntdll = ctypes.WinDLL('ntdll')
    from subprocess import Popen, PIPE
    from _winapi import GetCurrentProcess, TerminateProcess
    from _winapi import DuplicateHandle, DUPLICATE_SAME_ACCESS

    p = Popen('cmd.exe', stdin=PIPE, stdout=PIPE, stderr=PIPE)
    TerminateProcess(p._handle, 0)

Try to duplicate the process handle into the terminated process:

    >>> source = GetCurrentProcess()
    >>> target = handle = p._handle
    >>> try:
    ...     DuplicateHandle(source, handle, target,
    ...         0, False, DUPLICATE_SAME_ACCESS)
    ... except:
    ...     status = ntdll.RtlGetLastNtStatus() 
    ...     print(f'NTSTATUS: {status & (2**32-1):#010x}')
    ...     raise
    ...
    NTSTATUS: 0xc000010a
    Traceback (most recent call last):
      File "<stdin>", line 2, in <module>
    PermissionError: [WinError 5] Access is denied

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38263>
_______________________________________

From report at bugs.python.org  Sat Feb 22 09:23:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 14:23:09 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
In-Reply-To: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>
Message-ID: <1582381389.23.0.16364847872.issue39382@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Feb 22 09:31:56 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 22 Feb 2020 14:31:56 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1582381916.5.0.308147568334.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17974
pull_request: https://github.com/python/cpython/pull/18608

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sat Feb 22 10:01:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Feb 2020 15:01:33 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582383693.33.0.283364759489.issue39724@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I understand, input() in one thread blocks print() in another thread. 
This sound like a new issue for this tracker, and possibly a bug in IDLE's implementation of std streams through a socket, but I need to see your code.  Please try attaching it again.

Also, try running >py -m idlelib -n path

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sat Feb 22 11:50:15 2020
From: report at bugs.python.org (John Smith)
Date: Sat, 22 Feb 2020 16:50:15 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582390215.45.0.242551940978.issue39724@roundup.psfhosted.org>


Change by John Smith <js5136317 at gmail.com>:


Added file: https://bugs.python.org/file48901/IDLE_threading_issue_min_example1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sat Feb 22 11:53:36 2020
From: report at bugs.python.org (John Smith)
Date: Sat, 22 Feb 2020 16:53:36 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582390416.03.0.575998950239.issue39724@roundup.psfhosted.org>


John Smith <js5136317 at gmail.com> added the comment:

py -m idlelib -n path output:

Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
==== No Subprocess ====

WARNING: Running IDLE without a Subprocess is deprecated
and will be removed in a later version. See Help/IDLE Help
for details.

>>> 
waiting for inputalive
alive
alive
alive
alive
alive

 -> so its working as intended

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sat Feb 22 11:54:31 2020
From: report at bugs.python.org (John Smith)
Date: Sat, 22 Feb 2020 16:54:31 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582390471.88.0.555976021077.issue39724@roundup.psfhosted.org>


John Smith <js5136317 at gmail.com> added the comment:

P.S. here (other computer but with same observed behavior) I have a 3.6 32bit as one can see from the output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sat Feb 22 12:56:05 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 22 Feb 2020 17:56:05 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582394165.65.0.225064307391.issue17422@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset fbe2e0bb8a7ee75d0f9d57682436dac7d69e202e by ananthan-123 in branch 'master':
bpo-17422: Language reference should specify restrictions on class namespace (#18559)
https://github.com/python/cpython/commit/fbe2e0bb8a7ee75d0f9d57682436dac7d69e202e


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Sat Feb 22 12:58:21 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 22 Feb 2020 17:58:21 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582394301.73.0.756963559533.issue17422@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/issue17422>
_______________________________________

From report at bugs.python.org  Sat Feb 22 12:59:58 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 17:59:58 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582394398.43.0.589590936133.issue17422@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17975
pull_request: https://github.com/python/cpython/pull/18610

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Sat Feb 22 13:00:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 18:00:06 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582394406.46.0.995263164802.issue17422@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17976
pull_request: https://github.com/python/cpython/pull/18611

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Sat Feb 22 13:40:50 2020
From: report at bugs.python.org (Pedro Algarvio)
Date: Sat, 22 Feb 2020 18:40:50 +0000
Subject: [issue38263] [Windows] multiprocessing: DupHandle.detach() race
 condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)
In-Reply-To: <1582379057.06.0.632585173597.issue38263@roundup.psfhosted.org>
Message-ID: <CAGTkXNHxckyNr2VTriQhrSfVYkCKFK8KMK4OP1EAYEbTkEnRuQ@mail.gmail.com>


Pedro Algarvio <pedro at algarvio.me> added the comment:

What I'm able to copy from the console(though I doubt I'm getting all of
the traceback):

Traceback (most recent call last):

  File "<string>", line 1, in <module>

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\spawn.py",
line 106, in spawn_main

    exitcode = _main(fd)

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\spawn.py",
line 116, in _main

    self = pickle.load(from_parent)

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\connection.py",
line 942, in rebuild_pipe_connection

    handle = dh.detach()

  File
"c:\hostedtoolcache\windows\python\3.5.4\x64\lib\multiprocessing\reduction.py",
line 128, in detach

    self._access, False, _winapi.DUPLICATE_CLOSE_SOURCE)

PermissionError: [WinError 5] Access is denied

Pedro Algarvio @ Phone

A s?bado, 22/02/2020, 13:44, Eryk Sun <report at bugs.python.org> escreveu:

>
> Eryk Sun <eryksun at gmail.com> added the comment:
>
> > I seem to be consistingly hitting this issue.
>
> It will help with test development if you can provide a minimal example
> that reliably reproduces the problem.
>
> In msg353064 I see DuplicateHandle calls failing with ERROR_ACCESS_DENIED
> (5). Assuming the process handles have the required PROCESS_DUP_HANDLE
> access, it's most likely the case that the underlying NtDuplicateObject
> system call is failing with STATUS_PROCESS_IS_TERMINATING (0xC000010A). For
> example:
>
>     import ctypes
>     ntdll = ctypes.WinDLL('ntdll')
>     from subprocess import Popen, PIPE
>     from _winapi import GetCurrentProcess, TerminateProcess
>     from _winapi import DuplicateHandle, DUPLICATE_SAME_ACCESS
>
>     p = Popen('cmd.exe', stdin=PIPE, stdout=PIPE, stderr=PIPE)
>     TerminateProcess(p._handle, 0)
>
> Try to duplicate the process handle into the terminated process:
>
>     >>> source = GetCurrentProcess()
>     >>> target = handle = p._handle
>     >>> try:
>     ...     DuplicateHandle(source, handle, target,
>     ...         0, False, DUPLICATE_SAME_ACCESS)
>     ... except:
>     ...     status = ntdll.RtlGetLastNtStatus()
>     ...     print(f'NTSTATUS: {status & (2**32-1):#010x}')
>     ...     raise
>     ...
>     NTSTATUS: 0xc000010a
>     Traceback (most recent call last):
>       File "<stdin>", line 2, in <module>
>     PermissionError: [WinError 5] Access is denied
>
> ----------
> nosy: +eryksun
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38263>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38263>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:24:18 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Sat, 22 Feb 2020 19:24:18 +0000
Subject: [issue39130] Dict is reversable from v3.8 and should say that in the
 doc
In-Reply-To: <1578263986.1.0.861594582146.issue39130@roundup.psfhosted.org>
Message-ID: <1582399458.6.0.0170358221922.issue39130@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39130>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:33:38 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Sat, 22 Feb 2020 19:33:38 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
In-Reply-To: <1577889536.91.0.731719128182.issue39180@roundup.psfhosted.org>
Message-ID: <1582400018.28.0.215842415468.issue39180@roundup.psfhosted.org>


Khalid Mammadov <khalidmammadov9 at gmail.com> added the comment:

How to find if it was intentional or over-site?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39180>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:36:21 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 22 Feb 2020 19:36:21 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
In-Reply-To: <1577889536.91.0.731719128182.issue39180@roundup.psfhosted.org>
Message-ID: <1582400181.54.0.622017931282.issue39180@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

A good place to start is looking at the blame to find the commit that introduced it. Which was:

https://github.com/python/cpython/commit/17ab123cf1f0597e7e257c1ce83a6e87b85ffd7b#diff-71666751dc5821f7fc30e9c8138019c9

and if we browse to the state of the file before that commit we see:

https://github.com/python/cpython/blob/bbd89b66b1b3c44836f560b60c7a176a6172f148/Lib/linecache.py#L32-L39

which indicates that it used to be exposed but was maybe overlooked when __all__ was added.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39180>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:44:30 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Sat, 22 Feb 2020 19:44:30 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
In-Reply-To: <1577889536.91.0.731719128182.issue39180@roundup.psfhosted.org>
Message-ID: <1582400670.99.0.664096123391.issue39180@roundup.psfhosted.org>


Khalid Mammadov <khalidmammadov9 at gmail.com> added the comment:

Looks like it's not meant to be made public as the module is meant to be working on a single line. So closing the issue and PR

----------
nosy:  -ammar2
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39180>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:46:58 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Sat, 22 Feb 2020 19:46:58 +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: <1582400818.89.0.289983206302.issue39139@roundup.psfhosted.org>


Khalid Mammadov <khalidmammadov9 at gmail.com> added the comment:

Looks like this is covered in greater detail in the other PRs. So, closing the PR and the issue

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39139>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:47:16 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Sat, 22 Feb 2020 19:47:16 +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: <1582400836.22.0.72660037942.issue39139@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39139>
_______________________________________

From report at bugs.python.org  Sat Feb 22 14:47:28 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Sat, 22 Feb 2020 19:47:28 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
In-Reply-To: <1577889536.91.0.731719128182.issue39180@roundup.psfhosted.org>
Message-ID: <1582400848.89.0.275040738756.issue39180@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39180>
_______________________________________

From report at bugs.python.org  Sat Feb 22 15:13:27 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Feb 2020 20:13:27 +0000
Subject: [issue30097] Command-line option to suppress "from None" for debugging
In-Reply-To: <1492553512.25.0.992335940269.issue30097@psf.upfronthosting.co.za>
Message-ID: <1582402407.01.0.57840911693.issue30097@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

+1 for the idea.

Instead of '-C' we could add it as one of the '-X' options -- it is, after all, a development issue.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30097>
_______________________________________

From report at bugs.python.org  Sat Feb 22 15:35:32 2020
From: report at bugs.python.org (Jeff Allen)
Date: Sat, 22 Feb 2020 20:35:32 +0000
Subject: [issue39639] Remove Suite node from AST
In-Reply-To: <1581767209.41.0.653411841191.issue39639@roundup.psfhosted.org>
Message-ID: <1582403732.88.0.230241432679.issue39639@roundup.psfhosted.org>


Jeff Allen <ja.py at farowl.co.uk> added the comment:

Jython uses the reference grammar and ASDL as a way to ensure it is Python we approximate, not some subtly different language. The presence of Suite here gives rise to a class (https://github.com/jythontools/jython/blob/v2.7.2b3/src/org/python/antlr/ast/Suite.java) and we actually use instances of it in the compiler (https://github.com/jythontools/jython/blob/v2.7.2b3/src/org/python/compiler/CodeCompiler.java#L2389).

It is a bit of a wart, to have a Jython-specific type here: somewhat defeating the object of using the same source. I expect there was a good reason: perhaps there was no better way to express the commonality between Interactive and Module. It was all before my involvement.

I would try to avoid needing it in Jython 3, and if we can't, it doesn't look hard to manage the variation our copy. It's not like we copy these files mechanically from from CPython during a build.

+1 on removing it.

----------
nosy: +jeff.allen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39639>
_______________________________________

From report at bugs.python.org  Sat Feb 22 16:00:22 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Feb 2020 21:00:22 +0000
Subject: [issue39710] "will be returned as unicode" reminiscent from Python 2
In-Reply-To: <1582300708.21.0.335550003251.issue39710@roundup.psfhosted.org>
Message-ID: <1582405222.52.0.858205293052.issue39710@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +newcomer friendly
stage:  -> needs patch
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39710>
_______________________________________

From report at bugs.python.org  Sat Feb 22 16:05:03 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 22 Feb 2020 21:05:03 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
Message-ID: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

Using the example from https://bugs.python.org/msg293185:

-----------------------------------------------------------------------
--> import os
--> try:
...     os.environ["NEW_VARIABLE"] = bug  # bug is not a str
... finally:
...     del os.environ["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  ...
KeyError: 'NEW_VARIABLE'
-----------------------------------------------------------------------

We lost the original exception, `TypeError: str expected, not object`, because in os.py we have:

    def __delitem__(self, key):
        encodedkey = self.encodekey(key)
        unsetenv(encodedkey)
        try:
            del self._data[encodedkey]
        except KeyError:
            # raise KeyError with the original key value
            raise KeyError(key) from None


If we remove the `from None` the result of the above code is:

-----------------------------------------------------------------------
Traceback (most recent call last):
TypeError: str expected, not type

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
KeyError: b'NEW_VARIABLE'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
KeyError: 'NEW_VARIABLE'
-----------------------------------------------------------------------


There are various tricks we can do to fix this isolated issue (and others like it), but the real problem is that one exception handler's work was destroyed by an unrelated exception handler.

The intent of `from None` is to get rid of any exception details in the try/except block it is contained within, not to lose details from exceptions that were already in play when its try/except block was entered.

Any ideas on how to correct this?

----------
messages: 362478
nosy: ethan.furman, ncoghlan, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: unrelated  `from None` exceptions lose prior exception information
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sat Feb 22 16:16:28 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 21:16:28 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582406188.1.0.979867089196.issue17422@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 91ba44623e5cb8f4a7b0d3fc1fab8ff8d8a849c2 by Miss Islington (bot) in branch '3.8':
bpo-17422: Language reference should specify restrictions on class namespace (GH-18559)
https://github.com/python/cpython/commit/91ba44623e5cb8f4a7b0d3fc1fab8ff8d8a849c2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Sat Feb 22 16:16:46 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 22 Feb 2020 21:16:46 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582406206.68.0.0121216537219.issue17422@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 36a120d343c1cb69b8d02913569c153e8bb969c8 by Miss Islington (bot) in branch '3.7':
bpo-17422: Language reference should specify restrictions on class namespace (GH-18559)
https://github.com/python/cpython/commit/36a120d343c1cb69b8d02913569c153e8bb969c8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Sat Feb 22 17:00:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 22 Feb 2020 22:00:45 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582408845.93.0.358772318687.issue39725@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Interesting problem.

Example which does not depend on os.environ:

import traceback
try:
    try:
        raise TypeError
    except:
        try:
            raise ValueError
        except:
            raise KeyError from None
except BaseException as exc:
    e = exc

print([e, e.__cause__, e.__context__, e.__suppress_context__])
traceback.print_exception(type(e), e, e.__traceback__)


"from None" sets __suppress_context__ to True. Currently, if __suppress_context__ is true, the output of __context__ will be suppressed in the traceback. But what if we suppress only a part __context__ and output the "original" exception. The problem is what is the "original" exception. Is it __context__.__context__? Or __context__.__cause__ if it is not None? Should we take __context__.__suppress_context__ into account? Maybe go down recursively?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sat Feb 22 18:08:37 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 22 Feb 2020 23:08:37 +0000
Subject: [issue36000] __debug__ is a keyword but not a keyword
In-Reply-To: <1550233328.67.0.392552434895.issue36000@roundup.psfhosted.org>
Message-ID: <1582412917.13.0.434731044446.issue36000@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Serhiy wrote in msg336099 that __debug__ isn't a keyword and the error message was changed in 3.8.  Due to that, I'm going to close this as not a bug.

----------
nosy: +cheryl.sabella
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36000>
_______________________________________

From report at bugs.python.org  Sat Feb 22 18:43:06 2020
From: report at bugs.python.org (Ben Darnell)
Date: Sat, 22 Feb 2020 23:43:06 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1582414986.73.0.101938493229.issue37373@roundup.psfhosted.org>


Ben Darnell <ben.darnell at gmail.com> added the comment:

I have an implementation of the selector-in-another-thread solution in https://github.com/tornadoweb/tornado/pull/2815. Is something like this worth considering for Python 3.9, or was Tornado the only project experiencing this pain and a tornado-specific solution is enough?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Sat Feb 22 18:55:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 22 Feb 2020 23:55:18 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582415718.72.0.252293650082.issue39724@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Summary: With IDLE running normally, with 2 processes, "input('prompt')" in the main thread blocks execution of "print('whatever')" in a separate thread.  (Verified on Windows with 3.9 and macOS with 3.8.)  The user can respond to the prompt without being disrupted by continued output.

For standard single process python or IDLE (started with -n), the thread output continues and can be mixed in with both the input prompt and user response and in the example, scroll prompt and even initial response off the screen.

I presume the difference is related to IDLE routing user-code use of the std streams through a 3rd thread that manages the inter-process socket connection.  But I did not see why after more than an hour of looking.

Overall, I think the experience with input() in IDLE is more useful and less confusing, especially to beginners.  (I am having trouble imagining when the intermixing and interference would be useful.)

Guido, do you have any recollection of whether the IDLE difference, when using an execution process, is intended?  Do you regard intermixing input prompts and responses and thread output as a required feature of Python, or as an (unfortunate, IMHO) side-effect of using a dumb text interface?

Note: in IDLE, '>>>' come from IDLE, not the usercode execution process.  Hence a) asynchonous outputs from the execution process can appear on the screen, and b) IDLE, unlike the standard REPL, can and does prevents such text from mixing into and spoiling user code input.  (It may appear after '>>>' but is put before the input area.  This is an intentional interface difference.

My *immediate* inclination is to regard the IDLE difference as overall being a positive feature and leave it alone.  But it should be documented in "Running user code", which is already mostly about stdio differences.  

I don't deny that blocking output while a user responds is a negative.  I just see mixing streams as worse.  To work towards not blocking while not mixing, I replaced the thread loop with
    for i in range(10): sys.stdout.write(f'some text {i}\n')
and separated input(prompt) into sys.stdout.write(prompt) and sys.stdin.readline().

Observations:
1. .write is better as it is atomic, while print() prints '\n' separately, with sometimes undesirable results.
2. The block is from readline.
3. While output to Shell is blocked on readline, typing a continuation-invoking '.' or calltip-invoking '(' in either Shell or editor allows one line of output.  Both send a non-stdio message from Shell to the run process and back.  This might be a clue as to how read/readline blocks.

In the longer term, after some changes to Shell, I could imagine replacing __builtins__.input with a function that would check if sys.stdin/out were IDLE's replacements and if so, send the prompt to Shell tagged as 'prompt' rather than as 'stdout', so that Shell could keep prompt and user response  separate from regular output, similar to the way now done for code input.  If .readline cannot be made to not block output, it might work for Shell to send  the response back tagged as 'response' rather than as 'stdin' and not use readline.

----------
nosy: +gvanrossum, taleinat
stage:  -> needs patch
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sat Feb 22 19:14:55 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Feb 2020 00:14:55 +0000
Subject: [issue30097] Command-line option to suppress "from None" for debugging
In-Reply-To: <1492553512.25.0.992335940269.issue30097@psf.upfronthosting.co.za>
Message-ID: <1582416895.67.0.774939959223.issue30097@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

The actual problem, I think, is that `from None` is suppressing more than it ought.  Martin's example would work just fine if the only omitted exception was the one captured during its own try/except.

Created issue39725.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30097>
_______________________________________

From report at bugs.python.org  Sat Feb 22 20:54:56 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 01:54:56 +0000
Subject: [issue38035] shared_semaphores cannot be shared across unrelated
 processes
In-Reply-To: <1567659668.43.0.186142682202.issue38035@roundup.psfhosted.org>
Message-ID: <1582422896.33.0.511814483022.issue38035@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

@taleinat what do you think?

----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38035>
_______________________________________

From report at bugs.python.org  Sat Feb 22 21:07:21 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 02:07:21 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582423641.06.0.944023945005.issue38691@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17977
pull_request: https://github.com/python/cpython/pull/18612

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Sat Feb 22 21:57:28 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 23 Feb 2020 02:57:28 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1582426648.71.0.191506678463.issue39529@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

FWIW, I agree with get_event_loop() being problematic with its error messages, and having a bit too much functionality in a single function from an API design perspective. It commonly comes up as an issue among asyncio users in communities that I'm active in. 

Typically, I advise them to use get_running_loop() where possible, as it can be directly substituted within a coroutine func. For __init__ methods, I recommend setting their internal loop attribute to None and then setting it to get_running_loop() in either a coro start() method or coro factory method. Outside of directly managing the event loop, this works for many use cases. When it's needed to actually create one, I advise them to use new_event_loop(), but mention that it's already handled if they're using asyncio.run().

Andrew Svetlov wrote:
> The asyncio.get_event_loop() function will stay in Python for a while in deprecated status. I don't know the exact period but it should be 3 releases at least I guess, with possibly extending to 5 releases if needed.

With how many libraries that rely on it, I suspect it will likely be a very slow transition from deprecation to removal. 4 versions seems like a reasonable period to me, but I think that 3 may be too short (assuming we retain the newer annual release cycle).

Yury Selivanov wrote:
> I think we still use get_event_loop() in asyncio code, no?

Indeed, we currently use it in several places throughout asyncio. From a brief glace using git grep "get_event_loop()":

Lib/asyncio/futures.py:76:            self._loop = events.get_event_loop()
Lib/asyncio/futures.py:390:        loop = events.get_event_loop()
Lib/asyncio/locks.py:81:            self._loop = events.get_event_loop()
Lib/asyncio/locks.py:177:            self._loop = events.get_event_loop()
Lib/asyncio/locks.py:244:            self._loop = events.get_event_loop()
Lib/asyncio/locks.py:375:            self._loop = events.get_event_loop()
Lib/asyncio/queues.py:35:            self._loop = events.get_event_loop()
Lib/asyncio/streams.py:45:        loop = events.get_event_loop()
Lib/asyncio/streams.py:82:        loop = events.get_event_loop()
Lib/asyncio/streams.py:104:            loop = events.get_event_loop()
Lib/asyncio/streams.py:120:            loop = events.get_event_loop()
Lib/asyncio/streams.py:147:            self._loop = events.get_event_loop()
Lib/asyncio/streams.py:403:            self._loop = events.get_event_loop()
Lib/asyncio/subprocess.py:206:        loop = events.get_event_loop()
Lib/asyncio/subprocess.py:227:        loop = events.get_event_loop()
Lib/asyncio/tasks.py:69:        loop = events.get_event_loop()
Lib/asyncio/tasks.py:129:            loop = events.get_event_loop()
Lib/asyncio/tasks.py:590:        loop = events.get_event_loop()
Lib/asyncio/tasks.py:669:            loop = events.get_event_loop()
Lib/asyncio/tasks.py:751:            loop = events.get_event_loop()

For brevity, I omitted the docs, tests, and the function definition for get_event_loop().

Based on Serhiy's idea (of making get_event_loop() an alias for get_running_loop() without warning inside of a coro func, but warning for using it outside of one), many of the above could remain as is to reduce some code churn. We just have to make sure the documentation is updated to reflect get_event_loop() becoming an alias for get_running_loop(), at the same time as the deprecation warning is added for using it outside of a coro func. Otherwise, I suspect it could lead to significant confusion from users that have warnings enabled.

That being said, I think we should eventually remove asyncio.get_event_loop() entirely from the asyncio internals, including the ones that wouldn't raise deprecation warnings (if/when it's made an alias to get_running_loop()) for improved clarity. Personally, I find that even the name get_event_loop() is rather vague; get_running_loop() is much more obvious as to its purpose and what it does from a readability perspective.

Yury Selivanov wrote:
> If we do, we should start by raising deprecation warnings in those call sites, e.g. if a Future or Lock is created outside of a coroutine and no explicit event loop is passed.

For asyncio.Lock (plus other synchronization primitives) and asyncio.Queue, this would be added in https://github.com/python/cpython/pull/18195. Currently waiting on emanu (author of the PR) to finish up some changes, but it's mostly complete. Could I work on adding it to asyncio.Future and other classes in the meantime?

One point to be clarified though: you mention "created outside of a coroutine and no explicit event loop is passed". However, there are already several deprecations in place for passing an explicit event loop for most (if not all) of the __init__ methods for objects across asyncio's high-level API. In those cases, should the deprecation for creating the object outside of a coroutine function care about whether or not an explicit event loop is passed?

I can see why it would matter for the lower level parts of the API (such as asyncio.Future) where passing the event loop explicitly is still allowed, but IMO it shouldn't be a factor for ones where passing the event loop explicitly is already deprecated. Especially considering that the loop argument will be removed from those entirely in 3.10 (according to the version listed in the current deprecation warnings added in 3.8).

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39529>
_______________________________________

From report at bugs.python.org  Sat Feb 22 23:38:19 2020
From: report at bugs.python.org (David Harding)
Date: Sun, 23 Feb 2020 04:38:19 +0000
Subject: [issue39726] ctypes on pypi has fallen behind
Message-ID: <1582432699.85.0.731912909682.issue39726@roundup.psfhosted.org>


New submission from David Harding <hardingprofessional at gmail.com>:

I wasn't sure where to report this.

ctypes currently bundled with Ubuntu 16.04 and 18.04 is version 1.1.0.

ctypes available through pypi is 1.0.2.

https://pypi.org/project/ctypes/

This makes maintaining a reproducible environment with venv kind of tricky. It would be desirable to catch the pypi version up to 1.1.0.

I don't really know who to bother about this, so I'm starting here.

Thanks!

----------
components: ctypes
messages: 362488
nosy: David Harding
priority: normal
severity: normal
status: open
title: ctypes on pypi has fallen behind
type: enhancement
versions: Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39726>
_______________________________________

From report at bugs.python.org  Sat Feb 22 23:40:14 2020
From: report at bugs.python.org (Fantix King)
Date: Sun, 23 Feb 2020 04:40:14 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1582432814.79.0.598061285158.issue33840@roundup.psfhosted.org>


Change by Fantix King <fantix.king at gmail.com>:


----------
nosy: +fantix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Sun Feb 23 00:13:56 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 23 Feb 2020 05:13:56 +0000
Subject: [issue39726] ctypes on pypi has fallen behind
In-Reply-To: <1582432699.85.0.731912909682.issue39726@roundup.psfhosted.org>
Message-ID: <1582434836.06.0.0321786566834.issue39726@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The ctypes on pypi is no longer maintained as it was merged by the original author Thomas Heller into python itself. 

This article goes over the history of it a little: https://blog.python.org/2011/04/thomas-heller-steps-down-as-ctypes.html

Why do you need the pypi version to be updated? You should just be able to import ctypes in your venv and have it use the one included in the standard library.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39726>
_______________________________________

From report at bugs.python.org  Sun Feb 23 00:34:16 2020
From: report at bugs.python.org (James Edington)
Date: Sun, 23 Feb 2020 05:34:16 +0000
Subject: [issue39727] cgi.parse() fatally attempts str.decode when handling
 multipart/form-data
Message-ID: <1582436056.52.0.172079709412.issue39727@roundup.psfhosted.org>


New submission from James Edington <je0029 at uah.edu>:

It appears that cgi.parse() in Python 3.7.6 [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] fatally chokes on POST requests with multipart/form-data due to some internal processing still relying on assumptions from when str and bytes were the same object.

I'll attach as the first comment the "try-it-at-home" file to demonstrate this error.

----------
components: Library (Lib)
files: curlLogs.txt
messages: 362490
nosy: James Edington
priority: normal
severity: normal
status: open
title: cgi.parse() fatally attempts str.decode when handling multipart/form-data
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48902/curlLogs.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39727>
_______________________________________

From report at bugs.python.org  Sun Feb 23 00:36:26 2020
From: report at bugs.python.org (James Edington)
Date: Sun, 23 Feb 2020 05:36:26 +0000
Subject: [issue39727] cgi.parse() fatally attempts str.decode when handling
 multipart/form-data
In-Reply-To: <1582436056.52.0.172079709412.issue39727@roundup.psfhosted.org>
Message-ID: <1582436186.7.0.613948247121.issue39727@roundup.psfhosted.org>


James Edington <je0029 at uah.edu> added the comment:

Here is a file to try it out in an instant.

(lines 11?28 are not necessary; they are just "luxuries" allowing easier testing of the issue in a web browser)

----------
Added file: https://bugs.python.org/file48903/demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39727>
_______________________________________

From report at bugs.python.org  Sun Feb 23 02:31:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Feb 2020 07:31:54 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582443114.36.0.381360230858.issue39725@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

For reference: PEP 3134 (and superseded PEP 344), PEP 409, PEP 415.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sun Feb 23 02:38:38 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 23 Feb 2020 07:38:38 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1582443518.56.0.930642551321.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17978
pull_request: https://github.com/python/cpython/pull/18613

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Feb 23 02:44:13 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 23 Feb 2020 07:44:13 +0000
Subject: [issue38035] shared_semaphores cannot be shared across unrelated
 processes
In-Reply-To: <1567659668.43.0.186142682202.issue38035@roundup.psfhosted.org>
Message-ID: <1582443853.99.0.57639451577.issue38035@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

I'm not convinced there is enough real need for this to justify implementing and supporting it.

Using shared memory wouldn't be possible with built-in Python objects; one would have to use a special-purpose library for this, or perhaps use something like ctypes. It seems to me that in any case, once someone is doing those, they might as well use those same tools to also create and manage shared resources such as shared memory.

Therefore, even if we allow creating such shared resources, it doesn't seem to me that they will be very usable without a lot of extra supporting features.

In other words, I'd like to see at least one convincing use-case for this before considering any implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38035>
_______________________________________

From report at bugs.python.org  Sun Feb 23 02:46:23 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 23 Feb 2020 07:46:23 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1582443983.97.0.527291962787.issue2771@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag, brett.cannon
nosy_count: 8.0 -> 10.0
pull_requests: +17979
pull_request: https://github.com/python/cpython/pull/18614

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Feb 23 02:47:22 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 23 Feb 2020 07:47:22 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1582444042.81.0.51257631461.issue2771@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Sun Feb 23 03:13:06 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 23 Feb 2020 08:13:06 +0000
Subject: [issue38101] Update devguide triaging keywords
In-Reply-To: <1568194769.69.0.909868564617.issue38101@roundup.psfhosted.org>
Message-ID: <1582445586.34.0.217856421495.issue38101@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for the fix, Ido!

----------
nosy: +taleinat
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38101>
_______________________________________

From report at bugs.python.org  Sun Feb 23 03:58:18 2020
From: report at bugs.python.org (Vinay Sharma)
Date: Sun, 23 Feb 2020 08:58:18 +0000
Subject: [issue38035] shared_semaphores cannot be shared across unrelated
 processes
In-Reply-To: <1567659668.43.0.186142682202.issue38035@roundup.psfhosted.org>
Message-ID: <1582448298.57.0.53834852679.issue38035@roundup.psfhosted.org>


Vinay Sharma <vinay0410sharma at gmail.com> added the comment:

Hi,
I think a use case for this is https://docs.python.org/3/library/multiprocessing.shared_memory.html

If not, can you please suggest a way to synchronise the above across unrelated processes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38035>
_______________________________________

From report at bugs.python.org  Sun Feb 23 04:07:04 2020
From: report at bugs.python.org (Jonas Malaco)
Date: Sun, 23 Feb 2020 09:07:04 +0000
Subject: [issue39728] Instantiating enum with invalid value results in
 ValueError twice
Message-ID: <1582448824.79.0.766917894274.issue39728@roundup.psfhosted.org>


New submission from Jonas Malaco <jonas at protocubo.io>:

Trying to instantiate an enum with an invalid value results in "During handling of the above exception, another exception occurred:".


$ cat > test.py << EOF
from enum import Enum

class Color(Enum):
    RED = 1
    GREEN = 2
    BLUE = 3

Color(0)
EOF


$ python --version
Python 3.8.1


$ python test.py
ValueError: 0 is not a valid Color

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 8, in <module>
    Color(0)
  File "/usr/lib/python3.8/enum.py", line 304, in __call__
    return cls.__new__(cls, value)
  File "/usr/lib/python3.8/enum.py", line 595, in __new__
    raise exc
  File "/usr/lib/python3.8/enum.py", line 579, in __new__
    result = cls._missing_(value)
  File "/usr/lib/python3.8/enum.py", line 608, in _missing_
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 0 is not a valid Color


I think this might be related to 019f0a0cb85e ("bpo-34536: raise error for invalid _missing_ results (GH-9147)"), but I haven't been able to confirm.

----------
components: Library (Lib)
messages: 362496
nosy: jonasmalaco
priority: normal
severity: normal
status: open
title: Instantiating enum with invalid value results in ValueError twice
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39728>
_______________________________________

From report at bugs.python.org  Sun Feb 23 04:10:47 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Feb 2020 09:10:47 +0000
Subject: [issue39728] Instantiating enum with invalid value results in
 ValueError twice
In-Reply-To: <1582448824.79.0.766917894274.issue39728@roundup.psfhosted.org>
Message-ID: <1582449047.22.0.255928802773.issue39728@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/issue39728>
_______________________________________

From report at bugs.python.org  Sun Feb 23 04:26:15 2020
From: report at bugs.python.org (John Smith)
Date: Sun, 23 Feb 2020 09:26:15 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582449975.3.0.466104865481.issue39724@roundup.psfhosted.org>


John Smith <js5136317 at gmail.com> added the comment:

Interesting finding. Just some thoughs: I have to disagree on the "the experience with input() in IDLE is more useful and less confusing, especially to beginners" part.

Here are some reasons:

1. If a beginner starts with threading and expect a concurrent execution the confusion will be high if there is non in IDLE => implicitly changes of the runtime behavior siliencly enforced by an IDE can lead to misconcepts.

2. It took me (and my team) more than one hour to track a strange issue down to this IDLE related behavior - mainly because I assumed that IDLE would not change the runtime behavior of a program in that way => the deviation in behavior can even confuse experienced developers.

3. During my search I came across several reports of similar issues and most people were told to simply quit IDLE => "quirks" have impact on the reputation.

Personally I like and mainly use IDLE and would like to continue with it.

----------
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sun Feb 23 05:00:34 2020
From: report at bugs.python.org (David Harding)
Date: Sun, 23 Feb 2020 10:00:34 +0000
Subject: [issue39726] ctypes on pypi has fallen behind
In-Reply-To: <1582432699.85.0.731912909682.issue39726@roundup.psfhosted.org>
Message-ID: <1582452034.23.0.134337560499.issue39726@roundup.psfhosted.org>


David Harding <hardingprofessional at gmail.com> added the comment:

Hi ammar2,

Your comment completely clears up my issue. I was just uninformed.

As you have stated, no change needs to be made to the pypi version.

To enforce a version of ctypes with venv/pip, I need only enforce a python version that is packaged with that version of ctypes.

I have closed this issue report. Thank you again for your time!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39726>
_______________________________________

From report at bugs.python.org  Sun Feb 23 05:08:44 2020
From: report at bugs.python.org (Arnon Yaari)
Date: Sun, 23 Feb 2020 10:08:44 +0000
Subject: [issue39729] stat.S_ISXXX can raise OverflowError for remote file
 modes
Message-ID: <1582452524.82.0.552566008779.issue39729@roundup.psfhosted.org>


New submission from Arnon Yaari <wiggin15 at gmail.com>:

The C implementation of the "stat" module on Python 3 (_stat) is using the type "mode_t" for file modes, which differs between operating systems. This type can be defined as either "unsigned short" (for example, in macOS, or the definition added specifically for Windows in _stat.c) or "unsigned long" (Linux and other Unix systems such as AIX).
This means that the "stat" module may only work with file modes that come from the same system that Python was compiled for.
It is sometimes desirable to work with file modes on remote systems (for example, when using the "fabric" module to handle remote files - https://github.com/fabric/fabric/blob/1.10/fabric/sftp.py#L42).
With the pure-python "stat" module on Python 2.7, using macros such as "stat.S_ISDIR" with any value used to work (even values that exceed "unsigned short" on macOS, for example) but with the C implementation this can result in an exception on systems with an "unsigned short" mode_t:

    >>> stat.S_ISDIR(0o240755)
    OverflowError: mode out of range

I encountered this exception when trying to "put" files from a macOS system to an AIX system with "fabric" (0o240755 is the st_mode found for "/" on AIX).

For uniform handling of file modes, modes should be handled as unsigned long instead of the system-defined "mode_t".

----------
components: Library (Lib)
messages: 362499
nosy: wiggin15
priority: normal
severity: normal
status: open
title: stat.S_ISXXX can raise OverflowError for remote file modes
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39729>
_______________________________________

From report at bugs.python.org  Sun Feb 23 06:08:24 2020
From: report at bugs.python.org (Mark Fernandes)
Date: Sun, 23 Feb 2020 11:08:24 +0000
Subject: [issue39730] Licence (license) for Python 3.8.1 is missing
Message-ID: <1582456104.31.0.935574059782.issue39730@roundup.psfhosted.org>


New submission from Mark Fernandes <mark.j.fernandes at gmail.com>:

At https://docs.python.org/3/license.html , the licence agreement for Python 3.8.2rc2 appears, however, I can't see the agreement for 3.8.1. It appears to be missing.

Likewise, other licences for various version numbers appear to be missing.

Also, it would be really helpful if you said one or more of the following:

 - that the licence only concerns:
     + copying, distribution, etc.
     + granting you extra copyright freedoms to those you already have under applicable law.
 - that there are no restrictions imposed on you by the licence, for the simple ordinary use of the software (that is other than copying, etc.) for x, y, z purposes.
 - that if you comply with the GPLv3 licence with respect to the software, you also meet the compliance requirements under the Python licence, and so you can treat the software as though it is GPLv3 software however, if you so treat the software, the software is still nonetheless licensed to you under the Python licence and NOT the GPL licence.

----------
assignee: docs at python
components: Documentation
messages: 362500
nosy: Mark Fernandes, docs at python
priority: normal
severity: normal
status: open
title: Licence (license) for Python 3.8.1 is missing
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39730>
_______________________________________

From report at bugs.python.org  Sun Feb 23 06:08:37 2020
From: report at bugs.python.org (Ammar Askar)
Date: Sun, 23 Feb 2020 11:08:37 +0000
Subject: [issue39729] stat.S_ISXXX can raise OverflowError for remote file
 modes
In-Reply-To: <1582452524.82.0.552566008779.issue39729@roundup.psfhosted.org>
Message-ID: <1582456117.14.0.211701371856.issue39729@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Size of the mode aside, isn't this approach problematic anyway? One platform could have an entirely different way of signalling ISDIR vs another. In this case using the host's S_ISDIR for the remote's mode would result in possibly incorrect values.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39729>
_______________________________________

From report at bugs.python.org  Sun Feb 23 06:21:42 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 11:21:42 +0000
Subject: [issue39648] Expand math.gcd() and math.lcm() to accept multiple
 arguments
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582456902.47.0.0473275502741.issue39648@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:


New changeset 559e7f165ad03731e6bc2211c0e6d8d9c02fb549 by Serhiy Storchaka in branch 'master':
bpo-39648: Expand math.gcd() and math.lcm() to handle multiple arguments. (GH-18604)
https://github.com/python/cpython/commit/559e7f165ad03731e6bc2211c0e6d8d9c02fb549


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 23 06:23:14 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 11:23:14 +0000
Subject: [issue39648] Expand math.gcd() and math.lcm() to accept multiple
 arguments
In-Reply-To: <1581860322.5.0.900527144573.issue39648@roundup.psfhosted.org>
Message-ID: <1582456994.68.0.167408069692.issue39648@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Merged; thank you to all involved.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39648>
_______________________________________

From report at bugs.python.org  Sun Feb 23 06:37:44 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 23 Feb 2020 11:37:44 +0000
Subject: [issue39730] Licence (license) for Python 3.8.1 is missing
In-Reply-To: <1582456104.31.0.935574059782.issue39730@roundup.psfhosted.org>
Message-ID: <1582457864.3.0.910829034274.issue39730@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
priority: normal -> high
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39730>
_______________________________________

From report at bugs.python.org  Sun Feb 23 07:06:26 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 23 Feb 2020 12:06:26 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582459586.2.0.844228444494.issue39724@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

I tend to think that we should avoid discrepancies with a simple Python command-line shell by default, and in this case I am not convinced that there is a good reason for a divergence in behavior.

I'd be happy to look into debugging this issue in the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sun Feb 23 07:16:45 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 12:16:45 +0000
Subject: [issue36027] Support negative exponents in pow() where a modulus is
 specified.
In-Reply-To: <1550520659.43.0.126744170658.issue36027@roundup.psfhosted.org>
Message-ID: <1582460205.14.0.032108553986.issue36027@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For tracker historians: see also #457066

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36027>
_______________________________________

From report at bugs.python.org  Sun Feb 23 07:25:22 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 12:25:22 +0000
Subject: [issue39657] Bezout and Chinese Remainder Theorem in the Standard
 Library?
In-Reply-To: <1581889239.13.0.672135436609.issue39657@roundup.psfhosted.org>
Message-ID: <1582460722.01.0.806496171803.issue39657@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm inclined to close this. Raymond, Tim: thoughts?

----------
assignee:  -> mark.dickinson
nosy: +rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39657>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:07:10 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 13:07:10 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1582463230.8.0.401546332322.issue39599@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/issue39599>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:08:03 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 13:08:03 +0000
Subject: [issue5996] abstract class instantiable when subclassing built-in
 types
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1582463283.76.0.078161983103.issue5996@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/issue5996>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:24:35 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 13:24:35 +0000
Subject: [issue38657] Clarify numeric padding behavior in string formatting
In-Reply-To: <1572554160.44.0.882070489525.issue38657@roundup.psfhosted.org>
Message-ID: <1582464275.24.0.992577841834.issue38657@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It looks as though this has been addressed, and can be closed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38657>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:30:39 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 23 Feb 2020 13:30:39 +0000
Subject: [issue39530] Documentation about comparisons between numeric types is
 misleading
In-Reply-To: <1580653054.78.0.127921454413.issue39530@roundup.psfhosted.org>
Message-ID: <1582464639.48.0.927138832126.issue39530@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +patch
pull_requests: +17980
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18615

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39530>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:31:32 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Feb 2020 13:31:32 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582464692.26.0.183042353741.issue39576@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
pull_requests: +17981
pull_request: https://github.com/python/cpython/pull/18616

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:36:57 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Feb 2020 13:36:57 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582465017.76.0.260169325124.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset b76518d43fb82ed9e5d27025d18c90a23d525c90 by Stefan Krah in branch 'master':
bpo-39576: Clarify the word size for the 32-bit build. (#18616)
https://github.com/python/cpython/commit/b76518d43fb82ed9e5d27025d18c90a23d525c90


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:37:33 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Feb 2020 13:37:33 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582465053.72.0.33774956311.issue39576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +17982
pull_request: https://github.com/python/cpython/pull/18617

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:37:40 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Feb 2020 13:37:40 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582465060.24.0.317888983739.issue39576@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17983
pull_request: https://github.com/python/cpython/pull/18618

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:43:04 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Feb 2020 13:43:04 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582465384.65.0.517309909451.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 24c570bbb82a7cb70576c253a73390accfa7ed78 by Miss Islington (bot) in branch '3.7':
bpo-39576: Clarify the word size for the 32-bit build. (GH-18616) (#18617)
https://github.com/python/cpython/commit/24c570bbb82a7cb70576c253a73390accfa7ed78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:44:29 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Sun, 23 Feb 2020 13:44:29 +0000
Subject: [issue39710] "will be returned as unicode" reminiscent from Python 2
In-Reply-To: <1582300708.21.0.335550003251.issue39710@roundup.psfhosted.org>
Message-ID: <1582465469.04.0.438572956466.issue39710@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
keywords: +patch
nosy: +dorosch
nosy_count: 2.0 -> 3.0
pull_requests: +17984
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18619

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39710>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:44:32 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Feb 2020 13:44:32 +0000
Subject: [issue39576] Surprising MemoryError in `decimal` with MAX_PREC
In-Reply-To: <1581046760.48.0.443155322154.issue39576@roundup.psfhosted.org>
Message-ID: <1582465472.34.0.228819517525.issue39576@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset c6ecd9c14081a787959e13df33e250102a658154 by Miss Islington (bot) in branch '3.8':
bpo-39576: Clarify the word size for the 32-bit build. (GH-18616) (#18618)
https://github.com/python/cpython/commit/c6ecd9c14081a787959e13df33e250102a658154


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39576>
_______________________________________

From report at bugs.python.org  Sun Feb 23 08:55:42 2020
From: report at bugs.python.org (Md. Al-Helal)
Date: Sun, 23 Feb 2020 13:55:42 +0000
Subject: [issue39731] ModuleNotFoundError: No module named '_ctypes'
Message-ID: <1582466142.44.0.612475216639.issue39731@roundup.psfhosted.org>


New submission from Md. Al-Helal <al2helal at gmail.com>:

ERROR: Command errored out with exit status 1:
     command: /usr/local/bin/python3.8 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-68ypuk30/django-tables2/setup.py'"'"'; __file__='"'"'/tmp/pip-install-68ypuk30/django-tables2/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-install-68ypuk30/django-tables2/pip-egg-info
         cwd: /tmp/pip-install-68ypuk30/django-tables2/
    Complete output (11 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/usr/local/lib/python3.8/site-packages/setuptools/__init__.py", line 20, in <module>
        from setuptools.dist import Distribution, Feature
      File "/usr/local/lib/python3.8/site-packages/setuptools/dist.py", line 35, in <module>
        from setuptools import windows_support
      File "/usr/local/lib/python3.8/site-packages/setuptools/windows_support.py", line 2, in <module>
        import ctypes
      File "/usr/local/lib/python3.8/ctypes/__init__.py", line 7, in <module>
        from _ctypes import Union, Structure, Array
    ModuleNotFoundError: No module named '_ctypes'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

----------
components: ctypes
messages: 362511
nosy: alhelal
priority: normal
severity: normal
status: open
title: ModuleNotFoundError: No module named '_ctypes'
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39731>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:04:28 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 14:04:28 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1582466668.79.0.677240382303.issue35885@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17985
pull_request: https://github.com/python/cpython/pull/18620

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:19:48 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 23 Feb 2020 14:19:48 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582467588.36.0.581353987118.issue39704@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

For me even a mail with a single line would be too much. I can filter that in my mail client but not on GitHub.

Speaking about that, I also don't want to get mail from Bevedere stating that I, in fact, have signed a CLA any time I open a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:23:39 2020
From: report at bugs.python.org (Mingye Wang)
Date: Sun, 23 Feb 2020 14:23:39 +0000
Subject: [issue39732] plistlib should export UIDs in XML like Apple does
Message-ID: <1582467819.43.0.259670073534.issue39732@roundup.psfhosted.org>


New submission from Mingye Wang <arthur200126 at gmail.com>:

Although there is no native UID type in Apple's XML format, Apple's NSKeyedArchiver still works with it because it converts the UID to a dict of {"CF$UID": int(some_uint64_val)}. Plistlib should do the same.

For a sample, see https://github.com/apple/swift-corelibs-foundation/blob/2a5bc4d8a0b073532e60410682f5eb8f00144870/Tests/Foundation/Resources/NSKeyedUnarchiver-ArrayTest.plist.

----------
components: Library (Lib)
messages: 362513
nosy: Artoria2e5
priority: normal
severity: normal
status: open
title: plistlib should export UIDs in XML like Apple does
type: behavior
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/issue39732>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:24:33 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 14:24:33 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1582467873.36.0.0162701570308.issue35885@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17986
pull_request: https://github.com/python/cpython/pull/18621

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:34:52 2020
From: report at bugs.python.org (Mingye Wang)
Date: Sun, 23 Feb 2020 14:34:52 +0000
Subject: [issue39732] plistlib should export UIDs in XML like Apple does
In-Reply-To: <1582467819.43.0.259670073534.issue39732@roundup.psfhosted.org>
Message-ID: <1582468492.85.0.171554630496.issue39732@roundup.psfhosted.org>


Change by Mingye Wang <arthur200126 at gmail.com>:


----------
keywords: +patch
pull_requests: +17987
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18622

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39732>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:41:54 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 14:41:54 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1582468914.06.0.690080276645.issue35885@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17988
pull_request: https://github.com/python/cpython/pull/18623

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:50:45 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 14:50:45 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1582469445.81.0.564387178555.issue35885@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

New PR: GH-18623

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 23 09:59:30 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 14:59:30 +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: <1582469970.86.0.767486898254.issue39128@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17989
pull_request: https://github.com/python/cpython/pull/18624

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:00:22 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 15:00:22 +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: <1582470022.69.0.513698183107.issue39128@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Created new PR and removed the old one GH-18624

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:01:13 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 23 Feb 2020 15:01:13 +0000
Subject: [issue35885] configparser: indentation
In-Reply-To: <1549061954.1.0.734541407213.issue35885@roundup.psfhosted.org>
Message-ID: <1582470073.52.0.257546791023.issue35885@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Your PRs are missing documentation and tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35885>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:07:50 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 15:07:50 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
In-Reply-To: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>
Message-ID: <1582470470.48.0.413787122115.issue39244@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17990
pull_request: https://github.com/python/cpython/pull/18625

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:09:55 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Feb 2020 15:09:55 +0000
Subject: [issue39728] Instantiating enum with invalid value results in
 ValueError twice
In-Reply-To: <1582448824.79.0.766917894274.issue39728@roundup.psfhosted.org>
Message-ID: <1582470595.28.0.33552854565.issue39728@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39728>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:11:05 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 15:11:05 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
In-Reply-To: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>
Message-ID: <1582470665.79.0.937900279396.issue39244@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Created a new clean PR GH-18625

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:18:42 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 15:18:42 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582471122.81.0.395739658749.issue38691@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17991
pull_request: https://github.com/python/cpython/pull/18627

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Sun Feb 23 10:19:44 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 15:19:44 +0000
Subject: [issue38691] importlib: PYTHONCASEOK should be ignored when using
 python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1582471184.78.0.685261602881.issue38691@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Added a new clean PR with the code changes, will let you know once the tests are fixed: GH-18627

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:00:04 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 23 Feb 2020 16:00:04 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582473604.21.0.900594119566.issue39698@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

I see that many breaking changes was done in recent releases. I get only the ones for `asyncio` in Python 3.8:

https://bugs.python.org/issue36921
https://bugs.python.org/issue36373
https://bugs.python.org/issue34790
https://bugs.python.org/issue32528
https://bugs.python.org/issue34687
https://bugs.python.org/issue32314

So I suppose the ship isn't sailed yet.


Passing a negative number to a function that should sleep the task for x seconds is a mistake. And mistakes should never pass silently.

Furthermore, coherence matters. It's really confusing that two functions in two builtin modules that are quite identical have a different behavior.

IMHO, deprecating and then removing support for negative argument in `asyncio.sleep()` is very much less breaking compared to issues #36921 and #36373 .

----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:24:28 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sun, 23 Feb 2020 16:24:28 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582475068.6.0.485797817998.issue39717@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Oh yes, this has bugged me often. Please fix it somehow.

Yes, using "from None" is probably the wrong way to go. Often we need more info in tracebacks, not less. But the "During handling" message is very misleading. Same as Ethan, many times I interpreted it as "something went wrong in the handler" when in fact the handler was doing exactly what it was supposed to do.

    except WhateverException as e:
        raise CustomException from e

might be too much to write every time, and while I understand that we cannot simply redefine `raise` under `except` to do that implicitly, maybe there is some middle solution. On Python-ideas, recently I saw an idea

    except WhateverException:
        raise as CustomException

which I like a lot, but I don't know how hard it is to implement.

---

If everything above seems like too much, at least we should consider changing the wording of the message. If it said

+"In the handler of the above exception, another exception was raised:"
-"During handling of the above exception, another exception occurred:"

I'd be much happier. And it would more often suggest the right thing.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:30:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Feb 2020 16:30:43 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1582475443.7.0.599108081653.issue2771@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/issue2771>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:39:06 2020
From: report at bugs.python.org (Arnon Yaari)
Date: Sun, 23 Feb 2020 16:39:06 +0000
Subject: [issue39729] stat.S_ISXXX can raise OverflowError for remote file
 modes
In-Reply-To: <1582452524.82.0.552566008779.issue39729@roundup.psfhosted.org>
Message-ID: <1582475946.42.0.00718514412769.issue39729@roundup.psfhosted.org>


Arnon Yaari <wiggin15 at gmail.com> added the comment:

Maybe so, but IMHO it is a lesser concern - the operating systems that use "unsigned long" add bits on the right, and don't change the less significant bits that the S_ISXXX macros check (if I am not mistaken, those bits are POSIX standards).
This issue is a regression from Python 2.7, so I believe it should be addressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39729>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:45:56 2020
From: report at bugs.python.org (Buzyboy)
Date: Sun, 23 Feb 2020 16:45:56 +0000
Subject: [issue19483] Pure-Python ElementTree classes no longer available
 since 3.3
In-Reply-To: <1383476320.61.0.0930927196631.issue19483@psf.upfronthosting.co.za>
Message-ID: <1582476356.22.0.782430802108.issue19483@roundup.psfhosted.org>


Change by Buzyboy <Buzyboy761 at gmail.com>:


Added file: https://bugs.python.org/file48904/Screenshot_20200223-214519.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19483>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:54:05 2020
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Feb 2020 16:54:05 +0000
Subject: [issue39691] Allow passing Pathlike objects to io.open_code
In-Reply-To: <1582153350.45.0.111444771925.issue39691@roundup.psfhosted.org>
Message-ID: <1582476845.12.0.886936962613.issue39691@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

As per PEP 578 it only accepts absolute path str.

Requires a documentation update to clarify, as this is not the only report. And issue39517 should add a str() call and ensure that the path is absolute.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, steve.dower
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39691>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:55:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Feb 2020 16:55:12 +0000
Subject: [issue39723] io.open_code should accept PathLike objects
In-Reply-To: <1582350228.37.0.922225151662.issue39723@roundup.psfhosted.org>
Message-ID: <1582476912.74.0.319753698185.issue39723@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Dup of issue39691

As per PEP 578, open_code only accepts an absolute path as a str. The other issue will be used to update the docstring.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Allow passing Pathlike objects to io.open_code

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39723>
_______________________________________

From report at bugs.python.org  Sun Feb 23 11:56:04 2020
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Feb 2020 16:56:04 +0000
Subject: [issue39517] runpy calls open_code with Path object
In-Reply-To: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>
Message-ID: <1582476964.91.0.991630354236.issue39517@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

open_code is correct according to PEP 578, so the fix here is for runpy to ensure the path is absolute and pass it through os.fsdecode() before calling io.open_code().

----------
nosy: +steve.dower
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39517>
_______________________________________

From report at bugs.python.org  Sun Feb 23 12:07:09 2020
From: report at bugs.python.org (Rahul Kumaresan)
Date: Sun, 23 Feb 2020 17:07:09 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1582477629.39.0.852982559869.issue39712@roundup.psfhosted.org>


Rahul Kumaresan <kayrahul at gmail.com> added the comment:

I would like to work on this issue.
Can you please suggest me specifics that I should be considering before I update the doc with the suggested inclusions.

----------
nosy: +rahul-kumi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Sun Feb 23 12:48:43 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Feb 2020 17:48:43 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582480123.1.0.445478360925.issue39717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Looking back at PEP3134 [1], the 

    raise NewException from exc

is used as one of the examples.


[1] https://www.python.org/dev/peps/pep-3134/#id37

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Sun Feb 23 12:52:34 2020
From: report at bugs.python.org (Ondrej Jakubcik)
Date: Sun, 23 Feb 2020 17:52:34 +0000
Subject: [issue35810] Object Initialization does not incref Heap-allocated
 Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1582480354.77.0.0703564410504.issue35810@roundup.psfhosted.org>


Ondrej Jakubcik <ojakubcik at gmail.com> added the comment:

How does this change affect stable ABI? Is it necessary to change the logic in modules that use only the Py_LIMITED_API?

----------
nosy: +Ondrej Jakubcik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Sun Feb 23 12:52:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 23 Feb 2020 17:52:37 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582480357.11.0.0736677679776.issue39724@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

It sounds like either an old implementation restriction or an old misguided attempt at keeping the IDLE console clean. I?m with Tal, let?s fix it and make it more like regular Python. Thanks John for taking the time to report this so clearly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sun Feb 23 12:54:50 2020
From: report at bugs.python.org (Xinfa Zhu)
Date: Sun, 23 Feb 2020 17:54:50 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582480490.57.0.0449271251733.issue38597@roundup.psfhosted.org>


Xinfa Zhu <xinfazhu at gmail.com> added the comment:

I have a similar issue. Do we have an estimate how long it may take to fix this bug? Thanks. I can help but would need some mentoring.

----------
nosy: +xinfazhu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Sun Feb 23 12:56:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 23 Feb 2020 17:56:37 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1582480597.23.0.182979050615.issue39019@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Once PEP 585 is implemented these should be rolled back and replaced with that, right?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Sun Feb 23 13:24:47 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Feb 2020 18:24:47 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582482287.43.0.847790886088.issue39725@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I think the way forward is going to be a recursive walk back to the first exception, and if __suppress_context__ is true for any exception then only the previous exception is omitted.

For example, the above example had the following chain:

Exception    __context__    __cause__    __suppress_context__
---------    -----------    ---------    --------------------
TypeError:     None           None          False
KeyError:      TypeError      None          False
KeyError:      KeyError       None          True

When walking the stack to decide which items get printed, the final KeyError is printed (obviously, as it's the last one), but because its __suppress_context__ is True then the immediately preceding exception, the first KeyError, is skipped; however, the first KeyError's __suppress_context__ is False, so we do print its __context__, which is the TypeError.  Giving us a traceback similar to:

---------------------------------------------------------------------
Traceback (most recent call last):
TypeError: str expected, not type

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
KeyError: 'NEW_VARIABLE'
---------------------------------------------------------------------

Which is entirely correct.

In cases where NewException has it's __cause__ set, we should print that as normal, then keep following the NewException.__context__ chain (with some kind of verbage or visual indicator between the __context__ and the __cause__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sun Feb 23 13:26:07 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Feb 2020 18:26:07 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582482367.77.0.939160080705.issue39725@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Can this be fixed in the traceback module or is there C code behind it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sun Feb 23 13:32:09 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 23 Feb 2020 18:32:09 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1582482729.34.0.94108471382.issue39019@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

> Once PEP 585 is implemented these should be rolled back and replaced with that, right?

I would say that ideally yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Sun Feb 23 14:43:45 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 23 Feb 2020 19:43:45 +0000
Subject: [issue39732] plistlib should export UIDs in XML like Apple does
In-Reply-To: <1582467819.43.0.259670073534.issue39732@roundup.psfhosted.org>
Message-ID: <1582487025.89.0.885413990237.issue39732@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +serhiy.storchaka
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39732>
_______________________________________

From report at bugs.python.org  Sun Feb 23 14:44:10 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 23 Feb 2020 19:44:10 +0000
Subject: [issue39657] Bezout and Chinese Remainder Theorem in the Standard
 Library?
In-Reply-To: <1581889239.13.0.672135436609.issue39657@roundup.psfhosted.org>
Message-ID: <1582487050.28.0.353825547775.issue39657@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Ya, I'll close this, channeling that Raymond would also reject it for now (although he's certainly free to reopen it).

There's nothing wrong with adding such functions, but the `math` module is already straying too far from its original intent as a home for floating-point functions, nearly all of which had counterparts in `cmath`.  _If_ we had a, say, `imath` module, it would be a much easier sell.

These are just "too specialized".  I'd put them in the same class as, say, a new function to compute the Jacobi symbol.  Very handy but only for a vanishingly small percentage of Python users.

Probably _the_ most common use for xgcd (or egcd, either of which I suggest are better names than `bezout` - "extended gcd" is descriptive and commonly used) is for finding modular inverses, but `pow()` does that now directly.

For Chinese remainder, I'd suggest two changes:

1. Generalize to any number of bases.  The 2-base case is common in toy RSA implementations, but in that context a more efficient way is generally used, based on precomputing "helper constants" specific to the modulus's 2 factors.

2. Since the same bases are generally used over & over while only the remainders change, the function signature would be more usable if it accepted a sequence of remainders, and a sequence of corresponding bases, as two distinct arguments.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39657>
_______________________________________

From report at bugs.python.org  Sun Feb 23 14:59:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Feb 2020 19:59:56 +0000
Subject: [issue39724] IDLE threading + stdout/stdin observed blocking behavior
In-Reply-To: <1582367377.76.0.509554808526.issue39724@roundup.psfhosted.org>
Message-ID: <1582487996.07.0.517946284601.issue39724@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I found a stackoverflow question (and my then answer) about the same issue:
https://stackoverflow.com/questions/50108354/python-idle-running-code-differently-than-other-ides

Although the code posted does not run, it gives a very legitimate use case (<Enter> is the signal) in which stream mixing is the lesser evil compared to the clearly wrong blocking of the output needed to decide when to give the signal. I now agree we should fix blocking now, if possible.

Tal, I posted my observations partly in the hope that you might be able to extend them.  So please take a look.

I am thinking about how to test a fix.  Test code needs to be able to 1. send code to be executed by run.py, 2. send a response to input() calls in the code, and 3. retrieve all output from the code.  New test machinery, needed not just for this issue, should be a separate issue.

A possibility including the minimum of transport machinery would be to replace the StdInputFile and StdOutputFile in run.py with test classes giving the needed test access.  Without knowing where the block is, it is unclear how much of the run machinery has to be included.

Another possibility, including all of the transport machinery except for the gui display, would be a test interpreter connected to an unaltered run process through a socket, as usual.  pyshell.PyShell (the shell window itself) initializespyshell.ModifiedInterpreter with itself.  A no-gui TestShell could do the same.  The TestShell would also need TestIn/OutputFile replacements.

----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39724>
_______________________________________

From report at bugs.python.org  Sun Feb 23 15:06:32 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 23 Feb 2020 20:06:32 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1582488392.46.0.90983925545.issue37970@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Sun Feb 23 15:48:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 23 Feb 2020 20:48:40 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1582490920.8.0.755461285391.issue39427@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 13951c7f25c628ea2dc0a869ebe18e7bf593fa6d by Pablo Galindo in branch '3.8':
[3.8] bpo-39427: Document -X opt options in the CLI --help and the man page (GH-18131) (GH-18133)
https://github.com/python/cpython/commit/13951c7f25c628ea2dc0a869ebe18e7bf593fa6d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Sun Feb 23 15:48:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 23 Feb 2020 20:48:40 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1582490920.97.0.335519430845.issue39427@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 333b9899fc7807575d1742b77b4633ac53bd528f by Pablo Galindo in branch '3.7':
[3.7] bpo-39427: Document -X opt options in the CLI --help and the man page (GH-18131) (#18134)
https://github.com/python/cpython/commit/333b9899fc7807575d1742b77b4633ac53bd528f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Sun Feb 23 15:48:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 23 Feb 2020 20:48:40 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1582490920.8.0.755461285391.issue39427@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 13951c7f25c628ea2dc0a869ebe18e7bf593fa6d by Pablo Galindo in branch '3.8':
[3.8] bpo-39427: Document -X opt options in the CLI --help and the man page (GH-18131) (GH-18133)
https://github.com/python/cpython/commit/13951c7f25c628ea2dc0a869ebe18e7bf593fa6d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Sun Feb 23 15:51:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 23 Feb 2020 20:51:42 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1582491102.52.0.595203962379.issue39427@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/issue39427>
_______________________________________

From report at bugs.python.org  Sun Feb 23 15:55:30 2020
From: report at bugs.python.org (12345NotFromHere54321)
Date: Sun, 23 Feb 2020 20:55:30 +0000
Subject: [issue39733] Bug in hypergeometric function
Message-ID: <1582491330.33.0.385073270653.issue39733@roundup.psfhosted.org>


New submission from 12345NotFromHere54321 <carlk at rocketmail.com>:

I want to evaluate Kummer's hypergeometric function. 

Code:
import scipy.special as sc
import numpy as np
 
#Parameters etc:
p=2 
s = -4.559190954155 -51.659216953928*1j

Evaluation:
s = -4.559190954155 -51.659216953928*1j
sc.hyp1f1(1/p, 1/p + 1, -s) 

Output:
(0.999999999999721-2.57668886227691e-13j)
This is close to 1 and agrees with Mathematica (see below)

Because the parameters 1/p and 1/p+1 are real, we know that if we replace s by its conjugate, the output should be the conjugate of the first output. This turns out not to be the case:

Evaluation:
s = -4.559190954155 -51.659216953928*1j
s = np.conj(s)
sc.hyp1f1(1/p, 1/p + 1, -s) 

Output:
(0.8337882727951572+0.1815268182862942j)

This is very far from 1. There seems to be a bug.


Mathematica:
s =  (-4.559190954155+51.659216953928I)
sconj=Conjugate[s]
Hypergeometric1F1[1/2,3/2,-s]
Hypergeometric1F1[1/2,3/2,-sconj]


Out[9]= 1.+1.99922*^-11 \[ImaginaryI]

Out[10]= 1.-1.99922*^-11 \[ImaginaryI]

----------
messages: 362539
nosy: 12345NotFromHere54321
priority: normal
severity: normal
status: open
title: Bug in hypergeometric function
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39733>
_______________________________________

From report at bugs.python.org  Sun Feb 23 16:03:30 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 23 Feb 2020 21:03:30 +0000
Subject: [issue39733] Bug in hypergeometric function
In-Reply-To: <1582491330.33.0.385073270653.issue39733@roundup.psfhosted.org>
Message-ID: <1582491810.18.0.231967406981.issue39733@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Hi, this is a wrong bug tracker. You can report numpy issues at https://github.com/numpy/numpy/issues and scipy one's at https://github.com/scipy/scipy/issues

----------
nosy: +SilentGhost
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39733>
_______________________________________

From report at bugs.python.org  Sun Feb 23 16:42:19 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Sun, 23 Feb 2020 21:42:19 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582494139.64.0.600664176486.issue39622@roundup.psfhosted.org>


Change by Maor Kleinberger <kmaork at gmail.com>:


----------
keywords: +patch
pull_requests: +17992
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18628

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Sun Feb 23 16:49:07 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Sun, 23 Feb 2020 21:49:07 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582494547.48.0.927626445308.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

After digging into asyncio, I stumbled upon this particularly suspicious block in BaseEventLoop._run_once: https://github.com/python/cpython/blob/v3.9.0a3/Lib/asyncio/base_events.py#L1873

handle = self._ready.popleft()
if handle._cancelled:
    continue
if self._debug:
    ...
    handle._run()
    ...
else:
    handle._run()

As you can see, a callback is popped from the dequeue of ready callbacks, and only after a couple of lines that callback is called. The question arises, what happens if an exception is raised in between? Or more specifically, What happens to that callback if a KeyboardInterrupt is raised before it is called?
Well, appparently it dies and becomes one with the universe. The chances of it happening are the highest when the ioloop is running very short coroutines (like sleep(0)), and are increased when debug is on (because more code is executed in between).

This is how the bug we've been experiencing came to life:
When SIGINT is received it raises a KeyboardInterrupt in the running frame. If the running frame is a coroutine, it stops, the exception climbs up the stack, and the ioloop shuts down. Otherwise, the KeyboardInterrupt is probably raised inside asyncio's code, somewhere inside run_forever. In that case, the ioloop stops and proceeds to cancel all of the running tasks. After cancelling all the tasks, asyncio actually reruns the ioloop so all tasks receive the CancelledError and handle it or just die (see asyncio.runners._cancel_all_tasks).
Enter our bug; sometimes, randomly, the loop gets stuck waiting for all the cancelled tasks to finish. This behavior is caused by the flaw I described earlier - if the KeyboardInterrupt was raised after a callback was popped and before it was run, the callback is lost and the task that was waiting for it will wait forever.
Depending on the running tasks, the event loop might hang on the select call (until a interrupted by a signal, like SIGINT). This is what happens in SleepTest.py. Another case might be that only a part of the ioloop gets stuck, and other parts that are not dependent on the lost call still run correctly (and run into a CancelledError). This behavior is demonstrated in the script I added to this thread, asyncio_bug_demo.py.

I see two possible solutions:
1. Make all the code inside run_forever signal safe
2. Override the default SIGINT handler in asyncio.run with one more fitting the way asyncio works

I find the second solution much easier to implement well, and I think it makes more sense. I think python's default SIGINT handler fits normal single-threaded applications very well, but not so much an event loop. When using an event loop it makes sense to handle a signal as an event an process it along with the other running tasks. This is fully supported by the ioloop with the help of signal.set_wakeup_fd.
I have implemented the second solution and opened a PR, please review it and tell me what you think!

----------
Added file: https://bugs.python.org/file48906/asyncio_bug_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Sun Feb 23 16:50:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 23 Feb 2020 21:50:54 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582494654.4.0.184754716803.issue39717@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/issue39717>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:13:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Feb 2020 22:13:18 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582495998.94.0.140176225455.issue39725@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is more complicated. In the following example

try:
    try:
        raise TypeError
    except:
        try:
            try:
                raise OverflowError
            except:
                raise ValueError
        except:
            raise KeyError from None
except BaseException as exc:
    e = exc

the __context__ chain is KeyError -> ValueError -> OverflowError -> TypeError. We want to suppress ValueError and OverflowError, and keep KeyError -> TypeError. I afraid that the chain of exceptions just do not have enough information to do this. Maybe analyzing tracebacks can help, but it looks too complex.

Maybe the simpler solution is to "cut" __context__ when we leave an exception handler. If __suppress_context__ is true and the current handled exception is not __context__, set it as __context__.

Here is a PR which implements this solution. I am not sure that it is correct, and it may miss some corner cases, it is just an example. Pay attention to the ipaddress module: in some cases we want to suppress more than one exception, and currently it is inconvenient.


Maybe we incorrectly handle exception chains. Maybe they should be build in a way similar to tracebacks: initially set __context__ to None and add a handled exception to the end of the chain when leave an exception handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:13:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Feb 2020 22:13:32 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1582496012.19.0.0696744481573.issue39019@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
nosy_count: 4.0 -> 5.0
pull_requests: +17994
pull_request: https://github.com/python/cpython/pull/18629

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:18:07 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Sun, 23 Feb 2020 22:18:07 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582496287.36.0.630020349206.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

After opening the PR, I see that add_signal_handler is not supported on non-unix event loop. After looking at the code, it seems there is no problem to implement it for other platforms, as it relies on signal.set_wakeup_fd() which seems to support all platforms. Should I open an enhancement issue for implementing add_signal_handler for all platforms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:22:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Feb 2020 22:22:29 +0000
Subject: [issue39732] plistlib should export UIDs in XML like Apple does
In-Reply-To: <1582467819.43.0.259670073534.issue39732@roundup.psfhosted.org>
Message-ID: <1582496549.68.0.532268337472.issue39732@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39732>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:27:16 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sun, 23 Feb 2020 22:27:16 +0000
Subject: [issue39697] Failed to build with --with-cxx-main=g++-9.2.0
In-Reply-To: <1582198678.47.0.589589124523.issue39697@roundup.psfhosted.org>
Message-ID: <1582496836.26.0.984627483986.issue39697@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

I think in this case the error is more trivial: simply `Programs/_testembed.c` is compiled with g++ but it should be compiled with gcc.

Indeed, there are much gcc-only options in the compilation of `Programs/_testembed.c`, and g++ complains about them:

> cc1plus: warning: ?-Werror=? argument ?-Werror=implicit-function-declaration? is not valid for C++
> cc1plus: warning: command line option ?-std=c99? is valid for C/ObjC but not for C++

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39697>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:34:00 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 23 Feb 2020 22:34:00 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582497240.12.0.510177572944.issue39681@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset 9f37872e307734666a7169f7be6e3370d3068282 by Antoine Pitrou in branch 'master':
bpo-39681: Fix C pickle regression with minimal file-like objects (#18592)
https://github.com/python/cpython/commit/9f37872e307734666a7169f7be6e3370d3068282


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:34:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 23 Feb 2020 22:34:06 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582497246.45.0.387555913327.issue39681@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +17995
pull_request: https://github.com/python/cpython/pull/18630

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:37:02 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Feb 2020 22:37:02 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582497422.19.0.234256267816.issue39725@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17996
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18629

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:37:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 23 Feb 2020 22:37:39 +0000
Subject: [issue39019] Missing class getitems in standard library classes
In-Reply-To: <1576000554.09.0.555887969918.issue39019@roundup.psfhosted.org>
Message-ID: <1582497459.66.0.533034024206.issue39019@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests:  -17994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39019>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:47:08 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 23 Feb 2020 22:47:08 +0000
Subject: [issue39734] Deprecate readinto() fallback path in _pickle.c
Message-ID: <1582498028.39.0.0123392152586.issue39734@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

In issue39681 we reestablished the fallback to read() when a file-like object doesn't provide readinto() in _pickle.c.  However, doing so leads to lower performance and all file-like object should nowadays provide readinto() (simply by deriving from the right base class - e.g. io.BufferedIOBase).

I propose to issue a DeprecationWarning when the fallback behaviour is selected, so that one day we can finally remove it.

----------
components: Library (Lib)
messages: 362547
nosy: ogrisel, pierreglaser, pitrou
priority: low
severity: normal
status: open
title: Deprecate readinto() fallback path in _pickle.c
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39734>
_______________________________________

From report at bugs.python.org  Sun Feb 23 17:53:27 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 23 Feb 2020 22:53:27 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582498407.95.0.216195253666.issue39681@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:


New changeset b19f7ecfa3adc6ba1544225317b9473649815b38 by Miss Islington (bot) in branch '3.8':
bpo-39681: Fix C pickle regression with minimal file-like objects (GH-18592) (#18630)
https://github.com/python/cpython/commit/b19f7ecfa3adc6ba1544225317b9473649815b38


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Sun Feb 23 18:10:39 2020
From: report at bugs.python.org (Steve Dower)
Date: Sun, 23 Feb 2020 23:10:39 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582499439.61.0.714036553511.issue38597@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Okay, looking at _find_vcvarsall in distutils, I'm guessing that something about how your machines are set up means that the vcredist search is failing.

First, could you specify which versions of Visual Studio you have installed, and if possible which one is being found and used by your builds.

Then, if you can search your install to find both vcvarsall.bat and vcruntime140.dll (there will be a few of these) and post the paths, that may indicate if the layout isn't consistent.

Distutils will try and dynamically link to the runtime if you have the redist, and statically link it if you don't (though I don't remember why it doesn't just rely on the copy included with Python... probably future-proofing or licencing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Sun Feb 23 18:20:42 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 23:20:42 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1582500042.7.0.199403254598.issue37970@roundup.psfhosted.org>


Change by Ido Michael <michael.ido at gmail.com>:


----------
pull_requests: +17997
pull_request: https://github.com/python/cpython/pull/18631

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Sun Feb 23 18:22:55 2020
From: report at bugs.python.org (Ido Michael)
Date: Sun, 23 Feb 2020 23:22:55 +0000
Subject: [issue37970] urllib.parse docstrings incomplete
In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org>
Message-ID: <1582500175.14.0.625609543317.issue37970@roundup.psfhosted.org>


Ido Michael <michael.ido at gmail.com> added the comment:

Created PR, most of the documentation besides the func signature looked alright: GH-18631

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37970>
_______________________________________

From report at bugs.python.org  Sun Feb 23 19:23:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 00:23:57 +0000
Subject: [issue36468] Treeview: wrong color change
In-Reply-To: <1553848318.4.0.250762836848.issue36468@roundup.psfhosted.org>
Message-ID: <1582503837.78.0.319095814228.issue36468@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified that problem continues on Windows with 3.8 and 3.9 alpha (with tk 8.6.9 -- might get updated later) and that fix posted by Matthew works.  I am testing because of #39636.

----------
nosy: +terry.reedy
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36468>
_______________________________________

From report at bugs.python.org  Sun Feb 23 19:29:08 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 00:29:08 +0000
Subject: [issue39636] Can't change Treeview row color in Tkinter
In-Reply-To: <1581764507.66.0.693125881903.issue39636@roundup.psfhosted.org>
Message-ID: <1582504148.38.0.674015057676.issue39636@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When I ran the initial test code of #36468, everything was black on white.  When I added Matthew Barnett's fix, both text and background were changed.  Until we get test code and version information that we can run and verify a problem with the fix, I am closing this.

The fix was copied from the tk buglist, https://core.tcl.tk/tk/info/509cafafae, where it got other verifications.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39636>
_______________________________________

From report at bugs.python.org  Sun Feb 23 19:37:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 00:37:41 +0000
Subject: [issue39642] Behaviour of disabled widgets: widget.bind(func) -vs- w
 = widget(command=func)
In-Reply-To: <1581822693.94.0.0781458615006.issue39642@roundup.psfhosted.org>
Message-ID: <1582504661.45.0.415743115095.issue39642@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am sure that the behavior you observe is correct.  The default button click handler must check the state before calling the command function, while I presume that your printBtn_onclick function (not shown) does not.  If Serhiy disagrees, he can reopen.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39642>
_______________________________________

From report at bugs.python.org  Sun Feb 23 20:15:24 2020
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 24 Feb 2020 01:15:24 +0000
Subject: [issue37539] CheckCommitCursorReset regression sqlite3 test fails
 with old sqlite3
In-Reply-To: <1562744749.11.0.451053951717.issue37539@roundup.psfhosted.org>
Message-ID: <1582506924.64.0.261986857283.issue37539@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thank you for the report and for the patch!

The minimum supported SQLite 3 version in Python 3 is 3.7.2 as declared at https://github.com/python/cpython/blob/9f37872e307734666a7169f7be6e3370d3068282/setup.py#L1364 

While it's still 3.0.8 in Python 2.7 (https://github.com/python/cpython/blob/249706c1fbce04125d81bd9993e6c010ae30f8e4/setup.py#L1175), I think we can live without the patch as Python 2.7 is now officially dead.

Of course, we can still apply it if one of our 2.7 buildbots were failing due to an ancient version of SQLite 3.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37539>
_______________________________________

From report at bugs.python.org  Sun Feb 23 20:23:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 01:23:48 +0000
Subject: [issue39653] test_posix fails during make test
In-Reply-To: <1581873332.9.0.500912340754.issue39653@roundup.psfhosted.org>
Message-ID: <1582507428.22.0.162144896468.issue39653@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My understanding that Python is compiled and installed and that the failure was during a later test.

In repository master (3.9) the line is 1549 instead of 1529.  The test function code is

    def test_no_such_executable(self):
        no_such_executable = 'no_such_executable'
        try:
            pid = self.spawn_func(no_such_executable,
                                  [no_such_executable],
                                  os.environ)
        # bpo-35794: PermissionError can be raised if there are
        # directories in the $PATH that are not accessible.
        except (FileNotFoundError, PermissionError) as exc:
            self.assertEqual(exc.filename, no_such_executable)
        else:
            pid2, status = os.waitpid(pid, 0)
            self.assertEqual(pid2, pid)
            self.assertNotEqual(status, 0)

It is part of a mixin class and once mixed in, spawn_func is either posix_spawn or posix_spawnp.  The first parameter is 'path'.

"The path parameter is the path to the executable file.The path should contain a directory.  Use posix_spawnp() to pass an executable file without directory."

FileNotFoundError and PermissionError are subclasses of OSError.  So is NotADirectoryError.  I was initially tempted to say that either the latter should be added to the tuple or that the tuple should be replaced by OSError.  However, the test failed with posix_spawnp, when the path should not be required to have a directory.  So I wonder if there is a problem with this function on this Debian.  (I do not work with Linux at all.)

Zachary, could you try adding NotADirectoryError to the exception list and see if the test
    self.assertEqual(exc.filename, no_such_executable)
passes?

----------
components: +Library (Lib), Tests -Installation
nosy: +larry, vstinner
stage:  -> test needed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39653>
_______________________________________

From report at bugs.python.org  Sun Feb 23 20:51:46 2020
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 24 Feb 2020 01:51:46 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582509106.33.0.838826594061.issue30566@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
nosy: +berker.peksag
nosy_count: 3.0 -> 4.0
pull_requests: +17998
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18632

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Sun Feb 23 20:52:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 01:52:56 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582509176.51.0.425965817868.issue39654@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Unlike the 3.9 code and doc change in #39411, this doc change applies since 3.7.  It does not conflict with #39411.

----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 20:57:32 2020
From: report at bugs.python.org (Xinfa Zhu)
Date: Mon, 24 Feb 2020 01:57:32 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582509452.21.0.119788009171.issue38597@roundup.psfhosted.org>


Xinfa Zhu <xinfazhu at gmail.com> added the comment:

Thanks Steve. Here is what you requested.

xinfa at LAPTOP-71TBJKSA MINGW64 /c/Program Files (x86)/Microsoft Visual Studio
$ ./Installer/vswhere.exe
Visual Studio Locator version 2.7.1+180c706d56 [query version 2.3.2200.14893]
Copyright (C) Microsoft Corporation. All rights reserved.

xinfa at LAPTOP-71TBJKSA MINGW64 /c/Program Files (x86)/Microsoft Visual Studio
$ find . -name "vcvarsall.bat"
./2019/BuildTools/VC/Auxiliary/Build/vcvarsall.bat

xinfa at LAPTOP-71TBJKSA MINGW64 /c/Program Files (x86)/Microsoft Visual Studio
$ find . -name "vcruntime140.dll"
./2019/BuildTools/VC/Redist/MSVC/14.24.28127/onecore/x64/Microsoft.VC142.CRT/vcruntime140.dll
./2019/BuildTools/VC/Redist/MSVC/14.24.28127/onecore/x86/Microsoft.VC142.CRT/vcruntime140.dll
./2019/BuildTools/VC/Redist/MSVC/14.24.28127/x64/Microsoft.VC142.CRT/vcruntime140.dll
./2019/BuildTools/VC/Redist/MSVC/14.24.28127/x86/Microsoft.VC142.CRT/vcruntime140.dll
./2019/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x64/vcruntime140.dll
./2019/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx64/x86/vcruntime140.dll
./2019/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx86/x64/vcruntime140.dll
./2019/BuildTools/VC/Tools/MSVC/14.24.28314/bin/Hostx86/x86/vcruntime140.dll
./Installer/resources/app/ServiceHub/Services/Microsoft.VisualStudio.Setup.Service/vcruntime140.dll
./Installer/vcruntime140.dll

xinfa at LAPTOP-71TBJKSA MINGW64 /c/Program Files (x86)/Microsoft Visual Studio


I want mention that I have 301 extension modules. I used setuptools in my setup.py
    from setuptools import setup
    from setuptools.extension import Extension
python setup.py build_ext
python setup.py bdist_wheel
I bring the whl file to another computer, pip install, then launch the app and I get this error
ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed.

I tried using distutils instead, but it says: error: invalid command 'bdist_wheel'
    from distutils.core import setup
    from distutils.extension import Extension

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Sun Feb 23 21:01:10 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 02:01:10 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582509670.68.0.697084622425.issue39654@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +17999
pull_request: https://github.com/python/cpython/pull/18633

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 21:00:44 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 02:00:44 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582509644.18.0.290051235589.issue39654@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset aea045adb8c90394264908670cbc495c5a41b65e by Hakan ?elik in branch 'master':
bpo-39654: Update pyclbr doc to reflect additional information returned (GH-18528)
https://github.com/python/cpython/commit/aea045adb8c90394264908670cbc495c5a41b65e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 21:01:16 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 02:01:16 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582509676.48.0.95272770815.issue39654@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18000
pull_request: https://github.com/python/cpython/pull/18634

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 21:07:40 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 02:07:40 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582510060.03.0.771189887864.issue39654@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 973348427e3e987f42ea8a871e18c8d17b5abf52 by Miss Islington (bot) in branch '3.8':
bpo-39654: Update pyclbr doc to reflect additional information returned (GH-18528)
https://github.com/python/cpython/commit/973348427e3e987f42ea8a871e18c8d17b5abf52


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 21:07:54 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 02:07:54 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582510074.19.0.684927478289.issue39654@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d57f99929a4013741f14233ed6e517ad6c9b24d0 by Miss Islington (bot) in branch '3.7':
bpo-39654: Update pyclbr doc to reflect additional information returned (GH-18528)
https://github.com/python/cpython/commit/d57f99929a4013741f14233ed6e517ad6c9b24d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 21:08:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 02:08:21 +0000
Subject: [issue39654] pyclbr: remove old references to class browser & add
 explain readmodule
In-Reply-To: <1581879663.39.0.234173268423.issue39654@roundup.psfhosted.org>
Message-ID: <1582510101.38.0.378177966838.issue39654@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/issue39654>
_______________________________________

From report at bugs.python.org  Sun Feb 23 22:15:06 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 03:15:06 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1582514106.17.0.685100266018.issue39649@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18001
pull_request: https://github.com/python/cpython/pull/18635

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 23 22:14:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 24 Feb 2020 03:14:57 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1582514097.24.0.059555646494.issue39649@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 4015d1cda3cdba869103779eb6ff32ad798ff885 by Daniel Hahler in branch 'master':
bpo-39649: Remove obsolete check for `__args__` in bdb.Bdb.format_stack_entry (GH-18531)
https://github.com/python/cpython/commit/4015d1cda3cdba869103779eb6ff32ad798ff885


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 23 22:15:13 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 03:15:13 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1582514113.17.0.362863719136.issue39649@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18002
pull_request: https://github.com/python/cpython/pull/18636

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 23 22:22:43 2020
From: report at bugs.python.org (Masahiro Sakai)
Date: Mon, 24 Feb 2020 03:22:43 +0000
Subject: [issue39735] Signal handler is invoked recursively
Message-ID: <1582514563.33.0.732332773883.issue39735@roundup.psfhosted.org>


New submission from Masahiro Sakai <masahiro.sakai at gmail.com>:

If I run following program, the parent process fails with "RecursionError: maximum recursion depth exceeded", because the signal handler is invoked during the execution of the same handler.

----
import os
import signal
import time

def f(signum, frame):
    time.sleep(1)

signal.signal(signal.SIGUSR1, f)

parent_pid = os.getpid()
child_pid = os.fork()
if child_pid == 0:
    for i in range(100000):
        os.kill(parent_pid, signal.SIGUSR1)
        time.sleep(0.01)
else:
    os.waitpid(child_pid, 0)
----

This behavior is in contrast to other languages such as C or Ruby.

In C, when a handler function is invoked on a signal, that signal is automatically blocked during the time the handler is running, unless SA_NODEFER is specified.

In Ruby, signal handler is handled in a way similar to Python (i.e. flag is set by C-level signal handler and Ruby/Python-level signal handler is executed later point which is safe for VM), but it prevents recursive signal handler invocation. (Related issue and commit: https://bugs.ruby-lang.org/issues/6009 https://github.com/ruby/ruby/commit/6190bb4d8ad7a07ddb1da8fc687b20612743a34a )

I believe that behavior of C and Ruby is desirable, because writing reentrant signal handler is sometimes error prone.

----------
components: Extension Modules
messages: 362562
nosy: msakai
priority: normal
severity: normal
status: open
title: Signal handler is invoked recursively
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39735>
_______________________________________

From report at bugs.python.org  Sun Feb 23 22:32:54 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 03:32:54 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1582515174.2.0.719181859814.issue39649@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 097612a3f711f5a6a3aec207cad78a35eb3a756d by Miss Islington (bot) in branch '3.7':
bpo-39649: Remove obsolete check for `__args__` in bdb.Bdb.format_stack_entry (GH-18531)
https://github.com/python/cpython/commit/097612a3f711f5a6a3aec207cad78a35eb3a756d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 23 22:33:11 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 03:33:11 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1582515191.46.0.146327457824.issue39649@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c97fc564a6c76ba5287f1b16bc841a1765820b0c by Miss Islington (bot) in branch '3.8':
bpo-39649: Remove obsolete check for `__args__` in bdb.Bdb.format_stack_entry (GH-18531)
https://github.com/python/cpython/commit/c97fc564a6c76ba5287f1b16bc841a1765820b0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:24:30 2020
From: report at bugs.python.org (Andy Lester)
Date: Mon, 24 Feb 2020 04:24:30 +0000
Subject: [issue39736] const strings in Modules/_datetimemodule.c and
 Modules/_testbuffer.c
Message-ID: <1582518270.89.0.669104927357.issue39736@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

In Modules/_datetimemodule.c, the char *timespec and char *specs[] can be made const.  Their contents are never modified.

In ndarray_get_format in Modules/_testbuffer.c, char *fmt can be made const.

----------
components: Interpreter Core
messages: 362565
nosy: petdance
priority: normal
severity: normal
status: open
title: const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39736>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:26:48 2020
From: report at bugs.python.org (Andy Lester)
Date: Mon, 24 Feb 2020 04:26:48 +0000
Subject: [issue39736] const strings in Modules/_datetimemodule.c and
 Modules/_testbuffer.c
In-Reply-To: <1582518270.89.0.669104927357.issue39736@roundup.psfhosted.org>
Message-ID: <1582518408.3.0.955196341208.issue39736@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +18003
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18637

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39736>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:50:34 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Feb 2020 04:50:34 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1582519834.94.0.112173637218.issue39712@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/issue39712>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:53:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 24 Feb 2020 04:53:40 +0000
Subject: [issue39649] bdb.Bdb.format_stack_entry: checks for obsolete __args__
In-Reply-To: <1581860504.66.0.826450545942.issue39649@roundup.psfhosted.org>
Message-ID: <1582520020.22.0.874722540788.issue39649@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/issue39649>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:56:41 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 24 Feb 2020 04:56:41 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
Message-ID: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

The following tiny change:

diff --git a/Objects/listobject.c b/Objects/listobject.c
index 3c39c6444b..3ac03b71d0 100644
--- a/Objects/listobject.c
+++ b/Objects/listobject.c
@@ -2643,8 +2643,7 @@ list_richcompare(PyObject *v, PyObject *w, int op)

         Py_INCREF(vitem);
         Py_INCREF(witem);
-        int k = PyObject_RichCompareBool(vl->ob_item[i],
-                                         wl->ob_item[i], Py_EQ);
+        int k = PyObject_RichCompareBool(vitem, witem, Py_EQ);
         Py_DECREF(vitem);
         Py_DECREF(witem);
         if (k < 0)

Creates the following performance improvement:

Before:
> .\python.bat -m timeit -s "A = list(range(10**7)); B = list(range(10**7))" "A==B"
2 loops, best of 5: 134 msec per loop
> .\python.bat -m timeit -s "A = list(range(10**7)); B = list(range(10**7))" "A==B"
2 loops, best of 5: 134 msec per loop

After:
> .\python.bat -m timeit -s "A = list(range(10**7)); B = list(range(10**7))" "A==B"
2 loops, best of 5: 126 msec per loop
> .\python.bat -m timeit -s "A = list(range(10**7)); B = list(range(10**7))" "A==B"
2 loops, best of 5: 126 msec per loop

----------
components: Interpreter Core
messages: 362566
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Speed up list.__eq__ by about 6%
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Sun Feb 23 23:57:41 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 24 Feb 2020 04:57:41 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582520261.9.0.396038441618.issue39737@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


----------
keywords: +patch
pull_requests: +18004
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18638

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Mon Feb 24 00:47:28 2020
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 24 Feb 2020 05:47:28 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582523248.7.0.983846593769.issue39717@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

Ethan, did we successfully convince you not to use `from None`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Mon Feb 24 01:03:28 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Mon, 24 Feb 2020 06:03:28 +0000
Subject: [issue39693] tarfile's extractfile documentation is misleading
In-Reply-To: <1582182731.51.0.0387908483587.issue39693@roundup.psfhosted.org>
Message-ID: <1582524208.09.0.480615461502.issue39693@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
keywords: +patch
nosy: +dorosch
nosy_count: 3.0 -> 4.0
pull_requests: +18005
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18639

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39693>
_______________________________________

From report at bugs.python.org  Mon Feb 24 01:11:33 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Mon, 24 Feb 2020 06:11:33 +0000
Subject: [issue15474] Differentiate decorator and decorator factory in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1582524693.25.0.491603387622.issue15474@roundup.psfhosted.org>


Andrei Daraschenka <dorosch.github.io at yandex.ru> added the comment:

Hi, Andr?s Delfino. Are you still working on it? I could help with this issues.

----------
nosy: +dorosch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15474>
_______________________________________

From report at bugs.python.org  Mon Feb 24 01:30:15 2020
From: report at bugs.python.org (zd nex)
Date: Mon, 24 Feb 2020 06:30:15 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582525815.63.0.407348162046.issue39672@roundup.psfhosted.org>


Change by zd nex <zdnexnet at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 01:32:03 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 24 Feb 2020 06:32:03 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582525923.31.0.1848314013.issue39717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

`Fraid not.  It is still going to be a case-by-case basis -- sometimes the previous exception just doesn't add any value, and sometimes it does.

PEP3134 did add a lot of justification for your changes, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Mon Feb 24 01:40:55 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 24 Feb 2020 06:40:55 +0000
Subject: [issue39736] const strings in Modules/_datetimemodule.c and
 Modules/_testbuffer.c
In-Reply-To: <1582518270.89.0.669104927357.issue39736@roundup.psfhosted.org>
Message-ID: <1582526455.18.0.831041550686.issue39736@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset c3fa634096eedbaf477698adab666f03085a7928 by Andy Lester in branch 'master':
closes bpo-39736: const strings in Modules/_datetimemodule.c and Modules/_testbuffer.c (GH-18637)
https://github.com/python/cpython/commit/c3fa634096eedbaf477698adab666f03085a7928


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39736>
_______________________________________

From report at bugs.python.org  Mon Feb 24 01:50:50 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 24 Feb 2020 06:50:50 +0000
Subject: [issue31718] some methods of uninitialized
 io.IncrementalNewlineDecoder objects raise SystemError
In-Reply-To: <1507313388.78.0.213398074469.issue31718@psf.upfronthosting.co.za>
Message-ID: <1582527050.46.0.681891925958.issue31718@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 5.0 -> 6.0
pull_requests: +18006
pull_request: https://github.com/python/cpython/pull/18640

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31718>
_______________________________________

From report at bugs.python.org  Mon Feb 24 02:27:49 2020
From: report at bugs.python.org (Christian Tismer)
Date: Mon, 24 Feb 2020 07:27:49 +0000
Subject: [issue35810] Object Initialization does not incref Heap-allocated
 Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1582529269.51.0.262042306975.issue35810@roundup.psfhosted.org>


Christian Tismer <tismer at stackless.com> added the comment:

> How does this change affect stable ABI? Is it necessary to change the 
> logic in modules that use only the Py_LIMITED_API?

If you use heap types, you need to adjust refcounts beginning
with Python 3.8 . And since the Py_LIMITED_API uses heap types
without hiding these refcount changes by an API call,
this breaks the stable API.

But it is easily fixable by a runtime version check, or you start
over with Python 3.8 as lowest version <wink>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Mon Feb 24 03:00:06 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Mon, 24 Feb 2020 08:00:06 +0000
Subject: [issue39728] Instantiating enum with invalid value results in
 ValueError twice
In-Reply-To: <1582448824.79.0.766917894274.issue39728@roundup.psfhosted.org>
Message-ID: <1582531206.64.0.242994063605.issue39728@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
keywords: +patch
nosy: +dorosch
nosy_count: 4.0 -> 5.0
pull_requests: +18007
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18641

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39728>
_______________________________________

From report at bugs.python.org  Mon Feb 24 03:44:33 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 24 Feb 2020 08:44:33 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582533873.73.0.512521373261.issue39717@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I guess https://bugs.python.org/issue39728 is a perfect example of "previous exception not adding any value". :-) And I think it isn't a coincidence that it happens in "your" module.

The morale: we think about exceptions in different ways, and it's hard to say what's the right way. Maybe we should just change the wording to imply that __context__ exception didn't spontaneously "occur", but was explicitly "raised" by a handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:26:03 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Mon, 24 Feb 2020 09:26:03 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582536363.13.0.393431001016.issue39672@roundup.psfhosted.org>


Andrei Daraschenka <dorosch.github.io at yandex.ru> added the comment:

Could you give more details for reproduce it because on the latest version cpython from master branch it's work
You can debug it with help pdb. Just set breakpoint:

...
test_shelve(data)
breakpoint()
data.close()
...

And try run it step-by-step (press 'S' to go to the next step and press 'll' to know where you are now)
https://docs.python.org/3/library/pdb.html#debugger-commands

----------
nosy: +dorosch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:28:03 2020
From: report at bugs.python.org (wjzbf)
Date: Mon, 24 Feb 2020 09:28:03 +0000
Subject: [issue39738] mod operation with large number is not correct.
Message-ID: <1582536483.25.0.598086329397.issue39738@roundup.psfhosted.org>


New submission from wjzbf <hgkdzbf6 at 163.com>:

hello python,

  when i calculate:

151476660579404160000-151476660579404160000//1000000007 * (1e9+7)

  it returns 

67534848.0

  when i calculate 

151476660579404160000 % (1e9+7)

  it returns 

67536199.0

  the two values are not equal.
  how to explain it?

thanks
zbf

----------
components: Windows
messages: 362574
nosy: paul.moore, steve.dower, tim.golden, wjzbf, zach.ware
priority: normal
severity: normal
status: open
title: mod operation with large number is not correct.
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39738>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:42:47 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 24 Feb 2020 09:42:47 +0000
Subject: [issue39738] mod operation with large number is not correct.
In-Reply-To: <1582536483.25.0.598086329397.issue39738@roundup.psfhosted.org>
Message-ID: <1582537367.33.0.852833689471.issue39738@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is a floating point issue, not a bug. Floats inherently only have a limited precision available, so they are not always the exact number you think they are.

Using 1e9 forces the result to be a float, which introduces rounding errors into the calculation. If you use an exact integer, the calculation is exact:


py> 151476660579404160000-151476660579404160000//1000000007 * (10**9+7)
67543367
py> 151476660579404160000 % (10**9+7)
67543367


*This is not a Python bug* this is an inherent limitation of floating point numbers and the same issues will occur in any language that uses floats.

https://docs.python.org/3/faq/design.html#why-am-i-getting-strange-results-with-simple-arithmetic-operations

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39738>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:50:23 2020
From: report at bugs.python.org (zd nex)
Date: Mon, 24 Feb 2020 09:50:23 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582537823.07.0.0818880431789.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

Hello,

well and in 3.8 it does not crash for you? Is there some devel build of 3.9 for ubuntu which I can try?

I have tested it on 3.7,3.8 and 3.6 and it crashed always when close was not present or when list was called in another function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:52:38 2020
From: report at bugs.python.org (zd nex)
Date: Mon, 24 Feb 2020 09:52:38 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582537958.83.0.11796115107.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

Ok I will try pdb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:54:56 2020
From: report at bugs.python.org (Floris Lambrechts)
Date: Mon, 24 Feb 2020 09:54:56 +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: <1582538096.2.0.882740879183.issue39090@roundup.psfhosted.org>


Floris Lambrechts <florisla at gmail.com> added the comment:

@ChrisBarker,

Could you review the proposed addition to the documentation?

https://github.com/florisla/cpython/commit/c146ad3d086fe9e401284c12fc670ea4f9398f3b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:55:54 2020
From: report at bugs.python.org (Floris Lambrechts)
Date: Mon, 24 Feb 2020 09:55:54 +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: <1582538154.53.0.805536635357.issue39090@roundup.psfhosted.org>


Floris Lambrechts <florisla at gmail.com> added the comment:

(sorry, didn't see the GitHub comments before... I'll process those first.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Mon Feb 24 04:58:40 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Mon, 24 Feb 2020 09:58:40 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582538320.01.0.592026434725.issue39672@roundup.psfhosted.org>


Andrei Daraschenka <dorosch.github.io at yandex.ru> added the comment:

Yes, It's work for me

$ uname -a
Linux laptop 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ python3.8 --version
Python 3.8.0
$ python3.8 ce_test_2.py 
start
end

Could you please write about the results of the research with pdb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 05:00:06 2020
From: report at bugs.python.org (zd nex)
Date: Mon, 24 Feb 2020 10:00:06 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582538406.03.0.726860006808.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

Okay I have tried to run it with breakpoint() but it does not crash on 3.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 05:07:42 2020
From: report at bugs.python.org (zd nex)
Date: Mon, 24 Feb 2020 10:07:42 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582538862.65.0.803515207507.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

Okay I have managed to crash it when exit() was called and also I am attaching output with -v

python3.8 -X faulthandler ce_test_2.py 
start
end
--Return--
> /home/fractal/workspace/test_py_crash/ce_test_2.py(19)<module>()->None
-> breakpoint()
(Pdb) exit()
Traceback (most recent call last):
  File "ce_test_2.py", line 19, in <module>
    breakpoint()
  File "/usr/lib/python3.8/bdb.py", line 92, in trace_dispatch
    return self.dispatch_return(frame, arg)
  File "/usr/lib/python3.8/bdb.py", line 154, in dispatch_return
    if self.quitting: raise BdbQuit
bdb.BdbQuit
Fatal Python error: Segmentation fault

Current thread 0x00007f976975f740 (most recent call first):
  File "/usr/lib/python3.8/shelve.py", line 124 in __setitem__
  File "/usr/lib/python3.8/shelve.py", line 168 in sync
  File "/usr/lib/python3.8/shelve.py", line 144 in close
  File "/usr/lib/python3.8/shelve.py", line 162 in __del__
Neopr?vn?n? p??stup do pam?ti (SIGSEGV)
$ 


# destroy string
# cleanup[2] removing threading
# cleanup[2] removing atexit
# cleanup[2] removing logging
# cleanup[2] removing material
# cleanup[2] removing _dbm
# cleanup[2] removing dbm.ndbm
# cleanup[2] removing dbm
# destroy dbm
# cleanup[2] removing _gdbm
# cleanup[2] removing dbm.gnu
# cleanup[2] removing _ast
# cleanup[2] removing ast
# cleanup[2] removing dbm.dumb
# destroy _ast
Fatal Python error: Segmentation fault

Current thread 0x00007fd5477cb740 (most recent call first):
  File "/usr/lib/python3.8/shelve.py", line 124 in __setitem__
  File "/usr/lib/python3.8/shelve.py", line 168 in sync
  File "/usr/lib/python3.8/shelve.py", line 144 in close
  File "/usr/lib/python3.8/shelve.py", line 162 in __del__
Neopr?vn?n? p??stup do pam?ti (SIGSEGV)

----------
Added file: https://bugs.python.org/file48907/crash_pdb.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Mon Feb 24 05:29:37 2020
From: report at bugs.python.org (Mike Frysinger)
Date: Mon, 24 Feb 2020 10:29:37 +0000
Subject: [issue25960] Popen.wait() hangs when called from a signal handler
 when os.waitpid() does not
In-Reply-To: <1451213882.47.0.471062889789.issue25960@psf.upfronthosting.co.za>
Message-ID: <1582540177.0.0.935933025352.issue25960@roundup.psfhosted.org>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

> fundamentally: this shouldn't work anyways.
>
> You are calling wait() from a signal handler.
> That is a blocking operation.
> You cannot do that from a signal handler.

what definition/spec are you referring to here ?  is this a Python limitation ?  i don't see any mention in the Python documentation on the subject:
https://docs.python.org/3/library/signal.html

maybe you meant this as an OS limitation ?  it's certainly not a POSIX limitation as it's quite clear on the subject:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
> The following table defines a set of functions that shall be async-signal-safe. Therefore, applications can call them, without restriction, from signal-catching functions.
> wait()
> waitpid()

in general, the idea that a signal handler "cannot block" is weird.  i guess you're saying that anything that involves the OS is forbidden ?  there's no guarantee something as simple as a file open() or close() won't block, or really any syscall at all.

i bisected a similar testcase from the OP down ... python 3.4.0 works, but 3.4.1 fails.  looks like it's due to this change:

https://github.com/python/cpython/commit/d65ba51e245ffdd155bc1e7b8884fc943048111f
Author: Gregory P. Smith <greg at krypto.org>
Date:   Wed Apr 23 00:27:17 2014 -0700

    subprocess's Popen.wait() is now thread safe so that multiple threads
    may be calling wait() or poll() on a Popen instance at the same time
    without losing the Popen.returncode value.  Fixes issue #21291.

----------
nosy: +vapier

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________

From report at bugs.python.org  Mon Feb 24 05:45:24 2020
From: report at bugs.python.org (Ronald van Elburg)
Date: Mon, 24 Feb 2020 10:45:24 +0000
Subject: [issue18837] multiprocessing.reduction is undocumented
In-Reply-To: <1377500170.46.0.281746133519.issue18837@psf.upfronthosting.co.za>
Message-ID: <1582541124.23.0.371852051126.issue18837@roundup.psfhosted.org>


Ronald van Elburg <vanelburg30 at hetnet.nl> added the comment:

Problem still exists in 3.7 documentation. It is unclear to me, even after inspecting issues and commits what proper usage of multiprocessing.reduction is. In case it is now fully internal to the module it would be reassuring to read that in the documentation.

My code seems to be running without explicit reference to the multiprocessing.reduction module. Which suggest that reduction and rising of connections is no longer needed or handled by the module internally.


For python 3.7 I was able to remove the following python 2.7 code:

'''python
    def __reduceConnection(self):
        # Reduce the connection object to enable sending it
        if(sys.platform=='win32'):
            self.connection = reduction.reduce_pipe_connection(self.connection)
        else:
            self.connection = reduction.reduce_connection(self.connection)

    def riseConnection(self,logger):
        if self.connectionReduced:
            logger.info('Connection for subscription to {0} with channel name {1} has risen!'.format(self.senderKey, self.receiverKey))
            red_conn = self.connection
            self.connection = red_conn[0](*red_conn[1])
            self.connectionReduced=False

        else:
            logger.info('Connection to {0} with channel name {1} had risen already!'.format(self.senderKey, self.receiverKey))
'''

----------
nosy: +Rajve
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18837>
_______________________________________

From report at bugs.python.org  Mon Feb 24 08:06:05 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 24 Feb 2020 13:06:05 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582549565.27.0.0483059621075.issue39681@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

The regression is fixed in git master and in the 3.8 branch. However, I would still advice against the idiom of handling a mmap object as a regular file when using pickle.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Mon Feb 24 09:08:39 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 14:08:39 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582553319.84.0.744324302798.issue39622@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The second solution doesn't help with breaking infinite loops like 
while True:
    pass

We need a more robust idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Mon Feb 24 09:15:00 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 14:15:00 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1582553700.54.0.568524597748.issue37373@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

>From my understanding, the issue is still desirable but we have a lack of resources.
Regarding the patch for tornado, using selectors.SelectSelector for implementing add_reader()/remove_reader() and add_writer()/remove_writer() in ProactorEventLoop looks is more robust solution IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Mon Feb 24 09:21:40 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 14:21:40 +0000
Subject: [issue39700] asyncio.selector_events._SelectorTransport: Add logging
 when sock.getpeername() fails
In-Reply-To: <1582203609.18.0.700176939953.issue39700@roundup.psfhosted.org>
Message-ID: <1582554100.24.0.257804690058.issue39700@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I'm not sure.
Logging can pollute the logger and make it almost useless.
Most of mentioned errno codes are programming errors, a few may happen due network issues.
Would you share what reasons did you observe?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39700>
_______________________________________

From report at bugs.python.org  Mon Feb 24 09:24:25 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 14:24:25 +0000
Subject: [issue33840] connection limit on listening socket in asyncio
In-Reply-To: <1528751429.93.0.592728768989.issue33840@psf.upfronthosting.co.za>
Message-ID: <1582554265.7.0.54229964327.issue33840@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

For server applications, the reverse proxy in front of the application can limit the connection limit.
It is a good workaround because the proxy is required (and most likely is used already) for any non-trivial server app.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33840>
_______________________________________

From report at bugs.python.org  Mon Feb 24 09:59:44 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 14:59:44 +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: <1582556384.53.0.597067361747.issue39128@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8af4712a16e4b7d1b60f1faec13cd7a88da95f6a by idomic in branch 'master':
bpo-39128: Added algorithm description (GH-18624)
https://github.com/python/cpython/commit/8af4712a16e4b7d1b60f1faec13cd7a88da95f6a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 24 09:59:56 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 14:59:56 +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: <1582556396.02.0.314038961582.issue39128@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18008
pull_request: https://github.com/python/cpython/pull/18649

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:01:22 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 15:01:22 +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: <1582556482.46.0.512756290612.issue39128@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/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:01:30 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 15:01:30 +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: <1582556490.75.0.457823924406.issue39128@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks, Ido

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:06:06 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 24 Feb 2020 15:06:06 +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: <1582556766.66.0.0323492452869.issue39128@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1f4cf0c22b00fefb17611546755b65d3cb488330 by Miss Islington (bot) in branch '3.8':
bpo-39128: Added algorithm description (GH-18624)
https://github.com/python/cpython/commit/1f4cf0c22b00fefb17611546755b65d3cb488330


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39128>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:19:26 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 15:19:26 +0000
Subject: [issue39613] IsolatedAsyncioTestCase closes default event loop
In-Reply-To: <1581450697.14.0.885131821456.issue39613@roundup.psfhosted.org>
Message-ID: <1582557566.58.0.937220209519.issue39613@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The behavior is intentional and follows asyncio.run() semantics.
Moreover, every test should have a separate event loop instance, this is stressed by IsolatedAsyncioTestCase class name

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39613>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:37:49 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 24 Feb 2020 15:37:49 +0000
Subject: [issue38988] Killing asyncio subprocesses on timeout?
In-Reply-To: <1575654060.86.0.979877919031.issue38988@roundup.psfhosted.org>
Message-ID: <1582558669.58.0.105246171809.issue38988@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

asyncio doesn't kill subprocess by timeout, that's why test1() doesn't work.
The kill is done by signal sending which is asynchronous. That's why test2 may fail at "FAIL(3)" point sometimes. 
1-second sleep is enough to stop this case, but maybe not enough, say, under high load and for much more complex program than "sleep".

That's how OS works, there is nothing specific for asyncio itself.
You can observe the same using an old good sync approach, written with any programming language. 
Nothing to fix here.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38988>
_______________________________________

From report at bugs.python.org  Mon Feb 24 10:51:51 2020
From: report at bugs.python.org (David)
Date: Mon, 24 Feb 2020 15:51:51 +0000
Subject: [issue39700] asyncio.selector_events._SelectorTransport: Add logging
 when sock.getpeername() fails
In-Reply-To: <1582203609.18.0.700176939953.issue39700@roundup.psfhosted.org>
Message-ID: <1582559511.06.0.526653918436.issue39700@roundup.psfhosted.org>


David <dsternlicht at infinidat.com> added the comment:

Hi asvetlov,

Thank you for your reply.

I'm currently trying to debug a network issue, but I cannot determine the root cause of it because of lack of logs. It would be extremely helpful for my debugging if we could log the error that was raised by getpeername.

I noticed that in asyncio.proactor_events._set_socket_extra there *is* some logging of exceptions. 

```
def _set_socket_extra(transport, sock):
    transport._extra['socket'] = trsock.TransportSocket(sock)

    try:
        transport._extra['sockname'] = sock.getsockname()
    except socket.error:
        if transport._loop.get_debug():
            logger.warning(
                "getsockname() failed on %r", sock, exc_info=True)

    if 'peername' not in transport._extra:
        try:
            transport._extra['peername'] = sock.getpeername()
        except socket.error:
            # UDP sockets may not have a peer name
            transport._extra['peername'] = None
```

Although I see that there there's also a check `if transport._loop.get_debug()` so that it won't pollute the log. Would you like me to add that check to my patch too?

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39700>
_______________________________________

From report at bugs.python.org  Mon Feb 24 11:06:00 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 24 Feb 2020 16:06:00 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582560360.39.0.221275515983.issue39737@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +corona10, serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Mon Feb 24 11:19:04 2020
From: report at bugs.python.org (Nathan Goldbaum)
Date: Mon, 24 Feb 2020 16:19:04 +0000
Subject: [issue39681] pickle.load expects an object that implements readinto
In-Reply-To: <1582074289.01.0.450273183434.issue39681@roundup.psfhosted.org>
Message-ID: <1582561144.86.0.50070662531.issue39681@roundup.psfhosted.org>


Nathan Goldbaum <nathan12343 at gmail.com> added the comment:

Thank you for the fix! Yes I'm planning to file an issue with flair about this and patch this use case in PyTorch itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39681>
_______________________________________

From report at bugs.python.org  Mon Feb 24 11:25:28 2020
From: report at bugs.python.org (nono)
Date: Mon, 24 Feb 2020 16:25:28 +0000
Subject: [issue39739] Python crash every time opening pycharm,
 seems related to tensorflow
Message-ID: <1582561528.75.0.376924358185.issue39739@roundup.psfhosted.org>


Change by nono <nonococochy at gmail.com>:


----------
components: macOS
nosy: leo212121, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python crash every time opening pycharm, seems related to tensorflow
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39739>
_______________________________________

From report at bugs.python.org  Mon Feb 24 11:35:26 2020
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 24 Feb 2020 16:35:26 +0000
Subject: [issue34033] distutils is not reproducible
In-Reply-To: <1530632785.81.0.56676864532.issue34033@psf.upfronthosting.co.za>
Message-ID: <1582562126.75.0.392651261223.issue34033@roundup.psfhosted.org>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
nosy:  -mcepl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34033>
_______________________________________

From report at bugs.python.org  Mon Feb 24 12:16:05 2020
From: report at bugs.python.org (RobHammann)
Date: Mon, 24 Feb 2020 17:16:05 +0000
Subject: [issue39740] Select module fails to build on Solaris 11.4
Message-ID: <1582564565.67.0.773509979349.issue39740@roundup.psfhosted.org>


New submission from RobHammann <robert.hammann at wdc.com>:

On an x86 Solaris 11.4 system, the standard procedure build of python from source fails to build the 'select' module. Make install then fails upon trying to import 'select'.

In the make output, while gcc is building 'select', these errors are printed:

building 'select' extension
gcc -fPIC -Wno-unused-result -Wsign-compare -g -Og -Wall -D_REENTRANT -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/usr/local/include -I/root/cpython-solaris/Include -I/root/cpython-solaris -c /root/cpython-solaris/Modules/selectmodule.c -o build/temp.solaris-2.11-i86pc.64bit-3.9-pydebug/root/cpython-solaris/Modules/selectmodule.o
/root/cpython-solaris/Modules/selectmodule.c:1147:21: error: 'devpoll_methods' undeclared here (not in a function); did you mean 'devpoll_dealloc'?
     {Py_tp_methods, devpoll_methods},
                     ^~~~~~~~~~~~~~~
                     devpoll_dealloc
/root/cpython-solaris/Modules/selectmodule.c:2299:20: warning: 'devpoll_methods' defined but not used [-Wunused-variable]
 static PyMethodDef devpoll_methods[] = {
                    ^~~~~~~~~~~~~~~

Attached is the combined outputs of ./configure, make, and make install

----------
components: Build
files: build-output.txt
messages: 362598
nosy: RobHammann
priority: normal
severity: normal
status: open
title: Select module fails to build on Solaris 11.4
type: compile error
versions: Python 3.9
Added file: https://bugs.python.org/file48908/build-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39740>
_______________________________________

From report at bugs.python.org  Mon Feb 24 12:23:47 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 24 Feb 2020 17:23:47 +0000
Subject: [issue20291] Argument Clinic should understand *args and **kwargs
 parameters
In-Reply-To: <1390010125.91.0.58212727704.issue20291@psf.upfronthosting.co.za>
Message-ID: <1582565027.11.0.83981329103.issue20291@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
nosy: +BTaskaya
nosy_count: 9.0 -> 10.0
pull_requests: +18009
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18609

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20291>
_______________________________________

From report at bugs.python.org  Mon Feb 24 12:30:10 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 24 Feb 2020 17:30:10 +0000
Subject: [issue39741] Argument Clinic name conflict
Message-ID: <1582565410.47.0.513154068013.issue39741@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

Argument clinic uses some extra variables (like args, or noptargs, nargs etc.) for parsing. But there is a catch about these names, the generated code becomes wrong if there are any usages of them inside the signature. Encountered with this problem while working on *args support (in issue 20291). 

The possible solution is prefixing every argument in the parser with __clinic_ (__clinic_{var}) for preventing any kind of conflict. I'll draft a PR for this issue.

----------
components: Argument Clinic
messages: 362599
nosy: BTaskaya, larry, pablogsal
priority: low
severity: normal
status: open
title: Argument Clinic name conflict
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39741>
_______________________________________

From report at bugs.python.org  Mon Feb 24 13:53:09 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 Feb 2020 18:53:09 +0000
Subject: [issue39739] Python crash every time opening pycharm,
 seems related to tensorflow
In-Reply-To: <1582561844.94.0.0622308922245.issue39739@roundup.psfhosted.org>
Message-ID: <1582570389.61.0.731517991143.issue39739@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm. I don't see anything here that would indicate that this is a core Python problem. This looks like something you'd need to take up with the tensorflow folks. (Investigations could conceivably turn up a CPython bug as the underlying cause, in which case a more detailed issue could be opened here, but as it stands there's not really much we can do with this.)

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39739>
_______________________________________

From report at bugs.python.org  Mon Feb 24 14:35:32 2020
From: report at bugs.python.org (nono)
Date: Mon, 24 Feb 2020 19:35:32 +0000
Subject: [issue39739] Python crash every time opening pycharm,
 seems related to tensorflow
In-Reply-To: <1582561844.94.0.0622308922245.issue39739@roundup.psfhosted.org>
Message-ID: <1582572932.49.0.479709466513.issue39739@roundup.psfhosted.org>


nono <nonococochy at gmail.com> added the comment:

Okay, I will discuss this in tensorflow forum. Thanks for providing the information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39739>
_______________________________________

From report at bugs.python.org  Mon Feb 24 15:07:45 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 24 Feb 2020 20:07:45 +0000
Subject: [issue39741] Argument Clinic name conflict
In-Reply-To: <1582565410.47.0.513154068013.issue39741@roundup.psfhosted.org>
Message-ID: <1582574865.92.0.664787164093.issue39741@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

After preparing the patch and transforming all arguments with a __clinic_ prefix, I saw there are some actions that are taken by relying on the parser code. An example;
https://github.com/python/cpython/blob/8af4712a16e4b7d1b60f1faec13cd7a88da95f6a/Objects/codeobject.c#L616-L631

In that case, self was already replaced with __clinic_self so that code doesn't work. IMHO there should be an identifier to distinguish these cases like; <self>->co_argc etc. When we see such defaults we can just replace them with the prefixed version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39741>
_______________________________________

From report at bugs.python.org  Mon Feb 24 15:36:13 2020
From: report at bugs.python.org (Enji Cooper)
Date: Mon, 24 Feb 2020 20:36:13 +0000
Subject: [issue39742] Enhancement: add `os.getdtablesize(..)` to `os`
 (`posix`) module
Message-ID: <1582576573.04.0.0159075532911.issue39742@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

getdtablesize({2,3}) is a wonderful library call/system call to have access to because it allows one to determine the descriptor limits at runtime in an easier manner than having to do the equivalent with os.sysconf(..):

>>> os.sysconf(os.sysconf_names["SC_OPEN_MAX"])

This has been present in *BSD since time memorial [1] and in Linux since 2010 [2], so I think it would be a good addition to the `os` (`posix`) module.

I will submit a diff for this in a few days, if it's deemed acceptable to have in the `posix` module.

1. https://www.freebsd.org/cgi/man.cgi?query=getdtablesize&sektion=2&manpath=freebsd-release-ports
2. http://man7.org/linux/man-pages/man2/getdtablesize.2.html

----------
components: Library (Lib)
messages: 362603
nosy: ngie
priority: normal
severity: normal
status: open
title: Enhancement: add `os.getdtablesize(..)` to `os` (`posix`) module
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39742>
_______________________________________

From report at bugs.python.org  Mon Feb 24 15:37:21 2020
From: report at bugs.python.org (Enji Cooper)
Date: Mon, 24 Feb 2020 20:37:21 +0000
Subject: [issue39742] Enhancement: add `os.getdtablesize(..)` to `os`
 (`posix`) module
In-Reply-To: <1582576573.04.0.0159075532911.issue39742@roundup.psfhosted.org>
Message-ID: <1582576641.38.0.346427005635.issue39742@roundup.psfhosted.org>


Change by Enji Cooper <yaneurabeya at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39742>
_______________________________________

From report at bugs.python.org  Mon Feb 24 15:50:19 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 24 Feb 2020 20:50:19 +0000
Subject: [issue39739] Python crash every time opening pycharm,
 seems related to tensorflow
In-Reply-To: <1582561844.94.0.0622308922245.issue39739@roundup.psfhosted.org>
Message-ID: <1582577419.66.0.480731060165.issue39739@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39739>
_______________________________________

From report at bugs.python.org  Mon Feb 24 16:04:59 2020
From: report at bugs.python.org (Syed Habeeb Ullah Quadri)
Date: Mon, 24 Feb 2020 21:04:59 +0000
Subject: [issue39743] variable quiet is not defined in function main.
Message-ID: <1582578299.58.0.858783047501.issue39743@roundup.psfhosted.org>


New submission from Syed Habeeb Ullah Quadri <shuq007 at gmail.com>:

'quiet' is an argument of function "compile" in "pycompile.py". I do not understand why 'quiet' is used in function "main" when function main has arguments, None.
Undefined 'quiet' variable is used in "main" function of "pycompile.py" in lines 200, 204, 214.
This is giving error in dist-upgrade of Ubuntu 19.1.

Attaching the pycompile.tar.xz for the review.

Please fix it at the earliest.

----------
components: Cross-Build
files: pycompile.tar.xz
messages: 362604
nosy: Alex.Willmer, syed007
priority: normal
severity: normal
status: open
title: variable quiet is not defined in function main.
versions: Python 3.8
Added file: https://bugs.python.org/file48909/pycompile.tar.xz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39743>
_______________________________________

From report at bugs.python.org  Mon Feb 24 16:23:14 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 24 Feb 2020 21:23:14 +0000
Subject: [issue39743] variable quiet is not defined in function main.
In-Reply-To: <1582578299.58.0.858783047501.issue39743@roundup.psfhosted.org>
Message-ID: <1582579394.86.0.666505675613.issue39743@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib) -Cross-Build
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> bad input crashes py_compile library
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39743>
_______________________________________

From report at bugs.python.org  Mon Feb 24 17:09:41 2020
From: report at bugs.python.org (=?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=)
Date: Mon, 24 Feb 2020 22:09:41 +0000
Subject: [issue39744] asyncio.subprocess's communicate(None) does not close
 stdin
Message-ID: <1582582181.12.0.732686127935.issue39744@roundup.psfhosted.org>


New submission from Marek Marczykowski-G?recki <marmarek at mimuw.edu.pl>:

Standard subprocess's communicate() called with None input (or no argument at all closes process stdin. The asyncio variant does not.
This leads to issue with various processes that wait for EOF on stdin before terminating.

Test script attached.

----------
components: asyncio
files: commmunicate-test.py
messages: 362605
nosy: asvetlov, marmarek, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.subprocess's communicate(None) does not close stdin
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48910/commmunicate-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39744>
_______________________________________

From report at bugs.python.org  Mon Feb 24 17:12:11 2020
From: report at bugs.python.org (=?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=)
Date: Mon, 24 Feb 2020 22:12:11 +0000
Subject: [issue39744] asyncio.subprocess's communicate(None) does not close
 stdin
In-Reply-To: <1582582181.12.0.732686127935.issue39744@roundup.psfhosted.org>
Message-ID: <1582582331.09.0.0849718200754.issue39744@roundup.psfhosted.org>


Marek Marczykowski-G?recki <marmarek at mimuw.edu.pl> added the comment:

This is BTW similar to https://bugs.python.org/issue26848

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39744>
_______________________________________

From report at bugs.python.org  Mon Feb 24 17:35:32 2020
From: report at bugs.python.org (=?utf-8?q?Marek_Marczykowski-G=C3=B3recki?=)
Date: Mon, 24 Feb 2020 22:35:32 +0000
Subject: [issue39744] asyncio.subprocess's communicate(None) does not close
 stdin
In-Reply-To: <1582582181.12.0.732686127935.issue39744@roundup.psfhosted.org>
Message-ID: <1582583732.28.0.291489222924.issue39744@roundup.psfhosted.org>


Change by Marek Marczykowski-G?recki <marmarek at mimuw.edu.pl>:


----------
keywords: +patch
pull_requests: +18010
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18650

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39744>
_______________________________________

From report at bugs.python.org  Mon Feb 24 18:22:02 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 24 Feb 2020 23:22:02 +0000
Subject: [issue25960] Popen.wait() hangs when called from a signal handler
 when os.waitpid() does not
In-Reply-To: <1451213882.47.0.471062889789.issue25960@psf.upfronthosting.co.za>
Message-ID: <1582586522.44.0.129700022801.issue25960@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

yes, Popen's use of a lock since that change means that Popen.wait() cannot be called in an asynchronous context where its own execution could be blocking the execution of code that would unlock the lock.

at this point we should probably just document that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________

From report at bugs.python.org  Mon Feb 24 19:13:37 2020
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 25 Feb 2020 00:13:37 +0000
Subject: [issue25960] Popen.wait() hangs when called from a signal handler
 when os.waitpid() does not
In-Reply-To: <1451213882.47.0.471062889789.issue25960@psf.upfronthosting.co.za>
Message-ID: <1582589617.53.0.866885442595.issue25960@roundup.psfhosted.org>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

to be clear, there is no Python or OS restriction that you're aware of for your earlier statement ?  you just want to make it into a new Popen restriction that didn't previously exist ?

we came across this bug as we upgraded our existing Python 2.7 codebase to Python 3.6.  so even if it's "been this way for a while" (which is to say, since the 3.4.1 release), at least some people are going to be coming across this for the first time as they migrate.

if the popen APIs aren't going to handle this correctly (check threading.active_count?), can we at least get a knob to disable it or class methods we can stub out ?  we never use threads, so having popen add support for a runtime mode we never utilize is kind of annoying.

for now i'm defining a custom subprocess.Popen class to break the lock, but it's kind of terrible to have to access _waitpid_lock outside of the subprocess module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________

From report at bugs.python.org  Mon Feb 24 19:30:46 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 25 Feb 2020 00:30:46 +0000
Subject: [issue25960] Popen.wait() hangs when called from a signal handler
 when os.waitpid() does not
In-Reply-To: <1451213882.47.0.471062889789.issue25960@psf.upfronthosting.co.za>
Message-ID: <1582590646.68.0.822765840561.issue25960@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Reopening so that spending time on deciding this in the future at least stays on my radar.

Your workaround sounds like the reasonable, if understandably not pretty approach for now.

----------
resolution: wont fix -> remind
status: closed -> open
versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________

From report at bugs.python.org  Mon Feb 24 19:31:01 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 25 Feb 2020 00:31:01 +0000
Subject: [issue25960] Popen.wait() hangs when called from a signal handler
 when os.waitpid() does not
In-Reply-To: <1451213882.47.0.471062889789.issue25960@psf.upfronthosting.co.za>
Message-ID: <1582590661.4.0.975524967703.issue25960@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +3.4regression, 3.5regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________

From report at bugs.python.org  Mon Feb 24 20:09:18 2020
From: report at bugs.python.org (Zhibin Dong)
Date: Tue, 25 Feb 2020 01:09:18 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582592958.31.0.104265673341.issue39622@roundup.psfhosted.org>


Zhibin Dong <developerdong at gmail.com> added the comment:

Yes, I think you are right. In the second solution, the callback of SIGINT will be append to the end of one task loop. If that code is defined in a task by some user, KeyboardInterrupt will not be raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Mon Feb 24 21:47:59 2020
From: report at bugs.python.org (Masahiro Sakai)
Date: Tue, 25 Feb 2020 02:47:59 +0000
Subject: [issue39745] BlockingIOError.characters_written represents number of
 bytes not characters
Message-ID: <1582598879.29.0.157478927981.issue39745@roundup.psfhosted.org>


New submission from Masahiro Sakai <masahiro.sakai at gmail.com>:

According to https://docs.python.org/3/library/exceptions.html#BlockingIOError , 'characters_written' is "An integer containing the number of characters written to the stream before it blocked". But I observed that it represents number of *bytes* not *characters* in the following program.

Program:
----
import os
import threading
import time

r, w = os.pipe()
os.set_blocking(w, False)
f_r = os.fdopen(r, mode="rb")
f_w = os.fdopen(w, mode="w", encoding="utf-8")

msg = "\u03b1\u03b2\u03b3\u3042\u3044\u3046\u3048\u304a" * (1024 * 16)
try:
    print(msg, file=f_w, flush=True)
except BlockingIOError as e:
    print(f"BlockingIOError.characters_written == {e.characters_written}")
    written = e.characters_written

def close():
    os.set_blocking(w, True)
    f_w.close()
threading.Thread(target=close).start()

b = f_r.read()
f_r.close()

print(f"{written} characters correspond to {len(msg[:written].encode('utf-8'))} bytes in UTF-8")
print(f"{len(b)} bytes read")
----

Output:
----
BlockingIOError.characters_written == 81920
81920 characters correspond to 215040 bytes in UTF-8
81920 bytes read
----

I think it is confusing behavior.
If this is intended behavior, then it should be documented as such and I think 'bytes_written' is more appropriate name.

----------
components: IO
messages: 362611
nosy: msakai
priority: normal
severity: normal
status: open
title: BlockingIOError.characters_written represents number of bytes not characters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39745>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:08:43 2020
From: report at bugs.python.org (Orion Fisher)
Date: Tue, 25 Feb 2020 03:08:43 +0000
Subject: [issue39746] Inappropriate short circuit relating to inequality
 comparison and membership test
Message-ID: <1582600123.76.0.783865258946.issue39746@roundup.psfhosted.org>


New submission from Orion Fisher <OCFI222 at g.uky.edu>:

I found a strange issue with how the interpreter produces bytecode for an expression like True != True in [False, False].

Reading it, one would expect the value of the expression to be True, whether the inequality comparison is evaluated first, or the membership test is evaluated first. Indeed, when parentheses are used to control the order of execution these results do occur.

However, without any parentheses, the result is False. The underlying cause seems to be in a short circuit which is dependent on the inequality comparison, seen in the JUMP_IF_FALSE_OR_POP instruction.

This expression is very synthetic, but I am submitting this bug under the worry that it speaks to a more significant error in the bytecode produced for inequality tests (or membership tests).

----------
components: Interpreter Core
files: bug_occurence.py
messages: 362612
nosy: Orion Fisher
priority: normal
severity: normal
status: open
title: Inappropriate short circuit relating to inequality comparison and membership test
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48911/bug_occurence.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39746>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:19:07 2020
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Feb 2020 03:19:07 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582600747.3.0.658253516974.issue30566@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset ba22e8f174309979d90047c5dc64fcb63bc2c32e by Berker Peksag in branch 'master':
bpo-30566: Fix IndexError when using punycode codec (GH-18632)
https://github.com/python/cpython/commit/ba22e8f174309979d90047c5dc64fcb63bc2c32e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:19:32 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Feb 2020 03:19:32 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582600772.14.0.520757950107.issue30566@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18012
pull_request: https://github.com/python/cpython/pull/18651

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:19:39 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Feb 2020 03:19:39 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582600779.25.0.353356008455.issue30566@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18013
pull_request: https://github.com/python/cpython/pull/18652

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:21:20 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Feb 2020 03:21:20 +0000
Subject: [issue39746] Inappropriate short circuit relating to inequality
 comparison and membership test
In-Reply-To: <1582600123.76.0.783865258946.issue39746@roundup.psfhosted.org>
Message-ID: <1582600880.63.0.81536264649.issue39746@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

"!=" and "in" are comparison operators in Python, and _all_ comparison operators "chain".  That is,

x < y < z

means

x < y and y < z

(although y is evaluated only once), and in the same way

True != True in [False, False]

means

True != True and True in [False, False]

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39746>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:34:16 2020
From: report at bugs.python.org (Orion Fisher)
Date: Tue, 25 Feb 2020 03:34:16 +0000
Subject: [issue39746] Inappropriate short circuit relating to inequality
 comparison and membership test
In-Reply-To: <1582600123.76.0.783865258946.issue39746@roundup.psfhosted.org>
Message-ID: <1582601656.43.0.0959236584007.issue39746@roundup.psfhosted.org>


Change by Orion Fisher <OCFI222 at g.uky.edu>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39746>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:36:31 2020
From: report at bugs.python.org (Orion Fisher)
Date: Tue, 25 Feb 2020 03:36:31 +0000
Subject: [issue39746] Inappropriate short circuit relating to inequality
 comparison and membership test
In-Reply-To: <1582600123.76.0.783865258946.issue39746@roundup.psfhosted.org>
Message-ID: <1582601791.03.0.454386880684.issue39746@roundup.psfhosted.org>


Orion Fisher <OCFI222 at g.uky.edu> added the comment:

Ah, I see, thank you for the clear explanation.

Chaining is so intuitive in the case it is always introduced with, yet I never knew it applied so generally.

(New to the interface so I hope this is indeed where I must reply.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39746>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:40:05 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 25 Feb 2020 03:40:05 +0000
Subject: [issue39746] Inappropriate short circuit relating to inequality
 comparison and membership test
In-Reply-To: <1582600123.76.0.783865258946.issue39746@roundup.psfhosted.org>
Message-ID: <1582602005.77.0.634387789534.issue39746@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

For reference see the section on comparisons in the language reference:

https://docs.python.org/3/reference/expressions.html#comparisons

----------
nosy: +eryksun
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39746>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:42:45 2020
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Feb 2020 03:42:45 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582602165.8.0.959782106034.issue30566@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset daef21ce7dfd3735101d85d6ebf7554187c33ab8 by Miss Islington (bot) in branch '3.8':
bpo-30566: Fix IndexError when using punycode codec (GH-18632)
https://github.com/python/cpython/commit/daef21ce7dfd3735101d85d6ebf7554187c33ab8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:43:49 2020
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Feb 2020 03:43:49 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582602229.27.0.237429285035.issue30566@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 55be9a6c09d4415f50b14212ce22eccefa83ca64 by Miss Islington (bot) in branch '3.7':
bpo-30566: Fix IndexError when using punycode codec (GH-18632)
https://github.com/python/cpython/commit/55be9a6c09d4415f50b14212ce22eccefa83ca64


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:46:03 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 25 Feb 2020 03:46:03 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582602363.36.0.801893608887.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

PEP 584 has been approved by the Steering Council (at my recommendation). We will shortly begin landing PRs related to this.

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:47:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 25 Feb 2020 03:47:37 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582602457.55.0.768059157114.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset eb8ac57af26c4eb96a8230eba7492ce5ceef7886 by Brandt Bucher in branch 'master':
bpo-36144: Dictionary Union (PEP 584) (#12088)
https://github.com/python/cpython/commit/eb8ac57af26c4eb96a8230eba7492ce5ceef7886


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:49:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 25 Feb 2020 03:49:09 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582602549.22.0.268817098625.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

While the main code has been merged now, I propose to keep this issue open until some other things have happened:

- Documentation
- Add | operators to some dict subclasses in the stdlib
- (What else?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Mon Feb 24 22:53:43 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 25 Feb 2020 03:53:43 +0000
Subject: [issue39746] Inappropriate short circuit relating to inequality
 comparison and membership test
In-Reply-To: <1582600123.76.0.783865258946.issue39746@roundup.psfhosted.org>
Message-ID: <1582602823.25.0.59753250479.issue39746@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Orion, you're using the interface as intended :-)

While it's too late to change now, if Python started over from scratch I'd argue to leave "in" and "not in" out of this feature - chaining them is _usually_ an unintended behavior.

Then again, sometimes it is slightly useful.  For example, if I want to know if `n` is in a set of primes, but isn't even,

if 2 != n in some_set_of_primes:

does the job succinctly.  But not really "Pythonically", since even experienced Python programmers may scratch their heads when reading it :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39746>
_______________________________________

From report at bugs.python.org  Mon Feb 24 23:10:48 2020
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 25 Feb 2020 04:10:48 +0000
Subject: [issue30566] punycode codec raises IndexError in
 decode_generalized_number()
In-Reply-To: <1496591394.26.0.00653153658066.issue30566@psf.upfronthosting.co.za>
Message-ID: <1582603848.14.0.529644415065.issue30566@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report and for the initial patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30566>
_______________________________________

From report at bugs.python.org  Mon Feb 24 23:33:02 2020
From: report at bugs.python.org (Masahiro Sakai)
Date: Tue, 25 Feb 2020 04:33:02 +0000
Subject: [issue39745] BlockingIOError.characters_written represents number of
 bytes not characters
In-Reply-To: <1582598879.29.0.157478927981.issue39745@roundup.psfhosted.org>
Message-ID: <1582605182.8.0.968456097045.issue39745@roundup.psfhosted.org>


Change by Masahiro Sakai <masahiro.sakai at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39745>
_______________________________________

From report at bugs.python.org  Tue Feb 25 00:36:29 2020
From: report at bugs.python.org (Ethan Smith)
Date: Tue, 25 Feb 2020 05:36:29 +0000
Subject: [issue39747] test_os debug assertion failure
Message-ID: <1582608989.67.0.495966477974.issue39747@roundup.psfhosted.org>


New submission from Ethan Smith <ethan at ethanhs.me>:

With CPython master branch and build.bat -e -p x64, if I run test_os I get the following (in a messagebox transcribed here for ease of consumption).

Sorry if I am missing something. This means I am unable to run test_os to completion.

I am on Windows 10.0.19559.1000 x64 with CL 19.24.28315/Visual Studio 16.4.3

For test_bad_fd:
-----
Debug Assertion Failed!

Program: C:\Users\ethanhs\cpython\PCbuild\amd64\python_d.exe
File: minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp
Line: 17

Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
 ---

----------
components: Windows
messages: 362624
nosy: Ethan Smith, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_os debug assertion failure
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39747>
_______________________________________

From report at bugs.python.org  Tue Feb 25 01:06:45 2020
From: report at bugs.python.org (Mike Frysinger)
Date: Tue, 25 Feb 2020 06:06:45 +0000
Subject: [issue25960] Popen.wait() hangs when called from a signal handler
 when os.waitpid() does not
In-Reply-To: <1451213882.47.0.471062889789.issue25960@psf.upfronthosting.co.za>
Message-ID: <1582610805.46.0.908690081437.issue25960@roundup.psfhosted.org>


Mike Frysinger <vapier at users.sourceforge.net> added the comment:

if threading.active_count() returns 1, then you know there's one thread, and you're it, so it's not racey, and a lock ins't needed.

thinking a bit more, what if the code just use a recursive lock ?  that would restore the single threaded status quo without overly complicating the code.

thinking a bit more, i think you're right that this is inherently racy, but not because using the APIs in async context isn't permissible.  if a signal is delivered after Popen.wait() finishes the OS waitpid call, but before it releases the lock, then the child state is not recoverable from the signal handler.

in our case, we're using the signal handler to kill the process, and we want to make sure it's exited, so being able to get the exact exit status is not important to us, just making sure we can detect when the process is gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25960>
_______________________________________

From report at bugs.python.org  Tue Feb 25 01:29:00 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 25 Feb 2020 06:29:00 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582612140.61.0.0393633268025.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

My current PR plans are:

- Docs. This will include the dict docs and the whatsnew 3.9. I assume we have no plans to cover this in the tutorials, etc. Let me know if I'm missing anything here.
- collections.defaultdict, with tests. I don't think this needs docs beyond a short "changed in version 3.9" note.
- collections.OrderedDict, with tests. Ditto defaultdict on docs.
- collections.ChainMap, ditto.
- types.MappingProxy, ditto.

I'll also create a BPO issue to discuss whether the dict subclasses in http.cookies should be updated.

That should do it for CPython; I'm planning on updating typeshed and adding a handful of tests to mypy for TypedDict, etc. after these are landed.

Guido, okay to tag you on these for review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 01:51:56 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 25 Feb 2020 06:51:56 +0000
Subject: [issue29450] xattr functions aren't in os.supports_fd,
 os.supports_follow_symlinks
In-Reply-To: <1486287860.62.0.802712636976.issue29450@psf.upfronthosting.co.za>
Message-ID: <1582613516.91.0.387418520303.issue29450@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +18014
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18653

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29450>
_______________________________________

From report at bugs.python.org  Tue Feb 25 02:25:04 2020
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Tue, 25 Feb 2020 07:25:04 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1582615504.23.0.877386403065.issue39511@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/issue39511>
_______________________________________

From report at bugs.python.org  Tue Feb 25 02:44:09 2020
From: report at bugs.python.org (Floris Lambrechts)
Date: Tue, 25 Feb 2020 07:44:09 +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: <1582616649.58.0.742209953443.issue39090@roundup.psfhosted.org>


Floris Lambrechts <florisla at gmail.com> added the comment:

Based on the feedback received in GitHub here:
https://github.com/florisla/cpython/commit/c146ad3d086fe9e401284c12fc670ea4f9398f3b

I made a new revision of the 'Absolute paths' chapter here:
https://github.com/florisla/cpython/blob/pathlib-chapter-absolute-paths-2/Doc/library/pathlib.rst#absolute-paths

Further feedback is welcome.

Changes:

* Be more 'in your face' about Path.resolve() being the recommended
  approach.
* Add separate section on Windows considerations
* Explain difference between Path.resolve() and os.path.isabs() w.r.t.
  checking for drive.
* Refer to 'mapped share' instead of 'mapped network share'.
* Explain replacement of substitute drive with final path.
* Mention os.path.abspath's upcasing of drive letter in case of
  a path missing a root.
* Mention different handling of junctions versus symlinks w.r.t.
  relative parts.

For brevity, I've kept the wording on substitute drive and handling of
junctions very short.

For the same reason I did not not include eryksun's (interesting!) info
on why mapped and substitute drives are non-canonical.

Not mentioning Path.resolve()'s behavior w.r.t. non-existing files since
that's documented in resolve() itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39090>
_______________________________________

From report at bugs.python.org  Tue Feb 25 03:10:07 2020
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Tue, 25 Feb 2020 08:10:07 +0000
Subject: [issue39683] 2to3 fix_exitfunc suggests duplicated import of atexit
 module
In-Reply-To: <1582078726.23.0.378327205623.issue39683@roundup.psfhosted.org>
Message-ID: <1582618207.17.0.0359324196896.issue39683@roundup.psfhosted.org>


Change by Paulo Henrique Silva <ph.silva at gmail.com>:


----------
keywords: +patch
nosy: +phsilva
nosy_count: 1.0 -> 2.0
pull_requests: +18015
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18654

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39683>
_______________________________________

From report at bugs.python.org  Tue Feb 25 04:04:42 2020
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Tue, 25 Feb 2020 09:04:42 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1582621482.61.0.756464335111.issue1635741@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/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Feb 25 04:18:28 2020
From: report at bugs.python.org (zd nex)
Date: Tue, 25 Feb 2020 09:18:28 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582622308.59.0.232552172851.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

So I was trying it again in Python 3.6.9 and 3.8.1 directly in REPL. And it behaves same.  I have tried it on two different linux boxes (both 64bit) where I have diffrent versions. In both of them it crashes in same way .. destroy _ast and then it crashes and faulthandler again shows shelve (pickle)


So I am attaching new crash reports directly from REPL where I just call list(data.items()) and then exit()

Btw it seems to me that when PDB is active crash does not occurs until exit() is called.

----------
Added file: https://bugs.python.org/file48912/crash.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Tue Feb 25 04:53:49 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Tue, 25 Feb 2020 09:53:49 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582624429.35.0.936901937768.issue39672@roundup.psfhosted.org>


Andrei Daraschenka <dorosch.github.io at yandex.ru> added the comment:

Hello
I was finally reproduce your problem.
Probles was in Lib/shelve.py module in method Shelf.sync. When python is shut down in classes calls __exit__ methods, in our issues method __exti__ called method close() which called method sync(). Method sync() tried sync data between disk and memory storage. But if key didn't exists on disk - python has error segfault.
I attach path for this problem and I will prepare PR soon.

----------
keywords: +patch
Added file: https://bugs.python.org/file48913/shelve.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Tue Feb 25 05:11:12 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Tue, 25 Feb 2020 10:11:12 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582625472.28.0.928677308014.issue39672@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
pull_requests: +18016
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18655

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Tue Feb 25 05:13:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 10:13:15 +0000
Subject: [issue39747] test_os debug assertion failure
In-Reply-To: <1582608989.67.0.495966477974.issue39747@roundup.psfhosted.org>
Message-ID: <1582625595.22.0.0332754661745.issue39747@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Well, you're running a debug build but building a release build (unless you missed the "-d" from the command line -- "-e" is the default now, BTW), so your build may be out of sync.

These assertion dialogs are supposed to be suppressed during the test suite, but only when run using "python.bat -m test test_os". If you're running the OS tests any other way, then you'll see these popups.

(I hope you used Ctrl+C in the dialog to copy the text, by the way. That's a lot to copy out by hand!)

---

FWIW, these are very good assertions for most programs. But most programs are not intentionally passing arbitrary values into system calls, so we have to suppress them for Python :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39747>
_______________________________________

From report at bugs.python.org  Tue Feb 25 06:30:30 2020
From: report at bugs.python.org (Noel del rosario)
Date: Tue, 25 Feb 2020 11:30:30 +0000
Subject: [issue39748] PyScripter could not find Python 3.8 64 bits
Message-ID: <1582630230.75.0.555477437991.issue39748@roundup.psfhosted.org>


New submission from Noel del rosario <noelzdelrosario at gmail.com>:

I installed Python 2.7, 3.7 and 3.8, all in 64 bits.   Then I installed the PYSCRYPTER 3.6 54 bits.  The PySCripter can easily set up PYTHON 2.7 and 3.7 easily.  But it cannot settup Python 3.8.  It cannot find it.

----------
components: Installation
messages: 362631
nosy: rosarion
priority: normal
severity: normal
status: open
title: PyScripter could not find Python 3.8 64 bits
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39748>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:03:05 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:03:05 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1582632185.17.0.711059000305.issue27657@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Can this be closed? Downgrading priority since the fix was released as part of 3.8.2rc2 and 3.8.2 final.

----------
priority: release blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:03:54 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:03:54 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1582632234.03.0.0231973871312.issue38856@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Downgrading priority on this, agreed with Victor.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:06:41 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:06:41 +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: <1582632401.73.0.557798397886.issue39042@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

I agree this should be fixed. Since we've already released 3.8.1 and 3.8.2 with this behavior it's hard to justify blocking releases on this, though.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39042>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:08:10 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:08:10 +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: <1582632490.26.0.0391549956687.issue38913@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Sadly, this missed the train for 3.8.2 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:09:37 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:09:37 +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: <1582632577.57.0.154700954915.issue37228@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Downgrading priority since it's released everywhere except for 3.5.

----------
priority: deferred blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37228>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:10:38 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:10:38 +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: <1582632638.29.0.715356166523.issue30064@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Downgrading priority on this one.

----------
priority: deferred blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30064>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:13:01 2020
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 25 Feb 2020 12:13:01 +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: <1582632781.1.0.437962565821.issue38410@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Sadly, this missed the train for 3.8.2. Steve, what's the status of the open PR for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38410>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:26:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Feb 2020 12:26:58 +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: <1582633618.75.0.175352492033.issue38913@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/issue38913>
_______________________________________

From report at bugs.python.org  Tue Feb 25 07:29:34 2020
From: report at bugs.python.org (Markus Roth)
Date: Tue, 25 Feb 2020 12:29:34 +0000
Subject: [issue31539] asyncio.sleep may sleep less time then it should
In-Reply-To: <1505980378.53.0.90581891243.issue31539@psf.upfronthosting.co.za>
Message-ID: <1582633774.04.0.267576184591.issue31539@roundup.psfhosted.org>


Markus Roth <markusroth86 at gmail.com> added the comment:

When the fine tuning options for install-directories are set, the default directories "lib", "bin" and "include" are still created with essential content. Even if options like --libdir are set.

----------
nosy: +CatorCanulis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31539>
_______________________________________

From report at bugs.python.org  Tue Feb 25 08:00:18 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 25 Feb 2020 13:00:18 +0000
Subject: [issue39748] PyScripter could not find Python 3.8 64 bits
In-Reply-To: <1582630230.75.0.555477437991.issue39748@roundup.psfhosted.org>
Message-ID: <1582635618.63.0.889032800964.issue39748@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This sounds like an issue with PyScripter. I suggest you ask them for guidance on how to debug it.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39748>
_______________________________________

From report at bugs.python.org  Tue Feb 25 08:24:53 2020
From: report at bugs.python.org (=?utf-8?b?6r+I64+M?=)
Date: Tue, 25 Feb 2020 13:24:53 +0000
Subject: [issue39749] python 3.8.1 (3.14 * 10  = 31.400000002  bug)
Message-ID: <1582637093.58.0.373430719424.issue39749@roundup.psfhosted.org>


New submission from ?? <bwook0721 at gmail.com>:

10 * 3.14
31.400000000000002

there is a bug in 3.8.1 python, 10 * 3.14 is 31.4 but in python 31.400000000000002....

----------
messages: 362641
nosy: ??
priority: normal
severity: normal
status: open
title: python 3.8.1 (3.14 * 10  = 31.400000002  bug)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39749>
_______________________________________

From report at bugs.python.org  Tue Feb 25 08:28:33 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Feb 2020 13:28:33 +0000
Subject: [issue39749] python 3.8.1 (3.14 * 10  = 31.400000002  bug)
In-Reply-To: <1582637093.58.0.373430719424.issue39749@roundup.psfhosted.org>
Message-ID: <1582637313.98.0.140188895263.issue39749@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a known behavior : https://docs.python.org/3/tutorial/floatingpoint.html

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39749>
_______________________________________

From report at bugs.python.org  Tue Feb 25 09:59:24 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 25 Feb 2020 14:59:24 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1582642764.18.0.512427465298.issue37373@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> was Tornado the only project experiencing this pain

At least twisted and anyio are still broken on 3.8+Windows because of this change:

https://twistedmatrix.com/trac/ticket/9766
https://github.com/agronholm/anyio/issues/77

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Tue Feb 25 10:02:04 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 25 Feb 2020 15:02:04 +0000
Subject: [issue31539] asyncio.sleep may sleep less time then it should
In-Reply-To: <1505980378.53.0.90581891243.issue31539@psf.upfronthosting.co.za>
Message-ID: <1582642924.37.0.9008966459.issue31539@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Markus, your comment does not seem relevant to this issue. Maybe you meant to add it to a different issue, or you meant to create a new issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31539>
_______________________________________

From report at bugs.python.org  Tue Feb 25 10:07:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 25 Feb 2020 15:07:40 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1582612140.61.0.0393633268025.issue36144@roundup.psfhosted.org>
Message-ID: <CAP7+vJJ9uMtQFkyScB7cc3BEX-zzM4tV8w-Mohq0U-_-unhTig@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yup, great plan.

On Mon, Feb 24, 2020 at 22:29 Brandt Bucher <report at bugs.python.org> wrote:

>
> Brandt Bucher <brandtbucher at gmail.com> added the comment:
>
> My current PR plans are:
>
> - Docs. This will include the dict docs and the whatsnew 3.9. I assume we
> have no plans to cover this in the tutorials, etc. Let me know if I'm
> missing anything here.
> - collections.defaultdict, with tests. I don't think this needs docs
> beyond a short "changed in version 3.9" note.
> - collections.OrderedDict, with tests. Ditto defaultdict on docs.
> - collections.ChainMap, ditto.
> - types.MappingProxy, ditto.
>
> I'll also create a BPO issue to discuss whether the dict subclasses in
> http.cookies should be updated.
>
> That should do it for CPython; I'm planning on updating typeshed and
> adding a handful of tests to mypy for TypedDict, etc. after these are
> landed.
>
> Guido, okay to tag you on these for review?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36144>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 10:08:23 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 25 Feb 2020 15:08:23 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582643303.73.0.570941297377.issue39737@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

IMHO, I can not see a noticeable performance improvement.
I think that the modern compiler will optimize the reused variable. ;)
The below result might be noise.


[master]
./python.exe -m pyperf timeit "A = list(range(10**3)); B = list(range(10**3))" "A==B"
.....................
Mean +- std dev: 415 us +- 6 us

[PR 18638]
./python.exe -m pyperf timeit "A = list(range(10**3)); B = list(range(10**3))" "A==B"
.....................
Mean +- std dev: 433 us +- 20 us

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 10:38:20 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 25 Feb 2020 15:38:20 +0000
Subject: [issue39749] python 3.8.1 (3.14 * 10  = 31.400000002  bug)
In-Reply-To: <1582637093.58.0.373430719424.issue39749@roundup.psfhosted.org>
Message-ID: <1582645100.27.0.925352829044.issue39749@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This behaviour is shared by all programming languages that use floating point numbers. For example, this is Ruby:

    [steve at ando ~]$ irb
    irb(main):001:0> 10 * 3.14 == 31.4
    => false
    irb(main):002:0> 10 * 3.14 - 31.4
    => 3.5527136788005e-15

It's not a bug in Python or even in floating point numbers. See the link in the tutorial that xtreak gave and the FAQ

https://docs.python.org/3/faq/design.html#why-am-i-getting-strange-results-with-simple-arithmetic-operations

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39749>
_______________________________________

From report at bugs.python.org  Tue Feb 25 11:15:36 2020
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Eiras?=)
Date: Tue, 25 Feb 2020 16:15:36 +0000
Subject: [issue39750] UnicodeError becomes unpicklable if data is appended to
 args
Message-ID: <1582647336.17.0.517223219132.issue39750@roundup.psfhosted.org>


New submission from Jo?o Eiras <joao.eiras at gmail.com>:

Given some exception `ex`, you can append data like
  ex.args += (value1, value2, ...)
and then re-raise.

This is something I do in my projects to sometime propagate context when errors are raised, e.g., stacktraces across process boundaries or blobs of text with pickling or unicode errors.

When this is done with UnicodeError, the exception becomes non-unpicklable:

  TypeError: function takes exactly 5 arguments (6 given)

Example:
    import pickle

    def test_unicode_error_unpickle():
        ex0 = UnicodeEncodeError('ascii','message', 1, 2, 'e')
        ex0.args += ("extra context",)
        ex1 = pickle.loads(pickle.dumps(ex0))
        assert type(ex0).args == type(ex1).args
        assert ex0.args == ex1.args

The issue seems to be UnicodeEncodeError_init() at https://github.com/python/cpython/blob/v3.8.1/Objects/exceptions.c#L1895 and also UnicodeDecodeError_init().

The BaseException is initialized, but then Unicode*Error_init() tries to reparse the arguments and does not tolerate extra values.

This because BaseException.__reduce__ return a tuple (class,args).

----------
components: Interpreter Core
files: test_unicode_error_unpickle.py
messages: 362648
nosy: Jo?o Eiras
priority: normal
severity: normal
status: open
title: UnicodeError becomes unpicklable if data is appended to args
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48914/test_unicode_error_unpickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39750>
_______________________________________

From report at bugs.python.org  Tue Feb 25 11:37:00 2020
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Eiras?=)
Date: Tue, 25 Feb 2020 16:37:00 +0000
Subject: [issue39751] multiprocessing breaks when payload fails to unpickle
Message-ID: <1582648620.1.0.266788942102.issue39751@roundup.psfhosted.org>


New submission from Jo?o Eiras <joao.eiras at gmail.com>:

The multiprocessing module uses pickles to send data between processes.

If a blob fails to unpickle (bad implementation of __setstate__, invalid payload from __reduce__, random crash in __init__) when the multiprocessing module will crash inside the _handle_results worker, e.g.:

  File "lib\threading.py", line 932, in _bootstrap_inner
    self.run()
  File "lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "lib\multiprocessing\pool.py", line 576, in _handle_results
    task = get()
  File "lib\multiprocessing\connection.py", line 251, in recv
    return _ForkingPickler.loads(buf.getbuffer())
  TypeError: __init__() takes 1 positional argument but 4 were given

After this the worker has crashed and every task waiting from results from the pool will wait forever.

There are 2 things that I think should be fixed:
1. in handle_results, capture all unrecognized errors and propagate in the main thread. At this point at least one of the jobs' replies is lost forever so there is little point in trying to log and resume.
2. separate the result payload from the payload that contains the job index/id so they are unpickled in two steps. The first step unpickles the data internal to multiprocessing to know which task the result refers to. The second step unpickles the return value or exception from the function that was called, and if this object fails to unpickle, propagate that error to the main thread through the proper ApplyResult or IMapIterator instances.

----------
components: email
files: test_multiproc_error_unpickle.py
messages: 362649
nosy: Jo?o Eiras, barry, r.david.murray
priority: normal
severity: normal
status: open
title: multiprocessing breaks when payload fails to unpickle
versions: Python 3.8
Added file: https://bugs.python.org/file48915/test_multiproc_error_unpickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39751>
_______________________________________

From report at bugs.python.org  Tue Feb 25 11:37:04 2020
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Eiras?=)
Date: Tue, 25 Feb 2020 16:37:04 +0000
Subject: [issue39751] multiprocessing breaks when payload fails to unpickle
In-Reply-To: <1582648620.1.0.266788942102.issue39751@roundup.psfhosted.org>
Message-ID: <1582648624.58.0.821770462553.issue39751@roundup.psfhosted.org>


Change by Jo?o Eiras <joao.eiras at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39751>
_______________________________________

From report at bugs.python.org  Tue Feb 25 12:04:00 2020
From: report at bugs.python.org (Rahul Kumaresan)
Date: Tue, 25 Feb 2020 17:04:00 +0000
Subject: [issue39705] Tutorial, 5.6 Looping Techniques, sorted() example
In-Reply-To: <1582277071.44.0.766763125418.issue39705@roundup.psfhosted.org>
Message-ID: <1582650240.98.0.236104774835.issue39705@roundup.psfhosted.org>


Rahul Kumaresan <kayrahul at gmail.com> added the comment:

I would like to work on this documentation improvement task.
Please help me understand if this is not being worked on already.

----------
nosy: +rahul-kumi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39705>
_______________________________________

From report at bugs.python.org  Tue Feb 25 12:24:16 2020
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Eiras?=)
Date: Tue, 25 Feb 2020 17:24:16 +0000
Subject: [issue39752] multiprocessing halts when child process crashes/quits
Message-ID: <1582651456.06.0.685882029108.issue39752@roundup.psfhosted.org>


New submission from Jo?o Eiras <joao.eiras at gmail.com>:

Hi.

When one of the processes in a multiprocessing.pool picks up a task then then somehow crashes (and by crash I mean crashing the python process with something like a SEGV) or is killed, the pool in the main process will notice one of the workers died and will repopulate the pool, but it does not keep track which task was being handled by the process that died. As consequence, a caller waiting for a result will get stuck forever.

Example:
    with multiprocessing.Pool(1) as pool:
        result = pool.map_async(os._exit, [1]).get(timeout=2)

I found this because I was trying to use a lock with a spawned process on linux and that caused a crash and my program froze, but that is another issue.

----------
components: Extension Modules
messages: 362651
nosy: Jo?o Eiras
priority: normal
severity: normal
status: open
title: multiprocessing halts when child process crashes/quits
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39752>
_______________________________________

From report at bugs.python.org  Tue Feb 25 12:39:08 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 17:39:08 +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: <1582652348.85.0.750354723356.issue38410@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I thought we weren't going to take the fix for 3.8 anyway? (Or did we make a smaller one and commit it directly, apparently without linking it to the issue correctly?)

The status is the PR needs conflicts resolved, and people need to stop adding to my infinite list of GitHub notifications and ping me on here instead :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38410>
_______________________________________

From report at bugs.python.org  Tue Feb 25 12:41:33 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 17:41:33 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582652493.78.0.617665496636.issue38597@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You should be able to install "wheel" without setuptools to get the bdist_wheel command.

Can you confirm that the build process is actually using that Visual Studio install? If it's going through the regular distutils detection process then it ought to be finding the right files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Mon Feb 24 11:30:44 2020
From: report at bugs.python.org (nono)
Date: Mon, 24 Feb 2020 16:30:44 +0000
Subject: [issue39739] Python crash every time opening pycharm,
 seems related to tensorflow
Message-ID: <1582561844.94.0.0622308922245.issue39739@roundup.psfhosted.org>


New submission from nono <nonococochy at gmail.com>:

Hey,

Whenever I try to open project in Pycharm, it will update python interpreter before the python process crashes with a SIGABRT and I get a crash window from OSX. I use homebrew with the latest packages and python 3.7.6.

Any help is appreciated. Here's the log:

Process:               Python [3240]
Path:                  /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.7.6 (3.7.6)
Code Type:             X86-64 (Native)
Parent Process:        Python [2877]
Responsible:           pycharm [2777]
User ID:               501

Date/Time:             2020-02-23 20:43:10.553 -0500
OS Version:            Mac OS X 10.15.3 (19D76)
Report Version:        12


Time Awake Since Boot: 17000 seconds
Time Since Wake:       1000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
/usr/local/lib/python3.7/site-packages/tensorflow_core/compiler/tf2xla/ops/_xla_ops.so
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff656707fa __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff6572dbc1 pthread_kill + 432
2   libsystem_c.dylib             	0x00007fff655873a2 raise + 26
3   libsystem_platform.dylib      	0x00007fff6572242d _sigtramp + 29
4   ???                           	0x00007fff8f33a988 __c_locale + 1480
5   libsystem_c.dylib             	0x00007fff655f7a1c abort + 120
6   libtensorflow_framework.2.dylib	0x0000000122394bec tensorflow::internal::LogMessageFatal::~LogMessageFatal() + 44
7   libtensorflow_framework.2.dylib	0x0000000122394c20 tensorflow::internal::LogMessageFatal::~LogMessageFatal() + 16
8   libtensorflow_framework.2.dylib	0x0000000121c0452a tensorflow::OpRegistry::Register(std::__1::function<tensorflow::Status (tensorflow::OpRegistrationData*)> const&) + 186
9   libtensorflow_framework.2.dylib	0x0000000121c06280 tensorflow::register_op::OpDefBuilderReceiver::OpDefBuilderReceiver(tensorflow::register_op::OpDefBuilderWrapper<true> const&) + 128
10  _xla_ops.so                   	0x00000001304d6515 _GLOBAL__sub_I_xla_ops.cc + 757
11  dyld                          	0x000000010640e15d ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 539
12  dyld                          	0x000000010640e582 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
13  dyld                          	0x0000000106408dc7 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 493
14  dyld                          	0x0000000106406e58 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 188
15  dyld                          	0x0000000106406ef8 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 82
16  dyld                          	0x00000001063f8f87 dyld::runInitializers(ImageLoader*) + 82
17  dyld                          	0x0000000106402ad7 dlopen_internal + 609
18  libdyld.dylib                 	0x00007fff65514a7f dlopen + 171
19  org.python.python             	0x000000010399e759 _PyImport_FindSharedFuncptr + 301
20  org.python.python             	0x000000010397d5c2 _PyImport_LoadDynamicModuleWithSpec + 495
21  org.python.python             	0x000000010397d138 _imp_create_dynamic + 309
22  org.python.python             	0x00000001038d2472 _PyMethodDef_RawFastCallDict + 549
23  org.python.python             	0x00000001038d1a83 _PyCFunction_FastCallDict + 41
24  org.python.python             	0x000000010396065a _PyEval_EvalFrameDefault + 7738
25  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
26  org.python.python             	0x00000001038d1d88 _PyFunction_FastCallKeywords + 212
27  org.python.python             	0x0000000103967321 call_function + 737
28  org.python.python             	0x000000010396028f _PyEval_EvalFrameDefault + 6767
29  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
30  org.python.python             	0x0000000103967321 call_function + 737
31  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
32  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
33  org.python.python             	0x0000000103967321 call_function + 737
34  org.python.python             	0x000000010396032a _PyEval_EvalFrameDefault + 6922
35  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
36  org.python.python             	0x0000000103967321 call_function + 737
37  org.python.python             	0x000000010396032a _PyEval_EvalFrameDefault + 6922
38  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
39  org.python.python             	0x0000000103967321 call_function + 737
40  org.python.python             	0x000000010396032a _PyEval_EvalFrameDefault + 6922
41  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
42  org.python.python             	0x00000001038d3542 object_vacall + 267
43  org.python.python             	0x00000001038d3641 _PyObject_CallMethodIdObjArgs + 168
44  org.python.python             	0x000000010397c373 PyImport_ImportModuleLevelObject + 1490
45  org.python.python             	0x000000010395b7c2 builtin___import__ + 122
46  org.python.python             	0x00000001038d2865 _PyMethodDef_RawFastCallKeywords + 537
47  org.python.python             	0x00000001038d1dc0 _PyCFunction_FastCallKeywords + 41
48  org.python.python             	0x00000001039672b4 call_function + 628
49  org.python.python             	0x000000010396032a _PyEval_EvalFrameDefault + 6922
50  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
51  org.python.python             	0x00000001038d1a00 _PyFunction_FastCallDict + 444
52  org.python.python             	0x0000000103960573 _PyEval_EvalFrameDefault + 7507
53  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
54  org.python.python             	0x00000001038d1a00 _PyFunction_FastCallDict + 444
55  org.python.python             	0x0000000103960573 _PyEval_EvalFrameDefault + 7507
56  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
57  org.python.python             	0x0000000103967321 call_function + 737
58  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
59  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
60  org.python.python             	0x0000000103967321 call_function + 737
61  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
62  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
63  org.python.python             	0x0000000103967321 call_function + 737
64  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
65  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
66  org.python.python             	0x00000001038d2b07 _PyObject_Call_Prepend + 131
67  org.python.python             	0x000000010390fe96 slot_tp_init + 80
68  org.python.python             	0x000000010390cbc2 type_call + 172
69  org.python.python             	0x00000001038d1c36 _PyObject_FastCallKeywords + 358
70  org.python.python             	0x000000010396731a call_function + 730
71  org.python.python             	0x000000010396032a _PyEval_EvalFrameDefault + 6922
72  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
73  org.python.python             	0x0000000103967321 call_function + 737
74  org.python.python             	0x000000010396028f _PyEval_EvalFrameDefault + 6767
75  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
76  org.python.python             	0x0000000103967321 call_function + 737
77  org.python.python             	0x000000010396028f _PyEval_EvalFrameDefault + 6767
78  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
79  org.python.python             	0x0000000103967321 call_function + 737
80  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
81  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
82  org.python.python             	0x00000001038d1d88 _PyFunction_FastCallKeywords + 212
83  org.python.python             	0x0000000103967321 call_function + 737
84  org.python.python             	0x00000001039603d2 _PyEval_EvalFrameDefault + 7090
85  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
86  org.python.python             	0x0000000103967321 call_function + 737
87  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
88  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
89  org.python.python             	0x00000001038d1d88 _PyFunction_FastCallKeywords + 212
90  org.python.python             	0x0000000103967321 call_function + 737
91  org.python.python             	0x0000000103960276 _PyEval_EvalFrameDefault + 6742
92  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
93  org.python.python             	0x00000001038d1d88 _PyFunction_FastCallKeywords + 212
94  org.python.python             	0x0000000103967321 call_function + 737
95  org.python.python             	0x00000001039603d2 _PyEval_EvalFrameDefault + 7090
96  org.python.python             	0x00000001038d2194 function_code_fastcall + 106
97  org.python.python             	0x0000000103967321 call_function + 737
98  org.python.python             	0x000000010396032a _PyEval_EvalFrameDefault + 6922
99  org.python.python             	0x0000000103967b15 _PyEval_EvalCodeWithName + 1698
100 org.python.python             	0x000000010395e77d PyEval_EvalCode + 51
101 org.python.python             	0x000000010398cbc4 run_mod + 54
102 org.python.python             	0x000000010398bbf7 PyRun_FileExFlags + 160
103 org.python.python             	0x000000010398b2ae PyRun_SimpleFileExFlags + 270
104 org.python.python             	0x00000001039a3abe pymain_main + 5445
105 org.python.python             	0x00000001039a412c _Py_UnixMain + 56
106 libdyld.dylib                 	0x00007fff655297fd start + 1

Thread 1:
0   libsystem_kernel.dylib        	0x00007fff6566cce6 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff6572e185 _pthread_cond_wait + 701
2   libopenblasp-r0.3.7.dylib     	0x000000012a3c4c3b blas_thread_server + 619
3   libsystem_pthread.dylib       	0x00007fff6572de65 _pthread_start + 148
4   libsystem_pthread.dylib       	0x00007fff6572983b thread_start + 15

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00000001064bcdc0  rcx: 0x00007ffeec346ca8  rdx: 0x0000000000000000
  rdi: 0x0000000000000303  rsi: 0x0000000000000006  rbp: 0x00007ffeec346cd0  rsp: 0x00007ffeec346ca8
   r8: 0x0000000000000003   r9: 0xcccccccccccccccd  r10: 0x00000001064bcdc0  r11: 0x0000000000000246
  r12: 0x0000000000000303  r13: 0x0000000000000000  r14: 0x0000000000000006  r15: 0x0000000000000016
  rip: 0x00007fff656707fa  rfl: 0x0000000000000246  cr2: 0x000000012166e7c0
  
Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133


Binary Images:
       0x1038b0000 -        0x1038b1fff +org.python.python (3.7.6 - 3.7.6) <6948AAF1-D45E-3D9B-A895-03C843B1075D> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
       0x1038b8000 -        0x103a3bfff +org.python.python (3.7.6, [c] 2001-2019 Python Software Foundation. - 3.7.6) <25063A20-3D71-340D-81F1-96384E0857DA> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/Python
       0x103c0d000 -        0x103c0efff +lapack_lite.cpython-37m-darwin.so (0) <C3AA6C88-9EDB-3D5E-A9FA-7C9AF4ECFE3E> /usr/local/lib/python3.7/site-packages/numpy/linalg/lapack_lite.cpython-37m-darwin.so
       0x103c12000 -        0x103c12ff3 +_api_implementation.cpython-37m-darwin.so (0) <7DC68089-9C56-379B-81BB-57226E73C395> /usr/local/lib/python3.7/site-packages/google/protobuf/internal/_api_implementation.cpython-37m-darwin.so
       0x103c17000 -        0x103c18fff +termios.cpython-37m-darwin.so (0) <9808B153-1946-3BF9-B7D0-D38D95836A03> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/termios.cpython-37m-darwin.so
       0x103c1c000 -        0x103c1cfff +_uuid.cpython-37m-darwin.so (0) <49D01DE5-A3E3-3F6E-AB2A-54C1783B7B1C> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_uuid.cpython-37m-darwin.so
       0x103dc5000 -        0x103dc6fff +_heapq.cpython-37m-darwin.so (0) <0DA4E85D-9084-37B3-9998-8A7D3AF1B0B1> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x103e8b000 -        0x103e90fff +_json.cpython-37m-darwin.so (0) <A16EB964-F4E8-3E51-B03F-64349CD6803B> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_json.cpython-37m-darwin.so
       0x103efe000 -        0x103f0bff7 +_multiarray_tests.cpython-37m-darwin.so (0) <AE23762E-D167-3777-B727-FD1BD1A87420> /usr/local/lib/python3.7/site-packages/numpy/core/_multiarray_tests.cpython-37m-darwin.so
       0x103faa000 -        0x103fadfff +_hashlib.cpython-37m-darwin.so (0) <DD86C4DA-E460-36B1-A44A-F84AA6C7B818> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x103fb2000 -        0x104001fff +libssl.1.1.dylib (0) <8CC754E3-C1EE-37A0-AD64-D89C69816928> /usr/local/opt/openssl at 1.1/lib/libssl.1.1.dylib
       0x1040ea000 -        0x104283553 +libcrypto.1.1.dylib (0) <0E7D90A2-D870-3A17-B784-81564B61D7B9> /usr/local/opt/openssl at 1.1/lib/libcrypto.1.1.dylib
       0x104315000 -        0x10431affb +_blake2.cpython-37m-darwin.so (0) <24A45B55-A5EE-384C-9C8B-E2E19504DE49> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x10431f000 -        0x10432ffff +_sha3.cpython-37m-darwin.so (0) <3BD181F6-9F5F-39D0-8E3E-AFC9B7F36D8D> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x104335000 -        0x104338fff +zlib.cpython-37m-darwin.so (0) <9F0544E2-DA98-3105-8E35-6C9EA1D83E1E> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x10433e000 -        0x10433ffff +_bz2.cpython-37m-darwin.so (0) <7F5E7C34-9555-3C00-9002-D3872E2E1038> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x104344000 -        0x104347ff7 +_lzma.cpython-37m-darwin.so (0) <359A39BA-4669-3BD6-8174-7D03F3FAEC73> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x10434d000 -        0x104368ff3 +liblzma.5.dylib (0) <D5E25B2B-6DFB-3233-850B-65F488A14688> /usr/local/opt/xz/lib/liblzma.5.dylib
       0x10436e000 -        0x10436ffff +grp.cpython-37m-darwin.so (0) <068AE1FA-5DF7-30C7-AFB2-248D3602A60F> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x104373000 -        0x104373fff +_opcode.cpython-37m-darwin.so (0) <1B368B19-685C-3521-8617-6A2D5D506088> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x104377000 -        0x10437afff +_struct.cpython-37m-darwin.so (0) <4171BD07-989E-353C-820D-9F8BA813EFD2> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x104381000 -        0x104384ff7 +binascii.cpython-37m-darwin.so (0) <8B08F4CA-677D-3433-A6B1-51EC47E46AE0> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so
       0x1043c9000 -        0x1043cbff7 +_wrap_py_utils.so (0) <B0012B1A-85F2-3F42-8B0E-079BFFBE3C8C> /usr/local/lib/python3.7/site-packages/tensorflow_core/compiler/tf2tensorrt/_wrap_py_utils.so
       0x1043ce000 -        0x1043cfffb +libsz.2.dylib (0) <C3E13A34-DBC5-3EBD-85E2-2E68FAE23D68> /usr/local/lib/python3.7/site-packages/h5py/.dylibs/libsz.2.dylib
       0x1043d2000 -        0x1043d4fff +mmap.cpython-37m-darwin.so (0) <B29EAB03-27E7-3153-AACE-A37451EDF63D> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/mmap.cpython-37m-darwin.so
       0x10441a000 -        0x104426ffb +_pickle.cpython-37m-darwin.so (0) <C0C59BE5-1B64-3A9E-88BC-93C7A16CC0B5> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x104431000 -        0x104439ffb +_socket.cpython-37m-darwin.so (0) <132B2171-C425-3139-B7FF-79C3DAB3CDF0> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x104485000 -        0x104489ff3 +math.cpython-37m-darwin.so (0) <2C8E657B-4446-3844-B549-0F4DB5F5C351> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x104490000 -        0x104492fff +select.cpython-37m-darwin.so (0) <048BD53F-21B5-3BC2-9696-EBDA8C796C53> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x104498000 -        0x10449dffb +array.cpython-37m-darwin.so (0) <BA5C73BF-CED7-393A-8A48-333776936008> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/array.cpython-37m-darwin.so
       0x1044a5000 -        0x1044a5fff +_bisect.cpython-37m-darwin.so (0) <7C7230DF-C9CD-39F3-862E-DA9AFFEC69AE> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x1044a9000 -        0x1044aaffb +_random.cpython-37m-darwin.so (0) <3A53714A-1DEA-3F95-BE47-7933AC3AF60E> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x1044ae000 -        0x1044afffb +_multiprocessing.cpython-37m-darwin.so (0) <DA5DB622-3D54-3003-8A54-A4F6C9146108> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_multiprocessing.cpython-37m-darwin.so
       0x104533000 -        0x104534fff +_posixsubprocess.cpython-37m-darwin.so (0) <D75D7192-18DF-3465-BF8C-AB9CC8678AF1> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x104538000 -        0x10453bfff +_csv.cpython-37m-darwin.so (0) <0A1B0AC0-5DA1-3D33-8DEB-F4F57A1CD138> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_csv.cpython-37m-darwin.so
       0x104541000 -        0x104542fff +fcntl.cpython-37m-darwin.so (0) <5DF6EC0F-7822-349D-99EB-381F012CC7A8> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/fcntl.cpython-37m-darwin.so
       0x104589000 -        0x104598fff +_ctypes.cpython-37m-darwin.so (0) <513FA046-1F10-3D7A-890A-53352632CF58> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ctypes.cpython-37m-darwin.so
       0x1045e4000 -        0x104934ff7 +_multiarray_umath.cpython-37m-darwin.so (0) <108BF02E-C31A-3DC8-81A0-C68BB0B6AAA9> /usr/local/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-darwin.so
       0x104a44000 -        0x104b5bff7 +libgfortran.3.dylib (0) <9ABE5EDE-AD43-391A-9E54-866711FAC32A> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgfortran.3.dylib
       0x104bbf000 -        0x104bf5fff +libquadmath.0.dylib (0) <7FFA409F-FB04-3B64-BE9A-3E3A494C975E> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libquadmath.0.dylib
       0x104c04000 -        0x104c19ff7 +libgcc_s.1.dylib (0) <7C6D7CB7-82DB-3290-8181-07646FEA1F80> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgcc_s.1.dylib
       0x104c64000 -        0x104c6fffb +_datetime.cpython-37m-darwin.so (0) <6EC669D9-CA77-3C3C-808A-CF23B74EB19A> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_datetime.cpython-37m-darwin.so
       0x104ef7000 -        0x104f10ffb +_umath_linalg.cpython-37m-darwin.so (0) <68453A36-B5FB-3BEC-BED3-45F2F63685EF> /usr/local/lib/python3.7/site-packages/numpy/linalg/_umath_linalg.cpython-37m-darwin.so
       0x104fde000 -        0x10500bff7 +_decimal.cpython-37m-darwin.so (0) <CE6DE5FD-DD63-317D-954C-7BAE0491D638> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_decimal.cpython-37m-darwin.so
       0x10501e000 -        0x10502fffb +_pocketfft_internal.cpython-37m-darwin.so (0) <C71DAC57-DAD0-3695-A304-4CED45596071> /usr/local/lib/python3.7/site-packages/numpy/fft/_pocketfft_internal.cpython-37m-darwin.so
       0x1050b3000 -        0x10511cfff +mtrand.cpython-37m-darwin.so (0) <09C5C5F8-0A50-393F-AD80-7379EC6DBA34> /usr/local/lib/python3.7/site-packages/numpy/random/mtrand.cpython-37m-darwin.so
       0x10516e000 -        0x10519fff7 +common.cpython-37m-darwin.so (0) <9D9EE272-AFE0-3404-8978-1E220961466D> /usr/local/lib/python3.7/site-packages/numpy/random/common.cpython-37m-darwin.so
       0x1051b4000 -        0x105208ff3 +bounded_integers.cpython-37m-darwin.so (0) <B47B65C9-ACAC-37EB-92E1-B91B274CBBF6> /usr/local/lib/python3.7/site-packages/numpy/random/bounded_integers.cpython-37m-darwin.so
       0x10522b000 -        0x10523effb +mt19937.cpython-37m-darwin.so (0) <49BA865A-45FB-3DBE-BD12-5EF19491E69E> /usr/local/lib/python3.7/site-packages/numpy/random/mt19937.cpython-37m-darwin.so
       0x10524a000 -        0x105269ffb +bit_generator.cpython-37m-darwin.so (0) <903DDE08-E40B-3F72-91AE-21C64282A3B9> /usr/local/lib/python3.7/site-packages/numpy/random/bit_generator.cpython-37m-darwin.so
       0x105284000 -        0x105291ff3 +philox.cpython-37m-darwin.so (0) <80A41DA7-64D9-35BA-B53D-EE07FCDF0F8E> /usr/local/lib/python3.7/site-packages/numpy/random/philox.cpython-37m-darwin.so
       0x10529d000 -        0x1052a7ff3 +pcg64.cpython-37m-darwin.so (0) <29CD4019-0957-345E-BE1F-0B52B96A295A> /usr/local/lib/python3.7/site-packages/numpy/random/pcg64.cpython-37m-darwin.so
       0x1052b2000 -        0x1052baff7 +sfc64.cpython-37m-darwin.so (0) <4583192E-B765-3004-913A-1A720207BE4A> /usr/local/lib/python3.7/site-packages/numpy/random/sfc64.cpython-37m-darwin.so
       0x1052c4000 -        0x10533bfff +generator.cpython-37m-darwin.so (0) <A4641B0B-2712-37A7-887C-542B836CA06F> /usr/local/lib/python3.7/site-packages/numpy/random/generator.cpython-37m-darwin.so
       0x105542000 -        0x105555fff +_pywrap_utils.so (0) <FE74D6B5-E661-3D4E-BDEF-67D004ED6437> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_utils.so
       0x105561000 -        0x10567cfe3 +_pywrap_tfprof.so (0) <447451BE-EFF8-30B0-AD86-A052B1414F54> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_tfprof.so
       0x1056c1000 -        0x1057e2fe7 +_pywrap_events_writer.so (0) <5B4AC036-2A02-314F-9DE6-47A99356920F> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_events_writer.so
       0x105828000 -        0x105837ffb +_pywrap_util_port.so (0) <568A5CC0-1B6A-35D9-A23A-FFB607113FBA> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_util_port.so
       0x105840000 -        0x105960ffb +_pywrap_stat_summarizer.so (0) <DB3EAEA4-2F45-32BB-838A-134F7EA59BF9> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_stat_summarizer.so
       0x1059a6000 -        0x105ac1feb +_pywrap_py_exception_registry.so (0) <F225EBE5-BD92-3BA9-98E0-890E6373A203> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_py_exception_registry.so
       0x105b04000 -        0x105c1efe3 +_pywrap_kernel_registry.so (0) <09FC1B11-10DA-37A8-A954-C830E1C936B8> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_kernel_registry.so
       0x105c61000 -        0x105d7bfff +_pywrap_quantize_training.so (0) <E7D3B0DF-BE10-37D1-9863-D2467688F663> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_quantize_training.so
       0x105dbe000 -        0x105eddfef +_pywrap_scoped_annotation.so (0) <55B36C82-3A2A-38AB-83D5-3C991B8C487B> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_scoped_annotation.so
       0x105f22000 -        0x10603efeb +_pywrap_transform_graph.so (0) <24231F76-11C0-3FDA-B56C-205FF7C9A36E> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_transform_graph.so
       0x106082000 -        0x1061a1ff7 +_pywrap_traceme.so (0) <A853B074-F451-37CA-ACF6-053967802E18> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_traceme.so
       0x1061e6000 -        0x1061f5ff3 +_pywrap_stacktrace_handler.so (0) <65C1411A-D477-33D7-AE73-C57D7AE68D98> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_stacktrace_handler.so
       0x106257000 -        0x106276ffb +pyexpat.cpython-37m-darwin.so (0) <9C6C9A81-891E-3799-B4CE-C25FEC273C47> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/pyexpat.cpython-37m-darwin.so
       0x1063c2000 -        0x1063c6ff7 +_wrappers.cpython-37m-darwin.so (0) <E3D3C494-02D1-3B65-A13B-EDFF9A34340F> /usr/local/lib/python3.7/site-packages/wrapt/_wrappers.cpython-37m-darwin.so
       0x1063d0000 -        0x1063dfffb +fast_tensor_util.so (0) <09022302-B598-374B-BF11-4000B99C18F8> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/framework/fast_tensor_util.so
       0x1063e8000 -        0x1063e9fff +_queue.cpython-37m-darwin.so (0) <48C4453F-AF5E-30EF-B482-02C1CE001FE2> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so
       0x1063ed000 -        0x1063eefff +_scproxy.cpython-37m-darwin.so (0) <7306C2E0-79B7-30CE-A953-A7154E3381C2> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_scproxy.cpython-37m-darwin.so
       0x1063f3000 -        0x106483cb7  dyld (733.8) <EBC07CB6-870A-3A8E-B48A-67F62EA161F3> /usr/lib/dyld
       0x1064f7000 -        0x109f62ae7 +libopenblasp-r0.3.7.dylib (0) <55F3042E-C8D5-347B-9813-A4781D2D592E> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libopenblasp-r0.3.7.dylib
       0x10c1a2000 -        0x116306bb7 +_pywrap_tensorflow_internal.so (0) <8F1B25FA-F2F4-3395-A3FB-BE98FE5DFB96> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_tensorflow_internal.so
       0x121668000 -        0x12266330f +libtensorflow_framework.2.dylib (0) <9DF0409D-3C47-348E-9375-75510306EA03> /usr/local/lib/python3.7/site-packages/tensorflow_core/libtensorflow_framework.2.dylib
       0x1231e6000 -        0x12320bfff +_tf_stack.so (0) <91B3C019-C9FD-33CD-B2B7-914CBADF9761> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_tf_stack.so
       0x1232e6000 -        0x12343affb +_message.cpython-37m-darwin.so (0) <9230CB5F-E164-3A96-88A6-703C43F9DB16> /usr/local/lib/python3.7/site-packages/google/protobuf/pyext/_message.cpython-37m-darwin.so
       0x1239c6000 -        0x123addffb +_op_def_registry.so (0) <CF523395-4B20-38E5-8321-8F31A8E14F87> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_op_def_registry.so
       0x1241a3000 -        0x1241b2ffb +_pywrap_py_func.so (0) <08D47897-03C8-371E-BF98-DA9940FF6466> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_py_func.so
       0x1245bb000 -        0x1246e7feb +_pywrap_checkpoint_reader.so (0) <22D285E4-3AF7-3E67-8525-C7294A58AC4B> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_checkpoint_reader.so
       0x124af5000 -        0x124b02fff +_ssl.cpython-37m-darwin.so (0) <54D25B2F-B931-38F1-8A90-AD1707160B80> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ssl.cpython-37m-darwin.so
       0x124b51000 -        0x124c68ffb +_pywrap_device_lib.so (0) <6C6B158D-8939-3772-A969-081AC353FE86> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_device_lib.so
       0x1257d5000 -        0x1257dbff7 +_errors.cpython-37m-darwin.so (???) <2596D770-FC02-3F3F-B90F-2C07D5B25A51> /usr/local/lib/python3.7/site-packages/h5py/_errors.cpython-37m-darwin.so
       0x1257e3000 -        0x125cfdfff +libhdf5.103.dylib (0) <94DDACB1-B35B-328C-9B73-F81561121E7A> /usr/local/lib/python3.7/site-packages/h5py/.dylibs/libhdf5.103.dylib
       0x125d51000 -        0x125d71fff +libhdf5_hl.100.dylib (0) <BEA67564-0F2E-30EC-9FF3-601F270688D3> /usr/local/lib/python3.7/site-packages/h5py/.dylibs/libhdf5_hl.100.dylib
       0x125d7a000 -        0x125d80ff7 +libaec.0.dylib (0) <6D76AD2E-74FD-326D-ADE4-68C426692120> /usr/local/lib/python3.7/site-packages/h5py/.dylibs/libaec.0.dylib
       0x125d83000 -        0x125d93ff7 +h5.cpython-37m-darwin.so (???) <1899543B-F829-3953-B0EF-5EFB3AB07CC6> /usr/local/lib/python3.7/site-packages/h5py/h5.cpython-37m-darwin.so
       0x125da3000 -        0x125dc6fff +defs.cpython-37m-darwin.so (???) <1ABCC1CE-0ACB-353C-9B42-E29F9289D950> /usr/local/lib/python3.7/site-packages/h5py/defs.cpython-37m-darwin.so
       0x125de0000 -        0x125df4ff7 +_objects.cpython-37m-darwin.so (???) <94D93E85-334F-324A-B273-5840104D0858> /usr/local/lib/python3.7/site-packages/h5py/_objects.cpython-37m-darwin.so
       0x125e04000 -        0x125e0fff7 +_conv.cpython-37m-darwin.so (???) <E7F0EB5E-80FA-3138-98CD-573CB51FC990> /usr/local/lib/python3.7/site-packages/h5py/_conv.cpython-37m-darwin.so
       0x125e18000 -        0x125e20ff7 +h5r.cpython-37m-darwin.so (???) <5D1A0B67-D8B7-3258-A643-89B312A80BDB> /usr/local/lib/python3.7/site-packages/h5py/h5r.cpython-37m-darwin.so
       0x125e2a000 -        0x125e83ff7 +h5t.cpython-37m-darwin.so (???) <D1D448A2-E9EF-382A-94C1-AB1F2317B8E0> /usr/local/lib/python3.7/site-packages/h5py/h5t.cpython-37m-darwin.so
       0x125efe000 -        0x125f04ff7 +utils.cpython-37m-darwin.so (???) <8806E7F1-CCA5-35BD-9FCF-D5699C3B1096> /usr/local/lib/python3.7/site-packages/h5py/utils.cpython-37m-darwin.so
       0x125f0b000 -        0x125f10ff7 +h5z.cpython-37m-darwin.so (???) <348731BB-B65A-3935-AD2C-0CC959486E0A> /usr/local/lib/python3.7/site-packages/h5py/h5z.cpython-37m-darwin.so
       0x125f19000 -        0x125f2eff7 +h5a.cpython-37m-darwin.so (???) <FAB201C3-5E9C-3602-9886-E6027F190953> /usr/local/lib/python3.7/site-packages/h5py/h5a.cpython-37m-darwin.so
       0x125f40000 -        0x125f52ff7 +h5s.cpython-37m-darwin.so (???) <13CC1101-5280-3270-9D7D-737E4A427441> /usr/local/lib/python3.7/site-packages/h5py/h5s.cpython-37m-darwin.so
       0x125f63000 -        0x125f9dff7 +h5p.cpython-37m-darwin.so (???) <3DA29D7B-1FE7-348C-8057-3335A5EEDB0A> /usr/local/lib/python3.7/site-packages/h5py/h5p.cpython-37m-darwin.so
       0x125fcc000 -        0x125fd2fff +h5ac.cpython-37m-darwin.so (???) <CF89CD6E-4C58-3F1B-8356-72D78BAF2E6D> /usr/local/lib/python3.7/site-packages/h5py/h5ac.cpython-37m-darwin.so
       0x12601a000 -        0x126020ff7 +_proxy.cpython-37m-darwin.so (???) <84148591-8EB7-32D1-85B3-7891C6CD388E> /usr/local/lib/python3.7/site-packages/h5py/_proxy.cpython-37m-darwin.so
       0x126026000 -        0x12603aff7 +h5d.cpython-37m-darwin.so (???) <A8B17616-5D70-3F0D-9D6C-7E59AB535FD5> /usr/local/lib/python3.7/site-packages/h5py/h5d.cpython-37m-darwin.so
       0x12604b000 -        0x126056fff +h5ds.cpython-37m-darwin.so (???) <7646F087-8B75-3CE8-B3DC-1D94A564003C> /usr/local/lib/python3.7/site-packages/h5py/h5ds.cpython-37m-darwin.so
       0x126061000 -        0x126074fff +h5f.cpython-37m-darwin.so (???) <9E6E11FA-93B5-369D-95F0-3CDC868F5D9F> /usr/local/lib/python3.7/site-packages/h5py/h5f.cpython-37m-darwin.so
       0x126088000 -        0x1260a3ff7 +h5g.cpython-37m-darwin.so (???) <7117C9D7-78CE-3130-9314-CA158BB02D57> /usr/local/lib/python3.7/site-packages/h5py/h5g.cpython-37m-darwin.so
       0x1260b8000 -        0x1260bfff7 +h5i.cpython-37m-darwin.so (???) <284CB67E-DA1F-39C8-A923-DCD66999A102> /usr/local/lib/python3.7/site-packages/h5py/h5i.cpython-37m-darwin.so
       0x1260c8000 -        0x1260e5fff +h5fd.cpython-37m-darwin.so (???) <451EFC4A-353B-377A-B337-DA626B05D4EE> /usr/local/lib/python3.7/site-packages/h5py/h5fd.cpython-37m-darwin.so
       0x1260f9000 -        0x1260fdff7 +h5pl.cpython-37m-darwin.so (???) <719A4DF2-D47A-3DE3-994D-09334620E91B> /usr/local/lib/python3.7/site-packages/h5py/h5pl.cpython-37m-darwin.so
       0x126143000 -        0x126153fff +h5o.cpython-37m-darwin.so (???) <E03B41DA-FE8B-381A-9071-CD4823D77AAD> /usr/local/lib/python3.7/site-packages/h5py/h5o.cpython-37m-darwin.so
       0x126164000 -        0x126174ff7 +h5l.cpython-37m-darwin.so (???) <AF5E79B7-5037-3946-8AAB-772E73C2979D> /usr/local/lib/python3.7/site-packages/h5py/h5l.cpython-37m-darwin.so
       0x126483000 -        0x126581fff +unicodedata.cpython-37m-darwin.so (0) <2266541F-A89E-3965-8237-BF8FCEF2948B> /usr/local/Cellar/python/3.7.6_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/unicodedata.cpython-37m-darwin.so
       0x126872000 -        0x12687eff7 +_ccallback_c.cpython-37m-darwin.so (0) <3FD6FCC1-1434-39D1-B04A-8767E76A202B> /usr/local/lib/python3.7/site-packages/scipy/_lib/_ccallback_c.cpython-37m-darwin.so
       0x1268ca000 -        0x1268d0ff7 +_uarray.cpython-37m-darwin.so (0) <E62A1703-D278-3B6D-8EC9-8D241CDF7B21> /usr/local/lib/python3.7/site-packages/scipy/_lib/_uarray/_uarray.cpython-37m-darwin.so
       0x1268d8000 -        0x126981fff +pypocketfft.cpython-37m-darwin.so (0) <F6A45020-A336-3159-9A14-53D247EBD365> /usr/local/lib/python3.7/site-packages/scipy/fft/_pocketfft/pypocketfft.cpython-37m-darwin.so
       0x126a42000 -        0x126e43ff7 +_sparsetools.cpython-37m-darwin.so (0) <092E52E1-967E-34CB-B0A7-09174E588939> /usr/local/lib/python3.7/site-packages/scipy/sparse/_sparsetools.cpython-37m-darwin.so
       0x126f61000 -        0x126fc4fff +_csparsetools.cpython-37m-darwin.so (0) <72D1E029-97E0-3B53-9C79-C1011391B6EE> /usr/local/lib/python3.7/site-packages/scipy/sparse/_csparsetools.cpython-37m-darwin.so
       0x127030000 -        0x127080ff3 +_shortest_path.cpython-37m-darwin.so (0) <5CC5125A-F433-3E6F-82F5-B1638F75B528> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_shortest_path.cpython-37m-darwin.so
       0x1270a9000 -        0x1270c3ffb +_tools.cpython-37m-darwin.so (0) <F077D312-C938-3CE1-9E9B-B4B5460455A8> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_tools.cpython-37m-darwin.so
       0x1270d8000 -        0x1270f1ff7 +_traversal.cpython-37m-darwin.so (0) <E162A906-56F2-3C3C-B09E-52BC5DA901B8> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_traversal.cpython-37m-darwin.so
       0x127101000 -        0x12711efff +_min_spanning_tree.cpython-37m-darwin.so (0) <A6304FE2-E44F-3662-949F-7CD5249F2D5D> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_min_spanning_tree.cpython-37m-darwin.so
       0x127133000 -        0x12715afff +_flow.cpython-37m-darwin.so (0) <C6E0E00B-E3E0-33A0-AC65-4869752BFFB1> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_flow.cpython-37m-darwin.so
       0x127176000 -        0x127194ff3 +_matching.cpython-37m-darwin.so (0) <3EEDFFCC-531B-3B06-A768-90DBE1B26CD9> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_matching.cpython-37m-darwin.so
       0x1271aa000 -        0x1271d3ffb +_reordering.cpython-37m-darwin.so (0) <9C3FCBB7-F07D-3CA2-84CB-EC95F26A1988> /usr/local/lib/python3.7/site-packages/scipy/sparse/csgraph/_reordering.cpython-37m-darwin.so
       0x127270000 -        0x1272a2fff +conversion.cpython-37m-darwin.so (0) <D3353200-98ED-302E-B68A-1BE6955E4937> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/conversion.cpython-37m-darwin.so
       0x1272c0000 -        0x1272e8fff +c_timestamp.cpython-37m-darwin.so (0) <0FE36C32-88AC-3F69-A968-6BB795BD1B37> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/c_timestamp.cpython-37m-darwin.so
       0x127305000 -        0x127327fff +nattype.cpython-37m-darwin.so (0) <00F14F50-2D86-3120-8AE1-46E363CCB553> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/nattype.cpython-37m-darwin.so
       0x127348000 -        0x127350fff +np_datetime.cpython-37m-darwin.so (0) <63DCCD9D-84ED-3C02-882C-CC7526F45CC8> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/np_datetime.cpython-37m-darwin.so
       0x127358000 -        0x12737dffb +timezones.cpython-37m-darwin.so (0) <D05B7E77-59A5-33DF-A0B8-F8DA8C802461> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timezones.cpython-37m-darwin.so
       0x1273d8000 -        0x127410fff +tzconversion.cpython-37m-darwin.so (0) <DE0FFF90-A987-3392-BBBA-457603ED19BA> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/tzconversion.cpython-37m-darwin.so
       0x12742f000 -        0x12747effb +timedeltas.cpython-37m-darwin.so (0) <3681D208-3DF9-3AB2-BBDB-64EAB4E161D8> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timedeltas.cpython-37m-darwin.so
       0x1274b3000 -        0x1274f6ffb +offsets.cpython-37m-darwin.so (0) <8AFBE212-AEEF-37AB-80C6-50F2B846EEBA> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/offsets.cpython-37m-darwin.so
       0x127527000 -        0x127530fff +ccalendar.cpython-37m-darwin.so (0) <3628C18E-C30E-3755-BFB6-8506967C69DD> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/ccalendar.cpython-37m-darwin.so
       0x12757c000 -        0x1275c1ff7 +strptime.cpython-37m-darwin.so (0) <887DBBF4-07CE-3858-9F16-BA3AED65E017> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/strptime.cpython-37m-darwin.so
       0x1275ef000 -        0x127618ffb +fields.cpython-37m-darwin.so (0) <1B2B1460-A1D2-3962-B178-745217C0CBE8> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/fields.cpython-37m-darwin.so
       0x127634000 -        0x12767dff7 +parsing.cpython-37m-darwin.so (0) <09F5DF42-13BF-3D98-9E4D-4AE7A3B9806B> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/parsing.cpython-37m-darwin.so
       0x1276ac000 -        0x1276bfffb +frequencies.cpython-37m-darwin.so (0) <F81E67A9-ADD6-318D-B48B-246E013B8E71> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/frequencies.cpython-37m-darwin.so
       0x127712000 -        0x12775ffff +period.cpython-37m-darwin.so (0) <2BEB5289-048D-3578-845E-7E454FC1C073> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/period.cpython-37m-darwin.so
       0x12778f000 -        0x1277c1ff7 +timestamps.cpython-37m-darwin.so (0) <D3A869AC-1026-30AB-912B-1B57D79C6C1E> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timestamps.cpython-37m-darwin.so
       0x1277ed000 -        0x127814ff7 +resolution.cpython-37m-darwin.so (0) <7F930156-8B53-3FDF-BEEA-502C82A9B098> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/resolution.cpython-37m-darwin.so
       0x127833000 -        0x1278a4fff +hashtable.cpython-37m-darwin.so (0) <D02816D9-72EC-33D1-8CBC-51BC4879140C> /usr/local/lib/python3.7/site-packages/pandas/_libs/hashtable.cpython-37m-darwin.so
       0x127924000 -        0x127945ff7 +missing.cpython-37m-darwin.so (0) <BF7CB471-BFEF-3C73-900F-62B731EEB5AA> /usr/local/lib/python3.7/site-packages/pandas/_libs/missing.cpython-37m-darwin.so
       0x127963000 -        0x127969ffb +ops_dispatch.cpython-37m-darwin.so (0) <EBD883A3-7B75-3D1B-9983-C499181498CD> /usr/local/lib/python3.7/site-packages/pandas/_libs/ops_dispatch.cpython-37m-darwin.so
       0x127973000 -        0x1279d7ff3 +lib.cpython-37m-darwin.so (0) <098A9456-3D70-30CF-AE36-14BE91682E11> /usr/local/lib/python3.7/site-packages/pandas/_libs/lib.cpython-37m-darwin.so
       0x127a1a000 -        0x127a51ff7 +tslib.cpython-37m-darwin.so (0) <C1B0D6AF-7AE8-3B84-955B-3EC4B1E87D47> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslib.cpython-37m-darwin.so
       0x127ab0000 -        0x127ba9ff7 +interval.cpython-37m-darwin.so (0) <EF8400A3-1AE0-3974-8298-B93CCE293911> /usr/local/lib/python3.7/site-packages/pandas/_libs/interval.cpython-37m-darwin.so
       0x127c0c000 -        0x127d6fff7 +algos.cpython-37m-darwin.so (0) <CDB802CA-DA94-3F59-9C27-43ECFD8E99BD> /usr/local/lib/python3.7/site-packages/pandas/_libs/algos.cpython-37m-darwin.so
       0x127e5a000 -        0x127e62ffb +properties.cpython-37m-darwin.so (0) <E9103AE5-4AC1-3F62-BED5-2B46817DCBD7> /usr/local/lib/python3.7/site-packages/pandas/_libs/properties.cpython-37m-darwin.so
       0x127e6c000 -        0x127e87ffb +hashing.cpython-37m-darwin.so (0) <D09BCB0A-01FB-362A-99EA-A4EE321F02BE> /usr/local/lib/python3.7/site-packages/pandas/_libs/hashing.cpython-37m-darwin.so
       0x127edb000 -        0x127f00fff +ops.cpython-37m-darwin.so (0) <04B64B85-8A74-3A56-9255-7879723E7ACB> /usr/local/lib/python3.7/site-packages/pandas/_libs/ops.cpython-37m-darwin.so
       0x1280ba000 -        0x128135ff3 +index.cpython-37m-darwin.so (0) <370498AA-AD60-3E2F-8D88-A63FBA9AB7DE> /usr/local/lib/python3.7/site-packages/pandas/_libs/index.cpython-37m-darwin.so
       0x128175000 -        0x1283c0ff3 +join.cpython-37m-darwin.so (0) <513C36CE-F365-3E59-AC09-B3CE5B8CB824> /usr/local/lib/python3.7/site-packages/pandas/_libs/join.cpython-37m-darwin.so
       0x128505000 -        0x1285ceffb +sparse.cpython-37m-darwin.so (0) <B464BD28-6AAA-3BDF-A79C-31E2798B3095> /usr/local/lib/python3.7/site-packages/pandas/_libs/sparse.cpython-37m-darwin.so
       0x1287c6000 -        0x1287cbff3 +indexing.cpython-37m-darwin.so (0) <A4F6E873-ACB0-303E-87EB-B325BF6EAE9D> /usr/local/lib/python3.7/site-packages/pandas/_libs/indexing.cpython-37m-darwin.so
       0x128812000 -        0x128831ff3 +writers.cpython-37m-darwin.so (0) <F1E39AB3-BD9B-3B01-A20A-D215C323F03D> /usr/local/lib/python3.7/site-packages/pandas/_libs/writers.cpython-37m-darwin.so
       0x128849000 -        0x128874fff +internals.cpython-37m-darwin.so (0) <52DD5EC3-1606-3EEB-BB11-3EC774D95FA3> /usr/local/lib/python3.7/site-packages/pandas/_libs/internals.cpython-37m-darwin.so
       0x128910000 -        0x12893cffb +reshape.cpython-37m-darwin.so (0) <99B48618-A424-3F64-9AAC-2A342C6BA2D3> /usr/local/lib/python3.7/site-packages/pandas/_libs/reshape.cpython-37m-darwin.so
       0x128995000 -        0x1289dffff +aggregations.cpython-37m-darwin.so (0) <6CA59D05-9F82-3132-8BC7-53FF4DB281D8> /usr/local/lib/python3.7/site-packages/pandas/_libs/window/aggregations.cpython-37m-darwin.so
       0x128a4b000 -        0x128a64fff +indexers.cpython-37m-darwin.so (0) <75105072-A853-3CEC-8D18-492459C3596C> /usr/local/lib/python3.7/site-packages/pandas/_libs/window/indexers.cpython-37m-darwin.so
       0x128ab7000 -        0x128bbeffb +groupby.cpython-37m-darwin.so (0) <39134568-A0E9-3433-88D9-4AB4F4377183> /usr/local/lib/python3.7/site-packages/pandas/_libs/groupby.cpython-37m-darwin.so
       0x128c07000 -        0x128c44ff7 +reduction.cpython-37m-darwin.so (0) <2730D448-6402-322F-8BE3-B0E1D2A25444> /usr/local/lib/python3.7/site-packages/pandas/_libs/reduction.cpython-37m-darwin.so
       0x128d27000 -        0x128d8efff +parsers.cpython-37m-darwin.so (0) <89F7E8F5-1F7E-3341-A226-202F393EF294> /usr/local/lib/python3.7/site-packages/pandas/_libs/parsers.cpython-37m-darwin.so
       0x128e49000 -        0x128e57ff7 +json.cpython-37m-darwin.so (0) <1EA12F67-0068-381E-A687-282B781C7331> /usr/local/lib/python3.7/site-packages/pandas/_libs/json.cpython-37m-darwin.so
       0x128f61000 -        0x128f70ff7 +testing.cpython-37m-darwin.so (0) <893284BC-97A3-3688-B55C-1A145A13E0A4> /usr/local/lib/python3.7/site-packages/pandas/_libs/testing.cpython-37m-darwin.so
       0x129566000 -        0x129683ffb +_pywrap_debug_events_writer.so (0) <95004ACA-3685-353F-999D-D9FC69E68890> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_debug_events_writer.so
       0x129748000 -        0x129768ff3 +_audio_microfrontend_op.so (0) <26A031CF-55B3-30EE-A223-6E1AD5C3F883> /usr/local/lib/python3.7/site-packages/tensorflow_core/lite/experimental/microfrontend/python/ops/_audio_microfrontend_op.so
       0x12977d000 -        0x12978dff7 +_pywrap_toco_api.so (0) <C472C5C7-3DA4-3EBE-977B-19645264F3FF> /usr/local/lib/python3.7/site-packages/tensorflow_core/python/_pywrap_toco_api.so
       0x1297e7000 -        0x1297f2ff7 +_flinalg.cpython-37m-darwin.so (0) <C30E9056-FE34-30E8-86FA-F8274213F40C> /usr/local/lib/python3.7/site-packages/scipy/linalg/_flinalg.cpython-37m-darwin.so
       0x129cfd000 -        0x129d57ff7 +_imaging.cpython-37m-darwin.so (0) <F0A198BC-043C-34A8-8E2E-ECC6D99B8BFC> /usr/local/lib/python3.7/site-packages/PIL/_imaging.cpython-37m-darwin.so
       0x129d7f000 -        0x129db6fff +libjpeg.9.dylib (0) <7A998DE1-01AD-3016-9CA1-F50ADFD20A1D> /usr/local/lib/python3.7/site-packages/PIL/.dylibs/libjpeg.9.dylib
       0x129dc6000 -        0x129e3cffb +libopenjp2.2.3.1.dylib (0) <070B3635-9516-3171-8E04-6F645281C96B> /usr/local/lib/python3.7/site-packages/PIL/.dylibs/libopenjp2.2.3.1.dylib
       0x129e47000 -        0x129e62ff7 +libz.1.2.11.dylib (0) <8F57D771-E0DD-3DA4-8241-A90A4B0AE451> /usr/local/lib/python3.7/site-packages/PIL/.dylibs/libz.1.2.11.dylib
       0x129e66000 -        0x129ef5fff +libtiff.5.dylib (0) <A68BDB7A-6AEF-3393-9025-F975315CDDC6> /usr/local/lib/python3.7/site-packages/PIL/.dylibs/libtiff.5.dylib
       0x129f07000 -        0x129f37fff +liblzma.5.dylib (0) <4E0649AF-77F8-3889-B300-B37ED7E6F40F> /usr/local/lib/python3.7/site-packages/PIL/.dylibs/liblzma.5.dylib
       0x129f3f000 -        0x129f60fff +_nd_image.cpython-37m-darwin.so (0) <79744D11-8BB5-394C-8FBD-15399F04CCF5> /usr/local/lib/python3.7/site-packages/scipy/ndimage/_nd_image.cpython-37m-darwin.so
       0x129fa7000 -        0x129fe1fff +_ni_label.cpython-37m-darwin.so (0) <C2E7187C-B8A8-3A0B-8F3A-9FEA8DA14043> /usr/local/lib/python3.7/site-packages/scipy/ndimage/_ni_label.cpython-37m-darwin.so
       0x129ffd000 -        0x12a056ff7 +_fblas.cpython-37m-darwin.so (0) <AEA5B6B6-E215-308E-ADF8-E5D46352B583> /usr/local/lib/python3.7/site-packages/scipy/linalg/_fblas.cpython-37m-darwin.so
       0x12a08e000 -        0x12daf9ae7 +libopenblasp-r0.3.7.dylib (0) <9914A383-F8C9-3559-BC88-B4DD28689BC5> /usr/local/lib/python3.7/site-packages/scipy/.dylibs/libopenblasp-r0.3.7.dylib
       0x12dd39000 -        0x12de50ff7 +libgfortran.3.dylib (0) <9ABE5EDE-AD43-391A-9E54-866711FAC32A> /usr/local/lib/python3.7/site-packages/scipy/.dylibs/libgfortran.3.dylib
       0x12deb4000 -        0x12dec9ff7 +libgcc_s.1.dylib (0) <7C6D7CB7-82DB-3290-8181-07646FEA1F80> /usr/local/lib/python3.7/site-packages/scipy/.dylibs/libgcc_s.1.dylib
       0x12ded4000 -        0x12df0afff +libquadmath.0.dylib (0) <7FFA409F-FB04-3B64-BE9A-3E3A494C975E> /usr/local/lib/python3.7/site-packages/scipy/.dylibs/libquadmath.0.dylib
       0x12ff19000 -        0x12fff9fff +_flapack.cpython-37m-darwin.so (0) <EB1AF558-9C33-3C58-B4C8-660E15954550> /usr/local/lib/python3.7/site-packages/scipy/linalg/_flapack.cpython-37m-darwin.so
       0x1300d4000 -        0x1300f8fff +_solve_toeplitz.cpython-37m-darwin.so (0) <C01B8789-C5E4-308C-A74B-9C289BB282DD> /usr/local/lib/python3.7/site-packages/scipy/linalg/_solve_toeplitz.cpython-37m-darwin.so
       0x130151000 -        0x130185ff3 +_decomp_update.cpython-37m-darwin.so (0) <A0C567D7-AEE8-356C-957C-7B1EF346C1CC> /usr/local/lib/python3.7/site-packages/scipy/linalg/_decomp_update.cpython-37m-darwin.so
       0x13019b000 -        0x1301c0fff +cython_blas.cpython-37m-darwin.so (0) <871E4896-B5CE-3600-B570-D216676C38BD> /usr/local/lib/python3.7/site-packages/scipy/linalg/cython_blas.cpython-37m-darwin.so
       0x1301dd000 -        0x130249ff7 +cython_lapack.cpython-37m-darwin.so (0) <F0BA7F5C-0A86-39C2-8150-ADBAF50B5A5B> /usr/local/lib/python3.7/site-packages/scipy/linalg/cython_lapack.cpython-37m-darwin.so
       0x1304d1000 -        0x130618feb +_xla_ops.so (0) <62E4E59A-CF6C-3630-9B8E-E964B1280AAD> /usr/local/lib/python3.7/site-packages/tensorflow_core/compiler/tf2xla/ops/_xla_ops.so
    0x7fff29ba8000 -     0x7fff29ba8fff  com.apple.Accelerate (1.11 - Accelerate 1.11) <EEBE6680-1AAB-3192-AA7C-450537B07F27> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff29bc0000 -     0x7fff2a22bfef  com.apple.vImage (8.1 - 524.2) <33B60C65-1E08-3490-ADC7-6C75AA3EA022> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff2a22c000 -     0x7fff2a495fff  libBLAS.dylib (1303.60.1) <0FE82DB0-0E71-300A-BF0B-70BF3478FE79> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff2a496000 -     0x7fff2a785ff7  libBNNS.dylib (144.40.3) <86C8FBB0-19D3-355B-99A3-6B094BB98C06> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fff2a787000 -     0x7fff2ab2cfff  libLAPACK.dylib (1303.60.1) <DCC36295-FF39-35A1-8DF1-1E8A714E2265> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff2ab2d000 -     0x7fff2ab42ff8  libLinearAlgebra.dylib (1303.60.1) <0E47C269-832E-3B55-A6B6-855648BD206E> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff2ab43000 -     0x7fff2ab48ff3  libQuadrature.dylib (7) <E0534024-B7E7-3382-830C-71E7BD9D3DE4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fff2ab49000 -     0x7fff2abb9fff  libSparse.dylib (103) <533DFAE8-8458-31F4-8AE2-B73C3869CED2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
    0x7fff2abba000 -     0x7fff2abccfef  libSparseBLAS.dylib (1303.60.1) <7CECC6DF-B4A8-38A7-B4E9-0CDDC6EA2510> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fff2abcd000 -     0x7fff2ada6ffb  libvDSP.dylib (735.40.1) <BD49856D-39CE-397F-A069-63B2F0D79529> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff2ada7000 -     0x7fff2ae62fd7  libvMisc.dylib (735.40.1) <F3C565E5-8571-3E16-BC22-7687D1A756BD> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff2ae63000 -     0x7fff2ae63fff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <A8B35A80-7217-38B1-8A20-E8B4F73124F0> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff2c59e000 -     0x7fff2c92aff6  com.apple.CFNetwork (1121.1.2 - 1121.1.2) <4E539AC8-A995-3BA8-AAD6-31D97DAE734B> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff2de01000 -     0x7fff2e281fe7  com.apple.CoreFoundation (6.9 - 1674.114) <5810CC45-FB5D-3A78-861F-7BE03F9B2FDD> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff2f1f1000 -     0x7fff2f1f1fff  com.apple.CoreServices (1069.11 - 1069.11) <3BBDA17B-6F86-35F4-B785-AFA2A14B6F51> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff2f1f2000 -     0x7fff2f277fff  com.apple.AE (838 - 838) <877C7270-575A-3D5F-B768-4724037F025D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff2f278000 -     0x7fff2f559ff7  com.apple.CoreServices.CarbonCore (1217 - 1217) <DDC45E79-973C-3FB0-92EC-392A654179F5> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff2f55a000 -     0x7fff2f5a7ff5  com.apple.DictionaryServices (1.2 - 323.3.1) <A21D442C-E7B7-3A6C-BEEC-44B323AF9CB2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff2f5a8000 -     0x7fff2f5b0fff  com.apple.CoreServices.FSEvents (1268.60.1 - 1268.60.1) <8C772593-A2BA-33A7-BB43-49B9FCDD37CE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fff2f5b1000 -     0x7fff2f7eaff0  com.apple.LaunchServices (1069.11 - 1069.11) <7189EED9-9252-3030-AB32-6704AD9AEBAE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff2f7eb000 -     0x7fff2f883ff9  com.apple.Metadata (10.7.0 - 2075.7) <AECD1E1F-1C1B-3C42-9ACD-596980F145C2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff2f884000 -     0x7fff2f8b1ff7  com.apple.CoreServices.OSServices (1069.11 - 1069.11) <67A2F664-DCA1-3FD6-B88E-CF020EA8C59D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff2f8b2000 -     0x7fff2f919fff  com.apple.SearchKit (1.4.1 - 1.4.1) <367BBFA7-F18C-34B6-B4C8-A244A125D5E0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff2f91a000 -     0x7fff2f93eff5  com.apple.coreservices.SharedFileList (131.4 - 131.4) <EB8F2B1B-B736-373F-B28B-E4E6F33A00C0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fff3018e000 -     0x7fff30194fff  com.apple.DiskArbitration (2.7 - 2.7) <5BE0B036-DEAB-3191-8D44-B489F4D39EE1> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff304c6000 -     0x7fff3088effc  com.apple.Foundation (6.9 - 1674.114) <532BBAE7-F2BA-3779-94E0-BFEDF2D7AB38> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff30c06000 -     0x7fff30ca9ffb  com.apple.framework.IOKit (2.0.2 - 1726.80.1) <B63FE840-8E32-3429-A95D-AB466FE62104> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff34513000 -     0x7fff3451fffe  com.apple.NetFS (6.0 - 4.0) <0B2088AE-C16D-3FC3-9445-4EDAD2D51686> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff370e5000 -     0x7fff37101fff  com.apple.CFOpenDirectory (10.15 - 220.40.1) <FF068FF7-C136-3A71-AD1F-B5170A918423> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff37102000 -     0x7fff3710dff7  com.apple.OpenDirectory (10.15 - 220.40.1) <9448EC8E-8B76-3142-9540-C0752529762A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff3a458000 -     0x7fff3a7aaffa  com.apple.security (7.0 - 59306.80.4) <FA5EBA16-2B2B-3105-8A17-C8624C4B3BB3> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff3a7ab000 -     0x7fff3a834ff7  com.apple.securityfoundation (6.0 - 55236.60.1) <0129932D-89E5-3608-B22E-DB5F0B3C3DC4> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff3a863000 -     0x7fff3a867ff0  com.apple.xpc.ServiceManagement (1.0 - 1) <2475707B-F909-33C4-AAB7-80DC8D2CB435> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff3b5fa000 -     0x7fff3b664fff  com.apple.SystemConfiguration (1.19 - 1.19) <61B73150-6D87-3E2F-A935-B957425CC992> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff3f3cf000 -     0x7fff3f493fe7  com.apple.APFS (1412.81.1 - 1412.81.1) <7EC14196-E481-35C0-94F0-09E5B81AD3E5> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
    0x7fff4110e000 -     0x7fff4111dfef  com.apple.AppleFSCompression (119 - 1.0) <EEDA4040-1835-39A6-AC13-6CE35560C159> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff428c5000 -     0x7fff428ceff3  com.apple.coreservices.BackgroundTaskManagement (1.0 - 104) <D0F2851A-521F-335A-B7C4-B1E39BB42DD7> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
    0x7fff45695000 -     0x7fff456a5ff3  com.apple.CoreEmoji (1.0 - 107) <544182E2-893F-3975-AA70-26ADC637B3F1> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fff45cf9000 -     0x7fff45d63ff0  com.apple.CoreNLP (1.0 - 213) <287973D6-1807-3A81-8F57-7BB39209F6C0> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
    0x7fff46982000 -     0x7fff469b0ff7  com.apple.CSStore (1069.11 - 1069.11) <26602CC8-0080-3E85-A588-79CEF78D21E5> /System/Library/PrivateFrameworks/CoreServicesStore.framework/Versions/A/CoreServicesStore
    0x7fff52aca000 -     0x7fff52b98ff5  com.apple.LanguageModeling (1.0 - 215.1) <B47A62F3-7F45-3A84-A856-C674D4613261> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff52b99000 -     0x7fff52be1ff7  com.apple.Lexicon-framework (1.0 - 72) <CD6D3F05-0647-348D-AED0-9566F968A954> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
    0x7fff52be8000 -     0x7fff52becff2  com.apple.LinguisticData (1.0 - 353.6.1) <91C3132C-EB52-32D6-9009-DE4B207ACE72> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
    0x7fff53f47000 -     0x7fff53f93fff  com.apple.spotlight.metadata.utilities (1.0 - 2075.7) <F7FA0F68-7E46-3461-9DA6-C55FBB85C799> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
    0x7fff54a47000 -     0x7fff54a51fff  com.apple.NetAuth (6.2 - 6.2) <A400CD55-B3EA-371A-8BAB-FDDA87660AE4> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff5d7d9000 -     0x7fff5d7e9ff3  com.apple.TCC (1.0 - 1) <A8308EDB-9AF7-3B6B-AAC3-143F91F58F1D> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff61a5a000 -     0x7fff61a5cff3  com.apple.loginsupport (1.0 - 1) <F2EC9213-901A-3657-A36A-DFD80BD8ABBC> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff61dbd000 -     0x7fff61df2ff7  libCRFSuite.dylib (48) <31D98527-9972-3A4B-9868-C9394FAF742E> /usr/lib/libCRFSuite.dylib
    0x7fff61df5000 -     0x7fff61dffff3  libChineseTokenizer.dylib (34) <9E2B02B0-32A5-3245-AC50-F6BEEC34FCEC> /usr/lib/libChineseTokenizer.dylib
    0x7fff61e8c000 -     0x7fff61e8eff7  libDiagnosticMessagesClient.dylib (112) <45E85899-039F-3B99-8789-F497DD9916C2> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff62354000 -     0x7fff62355ff3  libSystem.B.dylib (1281) <A2C26908-8802-3CA7-8B74-ED4A74AA152C> /usr/lib/libSystem.B.dylib
    0x7fff623e4000 -     0x7fff623e5fff  libThaiTokenizer.dylib (3) <9E5B4E50-E982-387C-AA2F-BB43867322ED> /usr/lib/libThaiTokenizer.dylib
    0x7fff623fd000 -     0x7fff62413fff  libapple_nghttp2.dylib (1.39.2) <C79E1B79-0BBE-311F-A177-6879D5C4D991> /usr/lib/libapple_nghttp2.dylib
    0x7fff62448000 -     0x7fff624baff7  libarchive.2.dylib (72.40.2) <1AE0592D-8451-30D1-AEE8-3F39F46D9DD4> /usr/lib/libarchive.2.dylib
    0x7fff62555000 -     0x7fff62555ff3  libauto.dylib (187) <71A48A59-FE0E-3D86-A219-B79DAF7CF9DD> /usr/lib/libauto.dylib
    0x7fff6261c000 -     0x7fff6262cff3  libbsm.0.dylib (60) <5EBEA671-D25B-3425-AC2B-70C2760B8B94> /usr/lib/libbsm.0.dylib
    0x7fff6262d000 -     0x7fff62639fff  libbz2.1.0.dylib (44) <FA7CE29A-2FE3-3107-8693-5D33D5B7E11F> /usr/lib/libbz2.1.0.dylib
    0x7fff6263a000 -     0x7fff6268dff7  libc++.1.dylib (800.7) <1D0CB627-8A78-329F-A679-1B5248FF4C59> /usr/lib/libc++.1.dylib
    0x7fff6268e000 -     0x7fff626a2fff  libc++abi.dylib (800.7) <7AF668FB-901D-3F45-BA0D-710A235A8D1F> /usr/lib/libc++abi.dylib
    0x7fff626a3000 -     0x7fff626a3ffb  libcharset.1.dylib (59) <56F66234-104F-3494-B336-598800CF3F71> /usr/lib/libcharset.1.dylib
    0x7fff626a4000 -     0x7fff626b5ffb  libcmph.dylib (8) <9B9AB2BA-75FB-3B70-AAE4-E32B06CF9D69> /usr/lib/libcmph.dylib
    0x7fff626b6000 -     0x7fff626cdfe7  libcompression.dylib (87) <A252D9B2-0D88-3345-94DC-E5D7C8245985> /usr/lib/libcompression.dylib
    0x7fff6299d000 -     0x7fff629b3ff7  libcoretls.dylib (167) <6D32CE15-591C-39AD-9A3E-0C2FFC03C3C1> /usr/lib/libcoretls.dylib
    0x7fff629b4000 -     0x7fff629b5fff  libcoretls_cfhelpers.dylib (167) <3CE60FA9-98FC-3EE0-B398-177F3CAA850D> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fff630de000 -     0x7fff630defff  libenergytrace.dylib (21) <8E5C9BB2-14F4-37DF-AAE7-8130EBF466A3> /usr/lib/libenergytrace.dylib
    0x7fff63106000 -     0x7fff63108fff  libfakelink.dylib (149) <7296A5B3-EE44-34E6-810A-2A12C2D3EF68> /usr/lib/libfakelink.dylib
    0x7fff63117000 -     0x7fff6311cfff  libgermantok.dylib (24) <7B3FFFFB-5E34-3940-8E0A-B64A2DE42E68> /usr/lib/libgermantok.dylib
    0x7fff63127000 -     0x7fff63217ff7  libiconv.2.dylib (59) <30414773-5E42-3976-B7C3-9BB8883792EE> /usr/lib/libiconv.2.dylib
    0x7fff63218000 -     0x7fff63470ff7  libicucore.A.dylib (64252.0.1) <0F9294A7-6EC0-3279-BF92-3233C89DFA0A> /usr/lib/libicucore.A.dylib
    0x7fff6348a000 -     0x7fff6348bfff  liblangid.dylib (133) <EDF945D6-A37D-3DEB-B956-B4745269603D> /usr/lib/liblangid.dylib
    0x7fff6348c000 -     0x7fff634a4ff3  liblzma.5.dylib (16) <F75FB525-C702-3A7E-9239-28D57E677DD5> /usr/lib/liblzma.5.dylib
    0x7fff634bc000 -     0x7fff63563fff  libmecab.dylib (883.1.1) <A2C923A6-D955-3FF1-82AE-7E54947F9566> /usr/lib/libmecab.dylib
    0x7fff63564000 -     0x7fff637c6fe1  libmecabra.dylib (883.1.1) <971A30D4-1C27-3DD1-AACF-8337AE059F70> /usr/lib/libmecabra.dylib
    0x7fff63c94000 -     0x7fff6410aff7  libnetwork.dylib (1880.60.5) <8B4092C3-9F1C-34C3-A73D-A2228C345831> /usr/lib/libnetwork.dylib
    0x7fff641a9000 -     0x7fff641dafc6  libobjc.A.dylib (781.2) <7B72F50A-5381-36D7-A616-65D3EA9748A5> /usr/lib/libobjc.A.dylib
    0x7fff641ed000 -     0x7fff641f1fff  libpam.2.dylib (25) <55302451-C2B2-3DB4-9092-B84E236104DA> /usr/lib/libpam.2.dylib
    0x7fff641f4000 -     0x7fff6422aff7  libpcap.A.dylib (89.60.2) <FD167BF3-6984-36E1-9D93-E8B98E3E64A1> /usr/lib/libpcap.A.dylib
    0x7fff64320000 -     0x7fff6450dff7  libsqlite3.dylib (308.4) <448E300F-0157-3AEA-B199-0DFA914B1547> /usr/lib/libsqlite3.dylib
    0x7fff6475f000 -     0x7fff64762ffb  libutil.dylib (57) <6CB26E6D-AD27-3FA8-8A30-4AFC3A2AE3F9> /usr/lib/libutil.dylib
    0x7fff64763000 -     0x7fff64770fff  libxar.1.dylib (420) <317EA455-78EE-35A4-B63F-D85993B8697C> /usr/lib/libxar.1.dylib
    0x7fff64776000 -     0x7fff64858ff7  libxml2.2.dylib (32.14) <4F4EB304-2AA5-3E5F-AB24-F645E0D16EFC> /usr/lib/libxml2.2.dylib
    0x7fff6485c000 -     0x7fff64884fff  libxslt.1.dylib (16.7) <E9BBE609-BA57-368D-95D7-ACA3A8C1AE8B> /usr/lib/libxslt.1.dylib
    0x7fff64885000 -     0x7fff64897ffb  libz.1.dylib (76) <52250917-039C-3B46-8011-497FEACF3550> /usr/lib/libz.1.dylib
    0x7fff652fb000 -     0x7fff65300ff3  libcache.dylib (83) <11C19883-6F99-390D-AF2A-A85A99DDFC48> /usr/lib/system/libcache.dylib
    0x7fff65301000 -     0x7fff6530cfff  libcommonCrypto.dylib (60165) <FEE99884-61F0-3332-852B-B0BB8EFF2288> /usr/lib/system/libcommonCrypto.dylib
    0x7fff6530d000 -     0x7fff65314fff  libcompiler_rt.dylib (101.2) <D7367E6D-A27D-3209-A3DB-A6F44582E502> /usr/lib/system/libcompiler_rt.dylib
    0x7fff65315000 -     0x7fff6531efff  libcopyfile.dylib (166.40.1) <91670D15-CB30-3277-8AA9-9A299CEAAE27> /usr/lib/system/libcopyfile.dylib
    0x7fff6531f000 -     0x7fff653b6fdb  libcorecrypto.dylib (866.80.2) <3B110D82-B403-31E8-8109-8BBC79C928CE> /usr/lib/system/libcorecrypto.dylib
    0x7fff654cd000 -     0x7fff6550eff0  libdispatch.dylib (1173.60.1) <5EF42E98-AD0D-3FAE-ABD4-46D791B8343F> /usr/lib/system/libdispatch.dylib
    0x7fff6550f000 -     0x7fff65544ff7  libdyld.dylib (733.8) <8B0DFE8A-42CF-32C8-B121-83C22BF25F69> /usr/lib/system/libdyld.dylib
    0x7fff65545000 -     0x7fff65545ffb  libkeymgr.dylib (30) <7DADC026-70A8-390F-95AF-F3F345760F24> /usr/lib/system/libkeymgr.dylib
    0x7fff65546000 -     0x7fff65552ff7  libkxld.dylib (6153.81.5) <7572CC82-E7E1-3C38-825F-9B34E2EADAD0> /usr/lib/system/libkxld.dylib
    0x7fff65553000 -     0x7fff65553ff7  liblaunch.dylib (1738.80.8) <C4EA8803-E506-3514-9839-9BBECC819953> /usr/lib/system/liblaunch.dylib
    0x7fff65554000 -     0x7fff65559ff7  libmacho.dylib (949.0.1) <395ABE7C-D2B1-343D-A451-9CEA98FDC12E> /usr/lib/system/libmacho.dylib
    0x7fff6555a000 -     0x7fff6555cff7  libquarantine.dylib (110.40.3) <560961FC-1FEF-3F07-8406-17A36558870E> /usr/lib/system/libquarantine.dylib
    0x7fff6555d000 -     0x7fff6555eff7  libremovefile.dylib (48) <E99833DE-CB1D-31AB-A948-2739AF503599> /usr/lib/system/libremovefile.dylib
    0x7fff6555f000 -     0x7fff65576fff  libsystem_asl.dylib (377.60.2) <21A259BC-F892-34EB-9A67-11232AD8913A> /usr/lib/system/libsystem_asl.dylib
    0x7fff65577000 -     0x7fff65577fff  libsystem_blocks.dylib (74) <8B23F806-8153-3163-B5D8-2C3327E211D8> /usr/lib/system/libsystem_blocks.dylib
    0x7fff65578000 -     0x7fff655ffff7  libsystem_c.dylib (1353.60.8) <99202CC3-2E27-3680-A8FF-5C516C485E90> /usr/lib/system/libsystem_c.dylib
    0x7fff65600000 -     0x7fff65603ffb  libsystem_configuration.dylib (1061.80.3) <8A149700-51AA-3205-A9D4-FF2A7BFC5412> /usr/lib/system/libsystem_configuration.dylib
    0x7fff65604000 -     0x7fff65607ff7  libsystem_coreservices.dylib (114) <CCC076FA-310D-3FC9-950D-41E0F8DDA5D2> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff65608000 -     0x7fff65610fff  libsystem_darwin.dylib (1353.60.8) <31ACD3CC-6DD9-3F2E-B163-9342BE1D0AB0> /usr/lib/system/libsystem_darwin.dylib
    0x7fff65611000 -     0x7fff65618ffb  libsystem_dnssd.dylib (1096.60.2) <BEBB815A-065A-365E-9701-8E05A8CF2040> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff65619000 -     0x7fff6561affb  libsystem_featureflags.dylib (17) <340AD606-7C39-3E6A-BAC3-EA1273FC27A4> /usr/lib/system/libsystem_featureflags.dylib
    0x7fff6561b000 -     0x7fff65668fff  libsystem_info.dylib (538) <B0EBAE05-01AD-3D8E-92CC-5704394FF94A> /usr/lib/system/libsystem_info.dylib
    0x7fff65669000 -     0x7fff65695ff7  libsystem_kernel.dylib (6153.81.5) <23909F45-79C3-34C9-A28F-337915925E5E> /usr/lib/system/libsystem_kernel.dylib
    0x7fff65696000 -     0x7fff656ddfcf  libsystem_m.dylib (3178) <7D775039-51B8-356E-82D7-98449065518A> /usr/lib/system/libsystem_m.dylib
    0x7fff656de000 -     0x7fff65705fff  libsystem_malloc.dylib (283.60.1) <00190446-C6A8-3EA6-92D1-850EA85C84CE> /usr/lib/system/libsystem_malloc.dylib
    0x7fff65706000 -     0x7fff65713ffb  libsystem_networkextension.dylib (1095.60.2) <1E7A59D0-BBCD-3CB0-8AD1-D442A1A5268E> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff65714000 -     0x7fff6571dff3  libsystem_notify.dylib (241) <AB3FAC47-A830-3158-8D99-DBC728CED1D6> /usr/lib/system/libsystem_notify.dylib
    0x7fff6571e000 -     0x7fff65727fef  libsystem_platform.dylib (220) <3DAFCC01-B768-3FFC-AC59-47AAE86BBEA1> /usr/lib/system/libsystem_platform.dylib
    0x7fff65728000 -     0x7fff65732fff  libsystem_pthread.dylib (416.60.2) <AAF506F4-9455-3CC4-8E0B-6791E3C0993C> /usr/lib/system/libsystem_pthread.dylib
    0x7fff65733000 -     0x7fff65737fff  libsystem_sandbox.dylib (1217.80.1) <C8F3841A-9364-3414-9E3F-9DE3D5FECF0C> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff65738000 -     0x7fff6573afff  libsystem_secinit.dylib (62.80.1) <32F36517-9A1C-3D30-85C8-611A2F5E2355> /usr/lib/system/libsystem_secinit.dylib
    0x7fff6573b000 -     0x7fff65742ffb  libsystem_symptoms.dylib (1238.60.1) <2EDF9CE8-4091-30A8-B125-0F25E579694A> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff65743000 -     0x7fff65759ff2  libsystem_trace.dylib (1147.80.3) <AE11B1AC-352A-37F0-BCA9-055609070104> /usr/lib/system/libsystem_trace.dylib
    0x7fff6575b000 -     0x7fff65760ffb  libunwind.dylib (35.4) <E867ACDE-EADE-3C91-A2A4-0C401788FD47> /usr/lib/system/libunwind.dylib
    0x7fff65761000 -     0x7fff65796ffe  libxpc.dylib (1738.80.8) <51E3E807-9133-3605-BB5F-D59ED6404ABF> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 58249
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=981.7M resident=0K(0%) swapped_out_or_unallocated=981.7M(100%)
Writable regions: Total=216.7M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=216.7M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    8K        1 
MALLOC                            62.1M       65 
MALLOC guard page                   16K        4 
MALLOC_LARGE (reserved)            256K        1         reserved VM address space (unallocated)
STACK GUARD                          8K        2 
Stack                             16.5M        2 
VM_ALLOCATE                       72.0M      289 
VM_ALLOCATE (reserved)            64.0M        2         reserved VM address space (unallocated)
__DATA                            17.3M      381 
__DATA_CONST                       380K       40 
__LINKEDIT                       558.9M      185 
__OBJC_RO                         32.0M        1 
__OBJC_RW                         1780K        2 
__TEXT                           422.8M      302 
__UNICODE                          564K        1 
shared memory                       12K        3 
===========                     =======  ======= 
TOTAL                              1.2G     1281 
TOTAL, minus reserved VM space     1.2G     1281

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39739>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:13:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Feb 2020 18:13:27 +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: <1582654407.62.0.342093665943.issue38913@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +18017
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18656

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38913>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:16:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Feb 2020 18:16:51 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582654611.96.0.800318744118.issue39737@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I have doubts that such small change can lead to significant speed up. It is likely a compiler glitch.

But this change makes the code clearer. If you remove a NEWS entry with a doubtful promise I will accept it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:23:02 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 18:23:02 +0000
Subject: [issue38519] Internal include files missing on Windows
In-Reply-To: <1571423438.26.0.118785392888.issue38519@roundup.psfhosted.org>
Message-ID: <1582654982.97.0.198087468587.issue38519@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/issue38519>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:28:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Feb 2020 18:28:44 +0000
Subject: [issue39750] UnicodeError becomes unpicklable if data is appended to
 args
In-Reply-To: <1582647336.17.0.517223219132.issue39750@roundup.psfhosted.org>
Message-ID: <1582655324.09.0.268215828298.issue39750@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, this is how exceptions are pickled. You save an information which which allows you to recreate the exception. If you fake args, you do not able to recreate it.

Just do not do this.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39750>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:42:14 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 25 Feb 2020 18:42:14 +0000
Subject: [issue39753] inspecting a partial with bound keywods gives incorrect
 signature
Message-ID: <1582656134.57.0.362705493242.issue39753@roundup.psfhosted.org>


New submission from Chris Withers <chris at withers.org>:

$ python
Python 3.8.1 (v3.8.1:1b293b6006, Dec 18 2019, 14:08:53) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import partial
>>> def foo(x, y, z, a=None): pass
... 
>>> p = partial(foo, 1, y=2)
>>> from inspect import signature
>>> signature(p).parameters.values()
odict_values([<Parameter "y=2">, <Parameter "z">, <Parameter "a=None">])

That <Parameter "y=2"> shouldn't be in there:

>>> p(2, y=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() got multiple values for argument 'y'

----------
messages: 362656
nosy: cjw296
priority: normal
severity: normal
status: open
title: inspecting a partial with bound keywods gives incorrect signature

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39753>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:42:45 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 25 Feb 2020 18:42:45 +0000
Subject: [issue39753] inspecting a partial with bound keywods gives incorrect
 signature
In-Reply-To: <1582656134.57.0.362705493242.issue39753@roundup.psfhosted.org>
Message-ID: <1582656165.41.0.837164837298.issue39753@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
components: +Library (Lib)
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39753>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:44:58 2020
From: report at bugs.python.org (Chris Withers)
Date: Tue, 25 Feb 2020 18:44:58 +0000
Subject: [issue39753] inspecting a partial with bound keywods gives incorrect
 signature
In-Reply-To: <1582656134.57.0.362705493242.issue39753@roundup.psfhosted.org>
Message-ID: <1582656298.71.0.311320793162.issue39753@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Surprised partials have no explicit signature:

>>> p.__signature__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'functools.partial' object has no attribute '__signature__'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39753>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:45:08 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 18:45:08 +0000
Subject: [issue38403] nuspec iconUrl field is deprecated
In-Reply-To: <1570508501.54.0.80221217734.issue38403@roundup.psfhosted.org>
Message-ID: <1582656308.63.0.503075313345.issue38403@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +18018
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18657

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38403>
_______________________________________

From report at bugs.python.org  Tue Feb 25 13:58:15 2020
From: report at bugs.python.org (Ben Darnell)
Date: Tue, 25 Feb 2020 18:58:15 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1582657095.19.0.0572453593358.issue37373@roundup.psfhosted.org>


Ben Darnell <ben.darnell at gmail.com> added the comment:

I considered using the `selectors` module directly, but it's not as simple as it sounds. Using the low-level interface means you need to also use a self-waker-pipe (or socket on windows) and manage a queue analogous to that used by `call_soon_threadsafe`. We already have two implementations of this pattern in asyncio with subtle differences between them (such as this one i just found: https://bugs.python.org/issue39651). In the end you'd have to duplicate a non-trivial portion of SelectorEventLoop. 

While there might be some efficiency gains to be had by working directly with the lower-level interface (and avoiding some redundancies between the two threads' event loops), I think the most robust/safest option is to use the well-tested SelectorEventLoop so that the only new code is what's needed to pass things back and forth between threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Tue Feb 25 14:02:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Feb 2020 19:02:28 +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: <1582657348.45.0.2751386152.issue38410@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +18019
pull_request: https://github.com/python/cpython/pull/18658

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38410>
_______________________________________

From report at bugs.python.org  Tue Feb 25 14:06:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Feb 2020 19:06:21 +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: <1582657581.51.0.805273609593.issue38410@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 18658 is a backport to 3.8 which preserves binary compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38410>
_______________________________________

From report at bugs.python.org  Tue Feb 25 14:19:08 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 25 Feb 2020 19:19:08 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582658348.57.0.483170772112.issue36144@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +18020
pull_request: https://github.com/python/cpython/pull/18659

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:05:25 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 20:05:25 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582661125.95.0.964095002052.issue36144@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Not sure if this is a big deal or not, and it seems likely that the preexisting behaviour of .update() and ** unpacking have already decided it, but is it intentional that you end up with the first-seen key and the last-seen value in the case of collisions?

class C:
    def __init__(self, *a): self.a = a
    def __hash__(self): return hash(self.a[0])
    def __eq__(self, o): return self.a[0] == o.a[0]
    def __repr__(self): return f"C{self.a}"

>>> c1 = C(1, 1); c1
C(1, 1)
>>> c2 = C(1, 2); c2
C(1, 2)

For set union we get the first seen value:
>>> {c1} | {c2}
{C(1, 1)}

For dict union we get the first seen key and the last seen value:
>>> {c1: 'a'} | {c2: 'b'}
{C(1, 1): 'b'}

But similarly for dict unpack (and .update(); code left as an exercise to the reader):
>>> {**{c1: 'a'}, **{c2: 'b'}}
{C(1, 1): 'b'}

So the union of two dicts may contain .items() elements that were not in either of the inputs.

Honestly, I've never noticed this before, as the only time I create equivalent objects with meaningfully-distinct identities is to use with sets. I just figured I'd try it out after seeing suggestions that the dict union operands were transposed from set union.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:07:18 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 20:07:18 +0000
Subject: [issue38403] nuspec iconUrl field is deprecated
In-Reply-To: <1570508501.54.0.80221217734.issue38403@roundup.psfhosted.org>
Message-ID: <1582661238.89.0.256443830073.issue38403@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d6448919702142123d937a54f20a81aeaf8d2acc by Steve Dower in branch 'master':
bpo-38403: Update nuspec file for deprecated field and git repository (GH-18657)
https://github.com/python/cpython/commit/d6448919702142123d937a54f20a81aeaf8d2acc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38403>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:07:17 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Feb 2020 20:07:17 +0000
Subject: [issue38403] nuspec iconUrl field is deprecated
In-Reply-To: <1570508501.54.0.80221217734.issue38403@roundup.psfhosted.org>
Message-ID: <1582661237.33.0.057264417419.issue38403@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18021
pull_request: https://github.com/python/cpython/pull/18660

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38403>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:17:09 2020
From: report at bugs.python.org (Marco Sulla)
Date: Tue, 25 Feb 2020 20:17:09 +0000
Subject: [issue39754] update_one_slot() does not inherit sq_contains and
 mp_subscript if they are explictly declared
Message-ID: <1582661829.56.0.319745659558.issue39754@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

I noticed that `__contains__()` and `__getitem__()` of subclasses of `dict` are much slower. I asked why on StackOverflow, and an user seemed to find the reason.

The problem for him/her is that `dict` implements directly `__contains__()` and `__getitem__()`. Usually, `sq_contains` and `mp_subscript` are wrapped to implement `__contains__()` and `__getitem__()`, but this way `dict` is a little faster, I suppose.

The problem is that `update_one_slot()` searches for the wrappers. If it does not find them, it does not inherit the `__contains__()` and `__getitem__()` of the class, but create a `__contains__()` and `__getitem__()` functions that do an MRO search and call the superclass method. This is why `__contains__()` and `__getitem__()` of `dict` subclasses are slower.


Is it possible to modify `update_one_slot()` so that, if no wrapper is found, the explicit implementation is inherited?

SO answer: https://stackoverflow.com/a/59914459/1763602

----------
components: C API
messages: 362662
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: update_one_slot() does not inherit sq_contains and mp_subscript if they are explictly declared
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39754>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:19:59 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 25 Feb 2020 20:19:59 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582661999.96.0.0843914842698.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

As a somewhat simpler example:

>>> f = {False: False}
>>> z = {0: 0}
>>> f | z
{False: 0}
>>> {**f, **z}
{False: 0}
>>> f.update(z); f
{False: 0}

Though these hairier cases aren't explicitly addressed, the conflict behavior is covered in the Rationale and Reference Implementation sections of the PEP. All of the above examples share code (`dict_update_arg`), and that's definitely intentional. I for one think it would be confusing (and probably a bug) if one of the examples above gave a different key-value pair!

I find it makes more sense if you see a set as valueless keys (rather than keyless values).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:24:55 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Feb 2020 20:24:55 +0000
Subject: [issue38403] nuspec iconUrl field is deprecated
In-Reply-To: <1570508501.54.0.80221217734.issue38403@roundup.psfhosted.org>
Message-ID: <1582662295.16.0.518700460523.issue38403@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1bbb81b251bcc8b05e0cd33cd36aef55481b13db by Miss Islington (bot) in branch '3.8':
bpo-38403: Update nuspec file for deprecated field and git repository (GH-18657)
https://github.com/python/cpython/commit/1bbb81b251bcc8b05e0cd33cd36aef55481b13db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38403>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:30:07 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 25 Feb 2020 20:30:07 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582662607.0.0.525248554173.issue39737@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I made the requested changes to reflect that this is for code cleanliness rather than strictly for performance.

However, it appears that Visual Studio on Windows 10 was not doing the optimization one might expect. In particular, here is the disassembly before this PR:

===========================================
        PyObject *vitem = vl->ob_item[i];
78E20C49  mov         eax,dword ptr [edx+0Ch]  
        PyObject *vitem = vl->ob_item[i];
78E20C4C  mov         ecx,dword ptr [eax+edi*4]  
        PyObject *witem = wl->ob_item[i];
78E20C4F  mov         eax,dword ptr [esi+0Ch]  
78E20C52  mov         dword ptr [vitem],ecx  
78E20C55  mov         esi,dword ptr [eax+edi*4]  
78E20C58  mov         dword ptr [witem],esi  
        if (vitem == witem) {
78E20C5B  cmp         ecx,esi  
78E20C5D  je          list_richcompare+12Bh (78E20CFBh)  
            continue;
        }

        Py_INCREF(vitem);
78E20C63  inc         dword ptr [ecx]  
        Py_INCREF(witem);
78E20C65  inc         dword ptr [esi]  
        int k = PyObject_RichCompareBool(vl->ob_item[i], 
78E20C67  mov         eax,dword ptr [w]  
78E20C6A  mov         eax,dword ptr [eax+0Ch]  
78E20C6D  mov         ebx,dword ptr [eax+edi*4]  
78E20C70  mov         eax,dword ptr [edx+0Ch]  
78E20C73  mov         eax,dword ptr [eax+edi*4]  
78E20C76  cmp         eax,ebx  
78E20C78  jne         list_richcompare+0B1h (78E20C81h)  
78E20C7A  mov         ebx,1  
78E20C7F  jmp         list_richcompare+100h (78E20CD0h)  
78E20C81  push        2  
78E20C83  push        ebx  
78E20C84  push        eax  
78E20C85  call        PyObject_RichCompare (78E35120h)  
78E20C8A  mov         esi,eax  
78E20C8C  add         esp,0Ch  
78E20C8F  test        esi,esi  
78E20C91  jne         list_richcompare+0C8h (78E20C98h)  
78E20C93  or          ebx,0FFFFFFFFh  
78E20C96  jmp         list_richcompare+0FAh (78E20CCAh)  
78E20C98  cmp         dword ptr [esi+4],offset PyBool_Type (790A3420h)  
===========================================

And after this PR:
===========================================
        PyObject *vitem = vl->ob_item[i];
795E0C4A  mov         eax,dword ptr [edx+0Ch]  
        PyObject *vitem = vl->ob_item[i];
795E0C4D  mov         ebx,dword ptr [eax+ecx*4]  
        PyObject *witem = wl->ob_item[i];
795E0C50  mov         eax,dword ptr [edi+0Ch]  
795E0C53  mov         edi,dword ptr [eax+ecx*4]  
        if (vitem == witem) {
795E0C56  cmp         ebx,edi  
795E0C58  je          list_richcompare+109h (795E0CD9h)  
            continue;
        }

        Py_INCREF(vitem);
795E0C5A  inc         dword ptr [ebx]  
        Py_INCREF(witem);
795E0C5C  inc         dword ptr [edi]  
        int k = PyObject_RichCompareBool(vitem, witem, Py_EQ);
795E0C5E  push        2  
795E0C60  push        edi  
795E0C61  push        ebx  
795E0C62  call        PyObject_RichCompare (795F5120h)  
795E0C67  mov         esi,eax  
795E0C69  add         esp,0Ch  
795E0C6C  test        esi,esi  
795E0C6E  jne         list_richcompare+0A5h (795E0C75h)  
795E0C70  or          esi,0FFFFFFFFh  
795E0C73  jmp         list_richcompare+0DBh (795E0CABh)  
795E0C75  cmp         dword ptr [esi+4],offset PyBool_Type (79863420h)  
795E0C7C  jne         list_richcompare+0BBh (795E0C8Bh)  
795E0C7E  xor         eax,eax  
795E0C80  cmp         esi,offset _Py_TrueStruct (798633FCh)  
795E0C86  sete        al  
795E0C89  jmp         list_richcompare+0C4h (795E0C94h)  
795E0C8B  push        esi  
795E0C8C  call        PyObject_IsTrue (795F62F0h)  
795E0C91  add         esp,4  
795E0C94  add         dword ptr [esi],0FFFFFFFFh  
795E0C97  mov         dword ptr [k],eax  
795E0C9A  jne         list_richcompare+0D8h (795E0CA8h)  
===========================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:33:42 2020
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 25 Feb 2020 20:33:42 +0000
Subject: [issue17050] argparse.REMAINDER doesn't work as first argument
In-Reply-To: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>
Message-ID: <1582662822.17.0.719022561901.issue17050@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +18022
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18661

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17050>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:42:02 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 20:42:02 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582663322.52.0.131019562708.issue36144@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

That's a much simpler example. And of course:

>>> z[False] = False
>>> z
{0: False}

So the precedent is well established that the key doesn't get updated with the value.

No further questions, yer honour ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 15:55:34 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 25 Feb 2020 20:55:34 +0000
Subject: [issue38403] nuspec iconUrl field is deprecated
In-Reply-To: <1570508501.54.0.80221217734.issue38403@roundup.psfhosted.org>
Message-ID: <1582664134.92.0.13760640703.issue38403@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Not enough value fixing 3.7 and 2.7 at this stage - nuget.org can't actively *break* the old format without spoiling half the repository, so I'm sure it'll be fine to leave them as they are for the last few uploads.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38403>
_______________________________________

From report at bugs.python.org  Tue Feb 25 16:16:20 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 25 Feb 2020 21:16:20 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582665380.21.0.717731195205.issue36144@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
title: Dictionary addition. (PEP 584) -> Dictionary union. (PEP 584)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Tue Feb 25 17:35:29 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Tue, 25 Feb 2020 22:35:29 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582670129.25.0.480180574915.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

Damn, good catch. How about the following idea - register a normal signal handler (using signal.signal) that does something like:

def sigint_handler():
    get_running_loop().interrupt()

# in class BaseEventLoop
def interrupt(self):
    # Might be a generally useful thread-safe way to interrupt a loop
    if self._is_inside_callback():
        _thread.interrupt_main() # All this behavior is only relevant to the main thread anyway
    else:
        self._interrupted = True

And inside BaseEventLoop._run_once() add the following check:

# in class BaseEventLoop
def _check_interrupted(self):
    # This will be called by BaseEventLoop._run_once() before calling select,
    # and before popping any handle from the ready queue
    if self._interrupted:
        raise KeyboardInterrupt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Tue Feb 25 17:39:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Feb 2020 22:39:04 +0000
Subject: [issue1207613] Idle Editor: Bottom Scroll Bar
Message-ID: <1582670344.82.0.415603548037.issue1207613@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Some IDLE users really want a horizontal scrollbar (for the editor), and even consider its absence to be a reason to not use it.

Stackoverflow 2012: https://stackoverflow.com/questions/10301071/is-there-a-horizontal-scroll-bar-in-pythons-idle

Reddit 2020: https://stackoverflow.com/questions/10301071/is-there-a-horizontal-scroll-bar-in-pythons-idle
This was brought to my attention by Steven D'Aprano and specifically compare the IDLE editor to other editors.

I have decided to not wait until a possible major refactoring to add this feature.  The patch needs several revisions (see review).

I neglected to mention above (msg352888) that the scrollbar added to the font sample box is a Scrollbar subclass, textview.AutoHideScrollbar, that only appears when needed.  After experimenting with editing the font sample, I think we can just add this with no option to disable it.

Since editor windows already allow lines longer than the window width and already have horizontal scrolling by cursor motion, such as by Home, End, and Left and Right arrow keys, adding a horizontal scrollbar makes scrolling easier, but does not really change editor window behavior.  The disappearance of the scrollbar when a long line is sufficiently shortened makes it easier to determine when one has shortened a line enough to meet the window width as a limit, if one wishes. 

The shell is a different issue.  It wraps at the window width, just like standard interactive Python (as least on Windows with Command Prompt and macOS with Terminal).  I think something like the following is better wrapped.  If nothing else, copying to paste is easier ;-).  

>>> 2**1024
179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216

So, at least for now, no hbar for Shell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1207613>
_______________________________________

From report at bugs.python.org  Tue Feb 25 18:13:31 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Tue, 25 Feb 2020 23:13:31 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582672411.32.0.541368793459.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

While looking into this proposal, I realized that this will not wake up the loop from the select call. I think the safest solution would be to use the wakeup fd mechanism.

An additional easy, but less secure solution would be to define an internal 'signal safe' context manager that will be used only in the critical parts.

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Tue Feb 25 18:38:54 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Feb 2020 23:38:54 +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: <1582673934.79.0.418050528066.issue30064@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I very doubt if any sane code is organizing like this test: start delayed reading, cancel it and read again.

Hm, cancellation should work correctly no matter how "sane" or "insane" the user code is.

> The worse, neither previous not current sock_read() implementation doesn't prevent the concurrent reading which basically delivers data in an unpredictable order.

But we're not discussing using a socket concurrently -- asyncio explicitly does not support that for the sock_ api. 

AFAICT this issue is about consequent cancel operation not working as expected in asyncio, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30064>
_______________________________________

From report at bugs.python.org  Tue Feb 25 18:53:56 2020
From: report at bugs.python.org (Mark Bell)
Date: Tue, 25 Feb 2020 23:53:56 +0000
Subject: [issue39755] Change example of itertools.product
Message-ID: <1582674836.69.0.647873846967.issue39755@roundup.psfhosted.org>


New submission from Mark Bell <mark00bell at googlemail.com>:

The documentation for itertools.product at: https://docs.python.org/3/library/itertools.html#itertools.product
currently says that:

    For example, product(A, B) returns the same as ((x,y) for x in A for y in B)

While this is broadly correct, since product first converts its arguments to tuples, this is not true if A or B are infinite iterables. For example, when A = itertools.count() and B = range(2) then the former runs forever using infinite memory, whereas the latter returns the lazy generator immediately for use.

Would it be clearer / more correct to instead say:

    For example, product(A, B) returns the same as ((x,y) for x in tuple(A) for y in tuple(B))

----------
assignee: docs at python
components: Documentation
messages: 362672
nosy: Mark.Bell, docs at python
priority: normal
severity: normal
status: open
title: Change example of itertools.product
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39755>
_______________________________________

From report at bugs.python.org  Tue Feb 25 18:58:20 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 25 Feb 2020 23:58:20 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582675100.16.0.960471177046.issue39698@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Source?

I could not find a good source, sorry. I remember I had a complaint in uvloop to support negative timeouts, but I can't trace it. 

That said, I also distinctly remember seeing code (and writing such code myself) that performs computation on timeouts and does not care if the end value goes below 0.  It might be a weak data point but it's still a valid one.

> IMHO, deprecating and then removing support for negative argument in `asyncio.sleep()` is very much less breaking compared to issues #36921 and #36373 .

Breaking code/APIs always has a price and we always try to have a very good explanation "why" we want to bother ourselves and users to break backwards compat.  This one is not worth it IMHO.

We have more breaking API changes that are more substantial coming in future versions of asyncio. So I try to limit the impact by only breaking what's really necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Tue Feb 25 19:04:02 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 26 Feb 2020 00:04:02 +0000
Subject: [issue39529] Deprecate get_event_loop()
In-Reply-To: <1580641897.21.0.210075972969.issue39529@roundup.psfhosted.org>
Message-ID: <1582675442.27.0.374551991039.issue39529@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> For asyncio.Lock (plus other synchronization primitives) and asyncio.Queue, this would be added in https://github.com/python/cpython/pull/18195. Currently waiting on emanu (author of the PR) to finish up some changes, but it's mostly complete. Could I work on adding it to asyncio.Future and other classes in the meantime?

I think the approach should be different:


  # leading underscore is significant:
  loop = asyncio._get_running_loop()  
  if loop is None:
    issue_deprecation_warning()
    loop = asyncio.get_event_loop()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39529>
_______________________________________

From report at bugs.python.org  Tue Feb 25 20:36:17 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 26 Feb 2020 01:36:17 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1582680977.86.0.821002600462.issue27657@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi  ?ukasz, There was a concern raised by python core-devs about behavior in 3.9. I plan to address that point raised in this issue and close this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Tue Feb 25 21:07:31 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 26 Feb 2020 02:07:31 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582682851.74.0.777326183547.issue39737@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

>  it appears that Visual Studio on Windows 10 was not doing the optimization one might expect.

Hmm, Is this build on release mode?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 21:17:47 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 26 Feb 2020 02:17:47 +0000
Subject: [issue39754] update_one_slot() does not inherit sq_contains and
 mp_subscript if they are explictly declared
In-Reply-To: <1582661829.56.0.319745659558.issue39754@roundup.psfhosted.org>
Message-ID: <1582683467.69.0.711908671833.issue39754@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

See also #34396.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39754>
_______________________________________

From report at bugs.python.org  Tue Feb 25 21:30:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 26 Feb 2020 02:30:59 +0000
Subject: [issue39755] Change example of itertools.product
In-Reply-To: <1582674836.69.0.647873846967.issue39755@roundup.psfhosted.org>
Message-ID: <1582684259.67.0.0336123707565.issue39755@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/issue39755>
_______________________________________

From report at bugs.python.org  Tue Feb 25 21:50:23 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 26 Feb 2020 02:50:23 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582685423.35.0.299651431301.issue39737@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

> Hmm, Is this build on release mode?

Yes--in debug mode, each Py_INCREF is these 8 instructions:

========================
78BD071E  mov         ecx,dword ptr [_Py_RefTotal (79039700h)]  
78BD0724  add         ecx,1  
78BD0727  mov         dword ptr [_Py_RefTotal (79039700h)],ecx  
78BD072D  mov         edx,dword ptr [ebp-10h]  
78BD0730  mov         eax,dword ptr [edx]  
78BD0732  add         eax,1  
78BD0735  mov         ecx,dword ptr [ebp-10h]  
78BD0738  mov         dword ptr [ecx],eax  
========================

instead of just the one `inc` in release mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 22:09:47 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 26 Feb 2020 03:09:47 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582686587.38.0.870172093743.issue39737@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Debug mode is not meaningful.
Visual Studio will optimize fully on release mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 22:57:32 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Wed, 26 Feb 2020 03:57:32 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582689452.21.0.829242077274.issue39737@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

> Debug mode is not meaningful.
> Visual Studio will optimize fully on release mode.

Sorry if I wasn't clear--the original assembly difference I posted in (https://bugs.python.org/msg362665) was indeed using the "release" build configuration. My last comment was trying to demonstrate this fact by showing that the assembly output would have looked different if I had selected the "debug" build configuration. 

Is there something I'm missing, or was Visual Studio just missing an opportunity to optimize?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Tue Feb 25 23:42:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Feb 2020 04:42:48 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582692168.45.0.468677420766.issue39737@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Speed-up or not, I concur that the new code it clearer.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Wed Feb 26 01:40:12 2020
From: report at bugs.python.org (Devin Morgan)
Date: Wed, 26 Feb 2020 06:40:12 +0000
Subject: [issue39756] Event sequence "KeyRelease-Shift_R" not being fired
Message-ID: <1582699212.15.0.411870257552.issue39756@roundup.psfhosted.org>


New submission from Devin Morgan <devmorgan14 at gmail.com>:

Trying to create a remake of Pong and am trying to use Right Control and Right Shift to move the right paddle up and down, moving the paddle down works fine but gets stuck in the move up state, despite my efforts root out logic errors through reviewing and debugging my code and the logic is correct.

----------
components: Tkinter
files: Py-Pong.py
messages: 362682
nosy: Devin Morgan
priority: normal
severity: normal
status: open
title: Event sequence "KeyRelease-Shift_R" not being fired
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48916/Py-Pong.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39756>
_______________________________________

From report at bugs.python.org  Wed Feb 26 02:00:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 07:00:39 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582700439.32.0.773386101673.issue39737@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset be7ead62db9a1db3e2cd997b0beffd4480e51f5c by sweeneyde in branch 'master':
bpo-39737: Remove code repitition in list_richcompare (GH-18638)
https://github.com/python/cpython/commit/be7ead62db9a1db3e2cd997b0beffd4480e51f5c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Wed Feb 26 02:01:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 07:01:45 +0000
Subject: [issue39737] Speed up list.__eq__ by about 6%
In-Reply-To: <1582520201.72.0.954951125447.issue39737@roundup.psfhosted.org>
Message-ID: <1582700505.24.0.876620434392.issue39737@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Dennis.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39737>
_______________________________________

From report at bugs.python.org  Wed Feb 26 02:24:36 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 26 Feb 2020 07:24:36 +0000
Subject: [issue39755] Change example of itertools.product
In-Reply-To: <1582674836.69.0.647873846967.issue39755@roundup.psfhosted.org>
Message-ID: <1582701876.91.0.687453450746.issue39755@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestion, but I will decline.  The existing wording communicates the intended mental relationship between the product() and nested for-loop.  IMO, the proposed change obfuscates that main point.  

The details of how product works are communicated in the pure python equivalent block that follows.  That code clearly shows that each pool is first converted to a tuple.  So, your point about infinite iterators is already covered and doesn't need to be said twice.

We could replace "the same as" with "roughly the same as", but I don't really think that would be an improvement.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39755>
_______________________________________

From report at bugs.python.org  Wed Feb 26 04:16:37 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 26 Feb 2020 09:16:37 +0000
Subject: [issue39748] PyScripter could not find Python 3.8 64 bits
In-Reply-To: <1582630230.75.0.555477437991.issue39748@roundup.psfhosted.org>
Message-ID: <1582708597.5.0.314612995307.issue39748@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm going to close this. If you have more information that shows it's a bug in Python, we can re-open it.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39748>
_______________________________________

From report at bugs.python.org  Wed Feb 26 04:36:15 2020
From: report at bugs.python.org (Julien Castiaux)
Date: Wed, 26 Feb 2020 09:36:15 +0000
Subject: [issue39757] EmailMessage wrong encoding for international domain
Message-ID: <1582709775.3.0.571538664603.issue39757@roundup.psfhosted.org>


New submission from Julien Castiaux <julien.castiaux at gmail.com>:

Affected python version: 3.5 and above (did test them all except 3.9)

Steps to reproduce:

  from mail.message import EmailMessage
  from mail.policy import SMTP

  msg = EmailMessage(policy=SMTP)
  msg['To'] = 'Joe <joe at exampl?.com>'  # notice the ? in the domain
  print(msg.as_string())

It prints

    To: "Joe <joe@=?utf-8?q?exampl=C3=A9?=.com>"

But it should be

    To: "Joe <joe at xn--exampl-gva.com>"

While b64/qp can be used to encode most non-ascii headers, the domain part of an email address is an exception. According to IDNA2008 (rfc5890 , rfc5891), non-ascii domain should be encoded using the punycode algorithm and the ACE prefix.

----------
components: email
messages: 362687
nosy: Julien Castiaux, barry, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage wrong encoding for international domain
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39757>
_______________________________________

From report at bugs.python.org  Wed Feb 26 05:30:28 2020
From: report at bugs.python.org (Julien Castiaux)
Date: Wed, 26 Feb 2020 10:30:28 +0000
Subject: [issue39757] EmailMessage wrong encoding for international domain
In-Reply-To: <1582709775.3.0.571538664603.issue39757@roundup.psfhosted.org>
Message-ID: <1582713028.87.0.530526003617.issue39757@roundup.psfhosted.org>


Change by Julien Castiaux <julien.castiaux at gmail.com>:


----------
keywords: +patch
pull_requests: +18023
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18667

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39757>
_______________________________________

From report at bugs.python.org  Wed Feb 26 05:36:06 2020
From: report at bugs.python.org (Tom Christie)
Date: Wed, 26 Feb 2020 10:36:06 +0000
Subject: [issue39758] StreamWriter.wait_closed() can hang indefinately.
Message-ID: <1582713366.75.0.743984348325.issue39758@roundup.psfhosted.org>


New submission from Tom Christie <tom at tomchristie.com>:

Raising an issue that's impacting us on `httpx`.

It appears that in some cases SSL unwrapping can cause `.wait_closed()` to hang indefinately.

Trio are particularly careful to work around this case, and have an extensive comment on it: https://github.com/python-trio/trio/blob/31e2ae866ad549f1927d45ce073d4f0ea9f12419/trio/_ssl.py#L779-L829 

Originally raised via https://github.com/encode/httpx/issues/634

Tested on:

* Python 3.7.6
* Python 3.8.1

```
import asyncio
import ssl
import certifi

hostname = 'login.microsoftonline.com'
context = ssl.create_default_context()
context.load_verify_locations(cafile=certifi.where())

async def main():
    reader, writer = await asyncio.open_connection(hostname, 443, ssl=context)
    print('opened')
    writer.close()
    print('close started')
    await writer.wait_closed()
    print('close completed')

asyncio.run(main())
```

----------
components: asyncio
messages: 362688
nosy: asvetlov, tomchristie, yselivanov
priority: normal
severity: normal
status: open
title: StreamWriter.wait_closed() can hang indefinately.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39758>
_______________________________________

From report at bugs.python.org  Wed Feb 26 05:53:32 2020
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Voron?=)
Date: Wed, 26 Feb 2020 10:53:32 +0000
Subject: [issue39758] StreamWriter.wait_closed() can hang indefinitely.
In-Reply-To: <1582713366.75.0.743984348325.issue39758@roundup.psfhosted.org>
Message-ID: <1582714412.3.0.122869014496.issue39758@roundup.psfhosted.org>


Change by Fran?ois Voron <fvoron at gmail.com>:


----------
nosy: +Fran?ois Voron
title: StreamWriter.wait_closed() can hang indefinately. -> StreamWriter.wait_closed() can hang indefinitely.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39758>
_______________________________________

From report at bugs.python.org  Wed Feb 26 06:44:26 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 26 Feb 2020 11:44:26 +0000
Subject: [issue39759] os.getenv documentation is misleading
Message-ID: <1582717466.93.0.921378424861.issue39759@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

The documentation states that "*key*, *default* and the result are str." at https://github.com/python/cpython/blame/3.8/Doc/library/os.rst#L224 but either I'm missing something or it's not actually true:

$ python -c 'import os; print(type(os.getenv("FOO")))'           
<class 'NoneType'>
$ python -c 'import os; print(type(os.getenv("FOO", default=1)))'
<class 'int'>

Only *key* needs to be a string as it is used to lookup the value in os.environ.

I think this can be fixed by a new contributor

----------
assignee: docs at python
components: Documentation
messages: 362689
nosy: docs at python, remi.lapeyre
priority: normal
severity: normal
status: open
title: os.getenv documentation is misleading
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39759>
_______________________________________

From report at bugs.python.org  Wed Feb 26 07:22:34 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Wed, 26 Feb 2020 12:22:34 +0000
Subject: [issue39759] os.getenv documentation is misleading
In-Reply-To: <1582717466.93.0.921378424861.issue39759@roundup.psfhosted.org>
Message-ID: <1582719754.11.0.54224041059.issue39759@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
keywords: +patch
nosy: +dorosch
nosy_count: 2.0 -> 3.0
pull_requests: +18024
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18668

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39759>
_______________________________________

From report at bugs.python.org  Wed Feb 26 07:39:03 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Feb 2020 12:39:03 +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: <1582720743.89.0.419347264589.issue30064@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

This is a very interesting question.
In asyncio, task cancellation is not executed on `task.cancel()` call immediately but the task is *marked* for cancellation. 
The actual cancellation requires a context switch (await asyncio.sleep(0) or similar) to propagate `asyncio.CancelledError` into the task code and unwind the exception.

As I said, the test needs a context switch between `cancel()` call and analyzing the state after the task cancellation.

Futures are canceled immediately, that's why the previous implementation passed uvloop's test suite untouched. Unfortunately, it had own flaws.
Also please note, sock_connect()/sock_accept() were implemented this way about two years before my changes, they also suffer from cancel-without-actual-cancellation problems as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30064>
_______________________________________

From report at bugs.python.org  Wed Feb 26 07:43:02 2020
From: report at bugs.python.org (Ilya Kamenshchikov)
Date: Wed, 26 Feb 2020 12:43:02 +0000
Subject: [issue39760] ast.FormattedValue.format_spec unnecessarily wrapped in
 JoinedStr
Message-ID: <1582720982.96.0.367799860574.issue39760@roundup.psfhosted.org>


New submission from Ilya Kamenshchikov <ikamenshchikov at gmail.com>:

Most usual usecase for format_spec is to specify it as a constant, that would be logical to represent as ast.Constant. However, ast.parse wraps value of ast.FormattedValue.format_spec into a JoinedStr with a single constant value, as can be seen from example below:


import ast

code = '''f"is {x:d}"'''
tree = ast.parse(code)

for n in ast.walk(tree):
    if isinstance(n, ast.FormattedValue):
        print(
            type(n.format_spec),
            len(n.format_spec.values),
            set(type(v) for v in n.format_spec.values),
        )

This is confusing for programmatically analyzing the ast, and likely creates some overhead in any modules using ast and FormattedValue.

Proposal: represent ast.FormattedValue.format_spec as ast.Constant in most cases.

----------
components: Library (Lib)
messages: 362691
nosy: Ilya Kamenshchikov
priority: normal
severity: normal
status: open
title: ast.FormattedValue.format_spec unnecessarily wrapped in JoinedStr
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39760>
_______________________________________

From report at bugs.python.org  Wed Feb 26 09:26:45 2020
From: report at bugs.python.org (Lord Anton Hvornum)
Date: Wed, 26 Feb 2020 14:26:45 +0000
Subject: [issue16487] Allow ssl certificates to be specified from memory
 rather than files.
In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za>
Message-ID: <1582727205.68.0.594975871216.issue16487@roundup.psfhosted.org>


Lord Anton Hvornum <anton.doxid at gmail.com> added the comment:

I agree with Jan-Philip Gehrcke, would have been nice to have had this.

Pretty pissed reading through this ancient issue.

In regards to how people treat other volunteers: We're all working for free, and I think expectations from people with authoritative powers must have room for accepting a initially lower contribution standard than they themselves claim to produce. Mainly to not crush the will to help and contibute, but also because the attitude could be a lot better towards fellow programmers. It would also allow for a more iterative process in achieving higher standards. Otherwise you limit yourself to a very select few in the contribution process. Not to mention a lot of "grunt work" could be done by people having an idea, but not nessecarily the same "academic background" in terms of producing perfect code.

I've seen this across numerous Open Source projects, and quite frankly it deter me from ever contributing. PoC code shouldn't be seen as garbage, but a first step in creating new fresh things. Someone with more knowledge should and could step in and clean up things that are deamed "unfit" for production or help said contributor to understanding why certain things needs to be improved, not just blatently say patches needs to be improved.

This whole "It ain't perfect, we don't touch it" is elitism at it's finest. Stop it, and have a meaningful discussion instead.

----------
nosy: +Lord Anton Hvornum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16487>
_______________________________________

From report at bugs.python.org  Wed Feb 26 09:34:01 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 26 Feb 2020 14:34:01 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1582727641.48.0.246570438629.issue34788@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 21da76d1f1b527d62b2e9ef79dd9aa514d996341 by opavlyuk in branch 'master':
bpo-34788: Add support for scoped IPv6 addresses (GH-13772)
https://github.com/python/cpython/commit/21da76d1f1b527d62b2e9ef79dd9aa514d996341


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34788>
_______________________________________

From report at bugs.python.org  Wed Feb 26 09:43:17 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Feb 2020 14:43:17 +0000
Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1582728197.24.0.462089528237.issue34788@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/issue34788>
_______________________________________

From report at bugs.python.org  Wed Feb 26 10:06:39 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Feb 2020 15:06:39 +0000
Subject: [issue39759] os.getenv documentation is misleading
In-Reply-To: <1582717466.93.0.921378424861.issue39759@roundup.psfhosted.org>
Message-ID: <1582729599.18.0.432594312096.issue39759@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I consider a free type for the default as an implementation detail, not the encouraged approach.

Since the value is always a string, using the same type for the default sounds like a sane design for me.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39759>
_______________________________________

From report at bugs.python.org  Wed Feb 26 10:07:25 2020
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Eiras?=)
Date: Wed, 26 Feb 2020 15:07:25 +0000
Subject: [issue39750] UnicodeError becomes unpicklable if data is appended to
 args
In-Reply-To: <1582647336.17.0.517223219132.issue39750@roundup.psfhosted.org>
Message-ID: <1582729645.96.0.946206427451.issue39750@roundup.psfhosted.org>


Jo?o Eiras <joao.eiras at gmail.com> added the comment:

Hi.
It's perfectly fine for classes to have their public APIs and intended uses.

But then unpickling would be the worst place to complain, specially when running 40 parallel processes while an unhandled stacktrace appears between a couple hundred thousand lines of logging data :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39750>
_______________________________________

From report at bugs.python.org  Wed Feb 26 10:22:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 26 Feb 2020 15:22:03 +0000
Subject: [issue39760] ast.FormattedValue.format_spec unnecessarily wrapped in
 JoinedStr
In-Reply-To: <1582720982.96.0.367799860574.issue39760@roundup.psfhosted.org>
Message-ID: <1582730523.13.0.536670854487.issue39760@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that could probably be simplified, if the format_spec is constant (which it need not be).

>>> ast.dump(ast.parse('f"is {x:d}"'))

"Module(body=[Expr(value=JoinedStr(values=[Str(s='is '), FormattedValue(value=Name(id='x', ctx=Load()), conversion=-1, format_spec=JoinedStr(values=[Str(s='d')]))]))])"

But:

ast.dump(ast.parse('f"is {x:{length+1}d}"'))

"Module(body=[Expr(value=JoinedStr(values=[Str(s='is '), FormattedValue(value=Name(id='x', ctx=Load()), conversion=-1, format_spec=JoinedStr(values=[FormattedValue(value=BinOp(left=Name(id='length', ctx=Load()), op=Add(), right=Num(n=1)), conversion=-1, format_spec=None), Str(s='d')]))]))])"

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39760>
_______________________________________

From report at bugs.python.org  Wed Feb 26 11:05:28 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 26 Feb 2020 16:05:28 +0000
Subject: [issue39759] os.getenv documentation is misleading
In-Reply-To: <1582717466.93.0.921378424861.issue39759@roundup.psfhosted.org>
Message-ID: <1582733128.19.0.34288784889.issue39759@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I don't really have a preference regarding saying that `default` should be a string or not but the phrase should still be reworded to be less confusing.

In typeshed it's documented with a generic type: https://github.com/python/typeshed/blob/master/stdlib/3/os/__init__.pyi#L363.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39759>
_______________________________________

From report at bugs.python.org  Wed Feb 26 11:11:45 2020
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 26 Feb 2020 16:11:45 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582733505.23.0.67607034796.issue39689@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

On this loop:

for c in [b'\x01', b'\x7f', b'\xff', b'\x0f', b'\xf0']:
    self.assertTrue(struct.unpack('>?', c)[0])

It fails for the b'\xf0' case

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Wed Feb 26 11:32:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 16:32:27 +0000
Subject: [issue39760] ast.FormattedValue.format_spec unnecessarily wrapped in
 JoinedStr
In-Reply-To: <1582720982.96.0.367799860574.issue39760@roundup.psfhosted.org>
Message-ID: <1582734747.88.0.0736180545843.issue39760@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

FYI you can use ast CLI:

$ echo 'f"is {x:d}"' | ./python -m ast
Module(
   body=[
      Expr(
         value=JoinedStr(
            values=[
               Constant(value='is ', kind=None),
               FormattedValue(
                  value=Name(id='x', ctx=Load()),
                  conversion=-1,
                  format_spec=JoinedStr(
                     values=[
                        Constant(value='d', kind=None)]))]))],
   type_ignores=[])

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39760>
_______________________________________

From report at bugs.python.org  Wed Feb 26 11:56:28 2020
From: report at bugs.python.org (Marcel Plch)
Date: Wed, 26 Feb 2020 16:56:28 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
Message-ID: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>


New submission from Marcel Plch <mplch at redhat.com>:

Steps to reproduce:

$ wget https://www.python.org/ftp/python/3.9.0/Python-3.9.0a4.tar.xz
$ tar xvf Python-3.9.0a4.tar.xz
$ cd Python-3.9.0a4
$ ./configure --with-dtrace
$ make -j12
/usr/bin/ld: libpython3.9.a(ceval.o): in function `_PyEval_EvalFrameDefault':
/home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:1117: undefined reference to `python_function__entry_semaphore'
/usr/bin/ld: /home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:1254: undefined reference to `python_line_semaphore'
/usr/bin/ld: /home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:3697: undefined reference to `python_function__return_semaphore'
/usr/bin/ld: /home/mplch/Work/fedpkg/Python-3.9.0a4/Python/ceval.c:1445: undefined reference to `python_line_semaphore'

...

/usr/bin/ld: libpython3.9.a(gcmodule.o):(.note.stapsdt+0x70): undefined reference to `python_gc__done_semaphore'
collect2: error: ld returned 1 exit status
make: *** [Makefile:709: Programs/_testembed] Error 1


Additional info:
$ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

----------
components: Build
messages: 362700
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: Python 3.9.0a4 fails to build when configured with --with-dtrace
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 12:05:35 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 Feb 2020 17:05:35 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582736735.95.0.339036989533.issue39761@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I can reproduce this from git and will try to bisect the introducer.

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 12:08:07 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 26 Feb 2020 17:08:07 +0000
Subject: [issue39530] Documentation about comparisons between numeric types is
 misleading
In-Reply-To: <1580653054.78.0.127921454413.issue39530@roundup.psfhosted.org>
Message-ID: <1582736887.62.0.83946862996.issue39530@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There's a PR on GitHub. (GH-18615)

Terry: I think you've looked at similar sorts of documentation clarifications in the past. Would you have any interest in reviewing this one?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39530>
_______________________________________

From report at bugs.python.org  Wed Feb 26 12:28:16 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 Feb 2020 17:28:16 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582738096.97.0.581713695133.issue39761@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

aabdeb766b7fa581e7de01f3c953b12792f0736d is the first new commit
commit aabdeb766b7fa581e7de01f3c953b12792f0736d
Author: David Carlier <dcarlier at afilias.info>
Date:   Tue Jan 28 12:53:32 2020 +0000

    bpo-38960: DTrace build fix for FreeBSD. (GH-17451)
    
    DTrace build fix for FreeBSD.
    
    - allowing passing an extra flag as it need to define the arch size.
    - casting some probe's arguments.

 .../next/Core and Builtins/2019-12-03-16-41-22.bpo-38960.kvoFM0.rst | 1 +
 Python/ceval.c                                                      | 6 +++---
 Python/import.c                                                     | 4 ++--
 Python/sysmodule.c                                                  | 2 +-
 configure                                                           | 3 +--
 configure.ac                                                        | 3 +--
 6 files changed, 9 insertions(+), 10 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2019-12-03-16-41-22.bpo-38960.kvoFM0.rst

----------
nosy: +David Carlier, petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 12:45:40 2020
From: report at bugs.python.org (David Carlier)
Date: Wed, 26 Feb 2020 17:45:40 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582739140.39.0.71440778872.issue39761@roundup.psfhosted.org>


David Carlier <dcarlier at afilias.info> added the comment:

Sorry for the inconveniences. I can reproduce on FreeBSD too if I do not set the DFLAGS env var (because FreeBSD needs architecture bits in addition). What happens when make distclean && export DFLAGS="" && ./configure --with-dtrace ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:19:28 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 26 Feb 2020 18:19:28 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
Message-ID: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

While trying to port python 2 C extension code forward to python 3, I noticed that the python 2.6 PyInt -> PyLong unification lacks a forward-compatible API for PyLong_AS_LONG.

I'm not sure if this was intentional, but it is a slightly annoying wicket to deal with when forward C extension code that needs to straddle 2 and 3 for a period of time.

----------
components: C API
messages: 362705
nosy: ngie
priority: normal
severity: normal
status: open
title: PyLong_AS_LONG missing from longobject.h
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:21:11 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 26 Feb 2020 18:21:11 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582741271.9.0.63751956562.issue39762@roundup.psfhosted.org>


Enji Cooper <yaneurabeya at gmail.com> added the comment:

For the record, some projects (like Cython, pywin32) worked around this by adding a preprocessor alias, PyLong_AS_LONG -> PyInt_AS_LONG with python 2.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:23:27 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 26 Feb 2020 18:23:27 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582741407.86.0.430626342516.issue39762@roundup.psfhosted.org>


Enji Cooper <yaneurabeya at gmail.com> added the comment:

For the record, this seems like it might be the only discrepancy, per the py3c project's exported PyInt APIs:

$ for api in `awk '$2 ~ /^PyInt/ { print $3 }' include/py3c/compat.h`; do grep -q $api /usr/include/python2.7/longobject.h || echo $api; done
PyLong_AS_LONG

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:29:36 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 26 Feb 2020 18:29:36 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582741776.52.0.715180099031.issue39762@roundup.psfhosted.org>


Enji Cooper <yaneurabeya at gmail.com> added the comment:

Workaround PR posted here: https://github.com/encukou/py3c/pull/28

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:34:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 18:34:31 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582742071.06.0.660173194868.issue39762@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Python 2 is no longer supported.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:46:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 18:46:36 +0000
Subject: [issue8269] Missing return values for PyUnicode C/API functions
In-Reply-To: <1269991617.43.0.918560470794.issue8269@psf.upfronthosting.co.za>
Message-ID: <1582742796.86.0.0239366131197.issue8269@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry, we missed this issue.

refcounts.dat was updated in other issues.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8269>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:54:50 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 18:54:50 +0000
Subject: [issue31015] PyErr_WriteUnraisable should be more verbose in Python
 2.7
In-Reply-To: <1500907708.11.0.730292884872.issue31015@psf.upfronthosting.co.za>
Message-ID: <1582743290.47.0.533353543357.issue31015@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is too late for 2.7.

----------
nosy: +serhiy.storchaka
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31015>
_______________________________________

From report at bugs.python.org  Wed Feb 26 13:58:57 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 Feb 2020 18:58:57 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582743537.38.0.600008212018.issue39761@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

export DFLAGS="" does not seem to workaround this.

$ make distclean && export DFLAGS="" && ./configure --with-dtrace && make
...
undefined reference to `python_line_semaphore'
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:00:45 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 26 Feb 2020 19:00:45 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582743645.22.0.0792546504883.issue39762@roundup.psfhosted.org>


Enji Cooper <yaneurabeya at gmail.com> added the comment:

@serhiy.storchaka: understood. Figured this would be a good errata note for others to potentially find in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:09:15 2020
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 26 Feb 2020 19:09:15 +0000
Subject: [issue39754] update_one_slot() does not inherit sq_contains and
 mp_subscript if they are explictly declared
In-Reply-To: <1582661829.56.0.319745659558.issue39754@roundup.psfhosted.org>
Message-ID: <1582744155.61.0.706891768636.issue39754@roundup.psfhosted.org>


Change by Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39754>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:11:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 19:11:09 +0000
Subject: [issue22714] target of 'import statement' entry in general index for
 'i' is wrong
In-Reply-To: <1414125308.24.0.874909264609.issue22714@psf.upfronthosting.co.za>
Message-ID: <1582744269.94.0.461577274798.issue22714@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There are 5 links for the "import statement" entry. Issue35506 partially solved the problem -- the main link is now emphasized. But it is still the last of links. I afraid it is a limitation of Sphinx.

If no other solution be proposed I'll close this issue as "won't fix".

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22714>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:11:37 2020
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 26 Feb 2020 19:11:37 +0000
Subject: [issue34396] Certain methods that heap allocated subtypes inherit
 suffer a 50-80% performance penalty
In-Reply-To: <1534189001.92.0.56676864532.issue34396@psf.upfronthosting.co.za>
Message-ID: <1582744297.78.0.431097341125.issue34396@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

I asked why on StackOverflow, and an user seemed to find the reason. The problem for him/her is in `update_one_slot()`. 

`dict` implements directly `__contains__()` and `__getitem__()`. Usually, `sq_contains` and `mp_subscript` are wrapped to implement `__contains__()` and `__getitem__()`, but this way `dict` is a little faster.

The problem is that `update_one_slot()` searches for the wrappers. If it does not find them, it does not inherit the `__contains__()` and `__getitem__()` of the class, but create a `__contains__()` and `__getitem__()` functions that do an MRO search and call the superclass method. This is why `__contains__()` and `__getitem__()` of `dict` subclasses are slower.


Is it possible to modify `update_one_slot()` so that, if no wrapper is found, the explicit implementation is inherited?

SO answer: https://stackoverflow.com/a/59914459/1763602

----------
components: +C API -Interpreter Core
nosy: +Marco Sulla
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34396>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:16:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 19:16:10 +0000
Subject: [issue23164] "pydoc filter" documentation restrictive
In-Reply-To: <1420377572.43.0.335658121107.issue23164@psf.upfronthosting.co.za>
Message-ID: <1582744570.0.0.246271135618.issue23164@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was fixed in Python 3, and it is too late for 2.7.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23164>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:18:35 2020
From: report at bugs.python.org (Elad Lahav)
Date: Wed, 26 Feb 2020 19:18:35 +0000
Subject: [issue39763] Hang after fork due to logging trying to reacquire the
 module lock in an atfork() handler
Message-ID: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>


New submission from Elad Lahav <e2lahav at gmail.com>:

The attached code causes the child processes to hang on QNX. The hang is caused by the logging module trying to acquire the module lock while in an atfork() handler. In a system where semaphore state is kept in user mode and is thus inherited from the parent on fork() the semaphore may appear to have a value of 0, and thus will never be posted to in the single-threaded child.
I don't know how it works on other systems - may be pure chance.

----------
components: Library (Lib)
files: fork_mt.py
messages: 362717
nosy: Elad Lahav
priority: normal
severity: normal
status: open
title: Hang after fork due to logging trying to reacquire the module lock in an atfork() handler
versions: Python 3.8
Added file: https://bugs.python.org/file48917/fork_mt.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:19:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 19:19:15 +0000
Subject: [issue25397] improve ac_cv_have_long_long_format GCC fallback
In-Reply-To: <1444776658.15.0.414406307364.issue25397@psf.upfronthosting.co.za>
Message-ID: <1582744755.3.0.095374707552.issue25397@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is too later for 2.7. The long long type is required for recent Python 3 versions, so this macro is no longer used.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25397>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:21:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Feb 2020 19:21:47 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582744907.35.0.474480611601.issue39699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6aa1f1ecf7142a4117eedb8c570f30da1598616c by Ammar Askar in branch 'master':
bpo-39699: Don't silence make on Azure and Github CIs (GH-18583)
https://github.com/python/cpython/commit/6aa1f1ecf7142a4117eedb8c570f30da1598616c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:22:47 2020
From: report at bugs.python.org (David Carlier)
Date: Wed, 26 Feb 2020 19:22:47 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582744967.81.0.272675118686.issue39761@roundup.psfhosted.org>


David Carlier <dcarlier at afilias.info> added the comment:

What about DFFLAGS=" " ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:25:12 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 Feb 2020 19:25:12 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582745112.16.0.828006212418.issue39761@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Nope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:25:53 2020
From: report at bugs.python.org (Lidi Zheng)
Date: Wed, 26 Feb 2020 19:25:53 +0000
Subject: [issue39764] PyAsyncGenObject causes task.get_stack() raising
 AttributeError
Message-ID: <1582745153.24.0.421575819454.issue39764@roundup.psfhosted.org>


New submission from Lidi Zheng <lidiz at google.com>:

This issue exists since 3.6.

The implementation of get stack on Task is looking for two attribute [1]: "cr_frame" for coroutines, "gi_frame" for generators (legacy coroutines). However, PyAsyncGenObject provides none of them but "ag_frame" [2].

Fix PR: https://github.com/python/cpython/pull/18669

A simple reproduce:

    def test_async_gen_aclose_compatible_with_get_stack(self):
        async def async_generator():
            yield object()

        async def run():
            ag = async_generator()
            asyncio.create_task(ag.aclose())
            tasks = asyncio.all_tasks()
            for task in tasks:
                # No AttributeError raised
                task.get_stack()

        self.loop.run_until_complete


I found this in my project I want to view who created the Tasks.

[1] https://github.com/python/cpython/blob/21da76d1f1b527d62b2e9ef79dd9aa514d996341/Lib/asyncio/base_tasks.py#L27
[2] https://github.com/python/cpython/blob/21da76d1f1b527d62b2e9ef79dd9aa514d996341/Objects/genobject.c#L1329

----------
components: asyncio
messages: 362722
nosy: asvetlov, lidiz, yselivanov
priority: normal
pull_requests: 18025
severity: normal
status: open
title: PyAsyncGenObject causes task.get_stack() raising AttributeError
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39764>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:28:05 2020
From: report at bugs.python.org (David Carlier)
Date: Wed, 26 Feb 2020 19:28:05 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582745285.91.0.498537137114.issue39761@roundup.psfhosted.org>


David Carlier <dcarlier at afilias.info> added the comment:

Weird I just tried on ubuntu/systemtap...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:31:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Feb 2020 19:31:17 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582745477.18.0.918713055555.issue39699@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +18026
pull_request: https://github.com/python/cpython/pull/18670

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:31:23 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Feb 2020 19:31:23 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582745483.17.0.71461790222.issue39699@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +18027
pull_request: https://github.com/python/cpython/pull/18671

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:46:12 2020
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 26 Feb 2020 19:46:12 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582746372.49.0.121246180764.issue39698@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> I also distinctly remember seeing code (and writing such code myself) that performs computation on timeouts and does not care if the end value goes below 0.

This is not a good statistics. Frankly we can't measure the impact of the change from these considerations. And furthermore, `asyncio.sleep()` is used often, testing and mocking apart? I doubt it.

> we always try to have a very good explanation "why" we want to bother ourselves and users to break backwards compat.

Coherence and unhide mistakes are *very* strong points.

That said, I'm not so much interested in practice. Do as you wish. The problem is I always considered Python a very elegant programming language, and this behavior is not elegant at all. But, hey, amen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:46:37 2020
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 26 Feb 2020 19:46:37 +0000
Subject: [issue39698] asyncio.sleep() does not adhere to time.sleep() behavior
 for negative numbers
In-Reply-To: <1582199063.86.0.853270870549.issue39698@roundup.psfhosted.org>
Message-ID: <1582746397.57.0.416250868986.issue39698@roundup.psfhosted.org>


Change by Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:


----------
resolution: not a bug -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39698>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:57:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Feb 2020 19:57:20 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582747040.74.0.0185108540053.issue39699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 343bc06d8047e4a2e675394528dbb5155be1b3b5 by Steve Dower in branch '3.8':
bpo-39699: Don't silence make on Azure and Github CIs (GH-18583)
https://github.com/python/cpython/commit/343bc06d8047e4a2e675394528dbb5155be1b3b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Wed Feb 26 14:59:43 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Feb 2020 19:59:43 +0000
Subject: [issue39763] Hang after fork due to logging trying to reacquire the
 module lock in an atfork() handler
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582747183.72.0.223621455042.issue39763@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:01:54 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Feb 2020 20:01:54 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582747314.6.0.985709149702.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset d0ca9bd93bb9d8d4aa9bbe939ca7fd54ac870c8f by Brandt Bucher in branch 'master':
bpo-36144: Document PEP 584 (GH-18659)
https://github.com/python/cpython/commit/d0ca9bd93bb9d8d4aa9bbe939ca7fd54ac870c8f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:02:42 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 20:02:42 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582747362.11.0.551756934837.issue39762@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The reason why there was the PyInt_AS_LONG macro is that it is very simple and efficient. It never fails, because the value of the int object always fits in the C long. PyInt_AsLong is much slower. If you know that the object is int, you can use PyInt_AS_LONG for performance and simplicity.

In contrary, converting the long object to the C long value requires a loop and it can overflow. There is no reason to implement it as a macro. You can use the PyLong_AsLong function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:02:54 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Feb 2020 20:02:54 +0000
Subject: [issue39763] Hang after fork due to logging trying to reacquire the
 module lock in an atfork() handler
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582747374.83.0.872949143743.issue39763@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Note the original problem stems when you using "setup.py -j <NJOBS>".

The attached reproducer is a bit of a red herring, because indeed doing fork() + exec() in pure Python is too fragile.  That is why the standard subprocess does it in C.  The problem here is that the `distutils.spawn` module still has its hand-baked fork() + exec() pure Python code from the 1990s.

So the solution to the OP's actual problem should be to recode `distutils.spawn` using the subprocess module.

Original mailing-list discussion at:
https://mail.python.org/archives/list/python-dev at python.org/thread/PTJ3UAZNYBYBYQ4WLMSERZR2XIVWISLM/

----------
type:  -> behavior
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:03:22 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Feb 2020 20:03:22 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582747402.91.0.215574454352.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Brandt: you have some more followup PRs planned right? Let's keep this issue open until you've done all of those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:03:27 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Feb 2020 20:03:27 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582747407.27.0.410348720778.issue39763@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
title: Hang after fork due to logging trying to reacquire the module lock in an atfork() handler -> distutils.spawn should use subprocess (hang in parallel builds on QNX)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:06:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Feb 2020 20:06:27 +0000
Subject: [issue22947] Enable 'imageop' - "Multimedia Srvices Feature module"
 for 64-bit platform
In-Reply-To: <1417004311.93.0.975050094816.issue22947@psf.upfronthosting.co.za>
Message-ID: <1582747587.3.0.235853367191.issue22947@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Python 2.7 no longer supported.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22947>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:06:38 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 26 Feb 2020 20:06:38 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582747598.17.0.0622262733779.issue39763@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +dstufft, eric.araujo, p-ganssle, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:10:06 2020
From: report at bugs.python.org (Elad Lahav)
Date: Wed, 26 Feb 2020 20:10:06 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582747806.61.0.29363182759.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

I'm not convinced that a multi-threaded fork()+exec() from C would be any better, unless the Python code goes to great lengths to avoid any non-async-signal-safe operations between the fork() and the exec().
So along with the proposed change to switch to the subprocess() module I would like to propose that that module switch to using posix_spawn() instead of fork()+exec().

----------
type: behavior -> 
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:13:46 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Feb 2020 20:13:46 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582748026.29.0.798028657917.issue39763@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@Antoine: I can sort of see why you consider the small example a red herring, since it mixes threads and fork. Nevertheless, a simpler version (not using an executor) would probably work just fine? It's the edge cases where the mixture becomes explosive. So I still think there's something that could be improved in ThreadPoolExecutor.

@Elad: Your script contains a bug (there is no definition of 'exec_fn'). But anything that returns or raises from the child process does indeed hang.

Since I can repro this on macOS I do QNX is a red herring here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:44:54 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 Feb 2020 20:44:54 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582749894.1.0.709347083113.issue39761@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

$ make clean && make distclean
$ git clean -x
$ export DFLAGS=""
$ export DFFLAGS=""
$ ./configure --with-dtrace && make
...
undefined reference to `python_audit_semaphore'
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:46:52 2020
From: report at bugs.python.org (Roger Dahl)
Date: Wed, 26 Feb 2020 20:46:52 +0000
Subject: [issue39765] asyncio loop.set_signal_handler() may not behave as
 expected
Message-ID: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>


New submission from Roger Dahl <git at dahlsys.com>:

This is a ticket to document two ways in which the behavior of loop.set_signal_handler() may not match what the user expects.

First, callbacks to handlers registered with loop.set_signal_handler() may be significantly delayed. I have a program where I've encountered delays of up to maybe a minute or so between hitting Ctrl-C and getting the callback for the SIGINT handler. During this time, the program works through queued aiohttp tasks. Though it's possible to have delays in callbacks for events set with signal.signal(), I haven't personally seen that, and I think that's the case for most users. So I think this point should be included in the docs.

Second, set_signal_handler() silently and implicitly removes corresponding handlers set with signal.signal(). Though perhaps logical, this potentially removes a "fast" handler and replaces it with a "slow" one. I think this should be documented as well.

----------
components: asyncio
messages: 362734
nosy: asvetlov, rogerdahl, yselivanov
priority: normal
severity: normal
status: open
title: asyncio loop.set_signal_handler() may not behave as expected
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:52:05 2020
From: report at bugs.python.org (Roger Dahl)
Date: Wed, 26 Feb 2020 20:52:05 +0000
Subject: [issue39765] asyncio loop.set_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1582750325.06.0.729951554685.issue39765@roundup.psfhosted.org>


Change by Roger Dahl <git at dahlsys.com>:


----------
keywords: +patch
pull_requests: +18028
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18664

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:56:09 2020
From: report at bugs.python.org (David Carlier)
Date: Wed, 26 Feb 2020 20:56:09 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582750569.91.0.760686105289.issue39761@roundup.psfhosted.org>


David Carlier <dcarlier at afilias.info> added the comment:

ah sorry I meant DFLAGS=" " (with a space).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:56:24 2020
From: report at bugs.python.org (tzickel)
Date: Wed, 26 Feb 2020 20:56:24 +0000
Subject: [issue38066] Hide internal asyncio.Stream methods
In-Reply-To: <1568029115.61.0.532730850424.issue38066@roundup.psfhosted.org>
Message-ID: <1582750584.65.0.885419361119.issue38066@roundup.psfhosted.org>


tzickel <icebreak at yahoo.com> added the comment:

The documentation needs to scrub this methods as well, for example:

https://docs.python.org/3/library/asyncio-stream.html#asyncio.StreamReader.at_eof

still mentions them.

----------
nosy: +tzickel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38066>
_______________________________________

From report at bugs.python.org  Wed Feb 26 15:57:49 2020
From: report at bugs.python.org (David Carlier)
Date: Wed, 26 Feb 2020 20:57:49 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582750669.33.0.613010252258.issue39761@roundup.psfhosted.org>


David Carlier <dcarlier at afilias.info> added the comment:

If it works for you, it might mean making a specific case for Linux systems in configure.ac as a proper fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 16:02:09 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 26 Feb 2020 21:02:09 +0000
Subject: [issue39758] StreamWriter.wait_closed() can hang indefinitely.
In-Reply-To: <1582713366.75.0.743984348325.issue39758@roundup.psfhosted.org>
Message-ID: <1582750929.98.0.0759773496972.issue39758@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Can reproduce in:

- 3.8.0
- 3.8.2
- 3.7.6

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39758>
_______________________________________

From report at bugs.python.org  Wed Feb 26 16:05:29 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 26 Feb 2020 21:05:29 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582751129.06.0.139787278726.issue39761@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Oh, my bad.

DFLAGS=" "

^ that indeed works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 16:20:54 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 26 Feb 2020 21:20:54 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582752054.33.0.214580806146.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Yep. I'm currently working on OrderedDict, defaultdict, and MappingProxyType.

My brother is looking to make his first contribution, so he'll be taking care of ChainMap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Wed Feb 26 16:22:15 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 26 Feb 2020 21:22:15 +0000
Subject: [issue39760] ast.FormattedValue.format_spec unnecessarily wrapped in
 JoinedStr
In-Reply-To: <1582720982.96.0.367799860574.issue39760@roundup.psfhosted.org>
Message-ID: <1582752135.85.0.101771615893.issue39760@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> FYI you can use ast CLI:

I did not know that. That's awesome, thanks for pointing it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39760>
_______________________________________

From report at bugs.python.org  Wed Feb 26 16:26:29 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Feb 2020 21:26:29 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1582752389.13.0.501991212523.issue27657@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

FYI, for those following along, now that 3.8.2 has been released with the revert of the regression, we are planning to accelerate the schedule for 3.7.7, the next 3.7.x bugfix release, in part to get the revert out to 3.7.x users sooner (https://discuss.python.org/t/3-7-7-schedule-accelerated-cutoff-now-2020-03-02/3511).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Wed Feb 26 16:35:45 2020
From: report at bugs.python.org (Elad Lahav)
Date: Wed, 26 Feb 2020 21:35:45 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582752945.14.0.766196733804.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

"Your script contains a bug (there is no definition of 'exec_fn')"

Told you I wasn't much of a Python developer ;-) 
This was just copy-pasted from spawn.py and I missed the fact that exec_fn() is not a library function.

Your last comment wasn't clear - do you see this problem on macOS? Is it only after you fixed the example? For me it hangs with the bug, as the problem occurs before the call to exec_fn().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:01:11 2020
From: report at bugs.python.org (daniel hahler)
Date: Wed, 26 Feb 2020 22:01:11 +0000
Subject: [issue39766] unittest's assertRaises removes locals from tracebacks
Message-ID: <1582754471.69.0.783470624559.issue39766@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

I was a bit surprised to find that unittest's assertRaises clears the locals on the traceback, which e.g. prevents pytest to display them in case of failures.

This was done via https://bugs.python.org/issue9815 (https://github.com/python/cpython/commit/9681022f1ee5c6c9160c515b24d2a3d1efe8b90d).

Maybe this should only get done for expected failures, so that unexpected exceptions can be inspected better?

----------
components: Library (Lib)
messages: 362744
nosy: blueyed
priority: normal
severity: normal
status: open
title: unittest's assertRaises removes locals from tracebacks
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/issue39766>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:08:14 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Feb 2020 22:08:14 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582754894.24.0.478881766227.issue39699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 3bf9de2fb954bd1131f4f41517d7d5c316fb95f8 by Steve Dower in branch '3.7':
bpo-39699: Don't silence make on Azure and Github CIs (GH-18583)
https://github.com/python/cpython/commit/3bf9de2fb954bd1131f4f41517d7d5c316fb95f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:09:39 2020
From: report at bugs.python.org (Ryan Petrello)
Date: Wed, 26 Feb 2020 22:09:39 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1582754979.19.0.0123558527918.issue38884@roundup.psfhosted.org>


Ryan Petrello <ryan at ryanpetrello.com> added the comment:

I believe I'm also encountering some version of this bug while importing code from the kombu library within a multi-threaded context.

For what it's worth, I'm able to reproduce the reported deadlock (https://bugs.python.org/file48737/issue38884.zip) using python3.8 on RHEL8 and CentOS 8 builds.

More details about what I'm encountering here: https://github.com/ansible/awx/issues/5617
https://github.com/ansible/awx/issues/5617#issuecomment-591618205

My intended workaround for now is to just not use a thread (we'll see if it helps):

https://github.com/ansible/awx/pull/6093

----------
nosy: +ryan.petrello

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:17:19 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Feb 2020 22:17:19 +0000
Subject: [issue39765] asyncio loop.set_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1582755439.2.0.207922835059.issue39765@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I'm sorry. but loop.set_signal_handler() method doesn't exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:23:52 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Feb 2020 22:23:52 +0000
Subject: [issue39765] asyncio loop.add_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1582755832.62.0.0512316765951.issue39765@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Assuming you mean loop.add_signal_handler() method, I would say that a minute-long delay is a sign of long blocking calls in your program.

Typical asyncio program blocks the loop for 1-10 milliseconds at most, and signal handlers are called with this delay.
This is not your case as I see.

----------
title: asyncio loop.set_signal_handler() may not behave as expected -> asyncio loop.add_signal_handler() may not behave as expected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:23:52 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 26 Feb 2020 22:23:52 +0000
Subject: [issue39765] asyncio loop.set_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1582755832.62.0.0512316765951.issue39765@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Assuming you mean loop.add_signal_handler() method, I would say that a minute-long delay is a sign of long blocking calls in your program.

Typical asyncio program blocks the loop for 1-10 milliseconds at most, and signal handlers are called with this delay.
This is not your case as I see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:26:24 2020
From: report at bugs.python.org (Enji Cooper)
Date: Wed, 26 Feb 2020 22:26:24 +0000
Subject: [issue39762] PyLong_AS_LONG missing from longobject.h
In-Reply-To: <1582741168.61.0.124981854369.issue39762@roundup.psfhosted.org>
Message-ID: <1582755984.27.0.637972308686.issue39762@roundup.psfhosted.org>


Enji Cooper <yaneurabeya at gmail.com> added the comment:

PyInt_AS_LONG doesn't exist on python 3, however:

$ grep -r PyInt_AS_LONG /usr/include/
[/usr/include/python2.7/intobject.h:#define PyInt_AS_LONG(op) (((PyIntObject *)(op))->ob_ival)

The code smell for the pieces that use PyInt_AS_LONG seems a bit questionable since they're used as array indexes; I'll poke a bit more and look at using one of the other sets of C APIs instead in our project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39762>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:29:53 2020
From: report at bugs.python.org (Roger Dahl)
Date: Wed, 26 Feb 2020 22:29:53 +0000
Subject: [issue39765] asyncio loop.add_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1582756193.75.0.86289136775.issue39765@roundup.psfhosted.org>


Roger Dahl <git at dahlsys.com> added the comment:

> I'm sorry. but loop.set_signal_handler() method doesn't exist.

Oops, fixed.

> Assuming you mean loop.add_signal_handler() method, I would say that a minute-long delay is a sign of long blocking calls in your program.

During the delay for the callback to occur, I see my program logging work performed on other asyncio tasks and receiving timer events from another thread. So, not long blocking?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Wed Feb 26 17:36:58 2020
From: report at bugs.python.org (David CARLIER)
Date: Wed, 26 Feb 2020 22:36:58 +0000
Subject: [issue39761] Python 3.9.0a4 fails to build when configured with
 --with-dtrace
In-Reply-To: <1582736188.76.0.993881693157.issue39761@roundup.psfhosted.org>
Message-ID: <1582756618.88.0.827290330795.issue39761@roundup.psfhosted.org>


Change by David CARLIER <devnexen at gmail.com>:


----------
keywords: +patch
nosy: +devnexen
nosy_count: 4.0 -> 5.0
pull_requests: +18029
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18672

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39761>
_______________________________________

From report at bugs.python.org  Wed Feb 26 18:00:35 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Wed, 26 Feb 2020 23:00:35 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582758035.48.0.927344050427.issue39622@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

I have pushed an update to my PR. While implementing the new solution I made the following list:

Examples for code segments where KeyboardInterrupt must not be raised:
 - Between popping and running a handle from the ready queue (a handle is lost)
 - After running a handle and before a subsequent call_soon finished running (the handle that should have been added by call_soon is lost)
 - After a handle is popped from the _scheduled heap and added to the _ready queue (a handle is lost)

Code segments where KeyboardInterrupt must be raised:
 - During the select call (can be achieved using signal.default_int_handler or signal.set_wakeup_fd)
 - During a running callback (can be achieved using signal.default_int_handler)

I think that while the loop is running, the signal handler should not raise a KeyboardInterrupt by default, as there are at least 3 unsafe code segments, and more might be added in the future. Currently, the only two segments that have to be directly interrupted by a SIGINT are the ones listed above, and I think this behavior should be allowed explicitly.
This is what I did in the new revision of my PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Wed Feb 26 18:02:14 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 26 Feb 2020 23:02:14 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582758134.05.0.0231163860632.issue39763@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

When I run this on macOS, either with the bug, or with the buggy line commented out, I get the same hang. When I interrupt it, I get
 a separate traceback from each thread. Here's the full session:

Parent 78918
Parent 78919
Child 78918
Parent 78920
Child 78919
Parent 78921
Child 78920
Child 78921
  C-c C-cTraceback (most recent call last):
  File "tt.py", line 18, in <module>
    fut.result()
  File "/usr/local/lib/python3.8/concurrent/futures/_base.py", line 434, in result
    self._condition.wait(timeout)
  File "/usr/local/lib/python3.8/threading.py", line 302, in wait
    waiter.acquire()
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in _worker
    work_item = work_queue.get(block=True)
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in _worker
    work_item = work_queue.get(block=True)
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in _worker
    work_item = work_queue.get(block=True)
KeyboardInterrupt
Exception in worker
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 78, in _worker
    work_item = work_queue.get(block=True)
KeyboardInterrupt
Done 78918 78917
Done 78921 78917
Done 78919 78917
Done 78920 78917

(I added some prints to the script. Here's the script I ran:)

import os
from concurrent.futures import ThreadPoolExecutor

def new_process(arg):
    pid = os.fork()
    if pid == 0:
        print("Child", os.getpid())
        ## os.execl("/usr/bin/true", "/usr/bin/true")
    else:
        print("Parent", pid)
        pid, status = os.waitpid(pid, 0)
        print("Done", pid, os.getpid())

executor = ThreadPoolExecutor(max_workers=4)
futures = [executor.submit(new_process, None)
           for i in range(0, 4)]
for fut in futures:
    fut.result()

When I uncomment the os.execl() line, the program runs and completes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Wed Feb 26 18:25:22 2020
From: report at bugs.python.org (daniel hahler)
Date: Wed, 26 Feb 2020 23:25:22 +0000
Subject: [issue39766] unittest's assertRaises removes locals from tracebacks
In-Reply-To: <1582754471.69.0.783470624559.issue39766@roundup.psfhosted.org>
Message-ID: <1582759522.25.0.334609804611.issue39766@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

The test for issue9815 passes since bbd3cf8f1e (bpo-23890).

It seems like `traceback.clear_frames(tb)` should probably removed altogether?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39766>
_______________________________________

From report at bugs.python.org  Wed Feb 26 18:46:31 2020
From: report at bugs.python.org (Dariusz Trawinski)
Date: Wed, 26 Feb 2020 23:46:31 +0000
Subject: [issue39767] create multiprocessing.SharedMemory by pointing to
 existing memoryview
Message-ID: <1582760791.31.0.349985357098.issue39767@roundup.psfhosted.org>


New submission from Dariusz Trawinski <dtrawins at gmail.com>:

Currently, in order to share numpy array between processes via multiprocessing.SharedMemory object, it is required to copy the memory content with:
input = np.ones((1,10,10,10))
shm = shared_memory.SharedMemory(create=True, size=input.nbytes)
write_array = np.ndarray(input.shape, dtype=input.dtype,buffer=shm.buf)
write_array1[:] = input[:]
In result the original numpy array is duplicated in RAM. It also adds extra cpu cycles to copy the content.

I would like to recommend adding an option to create shared memory object by pointing it to existing memoryview object, beside current method of using shared memory name. 
Is that doable?

----------
components: C API
messages: 362754
nosy: Dariusz Trawinski
priority: normal
severity: normal
status: open
title: create multiprocessing.SharedMemory by pointing to existing memoryview
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39767>
_______________________________________

From report at bugs.python.org  Wed Feb 26 18:56:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Feb 2020 23:56:38 +0000
Subject: [issue39699] Some CIs silence potentially useful output from make
In-Reply-To: <1582201406.96.0.183994759448.issue39699@roundup.psfhosted.org>
Message-ID: <1582761398.41.0.181934952914.issue39699@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Had to disable the doctests in the 3.7 branch because I just couldn't get them passing. Pablo did the work for 3.8 and later though, so they're on for those.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39699>
_______________________________________

From report at bugs.python.org  Wed Feb 26 19:01:12 2020
From: report at bugs.python.org (Xinfa Zhu)
Date: Thu, 27 Feb 2020 00:01:12 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582761672.38.0.889679052979.issue38597@roundup.psfhosted.org>


Xinfa Zhu <xinfazhu at gmail.com> added the comment:

I have had wheel installed. Following this SO answer (https://stackoverflow.com/a/50314071/7269441), I added "import setuptools" before distutils (my setup.py attached).

Following is the log, where we see the VS path it is using. BTW, I am trying to reduce my package to <120 modules and test it.

(base) C:\Users\xinfa\Documents\code\ezcad-dev\beta>C:\Users\xinfa\AppData\Local\Continuum\anaconda3\python.exe setup.py build_ext
Include directory: C:\Users\xinfa\Documents\code\ezcad-dev\beta
Number of ext modules = 225
running build_ext
building 'ezcad.__main__' extension
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MT -IC:\Users\xinfa\Documents\code\ezcad-dev\beta -I. -IC:\Users\xinfa\AppData\Loca
l\Continuum\anaconda3\include -IC:\Users\xinfa\AppData\Local\Continuum\anaconda3\include "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\include" "-IC:\Program Files (x86)\Windows Kits
\10\include\10.0.18362.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.1836
2.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\cppwinrt" /Tcezcad\__main__.c /Fobuild\temp.win-amd64-3.7\Release\ezcad\__main__.obj
__main__.c
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\bin\HostX86\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /nodefaultlib:libucrt.lib ucrt.lib /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPAT
H:C:\Users\xinfa\AppData\Local\Continuum\anaconda3\libs /LIBPATH:C:\Users\xinfa\AppData\Local\Continuum\anaconda3\PCbuild\amd64 "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.24.28314\l
ib\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64" "/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64" build\temp.win-amd64-3.7\Release\ezcad\__main__.obj /OUT:build\lib.win
-amd64-3.7\ezcad\__main__.cp37-win_amd64.pyd
   Creating library build\lib.win-amd64-3.7\ezcad\__main__.cp37-win_amd64.lib and object build\lib.win-amd64-3.7\ezcad\__main__.cp37-win_amd64.exp
Generating code
Finished generating code
version = 0.1.9

----------
versions: +Python 3.7 -Python 3.6
Added file: https://bugs.python.org/file48918/setup.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Wed Feb 26 19:29:35 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 27 Feb 2020 00:29:35 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582763375.54.0.131156745175.issue36144@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

What is ChainMap going to do? Normally, the left-most argument to ChainMap is the "top level" dict, but in a regular union scenario, last value wins. 

Seems like layering the right hand side's dict on top of the left hand side's would match dict union semantics best, but it feels... wrong, given ChainMap's normal left-to-right precedence. And top-mostness affects which dict receives all writes, so if  chain1 |= chain2 operates with dict-like precedence (chain2 layers over chain1), then that also means the target of writes/deletions/etc. changes to what was on top in chain2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Wed Feb 26 19:37:12 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Thu, 27 Feb 2020 00:37:12 +0000
Subject: [issue15474] Differentiate decorator and decorator factory in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1582763832.62.0.28885885095.issue15474@roundup.psfhosted.org>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Hi, no I'm no longer working on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15474>
_______________________________________

From report at bugs.python.org  Wed Feb 26 19:56:25 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 00:56:25 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582764985.35.0.424039817352.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

The plan is to follow dict?s semantics. The |= operator will basically delegate to the first map in the chain. The | operator will create a new ChainMap where the first map is the merged result of the old first map, and the others are the same.

So, basically update / copy-and-update, respectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Wed Feb 26 20:07:04 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Feb 2020 01:07:04 +0000
Subject: [issue15474] Differentiate decorator and decorator factory in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1582765624.25.0.508480995325.issue15474@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks Andr?s.  

I'm going to close this one as it has been open for a long time and not attracted interest.  Also, in practice this ambiguity doesn't seem to be an issue and people almost universally refer to anything usable with the @-notation as a decorator.  Further, it has become common for tooling such as @lru_cache and @dataclass to be usable both with and without arguments, so the distinction no longer makes sense in some cases.

----------
nosy: +rhettinger
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15474>
_______________________________________

From report at bugs.python.org  Wed Feb 26 20:26:37 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 27 Feb 2020 01:26:37 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582766797.08.0.136948892225.issue36144@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Sorry, I think I need examples to grok this in the general case. ChainMap unioned with dict makes sense to me (it's equivalent to update or copy-and-update on the top level dict in the ChainMap). But ChainMap unioned with another ChainMap is less clear. Could you give examples of what the expected end result is for:

    d1 = {'a': 1, 'b': 2}
    d2 = {'b': 3, 'c': 4}
    d3 = {'a': 5, 'd': 6}
    d4 = {'d': 7, 'e': 8}
    cm1 = ChainMap(d1, d2)
    cm2 = ChainMap{d3, d4)

followed by either:

    cm3 = cm1 | cm2

or
    cm1 |= cm2

? As in, what is the precise state of the ChainMap cm3 or the mutated cm1, referencing d1, d2, d3 and d4 when they are still incorporated by references in the chain?

My impression from what you said is that the plan would be for the updated cm1 to preserve references to d1 and d2 only, with the contents of cm2 (d3 and d4) effectively flattened and applied as an in-place update to d1, with an end result equivalent to having done:

    cm1 = ChainMap(d1, d2)
    d1 |= d4
    d1 |= d3

(except the key ordering would actually follow d3 first, and d4 second), while cm3 would effectively be equivalent to having done (note ordering):

    cm3 = ChainMap(d1 | d4 | d3, d2)

though again, key ordering would be based on d1, then d3, then d4, not quite matching the union behavior. And a reference to d2 would be preserved in the final result, but not any other original dict. Is that correct? If so, it seems like it's wasting ChainMap's key feature (lazy accumulation of maps), where:

    cm1 |= cm2

could be equivalent to either:

    cm1.maps += cm2.maps

though that means cm1 wins overlaps, where normal union would have cm2 win, or to hew closer to normal union behavior, make it equivalent to:

    cm1.map[:0] = cm2.maps

prepending all of cm2's maps to have the same duplicate handling rules as regular dicts (right side wins) at the expense of changing which map cm1 uses as the target for writes and deletes. In either case it would hew to the spirit of ChainMap, making dict "union"-ing an essentially free operation, in exchange for increasing the costs of lookups that don't hit the top dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Wed Feb 26 21:57:01 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 02:57:01 +0000
Subject: [issue39768] remove tempfile.mktemp()
Message-ID: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

the tempfile.mktemp() function was deprecated since version 2.3; it's long ago (nearly 17 years)! It should be removed since it causes security holes, as stated in the tempfile doc (https://docs.python.org/3/library/tempfile.html#tempfile.mktemp).

----------
components: IO
messages: 362762
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: remove tempfile.mktemp()
type: security
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Wed Feb 26 22:02:15 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 03:02:15 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582772535.88.0.337380735448.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

A small typo in the 1st comment:
The tempfile.mktemp() function was deprecated since version 2.3; it's long ago (nearly 17 years!). It should be removed since it causes security holes, as stated in the tempfile doc (https://docs.python.org/3/library/tempfile.html#tempfile.mktemp).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Wed Feb 26 22:03:17 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 03:03:17 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582772597.57.0.238547196736.issue39768@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Wed Feb 26 23:38:54 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 27 Feb 2020 04:38:54 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582778334.87.0.776567777878.issue39768@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I think this is a duplicate of bpo-36309.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Wed Feb 26 23:45:59 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Feb 2020 04:45:59 +0000
Subject: [issue37497] Add inspect.Signature.from_text().
In-Reply-To: <1562199086.77.0.800086984204.issue37497@roundup.psfhosted.org>
Message-ID: <1582778759.62.0.630124027887.issue37497@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

What's the actual use case for exposing this functionality?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37497>
_______________________________________

From report at bugs.python.org  Wed Feb 26 23:49:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 27 Feb 2020 04:49:03 +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: <1582778943.05.0.960944729732.issue39087@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 02a4d57263a9846de35b0db12763ff9e7326f62c by Inada Naoki in branch 'master':
bpo-39087: Optimize PyUnicode_AsUTF8AndSize() (GH-18327)
https://github.com/python/cpython/commit/02a4d57263a9846de35b0db12763ff9e7326f62c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39087>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:18:06 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 05:18:06 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
Message-ID: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

Easiest to demonstrate as such:

```shell
#!/bin/bash

mkdir bug
touch bug/__init__.py
mkdir bug/foo
touch bug/foo/__init__.py
touch bug/foo/bar.py

python3 -m compileall -d "<prefix>" bug
python2 -m compileall -d "<prefix>" bug

echo "prefix embedded in PY3 pyc code object for lib.foo.bar:"
strings bug/foo/__pycache__/bar.cpython-3*.pyc | grep prefix
echo "prefix embedded in PY2 pyc code object for lib.foo.bar:"
strings bug/foo/bar.pyc | grep prefix
```

Run that script and you'll see:
Listing 'bug'...
Compiling 'bug/__init__.py'...
Listing 'bug/foo'...
Compiling 'bug/foo/__init__.py'...
Compiling 'bug/foo/bar.py'...
Listing bug ...
Compiling bug/__init__.py ...
Listing bug/__pycache__ ...
Listing bug/foo ...
Compiling bug/foo/__init__.py ...
Listing bug/foo/__pycache__ ...
Compiling bug/foo/bar.py ...
prefix embedded in PY3 pyc code object for lib.foo.bar:
<prefix>/bar.py
prefix embedded in PY2 pyc code object for lib.foo.bar:
<prefix>/foo/bar.pyt


Notice that the Python 3 pyc file contains a code.co_filename of "<prefix>/bar.py" instead of the correct value (that Python 2 inserts) of "<prefix>/foo/bar.py".

----------
messages: 362767
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: compileall.compile_dir(..., ddir="<prefix>") omits the intermediate package paths when prepending the prefix
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:20:15 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 05:20:15 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582780815.98.0.801821208944.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

This has probably been happening for many 3 releases.  I noticed it on 3.6 when investigating a problem with wrong paths in tracebacks coming from code which we used compileall.compile_dir(src_root, quiet=1, ddir="<prefix">) on.

I'm guessing ddir= (-d on the cli) isn't widely used?

----------
components: +Library (Lib)
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:26:22 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 05:26:22 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582781182.03.0.444571957316.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Sorry, didn't realize that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:28:59 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 05:28:59 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582781339.27.0.0132475825874.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

But I think the function should redirect to NamedTemporaryFile(delete=False).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:51:38 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 05:51:38 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582782698.37.0.155304487387.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

You could add a check that does this:
(a)
from tempfile import mktemp
with open(mktemp()) as f:
    # do something...

## No Warnings
(b)
from tempfile import mktemp
path = mktemp()
# do something...
with open(mktemp()) as f:
    # do something...

## RuntimeWarning: mktemp() is unsafe. Use NamedTemporaryFile(delete=False).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:56:10 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 05:56:10 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
Message-ID: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

The array_modexec function in Modules/arraymodule.c has a loop that calculates the number of elements in the descriptors array.  This size was used at one point, but is no longer.  The loop can be removed.

----------
components: Interpreter Core
messages: 362772
nosy: petdance
priority: normal
severity: normal
status: open
title: Remove unnecessary size calculation in array_modexec in Modules/arraymodule.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:57:22 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 05:57:22 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582783042.75.0.977290341498.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

(c)
from tempfile import mktemp
# do something...
path = mktemp()
# do something... (the "path" var is not used at all)

## No Warning

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:58:12 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 05:58:12 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582783092.58.0.050105433768.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +18031
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18673

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 00:59:41 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 05:59:41 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582783181.04.0.040346704677.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I think for `|=` the only choice is for it to be essentially an alias to `.update()`. So that means `cm |= other` becomes `cm.maps[0].update(other)`.

For `|` we are breaking new ground and we could indeed make `cm | other` do something like `ChainMap(other, *cm.maps)`.

I've not used ChainMap much (though I've seen some code that uses it) so I'm probably not the best judge of whether this is a good feature to have.

Note that `other | cm` will just do whatever `other.__or__` does, since ChainMap isn't a true subclass of dict, so it will not fall back to `cm.__ror__`. Basically ChainMap will not get control in this case.

Other thoughts:

- Maybe `cm1 | cm2` (both ChainMaps) ought to return `ChainMap(*cm2.maps, *cm1.maps)`?

- These semantics make `|=` behave rather differently from `|`. Is that okay? If not, which of them should change, and how?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:04:16 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:04:16 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582783456.95.0.987796640674.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18032
pull_request: https://github.com/python/cpython/pull/18674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:04:41 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 06:04:41 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582783481.36.0.637782826013.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

case c is used for the case that is stated in https://mail.python.org/pipermail/python-dev/2019-March/156725.html (a
temporary name that an other program will create / act on).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:06:02 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 06:06:02 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582783562.4.0.997114142747.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

I know it's hard to achieve :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:08:25 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 06:08:25 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582783705.11.0.0371988274958.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Sorry, in (a)(b) is should be with "open(mktemp(),'x') as f:".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:14:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Feb 2020 06:14:00 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582784040.26.0.0794611766067.issue39768@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Remove tempfile.mktemp()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:32:49 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:32:49 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785169.34.0.748070734922.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18033
pull_request: https://github.com/python/cpython/pull/18675

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:33:57 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:33:57 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785237.35.0.296631496492.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -18032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:34:05 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:34:05 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785245.89.0.469982415301.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -18031

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:36:28 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 06:36:28 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582785388.81.0.167977917758.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Reopen.
1.See https://mail.python.org/pipermail/python-dev/2019-March/156765.html and https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File. It's *serious*.
2.Why not use this to generate a
temporary name that an other program will create/act on?
import secrets
path = f"{x}{secrets.token_hex(n)}" # n is an large int
                                    # x is a path like "/tmp"
# do something...

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:37:09 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:37:09 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785429.81.0.61626002135.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18034
pull_request: https://github.com/python/cpython/pull/18674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:37:19 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:37:19 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785439.48.0.150717003177.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18035
pull_request: https://github.com/python/cpython/pull/18673

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:37:49 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:37:49 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785469.0.0.448238098669.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -18034

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:38:00 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 27 Feb 2020 06:38:00 +0000
Subject: [issue39770] Remove unnecessary size calculation in array_modexec in
 Modules/arraymodule.c
In-Reply-To: <1582782970.67.0.345827847271.issue39770@roundup.psfhosted.org>
Message-ID: <1582785480.24.0.750405783159.issue39770@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -18035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39770>
_______________________________________

From report at bugs.python.org  Thu Feb 27 01:41:10 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 06:41:10 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582785670.17.0.141112483038.issue39768@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
nosy:  -ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 02:04:31 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 07:04:31 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582787071.25.0.714591248026.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> I think for `|=` the only choice is for it to be essentially an alias to `.update()`. So that means `cm |= other` becomes `cm.maps[0].update(other)`.

Agreed.

> These semantics make `|=` behave rather differently from `|`. Is that okay? If not, which of them should change, and how?

I don?t like this. Let me try to explain why:

So far (and to the best of my knowledge), setting and updating values on a ChainMap works exactly the same as it does for dict, with all of the same semantics (the docs themselves even say that ?all of the usual dictionary methods are supported?? which now could be interpreted as meaning | and |= as well). It?s only when deleting or using the new interfaces that things get more specialized.

But that doesn?t really apply here. Having different (or worse, inconsistent) behavior for these operators, I feel, would be more confusing than helpful. Remember, a major goal of this proposal is to aid in duck typing.

So, Josh?s understanding of my intended semantics is correct, I propose that, for:

    d1 = {'a': 1, 'b': 2}
    d2 = {'b': 3, 'c': 4}
    d3 = {'a': 5, 'd': 6}
    d4 = {'d': 7, 'e': 8}
    cm1 = ChainMap(d1, d2)
    cm2 = ChainMap{d3, d4)

    cm3 = cm1 | cm2

Gives cm3 a value of:

    ChainMap(d1 | d4 | d3, d2)  # Or, equivalently: ChainMap(d1 | dict(cm2), d2)

And:

    cm1 |= cm2

Is equivalent to:

    d1 |= cm2

I don?t want to change which map is "first", and I think changing the winning behavior from that of dict will create more problems than it solves. We only need to look at how ChainMap handles the update method? it keeps the same exact behavior, rather than trying to be lazy or reversed or something.

If we *are* deciding to do something different, then I think it should have no relationship to PEP 584, which reasons out a carefully considered merge operation for dict, not ChainMap. But, it would also probably need a different operator, and be able to stand on its own merits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 02:12:32 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Thu, 27 Feb 2020 07:12:32 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
Message-ID: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>


New submission from hwgdb Smith <hwgdb123 at gmail.com>:

here is the partial code:
    msg = EmailMessage()
    file_name = "?e?3000P.csv"
    ctype, encoding = mimetypes.guess_type(file_name)
    if ctype is None or encoding is not None:
        ctype = "application/octet-stream"
    maintype, subtype = ctype.split("/", 1)

    with open(file_name, "rb") as f:
        msg.add_attachment(f.read(), maintype=maintype, subtype=subtype, filename=("GBK", "", f"{file_name}"))


The file has non-ascii characters name, so I use the three tuple filename with encode GBK, but msg.as_string() doesn't change. 
print(msg.as_string()) I find the filename is  'filename*=utf-8\'\'%E8%B6 ......'. The encoding is not correct. And of course, after send the message, I saw the attached file's filename displayed incorrect on my mail client or web mail.
But when i use the legacy API, and using the Header class to generate the filename, it works.

----------
components: email
messages: 362780
nosy: barry, hwgdb Smith, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.add_header doesn't work
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 02:24:22 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Thu, 27 Feb 2020 07:24:22 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582788262.03.0.454222521933.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

"but msg.as_string() doesn't change. " , I mean using 

  filename=file_name  
or
  filename=("GBK", "", f"{file_name}")
or
  filename=("utf-8", "", f"{file_name}")

msg.as_string() doesn't change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 02:30:37 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 07:30:37 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582788637.4.0.0788069316215.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Ironically 3.9a4 gains some compileall enhancements that could be used as an awkward workaround from https://bugs.python.org/issue38112:

python 2.7 compile_dir(d, ddir="<foo>") behavior can be had with
python 3.9a4 compile_dir(d, prependdir="<foo>", stripdir=d)

I still intend to fix the actual ddir behavior as it is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 02:33:08 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 07:33:08 +0000
Subject: [issue38112] Compileall improvements
In-Reply-To: <1568210479.53.0.901531773072.issue38112@roundup.psfhosted.org>
Message-ID: <1582788788.32.0.721107002721.issue38112@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

https://bugs.python.org/issue39769 may be of interest.  compileall's ddir= does not behave properly in recursive subdirectories, it did the right thing in 2.7 which is similar to a combination of compile_dir(dir, prependdir=ddir, stripdir=dir) after this issue's feature.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38112>
_______________________________________

From report at bugs.python.org  Thu Feb 27 02:57:19 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 07:57:19 +0000
Subject: [issue39772] Python 2 FAQ shown in help@python.org auto reply
Message-ID: <1582790239.29.0.848001765747.issue39772@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

The auto-reply from help at python contains this:

The Python FAQ is available at

        http://docs.python.org/2/faq/index.html

Why is it .org/2/faq, not .org/3/faq?

----------
components: email
files: email.png
messages: 362784
nosy: barry, r.david.murray, wyz23x2
priority: normal
severity: normal
status: open
title: Python 2 FAQ shown in help at python.org auto reply
Added file: https://bugs.python.org/file48919/email.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39772>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:02:00 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 08:02:00 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582790520.2.0.645855093619.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

The regression was caused by the parallelization enhancement implementation from https://bugs.python.org/issue16104

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:02:38 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 08:02:38 +0000
Subject: [issue16104] Compileall script: add option to use multiple cores
In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za>
Message-ID: <1582790558.71.0.960527548218.issue16104@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

This caused a regression in behavior.  compileall.compile_dir()'s ddir= parameter no longer does the right thing for any subdirectories.

https://bugs.python.org/issue39769

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16104>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:02:58 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 08:02:58 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582790578.17.0.0756572481263.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

meaning this regression was introduced in 3.5.

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:04:38 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 08:04:38 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582790678.4.0.0401851861274.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

belated postmortem: if there had been tests against the filename encoded in the pycs living in subdirs as generated by compile_dir, this regression would not have happened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:08:41 2020
From: report at bugs.python.org (David Hewitt)
Date: Thu, 27 Feb 2020 08:08:41 +0000
Subject: [issue39773] Export symbols for vectorcall
Message-ID: <1582790921.68.0.338373290894.issue39773@roundup.psfhosted.org>


New submission from David Hewitt <david.hewitt.92 at gmail.com>:

I have been looking into using vectorcall in [pyo3](https://github.com/PyO3/pyo3) (Rust bindings to Python) against python3.8.

It looks like the _PyObject_Vectorcall symbols are not included in the shared library. I've checked both Windows and Linux.

I think the `static inline` definition of `PyObject_Vectorcall` and related functions in `abstract.h` means that they won't be exported as symbols in the final library?

----------
messages: 362789
nosy: David Hewitt
priority: normal
severity: normal
status: open
title: Export symbols for vectorcall
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39773>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:09:35 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 27 Feb 2020 08:09:35 +0000
Subject: [issue39772] Python 2 FAQ shown in help@python.org auto reply
In-Reply-To: <1582790239.29.0.848001765747.issue39772@roundup.psfhosted.org>
Message-ID: <1582790975.42.0.171672803881.issue39772@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
nosy:  -barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39772>
_______________________________________

From report at bugs.python.org  Thu Feb 27 03:47:19 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 08:47:19 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582793239.23.0.676919260417.issue39769@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +18036
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18676

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Thu Feb 27 04:06:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Feb 2020 09:06:01 +0000
Subject: [issue39773] Export symbols for vectorcall
In-Reply-To: <1582790921.68.0.338373290894.issue39773@roundup.psfhosted.org>
Message-ID: <1582794361.81.0.730120494077.issue39773@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39773>
_______________________________________

From report at bugs.python.org  Thu Feb 27 04:53:08 2020
From: report at bugs.python.org (igo95862)
Date: Thu, 27 Feb 2020 09:53:08 +0000
Subject: [issue39774] Missing documentation on how to make package executable
 as script
Message-ID: <1582797188.41.0.932040725136.issue39774@roundup.psfhosted.org>


New submission from igo95862 <igo9586 at gmail.com>:

This is package documentation: https://docs.python.org/3/tutorial/modules.html#packages


To make package executable (python -m package) you need to create a file __main__.py  in the package directory.


This is pretty much not documented anyone aside of trying to run a package missing __main__.py


This page already contains information on how to make module executable. (https://docs.python.org/3/tutorial/modules.html#executing-modules-as-scripts)

----------
assignee: docs at python
components: Documentation
messages: 362790
nosy: docs at python, igo95862
priority: normal
severity: normal
status: open
title: Missing documentation on how to make package executable as script
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39774>
_______________________________________

From report at bugs.python.org  Thu Feb 27 05:26:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 27 Feb 2020 10:26:26 +0000
Subject: [issue39774] Missing documentation on how to make package executable
 as script
In-Reply-To: <1582797188.41.0.932040725136.issue39774@roundup.psfhosted.org>
Message-ID: <1582799186.46.0.396800942142.issue39774@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You're right that it's hard to find any documentation on package `__main__.py` files. There's nothing here that I can see:

https://docs.python.org/3/reference/import.html#packages

Aside from the tutorial, the only other place I can find it referenced is a really brief aside here:

https://docs.python.org/3/library/__main__.html

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39774>
_______________________________________

From report at bugs.python.org  Thu Feb 27 06:17:32 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Thu, 27 Feb 2020 11:17:32 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582802252.56.0.494850482577.issue39771@roundup.psfhosted.org>


Andrei Daraschenka <dorosch.github.io at yandex.ru> added the comment:

Hello, could you please attach minimal-work file for reproduce it?

----------
nosy: +dorosch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 06:27:01 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 27 Feb 2020 11:27:01 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582802821.53.0.331934204776.issue39768@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 06:39:02 2020
From: report at bugs.python.org (Andrei Daraschenka)
Date: Thu, 27 Feb 2020 11:39:02 +0000
Subject: [issue39774] Missing documentation on how to make package executable
 as script
In-Reply-To: <1582797188.41.0.932040725136.issue39774@roundup.psfhosted.org>
Message-ID: <1582803542.13.0.895200471696.issue39774@roundup.psfhosted.org>


Change by Andrei Daraschenka <dorosch.github.io at yandex.ru>:


----------
keywords: +patch
nosy: +dorosch
nosy_count: 3.0 -> 4.0
pull_requests: +18037
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18677

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39774>
_______________________________________

From report at bugs.python.org  Thu Feb 27 07:55:22 2020
From: report at bugs.python.org (Xinfa Zhu)
Date: Thu, 27 Feb 2020 12:55:22 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582808122.72.0.950238719219.issue38597@roundup.psfhosted.org>


Xinfa Zhu <xinfazhu at gmail.com> added the comment:

FYI when I reduced my package to 106 extension modules, I could run without the DLL error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:14:46 2020
From: report at bugs.python.org (Elad Lahav)
Date: Thu, 27 Feb 2020 13:14:46 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582809286.53.0.694288372273.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

"When I uncomment the os.execl() line, the program runs and completes."

In that case I'm not sure it is the same issue. The child processes in your case executed their part of the new_process function, which then returned. Nevertheless from the trace it looks like none of the children exited. So you are not hitting the logging lock issue, but may be hitting a similar problem in another module.

Is the logging module always enabled, or does it depend on the environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:16:35 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 27 Feb 2020 13:16:35 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582809395.68.0.375355504952.issue38597@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, it does seem like it's finding the correct MSVC, but is not finding the redistributable DLL:

> cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MT ...

The "/MT" means to statically the CRT, and then we use link settings later to dynamically link the part installed in the OS (see https://stevedower.id.au/blog/building-for-python-3-5-part-two for more details).

The problem seems to be that this glob in distutils can't find the path listed below it:

"2019\BuildTools\VC\redist\MSVC\**\x64\Microsoft.VC14*.CRT\vcruntime140.dll"

"2019\BuildTools\VC\Redist\MSVC\14.24.28127\x64\Microsoft.VC142.CRT\vcruntime140.dll"

We swallow a lot of errors while doing this glob, so I assume there's something about your install that's affecting it (maybe related to it being BuildTools rather than Community or higher?)

Could you try running this code and see what result/error you get:

import glob
glob.glob(r"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\redist\MSVC\**\x64\Microsoft.VC14*.CRT\vcruntime140.dll", recursive=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:19:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 27 Feb 2020 13:19:36 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1582809576.81.0.973756653876.issue38597@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Hmm, just ran it on my own and it's finding the OneCore file first, which is not a problem (yet) but could become one.

So we at least need to replace the "**" with a "*" in Lib/distutils/_msvccompiler.py#L109. Not sure if that will help in this other case or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38597>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:21:11 2020
From: report at bugs.python.org (zd nex)
Date: Thu, 27 Feb 2020 13:21:11 +0000
Subject: [issue39672] SIGSEGV crash on shutdown with shelve & c pickle
In-Reply-To: <1582019462.33.0.255360625193.issue39672@roundup.psfhosted.org>
Message-ID: <1582809671.52.0.924542847875.issue39672@roundup.psfhosted.org>


zd nex <zdnexnet at gmail.com> added the comment:

Hi,

i was looking on failing tests on attached pull request and it seems to me that it intentionally should create new entry for saving.

Maybe that save should actually happen, but it should be fixed in different way? From my small tests I was thinking that problem was actually in pickle, but maybe it is connected to shelve itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39672>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:28:02 2020
From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0J/QsNGA0LjQtdCy?=)
Date: Thu, 27 Feb 2020 13:28:02 +0000
Subject: [issue39636] Can't change Treeview row color in Tkinter
In-Reply-To: <1581764507.66.0.693125881903.issue39636@roundup.psfhosted.org>
Message-ID: <1582810082.2.0.775321237456.issue39636@roundup.psfhosted.org>


???? ?????? <oleg.pariev at gmail.com> added the comment:

I figured out the problem myself. I found out that the problem was in the topic that I used for Tkinter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39636>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:41:48 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 27 Feb 2020 13:41:48 +0000
Subject: [issue23080] BoundArguments.arguments should be unordered
In-Reply-To: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za>
Message-ID: <1582810908.97.0.521538836773.issue23080@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

Done in bugs.python.org/issue36350 / https://github.com/python/cpython/pull/12412.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23080>
_______________________________________

From report at bugs.python.org  Thu Feb 27 08:47:39 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 27 Feb 2020 13:47:39 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
Message-ID: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

https://bugs.python.org/issue36350 / https://github.com/python/cpython/pull/12412 changed Signature.parameters and BoundArguments.arguments to be plain dicts, not OrderedDicts (for Py3.9a4).  Even though I agree for BoundArguments.arguments (in fact I argued for this behavior in https://bugs.python.org/issue23080), I think Signature.parameters should remain OrderedDicts.  Otherwise, one would get

    >>> inspect.signature(lambda x, y: None).parameters == inspect.signature(lambda y, x: None).parameters
    True

which seems plain wrong (comparing the signature objects themselves still correctly return False because __eq__ explicitly considers parameter order, but one may e.g. want to compare parameters for equality while ignoring the return annotation).

----------
components: Library (Lib)
messages: 362800
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: inspect.Signature.parameters should be an OrderedDict, not a plain dict
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39775>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:15:37 2020
From: report at bugs.python.org (Julien Castiaux)
Date: Thu, 27 Feb 2020 14:15:37 +0000
Subject: [issue39757] EmailMessage wrong encoding for international domain
In-Reply-To: <1582709775.3.0.571538664603.issue39757@roundup.psfhosted.org>
Message-ID: <1582812937.3.0.212802282445.issue39757@roundup.psfhosted.org>


Julien Castiaux <julien.castiaux at gmail.com> added the comment:

Duplicate of https://bugs.python.org/issue39757

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39757>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:17:13 2020
From: report at bugs.python.org (Julien Castiaux)
Date: Thu, 27 Feb 2020 14:17:13 +0000
Subject: [issue39757] EmailMessage wrong encoding for international domain
In-Reply-To: <1582709775.3.0.571538664603.issue39757@roundup.psfhosted.org>
Message-ID: <1582813033.91.0.935438559513.issue39757@roundup.psfhosted.org>


Julien Castiaux <julien.castiaux at gmail.com> added the comment:

Woops wrong copie/paste, here is the correct link: https://bugs.python.org/issue11783

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39757>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:40:43 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 27 Feb 2020 14:40:43 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582814443.13.0.912999638666.issue38380@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I've updated these patches to sqlite3-3.30.1 (https://www.sqlite.org/releaselog/3_30_1.html).

cpython-source-deps is updated (https://github.com/python/cpython-source-deps/pull/17).

CPython commits are updated and rebased onto current 3.9 master: https://github.com/erlend-aasland/cpython/tree/fix-issue-38380


(Since Oct 2019, SQLite 3.31 have been released, but that would probably require opening a new issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:43:56 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Thu, 27 Feb 2020 14:43:56 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582814636.09.0.866101025346.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

I have uploaded just now. Thank you.

----------
Added file: https://bugs.python.org/file48920/email bug.rar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:48:42 2020
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Feb 2020 14:48:42 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582814922.78.0.473305646032.issue39771@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think you are saying that you want the charset in the encoded filename to be GBK rather than utf-8?  utf-8 should certainly display correctly in your email client, though, so if it is not there is something else going wrong.  

As far as the 3 tuple not working to set the charset...I believe what is happening there is that a header created by the application gets "refolded" on serialization, and refolding doesn't keep the existing charset, it converts everything to utf-8.  This is an intentional part of the design: the library handles the gory details of MIME and uses utf-8 as the charset for application created content.  It is actually an accident of the implementation that the tuple form of the filename is even accepted; you will note that it is *not* documented in the contentmanager docs.

It wouldn't be crazy to ask for this as a feature, and it could even be treated as a bug that it doesn't work if we want to, but it may not be easy to "fix", because it goes against the design philosophy of the new API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:56:08 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 27 Feb 2020 14:56:08 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582815368.14.0.172882897166.issue38380@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Added file: https://bugs.python.org/file48921/0001-bpo-38380-Update-macOS-installer-to-use-SQLite-3.30.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:56:24 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 27 Feb 2020 14:56:24 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582815384.93.0.662346066049.issue38380@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Added file: https://bugs.python.org/file48922/0002-bpo-38380-Update-Windows-builds-to-use-SQLite-3.30.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Thu Feb 27 09:57:04 2020
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Feb 2020 14:57:04 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582815424.9.0.579978958955.issue39771@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Actually, given that the contentmanager does accept a charset parameter for text content, it does seem reasonable to treat this as a bug.  But as I said fixing it may not be trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:00:06 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 27 Feb 2020 15:00:06 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582815606.86.0.759613271862.issue38380@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +18038
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18678

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:25:13 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Thu, 27 Feb 2020 15:25:13 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
Message-ID: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>


New submission from Evgeny Boytsov <boytsovea at yandex.ru>:

Hello everybody!

We are using Python 3.7 running at CentOS 7 x64. Python is used as a library to create dynamic extensions for our app server. 

Some time ago we began to experience crashes in decimal module in some heavy-multithreaded scenarios. After some testing and debugging I was able to reproduce it without our own code using only pybind11 library to simplify embedding (in real app we are using boost.python).


I've built python 3.8 with clang 7 and address sanitizer enabled and got error "use-after-free" with some additional data.

Please find attached C++ source file, python module and ASAN output. Is it really a bug (most probably - data race) or there is something wrong with such embedding scenario?

----------
components: Interpreter Core
files: decimal_crash.zip
messages: 362807
nosy: boytsovea
priority: normal
severity: normal
status: open
title: Crash in decimal module in heavy-multithreaded scenario
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48923/decimal_crash.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:31:58 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Thu, 27 Feb 2020 15:31:58 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582817518.24.0.138996786246.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

Using utf-8 doesn't display correctly on my mail client.
So i thought it might work using GBK, and I try to change the Content-Disposition filename using GBK.
And just now, I print the legacy Api MIMEMultipart.as_string(), I found it using utf-8 too. The difference is 
legacy api:  filename="=?utf-8?b?6LaFZeS/nTMwMDBQLmNzdg==?="   
EmailMessage: filename*=utf-8''.%2F%E8%B6%85e%E4%BF%9D3000P.csv

So it is not the encoding cause the display error. But I still don't know why? Base64?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:33:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Feb 2020 15:33:45 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582817625.28.0.86514170699.issue39768@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

wyz23x2, why do you think that this is not a duplicate of issue36309?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:43:45 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 15:43:45 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1582787071.25.0.714591248026.issue36144@roundup.psfhosted.org>
Message-ID: <CAP7+vJLY8wBcMNRBBiPBR5_ZQDu5O1F68gWAaQPCS7F-9=Qv8w@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I had just come to a different conclusion. Maybe ChainMap should just not
grow `|` and `|=` operators? That way there can be no confusion. `dict() |
ChainMap()` and `ChainMap() | dict()` will fail because ChainMap doesn't
inherit from dict. (Note that in your last message, `d1 |= cm2` will fail
for this reason. You can of course fix that with `d1 |= dict(cm2)`,
although IIUC there's no reason one of the maps couldn't be some other
[Mutable]Mapping.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:49:10 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 27 Feb 2020 15:49:10 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582818550.79.0.353165468311.issue39689@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The call:
    struct.unpack('>?', b'\xf0')
means to unpack a "native bool", i.e. native size and alignment. Internally, this does:

    static PyObject *
    nu_bool(const char *p, const formatdef *f)
    {
        _Bool x;
        memcpy((char *)&x, p, sizeof x);
        return PyBool_FromLong(x != 0);
    }

i.e., copies "sizeof x" (1 byte) of memory to a temporary buffer x, and then treats that as _Bool.

While I don't have access to the C standard, I believe it says that assignment of a true value to _Bool can coerce to a unique "true" value. It seems that if a char doesn't have the exact bit pattern for true or false, casting to _Bool is undefined behavior. Is that correct?

Clang 10 on s390x seems to take advantage of this: it probably only looks at the last bit(s) so a _Bool with a bit pattern of 0xf0 turns out false.
But the tests assume that 0xf0 should unpack to True.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:55:53 2020
From: report at bugs.python.org (SilentGhost)
Date: Thu, 27 Feb 2020 15:55:53 +0000
Subject: [issue39757] EmailMessage wrong encoding for international domain
In-Reply-To: <1582709775.3.0.571538664603.issue39757@roundup.psfhosted.org>
Message-ID: <1582818953.61.0.904272008074.issue39757@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
superseder:  -> email parseaddr and formataddr should be IDNA aware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39757>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:57:36 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 27 Feb 2020 15:57:36 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582819056.39.0.67776239808.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Before I look at the example code: Can you also reproduce this with
Python 3.6?  The threading code in _decimal was changed to a ContextVar
in 3.7.

There's a high chance though that the problem is in the c++ module.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Thu Feb 27 10:57:52 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 15:57:52 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582819072.91.0.675459966939.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> Note that in your last message, `d1 |= cm2` will fail for this reason. You can of course fix that with `d1 |= dict(cm2)`, although IIUC there's no reason one of the maps couldn't be some other [Mutable]Mapping.

Mappings and iterables are fine for the in-place variant. :)

>>> from collections import ChainMap
>>> d = {}
>>> c = ChainMap({"r": 2, "d":2})
>>> d |= c
>>> d
{'r': 2, 'd': 2}

I think it would be confusing to have `ChainMap | ChainMap` behave subtly different than `dict | ChainMap`. It would be *especially* odd if it also differed subtly from `ChainMap | dict`.

To recap:

+1 on adding the operators with dict semantics,
+0 on no PEP 584 for ChainMap.
-0 on implementing them, but changing the winning behavior by concatenating the maps lists or something. This would probably make more sense to me as a `+` operator, honestly. :(
-1 for having the operators behave differently (other than performance shortcuts) for `cm | d`, `cm | cm`, `cm |= d`, `cm |= cm`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 11:09:44 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Thu, 27 Feb 2020 16:09:44 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582819784.66.0.988937873347.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

Why there are two different representations of the same file name?  It displays incorrectly when use the EmailMessage API filename representation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 11:32:48 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 27 Feb 2020 16:32:48 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582821168.91.0.778257387599.issue39689@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

C compiler dev that it's indeed undefined behavior.

> Quick and obvious fix:
> 
>       static PyObject *
>       nu_bool(const char *p, const formatdef *f)
>       {
>           char x;
>           memcpy((char *)&x, p, sizeof x);
>           return PyBool_FromLong(x != 0);
>       }
>
> Which is optimized to
>
>     static PyObject *
>     nu_bool(const char *p, const formatdef *f)
>     {
>         return PyBool_FromLong(*p != 0);
>     }


I'm left with a question for CPython's struct experts:

The above would be my preferred fix, but the Python code is asking to convert a memory buffer to bool *using platform-specific semantics*.
Is this fix OK if C treats a \xf0 _Bool as falsey?


(Also, this assumes size of _Bool is the same as size of char.
I guess we can add a build-time assertion for that, and say we don't support platforms where that's not the case.)

----------
nosy: +mark.dickinson, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:01:25 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 17:01:25 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1582819072.91.0.675459966939.issue36144@roundup.psfhosted.org>
Message-ID: <CAP7+vJKWcuOZ2sKgEp6=amHokcA0JxgjCTywUVKxwtTVAtVAyQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

OK, assuming `|=` gets the same semantics as update(), can you repeat once
more (without motivation) what the specification for `cm | other` will be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:10:59 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 17:10:59 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582823459.58.0.899872208884.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I believe that:

    cm | other

Should return the equivalent of:

    ChainMap(cm.maps[0] | dict(other), *cm.maps[1:])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:15:24 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 17:15:24 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582823724.7.0.293487848947.issue39763@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The key is that os.execl() never returns.

My understanding is that the hang happens when the child code returns (or raises) in the forked child process, because the semaphore state is cloned by the fork.

There is no logging here. I just added some print() calls. (See the script I posted.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:18:57 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 17:18:57 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582823937.09.0.876872620276.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

...however, I could also see the (similar):

    ChainMap(other, *cm.maps)  # Note that `other` is the original reference here.

Being okay as well. Maybe even better, now that I've written it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:23:53 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 27 Feb 2020 17:23:53 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582824233.7.0.22821041097.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I've briefly looked at the zip archive. Without going much into
the C++ module as a whole, this should not be done:


    gil_unlocker.UnlockGILAndSleep()
    self.val = decimal.Decimal(1) / decimal.Decimal(7)
    gil_unlocker.UnlockGILAndSleep()


If you want C++ threads with a released GIL, you should use libmpdec
directly and not the Python module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:26:54 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 17:26:54 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582824414.55.0.612169720779.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

OK, that makes sense, it works similar to ChainMap.copy(), which copies maps[0] and keeps links to the rest. So in particular `cm | {}` will do the same thing as cm.copy().

Im not sure if the dict(other) cast is the best way to go about it. Maybe this would work?

def __or__(self, other):
    new = self.copy()
    new |= other  # OR new.update(other) ???
    return new

def __ior__(self, other):
    self.update(other)
    return self

Note that there is no ChainMap.update() definition -- it relies on MutableMapping.update().

I guess we need a __ror__ as well, in case there's some other mapping that doesn't implement __or__:

def __ror__(self, other):
    new = other.copy()
    new.update(self)
    return new

Note that this doesn't return a ChainMap but an instance of type(other).  If other doesn't have a copy() method it'll fail.

As a refinement, __or__ and __ror__ should perhaps check whether the operation can possibly succeed and return NotImplemented instead of raising? (Based on the type of other only, not its contents.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:28:35 2020
From: report at bugs.python.org (Elad Lahav)
Date: Thu, 27 Feb 2020 17:28:35 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582824515.97.0.895378910028.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

OK, but that's not the problem I see. The parent calls fork(), creates a child that then runs the atfork() handlers *before* returning from the os.fork() call (which is the expected behaviour). At least one of those atfork() handlers is the one registered by the logging module (Lib/logging/__init__.py) and that one attempts to acquire a lock. So in my case the child never gets to the point of calling exec(), which is why I didn't notice the bug in the script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:28:42 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 17:28:42 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582824522.9.0.601199222916.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I didn't see your second reply, with `ChainMap(other, *cm.maps)`.

I'm not so keen on that, because its special behavior can't be mimicked by `|=`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:34:56 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 27 Feb 2020 17:34:56 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582824896.85.0.0716030336443.issue39776@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:35:19 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 27 Feb 2020 17:35:19 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582824919.55.0.68334937706.issue39763@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

And you're sure that your "toy" example hangs in the at-fork handler.

In that case I can't help you further, I don't have the resources or time to try out QNX. Your best bet is indeed to change distutils.spawn to not use fork+exec -- do you think you can come up with a PR for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:41:28 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Thu, 27 Feb 2020 17:41:28 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582825288.16.0.539302009644.issue39776@roundup.psfhosted.org>


Evgeny Boytsov <boytsovea at yandex.ru> added the comment:

Please note, that UnlockGILandSleep takes GIL back before returning. In a real production code there is a database query. In this example I emulate them with random sleep. So I don't see any problems here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:46:53 2020
From: report at bugs.python.org (Elad Lahav)
Date: Thu, 27 Feb 2020 17:46:53 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582825613.2.0.0837910242343.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

As sure as I can be given my limited experience debugging Python... Luckily I do know my way around the QNX kernel ;-)

The stack trace for the child shows it stuck on a semaphore with a count value of 0. A print in the logging module shows that the child gets to the _acquireLock() call on line 245 of logging/__init__.py  but a print after that line is never displayed. I am basing my analysis on the combination of the two observations.

I'll try to come up with a change to distutils.spawn, as well as a change to subprocess to use posix_spawn().

Stack trace:
#0  SyncSemWait () at /builds/workspace/710-SDP/build_x86_64/lib/c/kercalls/x86_64/SyncSemWait.S:37
#1  0x000000267938bac6 in PyThread_acquire_lock_timed (lock=lock at entry=0x3bcde5a430, microseconds=microseconds at entry=-1000000, 
    intr_flag=intr_flag at entry=1) at Python/thread_pthread.h:459
#2  0x00000026793de7bd in acquire_timed (lock=0x3bcde5a430, timeout=-1000000000) at ./Modules/_threadmodule.c:63
#3  0x00000026793de8e7 in rlock_acquire (self=0x3bce057c90, args=<optimized out>, kwds=<optimized out>) at ./Modules/_threadmodule.c:308
#4  0x000000267941b631 in method_vectorcall_VARARGS_KEYWORDS (func=0x3bcdee2ef0, args=0x3bce1ad4d0, nargsf=<optimized out>, kwnames=<optimized out>)
    at Objects/descrobject.c:332
#5  0x0000002679285ff6 in _PyObject_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, args=<optimized out>, callable=<optimized out>)
    at ./Include/cpython/abstract.h:123
#6  call_function (kwnames=0x0, oparg=1, pp_stack=<synthetic pointer>, tstate=0x3bcdea9040) at Python/ceval.c:4987
#7  _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3486
#8  0x000000267928395b in function_code_fastcall (co=<optimized out>, args=<optimized out>, nargs=0, globals=<optimized out>) at Objects/call.c:283
#9  0x0000002679285d29 in _PyObject_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, args=<optimized out>, callable=<optimized out>)
    at ./Include/cpython/abstract.h:127
#10 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0x3bcdea9040) at Python/ceval.c:4987
#11 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3500
#12 0x000000267928395b in function_code_fastcall (co=<optimized out>, args=<optimized out>, nargs=1, globals=<optimized out>) at Objects/call.c:283
#13 0x0000002679285d29 in _PyObject_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, args=<optimized out>, callable=<optimized out>)
    at ./Include/cpython/abstract.h:127
#14 call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>, tstate=0x3bcdea9040) at Python/ceval.c:4987
#15 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3500
#16 0x000000267928395b in function_code_fastcall (co=<optimized out>, args=<optimized out>, nargs=1, globals=<optimized out>) at Objects/call.c:283
#17 0x0000002679285ff6 in _PyObject_Vectorcall (kwnames=<optimized out>, nargsf=<optimized out>, args=<optimized out>, callable=<optimized out>)
    at ./Include/cpython/abstract.h:123
#18 call_function (kwnames=0x0, oparg=1, pp_stack=<synthetic pointer>, tstate=0x3bcdea9040) at Python/ceval.c:4987
#19 _PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:3486
#20 0x000000267928395b in function_code_fastcall (co=<optimized out>, args=<optimized out>, nargs=0, globals=<optimized out>) at Objects/call.c:283
#21 0x000000267929d26a in _PyObject_FastCallDict (callable=0x3bce1bd160, args=<optimized out>, nargsf=<optimized out>, kwargs=<optimized out>)
    at Objects/call.c:96
#22 0x00000026793a0584 in run_at_forkers (lst=<optimized out>, reverse=<optimized out>) at ./Modules/posixmodule.c:435
#23 0x00000026793abbfb in run_at_forkers (reverse=0, lst=<optimized out>) at ./Modules/posixmodule.c:420
#24 PyOS_AfterFork_Child () at ./Modules/posixmodule.c:474
#25 0x00000026793abd08 in os_fork_impl (module=<optimized out>) at ./Modules/posixmodule.c:6082

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:49:23 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 17:49:23 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582825763.8.0.875939579822.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> Im not sure if the dict(other) cast is the best way to go about it. Maybe this would work?

Yeah, I was imagining something like that... I used the cast for brevity in my reply but that probably wasn't helpful.

Note that for __or__, we probably want to check the type of the argument (for either dict or ChainMap, or maybe just Mapping), to keep it from working on an iterable of key-value pairs.

> I guess we need a __ror__ as well, in case there's some other mapping that doesn't implement __or__:

Agreed. Again, we can check for Mapping here to assure success for the copy() move.

> As a refinement, __or__ and __ror__ should perhaps check whether the operation can possibly succeed and return NotImplemented instead of raising? (Based on the type of other only, not its contents.)

Yup, see above. I think a check for Mapping should be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 12:52:25 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 17:52:25 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582825945.38.0.958185129011.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Just to clarify:

If we decide to check isinstance(other, (ChainMap, dict)), '|' should probably be used.

If we decide to check isinstance(other, Mapping), I think the copy/update methods should be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 13:53:33 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 27 Feb 2020 18:53:33 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582829613.55.0.771362386232.issue39689@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

maybe we should be raising an error if the bytes are not a valid platform _Bool pattern?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Thu Feb 27 14:01:55 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 27 Feb 2020 19:01:55 +0000
Subject: [issue39765] asyncio loop.add_signal_handler() may not behave as
 expected
In-Reply-To: <1582750012.4.0.489053907607.issue39765@roundup.psfhosted.org>
Message-ID: <1582830115.13.0.08492724103.issue39765@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Other threads are not related.

Speaking about the main thread that runs an event loop with the signal handler installed -- the handler is executed along with other async code.
If the loop executes some user-provides async task -- it executes the signal handler as well if needed.

This is why I suspect that the discussed program is not completely correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39765>
_______________________________________

From report at bugs.python.org  Thu Feb 27 14:54:41 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 19:54:41 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582833281.41.0.418604737121.issue39689@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
components: +Extension Modules
nosy: +gregory.p.smith
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:00:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Feb 2020 20:00:33 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582833633.75.0.455316226946.issue36144@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

1.

def __or__(self, other):
    return self.__class__(self.maps[0] | other, *self.maps[1:])

def __ror__(self, other):
    return other | dict(self)


2.

def __or__(self, other):
    return self.__class__(other, *self.maps)

def __ror__(self, other):
    return self.__class__(*self.maps, other)


There are problems with both variants, so I think it may be better to not add this operator to ChainMap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:01:59 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Feb 2020 20:01:59 +0000
Subject: [issue39609] Set the thread_name_prefix for asyncio's default
 executor ThreadPoolExecutor
In-Reply-To: <1581420918.89.0.0710307394.issue39609@roundup.psfhosted.org>
Message-ID: <1582833719.37.0.297119167885.issue39609@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 374d998b507d34a6c0a3816a163926a8ba0c483f by Markus Mohrhard in branch 'master':
bpo-39609: set the thread_name_prefix for the default asyncio executor (GH-18458)
https://github.com/python/cpython/commit/374d998b507d34a6c0a3816a163926a8ba0c483f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39609>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:02:17 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 27 Feb 2020 20:02:17 +0000
Subject: [issue39609] Set the thread_name_prefix for asyncio's default
 executor ThreadPoolExecutor
In-Reply-To: <1581420918.89.0.0710307394.issue39609@roundup.psfhosted.org>
Message-ID: <1582833737.48.0.27602137692.issue39609@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/issue39609>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:02:24 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Feb 2020 20:02:24 +0000
Subject: [issue39689] test_struct failure on s390x Fedora Clang buildbot
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1582833744.62.0.868537406902.issue39689@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

the concept of a native _Bool seems fuzzy.  the important thing for the struct module is to consume sizeof _Bool bytes from the input stream.  how those are interpreted is up to the platform.  So if the platform says a bool is 8 bytes and it only ever looks at the lowest bit in those for bool-ness, good for it.

in that situation our unittest assuming that b'\xf0' should be true when interpreted as a bool is wrong.

just get rid of that value from the loop in the test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:07:54 2020
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 27 Feb 2020 20:07:54 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582834074.39.0.976766207979.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I built your example with 3.6:

git clone https://github.com/pybind/pybind11
wget https://bugs.python.org/file48923/decimal_crash.zip
unzip decimal_crash.zip

git checkout v3.6.7
./configure --with-pydebug
make

g++ -std=c++11 -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include -I./pybind11/include -c main.cpp

g++ -pthread -Xlinker -export-dynamic -o main main.o libpython3.6dm.a -lpthread -ldl -lutil -lm


cp python python3
PATH=.:$PATH
./main



And I literally get this error (not always, it may take 10 runs or so):

$ ./main
Fatal Python error: Python memory allocator called without holding the GIL

Thread 0x00007f1e73fff700 (most recent call first):

Thread 0x00007f1e7b836700 (most recent call first):

Thread 0x00007f1e7a834700 (most recent call first):

Thread 0x00007f1e7b035700 (most recent call first):

Thread 0x00007f1e7d039700 (most recent call first):

Thread 0x00007f1e7c838700 (most recent call first):

Current thread 0x00007f1e7c037700 (most recent call first):

Thread 0x00007f1e7e84f740 (most recent call first):
Aborted (core dumped)



So no, I don't think the GIL handling is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:12:28 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 27 Feb 2020 20:12:28 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582834348.63.0.192057697956.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I think we're only seriously considering the first variant (although implemented slightly differently, see my last two messages). And __ror__ would probably change, returning the type of self.

What are the "problems" with it, exactly? We seem to be in agreement that the update behavior is reasonable, even for ChainMaps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:14:33 2020
From: report at bugs.python.org (R. David Murray)
Date: Thu, 27 Feb 2020 20:14:33 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582834473.24.0.153979133609.issue39771@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

The legacy API appears to be using an RFC-incorrect (but common) encoded-word encoding, while the new API is using the RFC-compliant MIME-parameter encoding (% encoding).  Which email client are you using?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:47:25 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 20:47:25 +0000
Subject: [issue39730] Licence (license) for Python 3.8.1 is missing
In-Reply-To: <1582456104.31.0.935574059782.issue39730@roundup.psfhosted.org>
Message-ID: <1582836445.94.0.812996279357.issue39730@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

The 3.8.1 license can be found at https://github.com/python/cpython/blob/v3.8.1/LICENSE. But the reason you are seeing the license as under 3.8.2rc2 is because that's the version the 3.8 docs is showing, not 3.8.1. So there's no license missing, you're just not looking at the 3.8.1 docs as we are not displaying those at docs.python.org anymore.

----------
nosy: +brett.cannon
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39730>
_______________________________________

From report at bugs.python.org  Thu Feb 27 15:51:19 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 20:51:19 +0000
Subject: [issue39715] Implement __repr__ methods for AST classes
In-Reply-To: <1582308303.42.0.673674481243.issue39715@roundup.psfhosted.org>
Message-ID: <1582836679.7.0.0707720129286.issue39715@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/issue39715>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:08:07 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 21:08:07 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582837687.98.0.0303893997686.issue39704@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

The codecov config lives at https://github.com/python/cpython/blob/master/.github/codecov.yml and the docs for the file are at https://docs.codecov.io/docs/codecov-yaml. Specifically, the comment feature is covered at https://docs.codecov.io/docs/pull-request-comments and the status check is at https://docs.codecov.io/docs/commit-status.

Nothing has changed in the config, though, so it might be a change related to https://docs.codecov.io/docs/codecov-yaml#section-can-i-name-the-file-codecov-yml and thus the file path to the config might need to be added to the upload step in the following files:

1. https://github.com/python/cpython/blob/master/.github/workflows/coverage.yml
2. https://github.com/python/cpython/blob/master/.travis.yml
3. https://github.com/python/cpython/blob/master/.azure-pipelines/posix-steps.yml#L52

(I would submit a PR myself but I'm still digging myself out from under email after vacation.)

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:09:05 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 21:09:05 +0000
Subject: [issue39777] Use the codecov GH Action
Message-ID: <1582837745.01.0.0567552110573.issue39777@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

Codecov provides a GH Action for uploading coverage reports which we might as well use instead of their bash uploader: https://github.com/marketplace/actions/codecov.

----------
messages: 362839
nosy: brett.cannon, steve.dower
priority: normal
severity: normal
status: open
title: Use the codecov GH Action

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39777>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:17:26 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 21:17:26 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1582838246.03.0.948797619521.issue39682@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

A use-case of "closing" a path is to cheaply flag that a path object is no longer valid, e.g. you deleted the underlying file and so you don't want others using the object anymore without paying the penalty of having to do the I/O to trigger the failure due to the path no longer existing.

Now whether anyone is using this functionality I don't know, but removing it will inevitably break code for someone, so someone will need to make at least some form of an attempt to see if there's any use in the wild to justify simplifying the code by removing the functionality.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39682>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:19:04 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 27 Feb 2020 21:19:04 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582838344.83.0.387407440344.issue39704@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Thanks for the pointer Brett, I'll submit a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:21:07 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 21:21:07 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1582838467.59.0.960278009007.issue14678@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@crwilcox Don't know what's left. That's probably part of the work that's left. ;) This issue is so old that it's possibly out-of-date since zipimport got rewritten in pure Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:22:40 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 27 Feb 2020 21:22:40 +0000
Subject: [issue39777] Use the codecov GH Action
In-Reply-To: <1582837745.01.0.0567552110573.issue39777@roundup.psfhosted.org>
Message-ID: <1582838560.59.0.611040653638.issue39777@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

This has the disadvantage that it won't work for PRs because Github doesn't make secrets like `${{ secrets.CODECOV_TOKEN }}` available in PRs.

See: https://github.com/codecov/codecov-action/issues/29

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39777>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:25:09 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 21:25:09 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1582838709.98.0.692570950229.issue10572@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@ned.deily the motivation is covered in Michael's initial comment; some vendors like to leave out the tests and not having them all under 'test' prevents that from working cleanly. Plus it makes the tests more discoverable.

As for any of the projects being vendored from outside the stdlib, none of them fall under https://www.python.org/dev/peps/pep-0360/ so it isn't a worry. Plus none of them are anymore to my knowledge anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:26:43 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 27 Feb 2020 21:26:43 +0000
Subject: [issue39777] Use the codecov GH Action
In-Reply-To: <1582837745.01.0.0567552110573.issue39777@roundup.psfhosted.org>
Message-ID: <1582838803.9.0.398688430073.issue39777@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

On a second look, we currently do this anyway: https://github.com/python/cpython/blob/374d998b507d34a6c0a3816a163926a8ba0c483f/.github/workflows/coverage.yml#L66-L70

and don't run coverage for PRs so it shouldn't matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39777>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:32:33 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 27 Feb 2020 21:32:33 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582839153.91.0.610906162455.issue39704@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +18039
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18680

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 27 16:52:09 2020
From: report at bugs.python.org (Leonard Lausen)
Date: Thu, 27 Feb 2020 21:52:09 +0000
Subject: [issue39778] collections.OrderedDict and weakref.ref raises "refcount
 is too small" assertion
Message-ID: <1582840329.06.0.498356539569.issue39778@roundup.psfhosted.org>


New submission from Leonard Lausen <leonard at lausen.nl>:

Below sample program, will raise "Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small" on Python 3.8.2 debug build.
On 3.7.6 debug build, "Modules/gcmodule.c:277: visit_decref: Assertion `_PyGCHead_REFS(gc) != 0' failed." is raised.

```
import collections
import gc
import weakref

hooks_dict = collections.OrderedDict()
hooks_dict_ref = weakref.ref(hooks_dict)
gc.collect()

print('Hello world')
```


The complete error message on 3.8.2 debug build is

```
Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small
Memory block allocated at (most recent call first):
  File "/home/$USER/test.py", line 6

object  : <weakref at 0x7ff788208a70; to 'collections.OrderedDict' at 0x7ff7881fab90>
type    : weakref
refcount: 1
address : 0x7ff788208a70
Fatal Python error: _PyObject_AssertFailed
Python runtime state: initialized

Current thread 0x00007ff789f9c080 (most recent call first):
  File "/home/$USER/test.py", line 7 in <module>
zsh: abort      PYTHONTRACEMALLOC=1 python ~/test.py
```

----------
components: C API
messages: 362846
nosy: leezu
priority: normal
severity: normal
status: open
title: collections.OrderedDict and weakref.ref raises "refcount is too small" assertion
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39778>
_______________________________________

From report at bugs.python.org  Thu Feb 27 17:06:11 2020
From: report at bugs.python.org (Leonard Lausen)
Date: Thu, 27 Feb 2020 22:06:11 +0000
Subject: [issue39778] collections.OrderedDict and weakref.ref raises "refcount
 is too small" assertion
In-Reply-To: <1582840329.06.0.498356539569.issue39778@roundup.psfhosted.org>
Message-ID: <1582841171.59.0.127043163618.issue39778@roundup.psfhosted.org>


Change by Leonard Lausen <leonard at lausen.nl>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39778>
_______________________________________

From report at bugs.python.org  Thu Feb 27 17:10:37 2020
From: report at bugs.python.org (Elad Lahav)
Date: Thu, 27 Feb 2020 22:10:37 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1582841437.71.0.161172825908.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

I may be missing something, but subprocess depends on _posixsubprocess, which doesn't get built until setup.py is run, which results in a circular dependency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Thu Feb 27 18:08:37 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 27 Feb 2020 23:08:37 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582844917.32.0.794526451294.issue39704@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 766b7546a564c8e386a3c31eb06fc1b55e8f5a25 by Ammar Askar in branch 'master':
bpo-39704: Explicitly pass the path to codecov config (GH-18680)
https://github.com/python/cpython/commit/766b7546a564c8e386a3c31eb06fc1b55e8f5a25


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 27 18:40:07 2020
From: report at bugs.python.org (brian.gallagher)
Date: Thu, 27 Feb 2020 23:40:07 +0000
Subject: [issue39779] [argparse] Add parameter to sort help output arguments
Message-ID: <1582846807.44.0.751374358876.issue39779@roundup.psfhosted.org>


New submission from brian.gallagher <oss.brnglr at gmail.com>:

1 import argparse                                                                       
  2                                                                                       
  3 parser = argparse.ArgumentParser(description='Test')                                  
  4 parser.add_argument('c', help='token c')                                              
  5 parser.add_argument('b', help='token b')                                              
  6 parser.add_argument('d', help='token d')                                              
  7 parser.add_argument('-a', help='token a')                                             
  8 parser.add_argument('-z', help='token z')                                             
  9 parser.add_argument('-f', help='token f', required=True)                                                                                                                
 10 parser.print_help() 

It would be nice if we could have the option to alphabetically sort the tokens in the optional and positional arguments sections of the help message in order to find an argument more quickly when reading long help descriptions.

Currently we output the following, when the above program is ran:

positional arguments:
  c           token c
  b           token b
  d           token d

optional arguments:
  -h, --help  show this help message and exit
  -a A        token a
  -z Z        token z
  -f F        token f

I'm proposing that we provide a mechanism to allow alphabetical ordering of both sections, like so:

positional arguments:
  b           token b
  c           token c
  d           token d

optional arguments:
  -h, --help  show this help message and exit
  -a A        token a
  -f F        token f
  -z Z        token z

I've chosen to leave -h as an exception, as it will always be there as an optional argument, but it could easily be treated no different.

We could provide an optional argument to print_help(sort=False) as a potential approach.

If this is something that the maintainer's would be willing to accept, I'd love to take it on and prepare a patch.

----------
components: Library (Lib)
messages: 362849
nosy: brian.gallagher
priority: normal
severity: normal
status: open
title: [argparse] Add parameter to sort help output arguments
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39779>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:22:20 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 28 Feb 2020 00:22:20 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582849340.8.0.852075082918.issue39704@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Can someone with access check that https://codecov.io/gh/python/cpython/settings/yaml has the right config? The latest run after my PR was pushed through still has the status check running :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:42:01 2020
From: report at bugs.python.org (Ali McMaster)
Date: Fri, 28 Feb 2020 00:42:01 +0000
Subject: [issue39780] Add HTTP Response code 451
Message-ID: <1582850521.34.0.826318713504.issue39780@roundup.psfhosted.org>


Change by Ali McMaster <alimcmaster1 at gmail.com>:


----------
components: Library (Lib)
nosy: Ali McMaster
priority: normal
severity: normal
status: open
title: Add HTTP Response code 451
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39780>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:42:33 2020
From: report at bugs.python.org (Ali McMaster)
Date: Fri, 28 Feb 2020 00:42:33 +0000
Subject: [issue39780] Add HTTP Response code 103
Message-ID: <1582850553.98.0.0461428688103.issue39780@roundup.psfhosted.org>


New submission from Ali McMaster <alimcmaster1 at gmail.com>:

https://tools.ietf.org/html/rfc8297

I would like to work on this - PR to follow

----------
title: Add HTTP Response code 451 -> Add HTTP Response code 103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39780>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:43:30 2020
From: report at bugs.python.org (Ali McMaster)
Date: Fri, 28 Feb 2020 00:43:30 +0000
Subject: [issue39780] Add HTTP Response code 103
In-Reply-To: <1582850553.98.0.0461428688103.issue39780@roundup.psfhosted.org>
Message-ID: <1582850610.16.0.195703240954.issue39780@roundup.psfhosted.org>


Change by Ali McMaster <alimcmaster1 at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39780>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:48:12 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Feb 2020 00:48:12 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582850892.96.0.0629630801258.issue36144@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

We already have somewhat different semantics of `|` for Counter, and hence I think it's fine to give it the most useful semantics for ChainMap given that class's special behavior. I think we've come up with the right solution there.

Let's stop the debate and put up a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:54:37 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 28 Feb 2020 00:54:37 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582851277.61.0.812336229654.issue17422@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for working on this.  Sorry I didn't get a chance to see your PR sooner.  There was one small thing that needs to be changed back, as I implied in my comment on the PR [1].  Please undo the change in the text from "ordered mapping" to "dict".

The original "is initialised as an empty ordered mapping" text line should be restored.  "dict" is currently still not correct (the language spec does not dictate that dict be ordered).  However, PEP 520 specifies that it must be ordered.

Thanks!


[1] https://github.com/python/cpython/pull/18559#pullrequestreview-366098695

----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:58:09 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Feb 2020 00:58:09 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582851489.46.0.226044821689.issue17422@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

As I mentioned in my response on the PR, dict *is* required to be ordered since 3.7. So I think it is okay as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Thu Feb 27 19:58:56 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 28 Feb 2020 00:58:56 +0000
Subject: [issue36144] Dictionary union. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1582851536.89.0.288726612221.issue36144@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Sounds good, I'll have these up soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36144>
_______________________________________

From report at bugs.python.org  Thu Feb 27 20:08:11 2020
From: report at bugs.python.org (Caleb Donovick)
Date: Fri, 28 Feb 2020 01:08:11 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582852091.43.0.0328074038935.issue17422@roundup.psfhosted.org>


Caleb Donovick <donovick at cs.stanford.edu> added the comment:

While It is perfectly fine behavior for CPython to use a dict, as dict is an ordered mapping.  I think Eric is right that the data model should not specify that a dict is necessarily used in the absence of __prepare__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Thu Feb 27 20:21:18 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Fri, 28 Feb 2020 01:21:18 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582852878.9.0.402989108751.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

Microsoft outlook 20116 MSO(16.0.4266.10001) x64
Foxmail 7.2 (build 7.026)

I use these two email client. All display incorrectly. And I have uploaded the screenshot.

----------
Added file: https://bugs.python.org/file48924/foxmail_screenshot.jpeg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 20:23:09 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Fri, 28 Feb 2020 01:23:09 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582852989.65.0.897941517614.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

Microsoft outlook 2016 MSO(16.0.4266.10001) x64

----------
Added file: https://bugs.python.org/file48925/outlook_screenshot.jpeg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Thu Feb 27 20:34:56 2020
From: report at bugs.python.org (Ali McMaster)
Date: Fri, 28 Feb 2020 01:34:56 +0000
Subject: [issue39780] Add HTTP Response code 103
In-Reply-To: <1582850553.98.0.0461428688103.issue39780@roundup.psfhosted.org>
Message-ID: <1582853696.99.0.473363488028.issue39780@roundup.psfhosted.org>


Change by Ali McMaster <alimcmaster1 at gmail.com>:


----------
keywords: +patch
pull_requests: +18040
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18681

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39780>
_______________________________________

From report at bugs.python.org  Thu Feb 27 20:41:56 2020
From: report at bugs.python.org (Caleb Donovick)
Date: Fri, 28 Feb 2020 01:41:56 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582854116.01.0.650389956839.issue17422@roundup.psfhosted.org>


Change by Caleb Donovick <donovick at cs.stanford.edu>:


----------
pull_requests: +18041
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18682

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17422>
_______________________________________

From report at bugs.python.org  Thu Feb 27 20:57:22 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 28 Feb 2020 01:57:22 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1582855042.05.0.675544806509.issue17422@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/issue17422>
_______________________________________

From report at bugs.python.org  Thu Feb 27 21:28:58 2020
From: report at bugs.python.org (Caleb Donovick)
Date: Fri, 28 Feb 2020 02:28:58 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
In-Reply-To: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>
Message-ID: <1582856938.93.0.20013274364.issue39775@roundup.psfhosted.org>


Change by Caleb Donovick <donovick at cs.stanford.edu>:


----------
nosy: +donovick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39775>
_______________________________________

From report at bugs.python.org  Thu Feb 27 21:30:33 2020
From: report at bugs.python.org (Caleb Donovick)
Date: Fri, 28 Feb 2020 02:30:33 +0000
Subject: [issue39753] inspecting a partial with bound keywods gives incorrect
 signature
In-Reply-To: <1582656134.57.0.362705493242.issue39753@roundup.psfhosted.org>
Message-ID: <1582857033.86.0.327086993275.issue39753@roundup.psfhosted.org>


Change by Caleb Donovick <donovick at cs.stanford.edu>:


----------
nosy: +donovick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39753>
_______________________________________

From report at bugs.python.org  Thu Feb 27 21:45:16 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 28 Feb 2020 02:45:16 +0000
Subject: [issue39721] Fix constness of members of tok_state struct.
In-Reply-To: <1582331134.81.0.179748951937.issue39721@roundup.psfhosted.org>
Message-ID: <1582857916.07.0.455918686728.issue39721@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 384f3c536dd15ba33ea7e8afb4087ae359d4c12e by Andy Lester in branch 'master':
closes bpo-39721: Fix constness of members of tok_state struct. (GH-18600)
https://github.com/python/cpython/commit/384f3c536dd15ba33ea7e8afb4087ae359d4c12e


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39721>
_______________________________________

From report at bugs.python.org  Thu Feb 27 21:52:29 2020
From: report at bugs.python.org (wyz23x2)
Date: Fri, 28 Feb 2020 02:52:29 +0000
Subject: [issue39768] remove tempfile.mktemp()
In-Reply-To: <1582772221.62.0.0102658338874.issue39768@roundup.psfhosted.org>
Message-ID: <1582858349.11.0.74093856452.issue39768@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Well, I just think it's *serious*.
I respect your thoughts. If you want to close this, you can.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39768>
_______________________________________

From report at bugs.python.org  Thu Feb 27 22:15:19 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 03:15:19 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
Message-ID: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Tweak the code context widget so people can select context lines and copy to clipboard (perhaps to document nested code) without having to do the copy while still holding down the left mouse button.  Button-down, move, and release (to select) is not really a 'click', so I don't think a doc change is needed.

----------
assignee: terry.reedy
components: IDLE
messages: 362861
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: IDLE: Do not jump when select in codecontext
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Thu Feb 27 22:24:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 03:24:31 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582860271.99.0.398246811641.issue39781@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +18042
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/18683

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Thu Feb 27 22:38:48 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Feb 2020 03:38:48 +0000
Subject: [issue39778] collections.OrderedDict and weakref.ref raises "refcount
 is too small" assertion
In-Reply-To: <1582840329.06.0.498356539569.issue39778@roundup.psfhosted.org>
Message-ID: <1582861128.64.0.677214004368.issue39778@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Thanks for the succinct example!  Although you don't need the print() ;-)

I can confirm this crashes the same way under a current master build (albeit on Windows 64-bit).

gc is calculating how many references in the current generation are accounted for by intra-generation references, and gc's visit_decref() is getting called back by odictobject.c's odict_traverse(), on line

    Py_VISIT(od->od_weakreflist);

gc has found a second pointer to od->od_weakreflist, which is more than its refcount (1) claims exist.

Python's weakref implementation gives me headaches, so I'm adding Raymond to the nosy list under the hope the problem will be obvious to him.

----------
components: +Extension Modules -C API
nosy: +rhettinger, tim.peters
stage:  -> needs patch
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39778>
_______________________________________

From report at bugs.python.org  Thu Feb 27 22:50:09 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 28 Feb 2020 03:50:09 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582861809.56.0.626496897976.issue39704@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Looks like it was just cached, the latest pull request didn't get a codecov comment nor was it ran on the latest commit: https://github.com/python/cpython/pull/18682

Should this be back-ported so backport pull requests/pull requests to other versioned branches don't get affected by this either?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Thu Feb 27 22:53:59 2020
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Feb 2020 03:53:59 +0000
Subject: [issue39780] Add HTTP Response code 103
In-Reply-To: <1582850553.98.0.0461428688103.issue39780@roundup.psfhosted.org>
Message-ID: <1582862039.1.0.993405895644.issue39780@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

See also Issue 39509, proposing to add 103 and "425 Too Early"

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39780>
_______________________________________

From report at bugs.python.org  Thu Feb 27 23:12:22 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Fri, 28 Feb 2020 04:12:22 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582863142.36.0.571213405765.issue39776@roundup.psfhosted.org>


Evgeny Boytsov <boytsovea at yandex.ru> added the comment:

Thank you for feedback. I will try to reproduce the issue with 3.6. By the way, haven't you used gdb with python pretty-printers enabled to examine the state of the program? I've got the same error message, then I breaked the execution in debugger and tried to examine the callstack of threads, that stucked in UnlockGILandSleep. The reason for it is clear: then the debugger tries to build a callstack, some of pretty printers try to execute some python code to give a better representation of interpreter objects. The code is executed at the top of the stack of the examined thread. Since this thread explicitly released the GIL before going to sleep, these functions hit the assert about calling the memory allocator without holdng the GIL. Disabling pretty-printers makes these error messages to disappear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 00:31:48 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 28 Feb 2020 05:31:48 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
In-Reply-To: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>
Message-ID: <1582867908.89.0.332649454011.issue39775@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/issue39775>
_______________________________________

From report at bugs.python.org  Fri Feb 28 00:45:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Feb 2020 05:45:44 +0000
Subject: [issue39778] collections.OrderedDict and weakref.ref raises "refcount
 is too small" assertion
In-Reply-To: <1582840329.06.0.498356539569.issue39778@roundup.psfhosted.org>
Message-ID: <1582868744.97.0.897495687829.issue39778@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39778>
_______________________________________

From report at bugs.python.org  Fri Feb 28 00:53:29 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 28 Feb 2020 05:53:29 +0000
Subject: [issue39778] collections.OrderedDict and weakref.ref raises "refcount
 is too small" assertion
In-Reply-To: <1582840329.06.0.498356539569.issue39778@roundup.psfhosted.org>
Message-ID: <1582869209.41.0.998490683222.issue39778@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm suspecting that maybe we shouldn't be doing

    Py_VISIT(od->od_weakreflist);

at all - best I can tell from a quick (non-exhaustive!) scan, the objects in the weakref list aren't incref'ed to begin with.  And even if they were, that line would only be looking at the head of the list, ignoring all the non-head weakrefs after the head.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39778>
_______________________________________

From report at bugs.python.org  Fri Feb 28 00:59:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Feb 2020 05:59:11 +0000
Subject: [issue39779] [argparse] Add parameter to sort help output arguments
In-Reply-To: <1582846807.44.0.751374358876.issue39779@roundup.psfhosted.org>
Message-ID: <1582869551.27.0.502604878573.issue39779@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestion, but I am going to decline.

Since the parser remembers the order the arguments were added, the programmer already has complete control over the ordering of arguments.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39779>
_______________________________________

From report at bugs.python.org  Fri Feb 28 01:28:22 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 28 Feb 2020 06:28:22 +0000
Subject: [issue39780] Add HTTP Response code 103
In-Reply-To: <1582850553.98.0.0461428688103.issue39780@roundup.psfhosted.org>
Message-ID: <1582871302.42.0.56098022005.issue39780@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Yes, this is duplicated issue.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39780>
_______________________________________

From report at bugs.python.org  Fri Feb 28 01:35:57 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Fri, 28 Feb 2020 06:35:57 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582871757.89.0.345649182328.issue39776@roundup.psfhosted.org>


Evgeny Boytsov <boytsovea at yandex.ru> added the comment:

I'am unable to reproduce neither my or your issues with python 3.6. The program runs infinitely as it meant to be. Can you please give me C++ traceback from the core dump, which was created when you ran my program?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 01:42:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Feb 2020 06:42:12 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
In-Reply-To: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>
Message-ID: <1582872132.21.0.494264734082.issue39775@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39775>
_______________________________________

From report at bugs.python.org  Fri Feb 28 02:02:45 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 28 Feb 2020 07:02:45 +0000
Subject: [issue29505] Submit the re, json, csv,
 & struct modules to oss-fuzz testing
In-Reply-To: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za>
Message-ID: <1582873365.98.0.683795401551.issue29505@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
title: Submit the re, json, & csv modules to oss-fuzz testing -> Submit the re, json, csv, & struct modules to oss-fuzz testing

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29505>
_______________________________________

From report at bugs.python.org  Fri Feb 28 02:03:08 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 28 Feb 2020 07:03:08 +0000
Subject: [issue29505] Submit the re, json, csv,
 & struct modules to oss-fuzz testing
In-Reply-To: <1486587261.97.0.342323514088.issue29505@psf.upfronthosting.co.za>
Message-ID: <1582873388.07.0.00608921768397.issue29505@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +ammar2
nosy_count: 9.0 -> 10.0
pull_requests: +18043
pull_request: https://github.com/python/cpython/pull/18679

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29505>
_______________________________________

From report at bugs.python.org  Fri Feb 28 02:49:44 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 28 Feb 2020 07:49:44 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
In-Reply-To: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>
Message-ID: <1582876184.31.0.32134539078.issue39775@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +18044
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18684

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39775>
_______________________________________

From report at bugs.python.org  Fri Feb 28 02:54:20 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 28 Feb 2020 07:54:20 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
In-Reply-To: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>
Message-ID: <1582876460.81.0.446284144544.issue39775@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Would you review the PR 18684?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39775>
_______________________________________

From report at bugs.python.org  Fri Feb 28 03:02:38 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 28 Feb 2020 08:02:38 +0000
Subject: [issue34396] Certain methods that heap allocated subtypes inherit
 suffer a 50-80% performance penalty
In-Reply-To: <1534189001.92.0.56676864532.issue34396@psf.upfronthosting.co.za>
Message-ID: <1582876958.32.0.830336463712.issue34396@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/issue34396>
_______________________________________

From report at bugs.python.org  Fri Feb 28 04:16:00 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 28 Feb 2020 09:16:00 +0000
Subject: [issue39775] inspect.Signature.parameters should be an OrderedDict,
 not a plain dict
In-Reply-To: <1582811259.66.0.363702048971.issue39775@roundup.psfhosted.org>
Message-ID: <1582881360.67.0.451004347408.issue39775@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

It looks good to me, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39775>
_______________________________________

From report at bugs.python.org  Fri Feb 28 04:25:30 2020
From: report at bugs.python.org (brian.gallagher)
Date: Fri, 28 Feb 2020 09:25:30 +0000
Subject: [issue39779] [argparse] Add parameter to sort help output arguments
In-Reply-To: <1582846807.44.0.751374358876.issue39779@roundup.psfhosted.org>
Message-ID: <1582881930.55.0.601153828522.issue39779@roundup.psfhosted.org>


brian.gallagher <oss.brnglr at gmail.com> added the comment:

That makes sense. For what it's worth, the use-case that inspired this was for commands with a lot of optional arguments in a company where a large amount of contributors (who may not be aware of an effort to order the arguments in the source code) were able to make changes to the command.

I understand that isn't a particularly compelling reason though, as it can be addressed by other means -- increasing diligence at the code review stage, commit hooks, testing, etc.

Thanks for taking a look Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39779>
_______________________________________

From report at bugs.python.org  Fri Feb 28 05:24:35 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 10:24:35 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1582885475.47.0.787093479581.issue39712@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
Added file: https://bugs.python.org/file48926/0001-bpo-39712.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Fri Feb 28 05:24:45 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 10:24:45 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1582885485.35.0.323654533231.issue39712@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Added file: https://bugs.python.org/file48927/0001-3.8-bpo-39712.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Fri Feb 28 05:24:54 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 10:24:54 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1582885494.2.0.471219410757.issue39712@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Added file: https://bugs.python.org/file48928/0001-3.7-bpo-39712.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Fri Feb 28 05:32:21 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 10:32:21 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1582885941.73.0.892884980365.issue39712@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland
nosy_count: 9.0 -> 10.0
pull_requests: +18045
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18685

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Fri Feb 28 06:18:30 2020
From: report at bugs.python.org (Wang Jie)
Date: Fri, 28 Feb 2020 11:18:30 +0000
Subject: [issue39782] local varible referenced a Exception won't be collected
 in function
Message-ID: <1582888710.58.0.0521565801778.issue39782@roundup.psfhosted.org>


New submission from Wang Jie <i at i8e.net>:

I referenced an Exception object in a function and found memory usage will increase constantly in the accident. I think it may be a bug.

I wrote a minimal code to reproduce it.

```py
from threading import local, Thread
from time import sleep

l = {}

def t0():
  b = l.get('e') # memory usage won't increase if I remove this line
  try:
    raise Exception('1')
  except Exception as e:
    l['e'] = e

def target():
  while True:
    sleep(0.0001)
    t0()

target()

# t = Thread(target=target)
# t.daemon = True
# t.start()
```

I tried to execute it in IPython and got the following output:

```
In [1]: run py/ref_exception_causes_oom.py

In [2]: import objgraph

In [3]: objgraph.show_growth(limit=3)
frame        78792    +78792
Exception    78779    +78779
traceback    78779    +78779

In [4]: objgraph.show_growth(limit=3)
Exception   100862    +22083
traceback   100862    +22083
frame       100875    +22083

In [5]: objgraph.show_growth(limit=3)
Exception   115963    +15101
traceback   115963    +15101
frame       115976    +15101
```

And I tried to execute this code in python2.7 and pypy. Both of them won't occur this problem.

----------
components: Interpreter Core
messages: 362873
nosy: wangjie
priority: normal
severity: normal
status: open
title: local varible referenced a Exception won't be collected in function
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39782>
_______________________________________

From report at bugs.python.org  Fri Feb 28 06:36:37 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 28 Feb 2020 11:36:37 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
Message-ID: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

Many functions which take a path-like object typically also accept strings (sorry, no hard numbers here).  This means that if the function plans to call Path methods on the object, it needs to first call Path() on the arguments to convert them, well, to Paths.  This adds an unnecessary cost in the case where the argument is *already* a Path object (which should become more and more common as the use of pathlib spreads), as Path instantiation is not exactly cheap (it's on the order of microseconds).

Instead, given that Paths are immutable, `Path(path)` could just return the exact same path instance, completely bypassing instance creation (after checking that the argument's type exactly matches whatever we need and is not, say, PureWindowsPath when we want to instantiate a PosixPath, etc.).  Note that there is prior art for doing so in CPython: creating a frozenset from another frozenset just returns the same instance:
```
In [1]: s = frozenset({1}); id(s) == id(frozenset(s)) == id(s.copy())
Out[1]: True
```

----------
components: Library (Lib)
messages: 362874
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Optimize construction of Path from other Paths by just returning the same object?
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 06:40:24 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 28 Feb 2020 11:40:24 +0000
Subject: [issue1207613] Idle Editor: Bottom Scroll Bar
Message-ID: <1582890024.77.0.027842615509.issue1207613@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1207613>
_______________________________________

From report at bugs.python.org  Fri Feb 28 06:49:44 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Feb 2020 11:49:44 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582890584.77.0.888453718337.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

This is 3.6.7, compiled --with-pydebug:


$ ./main 
Aborted (core dumped)



(gdb) bt
#0  0x00007f9974077428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f997407902a in __GI_abort () at abort.c:89
#2  0x000000000056e2d1 in Py_FatalError (msg=msg at entry=0x62ccf8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1462
#3  0x00000000004c0cec in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1963
#4  0x00000000004c0d27 in _PyMem_DebugMalloc (ctx=0x8f7220 <_PyMem_Debug+96>, nbytes=75) at Objects/obmalloc.c:1971
#5  0x00000000004c204e in PyObject_Malloc (size=<optimized out>) at Objects/obmalloc.c:479
#6  0x00000000004ec12f in PyUnicode_New (size=10, maxchar=<optimized out>) at Objects/unicodeobject.c:1281
#7  0x00000000005162f4 in _PyUnicodeWriter_PrepareInternal (writer=writer at entry=0x7f9971ca4cf0, length=length at entry=10, maxchar=<optimized out>, maxchar at entry=127) at Objects/unicodeobject.c:13565
#8  0x000000000051af20 in PyUnicode_DecodeUTF8Stateful (s=0x61d15b "crash_test", size=10, errors=errors at entry=0x0, consumed=consumed at entry=0x0) at Objects/unicodeobject.c:5067
#9  0x000000000051c6b0 in PyUnicode_FromString (u=<optimized out>) at Objects/unicodeobject.c:2077
#10 0x0000000000563c1c in PyImport_ImportModule (name=<optimized out>) at Python/import.c:1266
#11 0x00000000004531dd in pybind11::module::import (name=0x61d15b "crash_test") at ./pybind11/include/pybind11/pybind11.h:849
#12 0x0000000000446434 in ThreadFunc () at main.cpp:30
#13 0x000000000046a1b1 in std::_Bind_simple<void (*())()>::_M_invoke<>(std::_Index_tuple<>) (this=0x10c28d8) at /usr/include/c++/5/functional:1531
#14 0x000000000046a10a in std::_Bind_simple<void (*())()>::operator()() (this=0x10c28d8) at /usr/include/c++/5/functional:1520
#15 0x000000000046a09a in std::thread::_Impl<std::_Bind_simple<void (*())()> >::_M_run() (this=0x10c28c0) at /usr/include/c++/5/thread:115
#16 0x00007f99749e3c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#17 0x00007f99750bb6ba in start_thread (arg=0x7f9971ca5700) at pthread_create.c:333
#18 0x00007f997414941d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 06:57:04 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Feb 2020 11:57:04 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582891024.13.0.926125320005.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Note that my pybind11 is from GitHub master, it can also be a pybind11
issue.


It is interesting that you cannot reproduce your original issue with
3.6, so I'm reopening this issue.

I think we need a reproducer without pybind11 though, could you
tweak Programs/_testembed.c (from the CPython sources) to run the
crash script?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 07:15:06 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Feb 2020 12:15:06 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582892106.42.0.0578881434816.issue39776@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
resolution: not a bug -> 
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 07:35:45 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Fri, 28 Feb 2020 12:35:45 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582893345.08.0.158398286585.issue39776@roundup.psfhosted.org>


Evgeny Boytsov <boytsovea at yandex.ru> added the comment:

Your callstack is very strange. At line 30 of main.cpp GIL is obviously locked:


   // importing module in this tread
   gstate = PyGILState_Ensure();
   py::module crash_test = py::module::import( "crash_test" ); <-- import
   PyGILState_Release( gstate );

I suppose that there is something wrong with your setup. Maybe - wrong working directory for the main executable, which doesn't contain crash_test.py

Also I've tried to revert this patch https://github.com/python/cpython/pull/5278 for 3.7. It makes problem to disappear, 1 hour of stable work under ASAN. So I suppose it is the source of the bug.

I will try to tweak _testembed.c.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 08:19:06 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Feb 2020 13:19:06 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582895946.69.0.693771764238.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Regarding *my* issue, it could be anything, e.g. a missing call to
PyEval_InitThreads() in 3.6:

"Changed in version 3.7: This function is now called by Py_Initialize(), so you don?t have to call it yourself anymore."


This is why we need to eliminate pybind11 so we can see what is
actually going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 08:49:05 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 13:49:05 +0000
Subject: [issue29076] Mac installer shell updater script silently fails if
 default shell is fish
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1582897745.08.0.417756164513.issue29076@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I've created a patch that applies fine to 3.7, 3.8 and 3.9, if anyone still is interested.

(Backporting to 3.6 and 2.7 is probably not going to happen, but at least the patch applies fine to both of them.)


The "Versions" label list should probably be updated to include 3.8 and 3.9.

----------
keywords: +patch
nosy: +erlendaasland
Added file: https://bugs.python.org/file48929/0001-bpo-29076-Add-fish-support-to-macOS-build.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Fri Feb 28 09:18:38 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Feb 2020 14:18:38 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
In-Reply-To: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>
Message-ID: <1582899518.62.0.957467571803.issue39783@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/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 09:20:57 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Fri, 28 Feb 2020 14:20:57 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582899657.09.0.372729551998.issue39776@roundup.psfhosted.org>


Evgeny Boytsov <boytsovea at yandex.ru> added the comment:

I rewrote my example without pybind and eliminated C++ module (I realized that time.sleep() also releases the GIL, so we achieve the same effect). Still the same results: with python 3.7.3 app crashes with attached ASAN output, with python 3.7.3 without https://github.com/python/cpython/pull/5278 works just fine.

To run main.cpp you should add directory with crash_test.py to PYTHONPATH.

----------
Added file: https://bugs.python.org/file48930/threaded_crash.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 09:26:49 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 28 Feb 2020 14:26:49 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1582900009.34.0.444865428464.issue12915@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 4f17c5cd9a1ec50fe8de7ef68c39220a01a862cb by Vinay Sajip in branch 'master':
bpo-12915: Improve Unicode support for package names and attributes. (GH-18517)
https://github.com/python/cpython/commit/4f17c5cd9a1ec50fe8de7ef68c39220a01a862cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Fri Feb 28 09:52:11 2020
From: report at bugs.python.org (Evgeny Boytsov)
Date: Fri, 28 Feb 2020 14:52:11 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582901531.32.0.43070076073.issue39776@roundup.psfhosted.org>


Evgeny Boytsov <boytsovea at yandex.ru> added the comment:

Also I understood the source of your crash with my initial example. Since you haven't used CMake to configure project, pybind didn't setup required macroses to enable threading support. So no issues in pybind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 10:47:16 2020
From: report at bugs.python.org (E. Castedo Ellerman)
Date: Fri, 28 Feb 2020 15:47:16 +0000
Subject: [issue28429] ctypes fails to import with grsecurity's TPE
In-Reply-To: <1476360738.57.0.800770600157.issue28429@psf.upfronthosting.co.za>
Message-ID: <1582904836.37.0.473898850384.issue28429@roundup.psfhosted.org>


E. Castedo Ellerman <castedo at castedo.com> added the comment:

This is now fixed in Python 3.8. See https://bugs.python.org/issue35523

----------
nosy: +E. Castedo Ellerman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28429>
_______________________________________

From report at bugs.python.org  Fri Feb 28 11:07:14 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Feb 2020 16:07:14 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
In-Reply-To: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>
Message-ID: <1582906034.98.0.411384684523.issue39783@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Possibly this could be done just by adding @lru_cache to the __new__() method.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 11:11:25 2020
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 28 Feb 2020 16:11:25 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582906285.83.0.838172799337.issue39776@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

> With python 3.7.3 without https://github.com/python/cpython/pull/5278 works just fine.

Thanks, I'm now getting the same results as you. Looking at the smaller
test case, I also agree that it should work (as it did in 3.6).

----------
keywords: +3.7regression
resolution: not a bug -> 
stage:  -> needs patch
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Fri Feb 28 11:23:17 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 28 Feb 2020 16:23:17 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
In-Reply-To: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>
Message-ID: <1582906997.15.0.830487914368.issue39783@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

There is the _closed attribute thought that is mutated by some methods.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 12:16:10 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Feb 2020 17:16:10 +0000
Subject: [issue27257] get_addresses results in traceback with an addrspec with
 an empty local part.
In-Reply-To: <1465327493.81.0.354921385455.issue27257@psf.upfronthosting.co.za>
Message-ID: <1582910170.18.0.83267850855.issue27257@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +18046
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27257>
_______________________________________

From report at bugs.python.org  Fri Feb 28 12:43:18 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 28 Feb 2020 17:43:18 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
In-Reply-To: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>
Message-ID: <1582911798.44.0.667116553294.issue39783@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

Decorating __new__ with lru_cache would likely run into memory leakage problems? (one would need a "weak lru_cache", I guess).

I didn't know about the _closed attribute. From a quick look it appears to only be settable by using the path (not the actual file) as a context manager, and only serves to block further filesystem methods, but I'm not even sure why? (for example, it doesn't block fspath, so it won't prevent operations via os.path functions anyways...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 12:44:14 2020
From: report at bugs.python.org (Marco Sulla)
Date: Fri, 28 Feb 2020 17:44:14 +0000
Subject: [issue39784] Tuple comprehension
Message-ID: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

I think a tuple comprehension could be very useful.

Currently, the only way to efficiently create a tuple from a comprehension is to create a list comprehension (generator comprehensions are more slow) and convert it with `tuple()`.

A tuple comprehension will do exactly the same thing, but without the creation of the intermediate list.

IMHO a tuple comprehension can be very useful, because:

1. there are many cases in which you create a list with a comprehension, but you'll never change it later. You could simply convert it with `tuple()`, but it will require more time
2. tuples uses less memory than lists
3. tuples can be interned

As syntax, I propose 

(* expr for x in iterable *)

with absolutely no blank character between the character ( and the *, and the same for ).

Well, I know, it's a bit strange syntax... but () are already taken by generator comprehensions. Furthermore, the * remembers a snowflake, and tuples are a sort of "frozenlists".

----------
components: Interpreter Core
messages: 362888
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Tuple comprehension
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 12:53:09 2020
From: report at bugs.python.org (Chris Wilcox)
Date: Fri, 28 Feb 2020 17:53:09 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1582912389.57.0.503929886741.issue14678@roundup.psfhosted.org>


Chris Wilcox <python at crwilcox.com> added the comment:

That is my thinking as well after rooting around a bit. I unfortunately am not knowledgable enough here to be 100% sure it is complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:11:44 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Feb 2020 18:11:44 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1582913504.7.0.910131386752.issue37266@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

There will be a problem with `concurrent.futures.ProcessPoolExecutor`, which currently launches its management thread as a daemon thread.  The daemon thread itself is not problematic, because ProcessPoolExecutor uses an atexit hook to shutdown itself and therefore join the management thread.

It seems, however, that it's not easy to make the thread non-daemon, because atexit hooks are executed *after* non-daemon threads are joined.  That would lead to a deadlock: the interpreter would wait for the non-daemon management thread to exit, but the ProcessPoolExecutor would wait for the atexit hook to be called before telling the management thread to exit.

cc'ing Thomas Moreau, who's worker a lot on this.

----------
nosy: +pitrou, tomMoral

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:13:32 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Feb 2020 18:13:32 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1582913612.09.0.171810502154.issue37266@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps the solution would be to have an additional kind of atexit hooks, which get executed before threads are joined.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:15:33 2020
From: report at bugs.python.org (fireattack)
Date: Fri, 28 Feb 2020 18:15:33 +0000
Subject: [issue39785] usr/bin/python doesn't use default python (3) on Windows
Message-ID: <1582913733.02.0.573169535769.issue39785@roundup.psfhosted.org>


New submission from fireattack <human.peng at gmail.com>:

STR

1. Install both Py2 and 3. 
2. Make sure Py3 is the default.
3. (Optional) Make sure only Python3 is in path, not Python2.

Run the following script from CMD:

```
#!/usr/bin/python

import platform
print(platform.python_version())
```

What expected:

3.8.1

What happened: 

2.8.5

According to https://docs.python.org/3/using/windows.html#shebang-lines, `#!/usr/bin/python` should use the default python. My environment is set to default to py3, and I don't even have python2 in my PATH. 

C:\Users\ikena\Desktop>py --version
Python 3.8.1

C:\Users\ikena\Desktop>python --version
Python 3.8.1

C:\Users\ikena\Desktop>where python
C:\Users\ikena\AppData\Local\Programs\Python\Python38\python.exe
C:\Users\ikena\AppData\Local\Microsoft\WindowsApps\python.exe

----------
components: Windows
messages: 362892
nosy: fireattack, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: usr/bin/python doesn't use default python (3) on Windows
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39785>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:16:39 2020
From: report at bugs.python.org (Ryan Ware)
Date: Fri, 28 Feb 2020 18:16:39 +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: <1582913799.34.0.827106153022.issue38576@roundup.psfhosted.org>


Change by Ryan Ware <ryan.r.ware at intel.com>:


----------
nosy: +ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38576>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:18:53 2020
From: report at bugs.python.org (fireattack)
Date: Fri, 28 Feb 2020 18:18:53 +0000
Subject: [issue39785] usr/bin/python doesn't use default python (3) on Windows
In-Reply-To: <1582913733.02.0.573169535769.issue39785@roundup.psfhosted.org>
Message-ID: <1582913933.44.0.843548515835.issue39785@roundup.psfhosted.org>


fireattack <human.peng at gmail.com> added the comment:

I've searched and found some related issue, but none is specific for this. 

For example, Segev Finer mentioned that "[..] "#!/usr/bin/python" which will prefer Python 2" in issue 34274 but didn't mention why it would/should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39785>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:21:06 2020
From: report at bugs.python.org (fireattack)
Date: Fri, 28 Feb 2020 18:21:06 +0000
Subject: [issue39785] #!/usr/bin/python shebang doesn't use default python (3)
 on Windows
In-Reply-To: <1582913733.02.0.573169535769.issue39785@roundup.psfhosted.org>
Message-ID: <1582914066.7.0.774946975435.issue39785@roundup.psfhosted.org>


Change by fireattack <human.peng at gmail.com>:


----------
title: usr/bin/python doesn't use default python (3) on Windows -> #!/usr/bin/python shebang doesn't use default python (3) on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39785>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:23:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 18:23:02 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582914182.5.0.465325614055.issue39781@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset c705fd1e89ccb8f6d414ec817b4616546147d877 by Terry Jan Reedy in branch 'master':
bpo-39781: Do not jump when select in IDLE codecontext (GH-18683)
https://github.com/python/cpython/commit/c705fd1e89ccb8f6d414ec817b4616546147d877


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:23:30 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 18:23:30 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582914210.17.0.430612074542.issue39781@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +18047
pull_request: https://github.com/python/cpython/pull/18688

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:23:38 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 18:23:38 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582914218.27.0.846988640161.issue39781@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18048
pull_request: https://github.com/python/cpython/pull/18689

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:24:33 2020
From: report at bugs.python.org (fireattack)
Date: Fri, 28 Feb 2020 18:24:33 +0000
Subject: [issue39785] #!/usr/bin/python shebang doesn't use default python (3)
 on Windows
In-Reply-To: <1582913733.02.0.573169535769.issue39785@roundup.psfhosted.org>
Message-ID: <1582914273.05.0.269664522791.issue39785@roundup.psfhosted.org>


fireattack <human.peng at gmail.com> added the comment:

Interestingly, I can't seem to reproduce this bug on my another Win7 machine with similar setup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39785>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:29:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 18:29:16 +0000
Subject: [issue39785] #!/usr/bin/python shebang doesn't use default python (3)
 on Windows
In-Reply-To: <1582913733.02.0.573169535769.issue39785@roundup.psfhosted.org>
Message-ID: <1582914556.65.0.907846191975.issue39785@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is not strictly a duplicate of issue28686, but it's close enough, so let's keep the discussion of changing the original shebang behaviour over no that issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> py.exe ignored PATH when using python3 shebang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39785>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:29:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 18:29:38 +0000
Subject: [issue34274] Python launcher behavior with "#!/usr/bin/env python"
 shebang
In-Reply-To: <1532900839.39.0.56676864532.issue34274@psf.upfronthosting.co.za>
Message-ID: <1582914578.98.0.227277947182.issue34274@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is not strictly a duplicate of issue28686, but it's close enough, so let's keep the discussion of changing the original shebang behaviour over on that issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34274>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:29:52 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 18:29:52 +0000
Subject: [issue34274] Python launcher behavior with "#!/usr/bin/env python"
 shebang
In-Reply-To: <1532900839.39.0.56676864532.issue34274@psf.upfronthosting.co.za>
Message-ID: <1582914592.91.0.261495429192.issue34274@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
superseder:  -> py.exe ignored PATH when using python3 shebang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34274>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:37:00 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 28 Feb 2020 18:37:00 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582915020.73.0.442346306408.issue39784@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

This change needs to be discussed first on Python-ideas, and ideally needs a PEP (and a sponsor). So you should post it on Python-ideas mailing list or discuss.python.org Ideas section.

----------
nosy: +Batuhan Taskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:37:40 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 28 Feb 2020 18:37:40 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582915060.07.0.889932495557.issue39784@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
Removed message: https://bugs.python.org/msg362898

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:37:48 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 28 Feb 2020 18:37:48 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582915068.04.0.855058395906.issue39784@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

This change needs to be discussed first on Python-ideas, and ideally needs a PEP (and a sponsor). So you should post it on Python-ideas mailing list or discuss.python.org Ideas section.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:41:23 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 18:41:23 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582915283.48.0.165280693168.issue39781@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f4198aee4c288ce47c5803e87a461e31f81a0138 by Miss Islington (bot) in branch '3.7':
bpo-39781: Do not jump when select in IDLE codecontext (GH-18683)
https://github.com/python/cpython/commit/f4198aee4c288ce47c5803e87a461e31f81a0138


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:42:10 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 18:42:10 +0000
Subject: [issue28686] py.exe ignored PATH when using python3 shebang
In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za>
Message-ID: <1582915330.26.0.138709494574.issue28686@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

So we're missing two things to move this forward:

1. A clear specification (and user-facing explanation) of the behaviour of py.exe in the presence of all possible shebangs and PATH settings
2. Someone willing to update the code

Given the current behaviour is described in PEP 397, step one probably requires a new PEP (unless it turns out to be a single sentence explanation, which so far, it has not). I'd be happy to sponsor such a PEP, but I don't feel the need for it and so I'm not inclined to write it myself.

Also worth noting is that the Microsoft Store package of Python *does* include versioned executables (because we're able to provide them without causing excessive clutter on PATH), but it does not include py.exe (because the versioning of that would get broken really quickly).

----------
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28686>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:43:28 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 18:43:28 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582915408.75.0.420186616396.issue39781@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 846ca4961da24669e6e0c901986e66ff485917b2 by Miss Islington (bot) in branch '3.8':
bpo-39781: Do not jump when select in IDLE codecontext (GH-18683)
https://github.com/python/cpython/commit/846ca4961da24669e6e0c901986e66ff485917b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39781>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:47:55 2020
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Feb 2020 18:47:55 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582915675.17.0.381830183645.issue39771@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since Outlook is one of the mailers that generates the non-RFC-compliant headers, it doesn't surprise me all that much that it can't interpret the RFC compliant headers correctly.

I'm not sure there is anything we can do here.

I suppose someone could do a survey of mail clients and document which ones can handle which style of parameter encoding.  If it turns out more handle the "wrong" way than handle the "right" way, we could consider adopting to the de-facto standard, although I won't like it much :)

(There is also a possibility there is a bug in our RFC compliance, but this is the first problem report I've seen.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:55:13 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Feb 2020 18:55:13 +0000
Subject: [issue39704] Disable code coverage
In-Reply-To: <1582241922.94.0.0257768022577.issue39704@roundup.psfhosted.org>
Message-ID: <1582916113.46.0.58115902725.issue39704@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I don't know if backporting will be needed; probably depends on the CI and whether they always pull from master or the branch that was affected. But I just tried backporting regardless and there's conflicts, so it will have to be done manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39704>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:55:54 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 18:55:54 +0000
Subject: [issue39781] IDLE: Do not jump when select in codecontext
In-Reply-To: <1582859719.48.0.980553540558.issue39781@roundup.psfhosted.org>
Message-ID: <1582916154.08.0.468742138416.issue39781@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/issue39781>
_______________________________________

From report at bugs.python.org  Fri Feb 28 13:59:49 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Feb 2020 18:59:49 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1582916389.64.0.636433406969.issue14678@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

It looks like it hasn't been done, else https://github.com/python/cpython/blob/master/Lib/zipimport.py would have some definition of a invalidate_caches() method. And specifically the finder lacks that method so it can be called by https://github.com/python/cpython/blob/c705fd1e89ccb8f6d414ec817b4616546147d877/Lib/importlib/_bootstrap_external.py#L1245-L1257.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:07:10 2020
From: report at bugs.python.org (R. David Murray)
Date: Fri, 28 Feb 2020 19:07:10 +0000
Subject: [issue39757] EmailMessage bad encoding for international domain
In-Reply-To: <1582709775.3.0.571538664603.issue39757@roundup.psfhosted.org>
Message-ID: <1582916830.2.0.14436183766.issue39757@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is not actually a duplicate of 11783.  Rereading (parts of) that issue, we decided we currently have no good way to do automatic conversion between unicode and internationalized domains, so the user of the library has to do it themselves.  This means that the bug *here* is that the new email API is *wrongly* encoding the non-ascii in the domain by using an encoded word.  I'm surprised at that; I thought I'd guarded against it.

What should be happening here is that an error should be raised when that header is set (or possibly when it is accessed/serialized, but when set would be better I think) saying that there is non-ascii in the domain part.

----------
resolution: duplicate -> 
stage: resolved -> needs patch
status: closed -> open
superseder: email parseaddr and formataddr should be IDNA aware -> 
title: EmailMessage wrong encoding for international domain -> EmailMessage bad encoding for international domain

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39757>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:18:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 19:18:13 +0000
Subject: [issue8824] Improve documentation of exec
In-Reply-To: <1274895407.96.0.160223468489.issue8824@psf.upfronthosting.co.za>
Message-ID: <1582917493.88.0.425447383679.issue8824@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I decided that the alternate addition in #13557 is enough.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8824>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:27:50 2020
From: report at bugs.python.org (fireattack)
Date: Fri, 28 Feb 2020 19:27:50 +0000
Subject: [issue28686] py.exe ignored PATH when using python3 shebang
In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za>
Message-ID: <1582918070.48.0.701329400751.issue28686@roundup.psfhosted.org>


fireattack <human.peng at gmail.com> added the comment:

Just copy/paste a related issue reported in issue39785:

When run a python script with "#!/usr/bin/python" shebang with py.exe, it will always use python2 instead of python3 on Win 10, despite the default being set to py3 already (so does the PATH).

According to https://docs.python.org/3/using/windows.html#shebang-lines, `#!/usr/bin/python` should use the default python, not just python 2.

----------
nosy: +fireattack

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28686>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:41:27 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 19:41:27 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582918887.64.0.946995467164.issue13790@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +18049
pull_request: https://github.com/python/cpython/pull/18690

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:44:20 2020
From: report at bugs.python.org (signing_agreement)
Date: Fri, 28 Feb 2020 19:44:20 +0000
Subject: [issue39786] Have the heaps library support max heap
Message-ID: <1582919060.63.0.948721548128.issue39786@roundup.psfhosted.org>


New submission from signing_agreement <kuglasses at gmail.com>:

For numeric types, I can negate the numeric argument for max heaps, but if I have strings, I cannot go about negating them.

----------
components: Library (Lib)
messages: 362909
nosy: signing_agreement
priority: normal
severity: normal
status: open
title: Have the heaps library support max heap
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39786>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:46:46 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 19:46:46 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582919206.74.0.777040060897.issue13790@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PR-18690 makes the approved change of 'string' to 'specification'.  After merging, I will re-review the other changes in i13790b.diff and possibly make another PR for review.

----------
versions: +Python 3.9 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:53:54 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 28 Feb 2020 19:53:54 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1582919634.29.0.85106087207.issue37266@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also cc'ing Kyle for the concurrent.futures issue.

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:54:02 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 19:54:02 +0000
Subject: [issue36516] Python Launcher can not recognize pyw file as Python GUI
 Script file type correctly.
In-Reply-To: <1554272827.64.0.548414335806.issue36516@roundup.psfhosted.org>
Message-ID: <1582919642.43.0.110209711198.issue36516@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I might have missed something, but I thought .pyw files were a Windows specific thing.

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36516>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:57:51 2020
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 28 Feb 2020 19:57:51 +0000
Subject: [issue39710] "will be returned as unicode" reminiscent from Python 2
In-Reply-To: <1582300708.21.0.335550003251.issue39710@roundup.psfhosted.org>
Message-ID: <1582919871.08.0.474524329173.issue39710@roundup.psfhosted.org>


Change by Pete Wicken <petewicken at gmail.com>:


----------
nosy: +Wicken
nosy_count: 3.0 -> 4.0
pull_requests: +18050
pull_request: https://github.com/python/cpython/pull/18691

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39710>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:59:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 19:59:23 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582919963.48.0.414740800476.issue13790@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 916895f93905f8b8dad677cceff501833f5a633a by Terry Jan Reedy in branch 'master':
bpo-13790: Change 'string' to 'specification' in format doc (GH-18690)
https://github.com/python/cpython/commit/916895f93905f8b8dad677cceff501833f5a633a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 14:59:30 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 19:59:30 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582919970.44.0.0211953142216.issue13790@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +18052
pull_request: https://github.com/python/cpython/pull/18692

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 15:00:10 2020
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 28 Feb 2020 20:00:10 +0000
Subject: [issue39710] "will be returned as unicode" reminiscent from Python 2
In-Reply-To: <1582300708.21.0.335550003251.issue39710@roundup.psfhosted.org>
Message-ID: <1582920010.87.0.502460270782.issue39710@roundup.psfhosted.org>


Change by Pete Wicken <petewicken at gmail.com>:


----------
pull_requests:  -18050

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39710>
_______________________________________

From report at bugs.python.org  Fri Feb 28 15:01:15 2020
From: report at bugs.python.org (Pete Wicken)
Date: Fri, 28 Feb 2020 20:01:15 +0000
Subject: [issue39710] "will be returned as unicode" reminiscent from Python 2
In-Reply-To: <1582300708.21.0.335550003251.issue39710@roundup.psfhosted.org>
Message-ID: <1582920075.64.0.619417585722.issue39710@roundup.psfhosted.org>


Change by Pete Wicken <petewicken at gmail.com>:


----------
pull_requests: +18053
pull_request: https://github.com/python/cpython/pull/18691

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39710>
_______________________________________

From report at bugs.python.org  Fri Feb 28 15:01:22 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 20:01:22 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582920082.37.0.962934729235.issue13790@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18054
pull_request: https://github.com/python/cpython/pull/18693

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 15:02:38 2020
From: report at bugs.python.org (Matheus Castanho)
Date: Fri, 28 Feb 2020 20:02:38 +0000
Subject: [issue39787] test_ssl and test_urllib2_localnet failing with new
 OpenSSL
Message-ID: <1582920158.93.0.343168507997.issue39787@roundup.psfhosted.org>


New submission from Matheus Castanho <msc at linux.ibm.com>:

test_ssl and test_urllib2_localnet are failing when Python is built against top-of-tree OpenSSL. I'm attaching the output of: `regrtest.py test_ssl test_urllib2_localnet -W`

The output is from a powerpc64le machine with Python 3.8.2+ (1bbb81b251bc) and OpenSSL master (db943f43a60d1b).

A git bisect showed the problems started with the following OpenSSL commit:

commit db943f43a60d1b5b1277e4b5317e8f288e7a0a3a
Author: Matt Caswell <matt at openssl.org>
Date:   Fri Jan 17 17:39:19 2020 +0000

    Detect EOF while reading in libssl
    
    If we hit an EOF while reading in libssl then we will report an error
    back to the application (SSL_ERROR_SYSCALL) but errno will be 0. We add
    an error to the stack (which means we instead return SSL_ERROR_SSL) and
    therefore give a hint as to what went wrong.
    
    Contains a partial fix for #10880
    
    Reviewed-by: Tomas Mraz <tmraz at fedoraproject.org>
    Reviewed-by: Dmitry Belyavskiy <beldmit at gmail.com>
    (Merged from https://github.com/openssl/openssl/pull/10882)

This also looks similar to: https://bugs.python.org/issue28689

----------
assignee: christian.heimes
components: SSL, Tests
files: test-output.txt
messages: 362915
nosy: christian.heimes, mscastanho
priority: normal
severity: normal
status: open
title: test_ssl and test_urllib2_localnet failing with new OpenSSL
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48931/test-output.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39787>
_______________________________________

From report at bugs.python.org  Fri Feb 28 15:04:25 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 20:04:25 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582920265.58.0.0939301427779.issue13790@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5157506e043f75f49caecae1c6afee8517a7bbb0 by Miss Islington (bot) in branch '3.7':
bpo-13790: Change 'string' to 'specification' in format doc (GH-18690)
https://github.com/python/cpython/commit/5157506e043f75f49caecae1c6afee8517a7bbb0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 15:07:00 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 20:07:00 +0000
Subject: [issue13790] In str.format an incorrect error message for list, tuple,
 dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1582920420.98.0.745845971347.issue13790@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 445152e0d3ab6e4381aef8d1404c2c17a516070f by Miss Islington (bot) in branch '3.8':
bpo-13790: Change 'string' to 'specification' in format doc (GH-18690)
https://github.com/python/cpython/commit/445152e0d3ab6e4381aef8d1404c2c17a516070f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 16:07:40 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 28 Feb 2020 21:07:40 +0000
Subject: [issue37708] Harmonize random.choice(s) behavior with random.sample
 on iterators
In-Reply-To: <1564428504.8.0.524832279971.issue37708@roundup.psfhosted.org>
Message-ID: <1582924060.95.0.823565453377.issue37708@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +18055
pull_request: https://github.com/python/cpython/pull/18694

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37708>
_______________________________________

From report at bugs.python.org  Fri Feb 28 16:36:04 2020
From: report at bugs.python.org (Marco Sulla)
Date: Fri, 28 Feb 2020 21:36:04 +0000
Subject: [issue39788] Exponential notation should return an int if it can
Message-ID: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>


New submission from Marco Sulla <launchpad.net at marco.sulla.e4ward.com>:

(venv_3_9) marco at buzz:~/sources/python-frozendict$ python
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.
>>> a = 1E9
>>> type(a)
<class 'float'>

IMHO if the exponent is positive, and the  "base number" (1 in the example) is an integer, the result should be an integer.

Optionally, also if the "base number" has a number of decimal places <= the exponent, the result should be an integer. Example:

1.25E2 == 125

If the user wants a float, it can write

1.2500E2 == 125.0

----------
components: Interpreter Core
messages: 362918
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Exponential notation should return an int if it can
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Fri Feb 28 16:41:52 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 28 Feb 2020 21:41:52 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
In-Reply-To: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>
Message-ID: <1582926112.94.0.890494554536.issue39783@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

> Decorating __new__ with lru_cache would likely run into memory leakage problems?

I think the LRU cache would be for returning the same instance when called with the same string. I don't think it would be needed to return the same instance when called with a Path instance.

> From a quick look it appears to only be settable by using the path (not the actual file) as a context manager, and only serves to block further filesystem methods, but I'm not even sure why?

This came up in bpo-39682 recently, I'm not sure what this flag is supposed to mean and I could not find it in the documentation.

Since it's uncorrelated to the file object and the physical file, I think it may actually be dangerous to rely on this flag. I don't know why is the purpose of using Path as a context manager.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:00:50 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:00:50 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1582927250.27.0.693216141205.issue38780@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Attached patch is based on Ronald Oussoren's and Alan Robertson's comments: Initialise self.socket to None early in __init()__, and then check for None in close() and emit(). Passes make test on 3.9, 3.8 and 3.7.

If this solution is ok I'll add a unit test for the case that triggered this report and prepare a PR.

----------
keywords: +patch
nosy: +erlendaasland
Added file: https://bugs.python.org/file48932/0001-bpo-38780-Harden-socket-use-in-logging.handlers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:04:15 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Fri, 28 Feb 2020 22:04:15 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582927455.33.0.41162223894.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

I think program's goal is to solve problem, not solve the "standard".

OK, if you insist that "standard" has the Top priority, could you please tell me a way to change the default behavior of the new api to use the "=?utf-8?b?" parameter style. Is there a function or parameter i can use to achieve this?

If not, i think the best way to solve it is to add a "param style" parameter that i can choose which style i use.

And if not, i am sad about this, i had to use the legacy api.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:08:32 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:08:32 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1582927712.32.0.682527647884.issue38780@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Removed file: https://bugs.python.org/file48932/0001-bpo-38780-Harden-socket-use-in-logging.handlers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:08:42 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:08:42 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1582927722.9.0.244718189294.issue38780@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


Added file: https://bugs.python.org/file48933/0001-bpo-38780-Harden-socket-use-in-logging.handlers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:20:42 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Fri, 28 Feb 2020 22:20:42 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582928442.87.0.144864388689.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

https://litmus.com/blog/infographic-the-2019-email-client-market-share

And there is a survey about email client market share. You see outlook is top 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:24:29 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 22:24:29 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582928669.66.0.6249881823.issue38380@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

We still need the tag added to the cpython-source-deps repo, and I still can't complete a clone right now (something is strange with SSL to GitHub on my (temporary) internet connection).

Zach - can you tag it? https://github.com/python/cpython-source-deps/pull/17

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:24:46 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Fri, 28 Feb 2020 22:24:46 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582928686.33.0.881886297125.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

And i just send a mail to my Gmail. I view it using web, it is incorrectly!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:26:15 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 28 Feb 2020 22:26:15 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1582928775.44.0.794230875378.issue39788@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I strongly disagree. Even if I thought it was a good idea (I don't), we'd break too much code by making this change now.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:26:21 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:26:21 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1582928781.61.0.619212429414.issue38780@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I'm a bit uncertain if the previous patch can handle the emit() case correctly. Proposed improvement in attached patch (0002-Improve-emit.patch).

----------
Added file: https://bugs.python.org/file48934/0002-Improve-emit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:27:47 2020
From: report at bugs.python.org (hwgdb Smith)
Date: Fri, 28 Feb 2020 22:27:47 +0000
Subject: [issue39771] EmailMessage.add_header doesn't work
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582928867.2.0.0784369195204.issue39771@roundup.psfhosted.org>


hwgdb Smith <hwgdb123 at gmail.com> added the comment:

Sorry, the Gmail web is correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:31:35 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:31:35 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582929095.69.0.166334630407.issue38380@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Yes, we need the tag for the Windows build, so the PR currently fails the Windows checks. (Tagging must be done explicitly by the maintainers, IIRC.) I also forgot to add a NEWS entry, so I'll do another push to add those (and kick off the CI) when the tag arrives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:33:47 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Feb 2020 22:33:47 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582929227.39.0.150024351656.issue38380@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PRs.  If we're going to update now as we should, why not to 3.31.1 which is current?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:40:42 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:40:42 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582929642.05.0.817078175948.issue38380@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

You're welcome. If you are ok with that, I'd be happy to prepare a PR for the source deps for sqlite3 v3.31.1, and update GH-18678 as soon as it is tagged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:44:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 22:44:47 +0000
Subject: [issue39789] Update Windows release build machines to latest versions
Message-ID: <1582929887.69.0.782945048331.issue39789@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Shouldn't have any impact at all, but I'm going to mention it here so it gets in the NEWS file. Just in case someone hits an obscure edge case and is trying to find out what changed.

----------
assignee: steve.dower
components: Windows
messages: 362931
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Update Windows release build machines to latest versions
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39789>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:45:08 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 22:45:08 +0000
Subject: [issue39789] Update Windows release build machines to latest versions
In-Reply-To: <1582929887.69.0.782945048331.issue39789@roundup.psfhosted.org>
Message-ID: <1582929908.27.0.590648289797.issue39789@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +18056
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39789>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:47:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Feb 2020 22:47:05 +0000
Subject: [issue36516] Python Launcher can not recognize pyw file as Python GUI
 Script file type correctly.
In-Reply-To: <1554272827.64.0.548414335806.issue36516@roundup.psfhosted.org>
Message-ID: <1582930025.5.0.187535122089.issue36516@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PR.

I believe there also used to be a distinction between .py and .pyw files back in the distant past of classic MacOS (9 and earlier) and limited support for .pyw was carried over into Mac OS X (10).  But most of the references to .pyw for macOS have been removed over the years other than, it seems, here in Python Launcher.app. There are other more basic concerns with the Launcher app so I have been holding off on merging this change for 3.9.  I plan to make a decision about its fate by the end of the PyCon sprints in April.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36516>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:52:14 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 28 Feb 2020 22:52:14 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582930334.11.0.10531805017.issue38380@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I would prefer to go to 3.31.1 at this point particularly given the track record of the SQLite project. It's been released for a month now.  Any objections, Steve?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:53:43 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 28 Feb 2020 22:53:43 +0000
Subject: [issue39682] pathlib.Path objects can be used as context managers
In-Reply-To: <1582078235.85.0.126538415089.issue39682@roundup.psfhosted.org>
Message-ID: <1582930423.99.0.883398728645.issue39682@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

A problem of having this bit of state in paths is that it violates assumptions based on immutability/hashability, e.g. with

    from pathlib import Path

    p = Path("foo")
    q = Path("foo")

    with p: pass

    unique_paths = {p, q}

    print(len(unique_paths))  # == 1, as p == q
    for path in unique_paths:
        print(path.resolve())  # Fails if the path is closed.

The last line fails with `unique_paths = {p, q}` as p has been closed (and apparently sets keep the first element when multiple "equal" elements are passed in), but not with `unique_paths = {q, p}`.

It would also prevent optimizations based on immutability as proposed in https://bugs.python.org/issue39783.

----------
nosy: +Antony.Lee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39682>
_______________________________________

From report at bugs.python.org  Fri Feb 28 17:58:58 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 28 Feb 2020 22:58:58 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582930738.17.0.963303833452.issue38380@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I agree. I've updated the branches for source deps and cpython. I'll wait for Steve's approval before I open a new PR over at cpython-source-deps and update GH-18678.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:01:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 23:01:10 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1582930870.02.0.860513717486.issue39717@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

While I have no specific opinion on tarfile, I strongly disagree with a blanket prohibition on 'from None'.  Its proper use is to maintain a defined API and hide irrelevant implementation details.  Realistic toy example:

def f(x, y):
    "Return (x+y)/y for non-zery y."

    if y == 0:  # Body 1: look ahead.
        raise ValueError('y cannot be 0')
    else:
        return (x+y)/y
# or
    try:  # Body 2: leap first.
        return (x+y)/y
    except ZeroDivisionError:
        raise ValueError('y cannot be 0') from None

'from e' instead of 'from None' would just add distracting noise.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:15:35 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 23:15:35 +0000
Subject: [issue39790] LICENSE.TXT file does not contain all incorporated
 software
Message-ID: <1582931735.09.0.762109151271.issue39790@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

Looking at https://docs.python.org/3/license.html there's a list of "incorporated software" licenses, most of which say you need to distribute the license.

Right now, the LICENSE.txt file we distribute on Windows (made from the /LICENSE and PC/crtlicense.txt files in the repo, plus those in the source dependencies) does not include any of these licenses that come from C source files.

Arguably, we should just include all of them in a central file somewhere in the repo, even though there'd be some duplication.

(I have no idea whether other distros correctly gather it all together.)

----------
components: Windows
messages: 362937
nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: LICENSE.TXT file does not contain all incorporated software
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39790>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:18:10 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 28 Feb 2020 23:18:10 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582931890.3.0.241894444584.issue38380@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Isn't that what we ended up merging? (Goes to check). Ah, that was 3.30.1.

Sure, go for it. We'll have RCs of everything before the next final releases go out, so provided someone double checks that it's all good before then I'm okay with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:22:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 23:22:04 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
In-Reply-To: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>
Message-ID: <1582932124.92.0.308398697325.issue39718@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified the additions in token.py.  Thanks for the report.

----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
type:  -> behavior
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:23:32 2020
From: report at bugs.python.org (Barney Gale)
Date: Fri, 28 Feb 2020 23:23:32 +0000
Subject: [issue39783] Optimize construction of Path from other Paths by just
 returning the same object?
In-Reply-To: <1582889797.54.0.821069987387.issue39783@roundup.psfhosted.org>
Message-ID: <1582932212.49.0.311201824084.issue39783@roundup.psfhosted.org>


Barney Gale <barney.gale at gmail.com> added the comment:

Attempted fix shown here: https://github.com/barneygale/cpython/commit/784630ef6ad05031abdefa523e61e0629b15e201

Note that I've already removed context manager support (and hence `_closed`) in this branch.

----------
nosy: +barneygale

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39783>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:25:40 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Feb 2020 23:25:40 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
In-Reply-To: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>
Message-ID: <1582932340.12.0.0100459603504.issue39718@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset c2f7eb254bee036afc8a71437ec6aac82f06a1ce by Shantanu in branch 'master':
bpo-39718: add TYPE_IGNORE, COLONEQUAL to py38 changes in token (GH-18598)
https://github.com/python/cpython/commit/c2f7eb254bee036afc8a71437ec6aac82f06a1ce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:25:50 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 23:25:50 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
In-Reply-To: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>
Message-ID: <1582932350.2.0.926156120477.issue39718@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +18057
pull_request: https://github.com/python/cpython/pull/18696

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:31:24 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Feb 2020 23:31:24 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
In-Reply-To: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>
Message-ID: <1582932684.15.0.40973542729.issue39718@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7f53d87cb0324e391c969855ed8f4b3255f9f744 by Miss Islington (bot) in branch '3.8':
bpo-39718: add TYPE_IGNORE, COLONEQUAL to py38 changes in token (GH-18598)
https://github.com/python/cpython/commit/7f53d87cb0324e391c969855ed8f4b3255f9f744


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 28 18:41:31 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Fri, 28 Feb 2020 23:41:31 +0000
Subject: [issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
In-Reply-To: <1581577789.38.0.529951784345.issue39622@roundup.psfhosted.org>
Message-ID: <1582933291.61.0.598293737087.issue39622@roundup.psfhosted.org>


Change by Maor Kleinberger <kmaork at gmail.com>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39622>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:00:14 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:00:14 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582934414.41.0.350929595504.issue39725@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Would it generaly work better if 'from None' only suppressed the previous exception?  That is the only one that the code writer knows about.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:00:55 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 29 Feb 2020 00:00:55 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1582934455.15.0.820126123677.issue39788@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Agreed with Eric.

----------
nosy: +zach.ware
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:01:01 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:01:01 +0000
Subject: [issue39718] TYPE_IGNORE,
 COLONEQUAL missing from py38 changes in token docs
In-Reply-To: <1582322500.81.0.452498925494.issue39718@roundup.psfhosted.org>
Message-ID: <1582934461.13.0.81686796784.issue39718@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/issue39718>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:03:28 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:03:28 +0000
Subject: [issue39727] cgi.parse() fatally attempts str.decode when handling
 multipart/form-data
In-Reply-To: <1582436056.52.0.172079709412.issue39727@roundup.psfhosted.org>
Message-ID: <1582934608.48.0.620601028221.issue39727@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +Rhodri James, ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39727>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:03:30 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Feb 2020 00:03:30 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582934610.56.0.904507310182.issue39784@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This was discussed on Python-Ideas:

https://mail.python.org/archives/list/python-ideas at python.org/message/LSGZF3G4RFVTKXB5Y2EW5USL2JANG5RS/

and on Discuss:

https://discuss.python.org/t/why-no-tuple-comprehension/2820/1

In both cases the consensus was mostly negative: tuple comprehensions aren't very useful, and performance of current solutions is adequate.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:05:46 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:05:46 +0000
Subject: [issue39729] stat.S_ISXXX can raise OverflowError for remote file
 modes
In-Reply-To: <1582452524.82.0.552566008779.issue39729@roundup.psfhosted.org>
Message-ID: <1582934746.37.0.608800439394.issue39729@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39729>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:09:46 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:09:46 +0000
Subject: [issue39731] ModuleNotFoundError: No module named '_ctypes'
In-Reply-To: <1582466142.44.0.612475216639.issue39731@roundup.psfhosted.org>
Message-ID: <1582934986.13.0.287049925902.issue39731@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This does not look like a bug in cpython; if is it not, it should be closed.  Please ask for help on python-list or another forum that covers installation issues.  Or maybe look for a pip user list.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39731>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:21:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:21:12 +0000
Subject: [issue39742] Enhancement: add `os.getdtablesize(..)` to `os`
 (`posix`) module
In-Reply-To: <1582576573.04.0.0159075532911.issue39742@roundup.psfhosted.org>
Message-ID: <1582935672.1.0.0478333801602.issue39742@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39742>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:22:02 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Feb 2020 00:22:02 +0000
Subject: [issue39789] Update Windows release build machines to latest versions
In-Reply-To: <1582929887.69.0.782945048331.issue39789@roundup.psfhosted.org>
Message-ID: <1582935722.4.0.286018151683.issue39789@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 03153dd1459fab94f294a118ed1525e34d58601a by Steve Dower in branch 'master':
bpo-39789: Update Windows release build machines to VS 2019 (GH-18695)
https://github.com/python/cpython/commit/03153dd1459fab94f294a118ed1525e34d58601a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39789>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:22:02 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Feb 2020 00:22:02 +0000
Subject: [issue39789] Update Windows release build machines to latest versions
In-Reply-To: <1582929887.69.0.782945048331.issue39789@roundup.psfhosted.org>
Message-ID: <1582935722.4.0.286018151683.issue39789@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 03153dd1459fab94f294a118ed1525e34d58601a by Steve Dower in branch 'master':
bpo-39789: Update Windows release build machines to VS 2019 (GH-18695)
https://github.com/python/cpython/commit/03153dd1459fab94f294a118ed1525e34d58601a


----------
message_count: 1.0 -> 2.0
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +18058
pull_request: https://github.com/python/cpython/pull/18697

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39789>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:25:25 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Feb 2020 00:25:25 +0000
Subject: [issue39789] Update Windows release build machines to latest versions
In-Reply-To: <1582929887.69.0.782945048331.issue39789@roundup.psfhosted.org>
Message-ID: <1582935925.13.0.181087478137.issue39789@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The backport to 3.8 doesn't matter so much for the build definition (the build always runs from master, even when targeting earlier versions), but the minor Nuget fixes are necessary, so may as well keep it all in sync.

I expect the backport to automerge, so closing.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39789>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:32:25 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 00:32:25 +0000
Subject: [issue39745] BlockingIOError.characters_written represents number of
 bytes not characters
In-Reply-To: <1582598879.29.0.157478927981.issue39745@roundup.psfhosted.org>
Message-ID: <1582936345.23.0.18938305806.issue39745@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Antoine, Although the text may have preceded your OSError reorganization, you were the last to touch this entry.  Is is correct, or does it need change?

Revision: f55011f8b63d3b046c1ec580312bc52ca47d721b
Author: Antoine Pitrou <solipsis at pitrou.net>
Date: 10/12/2011 12:57:23 PM
Message:
Update doc for BlockingIOError and its alias in the io module

----------
nosy: +pitrou, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39745>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:34:37 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Feb 2020 00:34:37 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582936477.17.0.062097382202.issue39784@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Regarding performance, on my computer, the overhead of calling tuple() on a list comp ranges from about 30% for tiny sequences down to about 5% for largish sequences.

Tiny sequences are fast either way:

[steve at ando cpython]$ ./python -m timeit "[i for i in (1,2,3)]"
50000 loops, best of 5: 5.26 usec per loop

[steve at ando cpython]$ ./python -m timeit "tuple([i for i in (1,2,3)])"
50000 loops, best of 5: 6.95 usec per loop


and for large sequences the time is dominated by the comprehension, not the call to tuple:

[steve at ando cpython]$ ./python -m timeit "[i for i in range(1000000)]"
1 loop, best of 5: 1.04 sec per loop

[steve at ando cpython]$ ./python -m timeit "tuple([i for i in range(1000000)])"
1 loop, best of 5: 1.1 sec per loop

(As the size of the list increases, the proportion of the time spent in calling tuple() approaches zero.)

So it is true that there is an opportunity to optimize the creation of a tuple. But we should all be aware of the dangerous of premature optimization and wasting our efforts on optimizing something that doesn't matter.

Marco, can you demonstrate an actual real piece of code, not a made-up contrived example, where the overhead of calling tuple is a bottleneck, or even a significant slow-down?



In real code, I would expect the processing inside the comprehension to be significant, which would decrease the proportional cost of calling tuple even more.


[steve at ando cpython]$ ./python -m timeit "[i**3 + 7*i**2 - 45*i + 11 
    for i in range(500) if (i%7 in (2, 3, 5))]"
100 loops, best of 5: 3.02 msec per loop


[steve at ando cpython]$ ./python -m timeit "tuple(
    [i**3 + 7*i**2 - 45*i + 11 
    for i in range(500) if (i%7 in (2, 3, 5))])"
100 loops, best of 5: 3.03 msec per loop


Remember too that timings of Python code on real computers is subject to a significant amount of variability and noise due to all the other processes running at the same time, from the OS down to other applications. In my tests, I found no less than five pairs of measurement where the call to tuple was faster than NOT calling tuple. This is of course impossible, but it demonstrates that the overhead of calling tuple is small enough that it is within the range of random variation in time.

The bottom line is that while this would be a genuine micro-optimization, it is doubtful that it would make a significant difference to performance of programs apart from contrived benchmarks.

(On the other hand, C is so fast overall because everything in C is micro-optimized.)

If adding tuple comprehensions were free of any other cost, I would say "Sure, why not? It can't hurt." but they are not. Inventing new, ugly, fragile syntax is a tax on the programmer's performance and the ability of newcomers to learn the language. Readability matters.

So I am a very strong -1 vote on the proposed syntax, even if it would micro-optimize the creation of a tuple.

Marco, if you still want to argue for this, you will need to

(1) take it back to Python-Ideas, hopefully to get consensus on syntax or at least a couple of options to choose between;

(2) find a core developer willing to sponsor a PEP;

(3) write a PEP;

(4) and get the PEP accepted.


I'm closing this as Pending/Postponed. If you get a PEP accepted, you can re-open it.

----------
resolution:  -> postponed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:41:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Feb 2020 00:41:06 +0000
Subject: [issue39789] Update Windows release build machines to latest versions
In-Reply-To: <1582929887.69.0.782945048331.issue39789@roundup.psfhosted.org>
Message-ID: <1582936866.96.0.899560993781.issue39789@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 45c4112b7250cb600aa2f3a42b4e6b5bfd2919c4 by Miss Islington (bot) in branch '3.8':
bpo-39789: Update Windows release build machines to VS 2019 (GH-18695)
https://github.com/python/cpython/commit/45c4112b7250cb600aa2f3a42b4e6b5bfd2919c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39789>
_______________________________________

From report at bugs.python.org  Fri Feb 28 19:44:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Feb 2020 00:44:26 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1582937066.49.0.172378292484.issue39788@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I agree with both Eric and Zachary, but I just wanted to point out that in a Python interpreter with a keyhole optimizer, you can expect that expressions like `1*10**9` to be a constant:

# Python 3.5
py> from dis import dis
py> dis('1*10**9')
  1           0 LOAD_CONST               4 (1000000000)
              3 RETURN_VALUE

Marco, if you are worried about the performance cost of multiplying by a power of ten when creating constants, you shouldn't.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:03:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 01:03:17 +0000
Subject: [issue39772] Python 2 FAQ shown in help@python.org auto reply
In-Reply-To: <1582790239.29.0.848001765747.issue39772@roundup.psfhosted.org>
Message-ID: <1582938197.73.0.717047396558.issue39772@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The autoresponse seems not to be in any .rst, .htm, .html, or .txt file in the cpython/python repository, so this tracker is not the right place for this issue.  I have sent a change request to both help at python.org and webmaster at python.org.

----------
nosy: +terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39772>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:14:25 2020
From: report at bugs.python.org (Mats Wichmann)
Date: Sat, 29 Feb 2020 01:14:25 +0000
Subject: [issue39772] Python 2 FAQ shown in help@python.org auto reply
In-Reply-To: <1582790239.29.0.848001765747.issue39772@roundup.psfhosted.org>
Message-ID: <1582938865.12.0.777480214179.issue39772@roundup.psfhosted.org>


Mats Wichmann <mats at python.org> added the comment:

Admit it doesn't seem vastly helpful to pile on with a "not us", but the current webmaster@ autoreply is here: https://github.com/tjguk/python-webmaster/blob/master/auto-responder.txt/.  It contains this link: https://docs.python.org/3/faq/index.html/. Don't know where the help@ one comes from.

----------
nosy: +mwichmann

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39772>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:26:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 01:26:00 +0000
Subject: [issue39782] local varible referenced a Exception won't be collected
 in function
In-Reply-To: <1582888710.58.0.0521565801778.issue39782@roundup.psfhosted.org>
Message-ID: <1582939560.94.0.360207315872.issue39782@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

For beginners, 'is this a Python bug' questions should usually be directed elsewhere for initial review.

https://docs.python.org/3/reference/compound_stmts.html#the-try-statement

"When an exception has been assigned using as target, it is cleared at the end of the except clause. This is as if

except E as N:
    foo

was translated to

except E as N:
    try:
        foo
    finally:
        del N

This means the exception must be assigned to a different name to be able to refer to it after the except clause. Exceptions are cleared because with the traceback attached to them, they form a reference cycle with the stack frame, keeping all locals in that frame alive until the next garbage collection occurs."

"l['e']" is the first new name.  "b" in each locals is the second.  Without "b = ..." there is no increase because l['e'] gets replaced on each call.  But inserting each exception into the next locals (see "keeping all locals in that frame alive") in effect makes a linked list of frames and locals.

If one wants to keep multiple exceptions around, best to copy just the info one want kept.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39782>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:28:40 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Feb 2020 01:28:40 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582939720.5.0.247859836184.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 02673352b5db6ca4d3dc804965facbedfe66425d by Gregory P. Smith in branch 'master':
bpo-39769: Fix compileall ddir for subpkgs. (GH-18676)
https://github.com/python/cpython/commit/02673352b5db6ca4d3dc804965facbedfe66425d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:29:46 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 01:29:46 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582939786.71.0.278345678598.issue39784@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

-1 also, not worth the cost, so I would not bother with python-ideas.

----------
nosy: +terry.reedy
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:31:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Feb 2020 01:31:12 +0000
Subject: [issue39784] Tuple comprehension
In-Reply-To: <1582911854.61.0.127481778131.issue39784@roundup.psfhosted.org>
Message-ID: <1582939872.27.0.924841637071.issue39784@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'pending' is a worthless state because any subsequent post changes back to 'open'.

----------
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39784>
_______________________________________

From report at bugs.python.org  Fri Feb 28 20:50:03 2020
From: report at bugs.python.org (fireattack)
Date: Sat, 29 Feb 2020 01:50:03 +0000
Subject: [issue28686] py.exe ignored PATH when using python3 shebang
In-Reply-To: <1479110844.15.0.911795795866.issue28686@psf.upfronthosting.co.za>
Message-ID: <1582941003.47.0.186038133912.issue28686@roundup.psfhosted.org>


fireattack <human.peng at gmail.com> added the comment:

More interestingly, I can't reproduce the same bug on my another Win 7 machine with similar setup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28686>
_______________________________________

From report at bugs.python.org  Fri Feb 28 21:02:43 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 29 Feb 2020 02:02:43 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1582941763.47.0.513169881402.issue37266@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> The daemon thread itself is not problematic, because ProcessPoolExecutor uses an atexit hook to shutdown itself and therefore join the management thread.

ThreadPoolExecutor also uses an atexit hook for its shutdown process. Also, it sets each worker thread to a daemon. So we'd definitely have to address as well that prior to killing off daemon threads.

> Perhaps the solution would be to have an additional kind of atexit hooks, which get executed before threads are joined.

Hmm, a potential way to do this might be adding a form of "atexit hook" support that's specific to threads. Each registered function would get called in the internal `_shutdown()` [1] function in the threading module, just before all of the non-daemon threads are joined. To me, this seems best implemented as a new public function for the threading module, perhaps something like `threading.register_atexit()`. Would this be reasonable?

---

[1] - IIUC, `threading._shutdown()` is called in pylifecycle.c, in `wait_for_thread_shutdown()`, which is the way that non-daemon threads are joined when the interpreter shuts down in `Py_EndInterpreter()` or is finalized in `Py_FinalizeEx()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Fri Feb 28 21:13:07 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Feb 2020 02:13:07 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1582942387.68.0.440982804517.issue39769@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

keeping this open while i investigate if fixing 3.8 and 3.7 is feasible.  if nothing else i'll try to add a note to the docs about the issue in 3.5-3.8 with a code sample suggested workaround.

----------
resolution:  -> fixed
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Fri Feb 28 23:11:30 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 29 Feb 2020 04:11:30 +0000
Subject: [issue39791] New `files()` api from importlib_resources.
Message-ID: <1582949490.73.0.868974160192.issue39791@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In the [importlib_resources backport](https://gitlab.com/python-devs/importlib_resources/)... in particular in [issue 58](https://gitlab.com/python-devs/importlib_resources/issues/58) and [merge request 76](https://gitlab.com/python-devs/importlib_resources/-/merge_requests/76), the backport now has a new feature, a "files()" function.

Let's incorporate that functionality into importlib.resources.

----------
messages: 362962
nosy: jaraco
priority: normal
severity: normal
status: open
title: New `files()` api from importlib_resources.
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39791>
_______________________________________

From report at bugs.python.org  Fri Feb 28 23:11:49 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 29 Feb 2020 04:11:49 +0000
Subject: [issue39791] New `files()` api from importlib_resources.
In-Reply-To: <1582949490.73.0.868974160192.issue39791@roundup.psfhosted.org>
Message-ID: <1582949509.43.0.703334993036.issue39791@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jaraco
components: +Library (Lib)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39791>
_______________________________________

From report at bugs.python.org  Sat Feb 29 00:37:41 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 05:37:41 +0000
Subject: [issue38380] Update SQLite to 3.30 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582954661.34.0.705282334837.issue38380@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Great, thanks folks! I've pushed an update to GH-18678.

(BTW, is it kosher to force push to PRs like this?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Sat Feb 29 00:38:34 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 05:38:34 +0000
Subject: [issue38380] Update SQLite to 3.31.1 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582954714.87.0.910100619983.issue38380@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
title: Update SQLite to 3.30 in Windows and macOS installer builds -> Update SQLite to 3.31.1 in Windows and macOS installer builds

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Sat Feb 29 00:46:59 2020
From: report at bugs.python.org (swgmma)
Date: Sat, 29 Feb 2020 05:46:59 +0000
Subject: [issue30082] hide command prompt when using subprocess.Popen with
 shell=False on Windows
In-Reply-To: <1492363586.51.0.498152844874.issue30082@psf.upfronthosting.co.za>
Message-ID: <1582955219.07.0.844586677952.issue30082@roundup.psfhosted.org>


Change by swgmma <jason.nader at protonmail.com>:


----------
nosy: +swgmma

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30082>
_______________________________________

From report at bugs.python.org  Sat Feb 29 01:04:20 2020
From: report at bugs.python.org (Masahiro Sakai)
Date: Sat, 29 Feb 2020 06:04:20 +0000
Subject: [issue39792] Two Ctrl+C is required to terminate when a pipe is
 blocking
Message-ID: <1582956260.49.0.773143606041.issue39792@roundup.psfhosted.org>


New submission from Masahiro Sakai <masahiro.sakai at gmail.com>:

I noticed that two Ctrl+C instead of one are required to terminate following program on macOS and Linux.
I guess that the first Ctrl+C is ignored inside one of the finalizers.

----
import os

def main():
    r, w = os.pipe()
    f_w = os.fdopen(w, "w")
    f_w.buffer.write(b"a" * 65536)
    f_w.buffer.write(b"b")

main()
----

----------
components: IO
messages: 362964
nosy: msakai
priority: normal
severity: normal
status: open
title: Two Ctrl+C is required to terminate when a pipe is blocking
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/issue39792>
_______________________________________

From report at bugs.python.org  Sat Feb 29 01:22:44 2020
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 29 Feb 2020 06:22:44 +0000
Subject: [issue39791] New `files()` api from importlib_resources.
In-Reply-To: <1582949490.73.0.868974160192.issue39791@roundup.psfhosted.org>
Message-ID: <1582957364.88.0.292740405384.issue39791@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39791>
_______________________________________

From report at bugs.python.org  Sat Feb 29 01:46:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 29 Feb 2020 06:46:36 +0000
Subject: [issue39725] unrelated `from None` exceptions lose prior exception
 information
In-Reply-To: <1582405503.93.0.737085396902.issue39725@roundup.psfhosted.org>
Message-ID: <1582958796.3.0.212573522827.issue39725@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Because there may be more exceptions than the code writer know. The code raised OverflowError and ValueError may be in different function, so the code writer know only about ValueError, but OverflowError is an implementation detail (and may be absent in other versions).

Currently the code writer has to write the cumbersome code

        was_raised = False
        try:
            foo()  # may raise ValueError -> OverflowError
        except:
            was_raised = True
        if was_raised:
            raise KeyError from None

if they want to suppress only exceptions raised in foo(). And it is worse in case of finally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39725>
_______________________________________

From report at bugs.python.org  Sat Feb 29 02:50:08 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Feb 2020 07:50:08 +0000
Subject: [issue39786] Have the heaps library support max heap
In-Reply-To: <1582919060.63.0.948721548128.issue39786@roundup.psfhosted.org>
Message-ID: <1582962608.72.0.103761714537.issue39786@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestion, but I am going to decline.  The min heap has suffices for a wide variety of use cases for many, many years.  I see your point when it comes to strings, but that is a somewhat exotic use case.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39786>
_______________________________________

From report at bugs.python.org  Sat Feb 29 02:53:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Feb 2020 07:53:50 +0000
Subject: [issue39776] Crash in decimal module in heavy-multithreaded scenario
In-Reply-To: <1582817113.42.0.194070983198.issue39776@roundup.psfhosted.org>
Message-ID: <1582962830.16.0.655535476944.issue39776@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39776>
_______________________________________

From report at bugs.python.org  Sat Feb 29 03:07:57 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 29 Feb 2020 08:07:57 +0000
Subject: [issue36516] Python Launcher can not recognize pyw file as Python GUI
 Script file type correctly.
In-Reply-To: <1554272827.64.0.548414335806.issue36516@roundup.psfhosted.org>
Message-ID: <1582963677.74.0.908720782337.issue36516@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm fairly sure support for .pyw, or rather a separate python executable, was introduced in the MacOSX port. In particular, we started out with two different executables "python" and "pythonw" where the first was the regular python executable, while the second did the "launch executable in Python.app" dance to support GUI code from the command-line.  This was changed later on to always use the executable from Python.app.

P.S. I still think Python Launcher is worrisome from a security standpoint (#5262).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36516>
_______________________________________

From report at bugs.python.org  Sat Feb 29 03:22:41 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 29 Feb 2020 08:22:41 +0000
Subject: [issue37534] In minidom module ability to add Standalone Document
 Declaraion is missing while generating XML documents
In-Reply-To: <1562714811.12.0.95150258791.issue37534@roundup.psfhosted.org>
Message-ID: <1582964561.72.0.320809122864.issue37534@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset dc04a0571e362cd3de040771d7705cb107ae26fc by Henry Harutyunyan in branch 'master':
bpo-37534: Allow adding Standalone Document Declaration when generating XML documents (GH-14912)
https://github.com/python/cpython/commit/dc04a0571e362cd3de040771d7705cb107ae26fc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37534>
_______________________________________

From report at bugs.python.org  Sat Feb 29 03:23:51 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 29 Feb 2020 08:23:51 +0000
Subject: [issue37534] In minidom module ability to add Standalone Document
 Declaraion is missing while generating XML documents
In-Reply-To: <1562714811.12.0.95150258791.issue37534@roundup.psfhosted.org>
Message-ID: <1582964631.3.0.201546011346.issue37534@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37534>
_______________________________________

From report at bugs.python.org  Sat Feb 29 04:56:17 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 09:56:17 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
Message-ID: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

$ ./python -m test test_email
0:00:00 load avg: 0.25 Run tests sequentially
0:00:00 load avg: 0.25 [1/1] test_email
test test_email failed -- Traceback (most recent call last):
  File "/usr/home/isidentical/cpython/Lib/test/test_email/test_email.py", line 3345, in test_make_msgid_default_domain
    self.assertTrue(
AssertionError: False is not true

test_email failed

== Tests result: FAILURE ==

1 test failed:
    test_email

Total duration: 9.5 sec
Tests result: FAILURE

>>> socket.getfqdn()
'xxx.com'
>>> socket.getfqdn()
'yyy.org'
>>> socket.getfqdn()
'xxx.com'
>>> socket.getfqdn()
'xxx.yyy.com'

----------
components: email
messages: 362969
nosy: BTaskaya, barry, r.david.murray
priority: normal
severity: normal
status: open
title: make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Sat Feb 29 04:59:53 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 09:59:53 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1582970393.18.0.671407024089.issue39793@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18059
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18698

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Sat Feb 29 06:17:39 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Feb 2020 11:17:39 +0000
Subject: [issue38380] Update SQLite to 3.31.1 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582975059.43.0.685806911068.issue38380@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> (BTW, is it kosher to force push to PRs like this?)

We always squash merge, so you don't need to do it to hide your history. Personally, I do it occasionally when the history is very long and nobody has started reviewing.

Force pushing will reset any reviews, so you'll be forcing reviewers to start again instead of just looking at your updates. Some reviewers (e.g. me) will often defer a full rereview if we don't have a lot of time and someone just force pushed. So in general, avoid it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Sat Feb 29 06:19:24 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Sat, 29 Feb 2020 11:19:24 +0000
Subject: [issue39517] runpy calls open_code with Path object
In-Reply-To: <1580576532.94.0.922991847859.issue39517@roundup.psfhosted.org>
Message-ID: <1582975164.27.0.239021314242.issue39517@roundup.psfhosted.org>


Change by Maor Kleinberger <kmaork at gmail.com>:


----------
keywords: +patch
pull_requests: +18060
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18699

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39517>
_______________________________________

From report at bugs.python.org  Sat Feb 29 06:24:13 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 11:24:13 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
Message-ID: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>


New submission from Stefan Krah <stefan at bytereef.org>:

#39776 has shown that it is hard to understand the interaction between
ContextVars and threading in embedded scenarios.

I want to understand the code again, so I'm adding back a compile time
option to enable the thread local context that was present prior to
f13f12d8d.

----------
messages: 362971
nosy: mark.dickinson, rhettinger, skrah
priority: normal
severity: normal
status: open
title: Add --without-decimal-contextvar option to use just threads in decimal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 06:27:20 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 11:27:20 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1582975640.76.0.512373053319.issue39794@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
assignee:  -> skrah
components: +Extension Modules
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 06:34:24 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 11:34:24 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1582976064.68.0.987438050459.issue39794@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Also, when I'm debugging things like #39776, I don't want to
switch between Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 06:50:44 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 11:50:44 +0000
Subject: [issue38380] Update SQLite to 3.31.1 in Windows and macOS installer
 builds
In-Reply-To: <1570313540.41.0.0224198940573.issue38380@roundup.psfhosted.org>
Message-ID: <1582977044.84.0.8350244634.issue38380@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Understood; I?ll remember it for future PRs. Thanks for clarifying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38380>
_______________________________________

From report at bugs.python.org  Sat Feb 29 07:05:59 2020
From: report at bugs.python.org (Ivan Bykov)
Date: Sat, 29 Feb 2020 12:05:59 +0000
Subject: [issue39795] multiprocessing creates duplicates of .pyc files
Message-ID: <1582977959.48.0.59229562314.issue39795@roundup.psfhosted.org>


New submission from Ivan Bykov <ivan.bykov at gmail.com>:

multiprocessing module creates duplicates of .pyc files 
in __pycache__ dirs
because subprocess._args_from_interpreter_flags()
ignores "-X pycache_prefix=PATH" option.

----------
components: Library (Lib)
messages: 362974
nosy: ivb
priority: normal
severity: normal
status: open
title: multiprocessing creates duplicates of .pyc files
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39795>
_______________________________________

From report at bugs.python.org  Sat Feb 29 07:20:11 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 29 Feb 2020 12:20:11 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1582978811.42.0.329856347058.issue37266@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To me, this seems best implemented as a new public function for the threading module, perhaps something like `threading.register_atexit()`. Would this be reasonable?

To me, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Sat Feb 29 07:25:34 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 29 Feb 2020 12:25:34 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1582979134.2.0.210175962759.issue39379@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset 1f0cd3c61a5ae3aac5ebaccc75ae9828ca4f96c4 by Ananthakrishnan in branch 'master':
bpo-39379: Remove reference to sys.path[0] being absolute path in whatsnew (GH-18561)
https://github.com/python/cpython/commit/1f0cd3c61a5ae3aac5ebaccc75ae9828ca4f96c4


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Sat Feb 29 07:26:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 29 Feb 2020 12:26:25 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1582979185.66.0.54197392668.issue39379@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have merged the doc change since it's minor. I will leave this open for clarification regarding Brett's question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Sat Feb 29 07:29:32 2020
From: report at bugs.python.org (swgmma)
Date: Sat, 29 Feb 2020 12:29:32 +0000
Subject: [issue30082] hide command prompt when using subprocess.Popen with
 shell=False on Windows
In-Reply-To: <1492363586.51.0.498152844874.issue30082@psf.upfronthosting.co.za>
Message-ID: <1582979372.72.0.477657644582.issue30082@roundup.psfhosted.org>


swgmma <jason.nader at protonmail.com> added the comment:

I would like to pick up work on this (have started at link below), however I would like some help:

For testing purposes, could someone please provide a minimum working example of using subprocess that causes a command prompt to pop up?

I have not been able to reproduce it (using Python 3.7), though I vaguely remember encountering it in the past.

https://github.com/ammgws/cpython/commit/03b9dac9205b9090dd67170427d887a9952345d3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30082>
_______________________________________

From report at bugs.python.org  Sat Feb 29 07:35:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 29 Feb 2020 12:35:11 +0000
Subject: [issue30082] hide command prompt when using subprocess.Popen with
 shell=False on Windows
In-Reply-To: <1492363586.51.0.498152844874.issue30082@psf.upfronthosting.co.za>
Message-ID: <1582979711.23.0.651171421892.issue30082@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If you use subprocess to launch any process that is marked SUBSYSTEM_CONSOLE, Windows will create a new console for it. For example, "python.exe" is such a process.

Eryk's answer in the very first StackOverflow link shows how to create a STARTUPINFO parameter with the correct settings. We just want to add a Boolean argument to subprocess.Popen.__init__() that can add that setting automatically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30082>
_______________________________________

From report at bugs.python.org  Sat Feb 29 08:03:37 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 29 Feb 2020 13:03:37 +0000
Subject: [issue39796] warning extension module inited twice in python3.9
Message-ID: <1582981417.61.0.704723505761.issue39796@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

In master branch, `_PyWarnings_Init()` have been called twice.
```
(gdb) bt
#0  _PyWarnings_Init () at Python/_warnings.c:1338
#1  0x0000000000525df3 in pycore_init_import_warnings (tstate=tstate at entry=0x9a19c0, sysmod=0x7ffff7f7e5f0) at Python/pylifecycle.c:680
...
Breakpoint 1, _PyWarnings_Init () at Python/_warnings.c:1338
1338    {
(gdb) bt
#0  _PyWarnings_Init () at Python/_warnings.c:1338
#1  0x0000000000511aac in _imp_create_builtin (module=<optimized out>, spec=0x7ffff7f2e7d0) at Python/import.c:1293
```

but in 2.7 branch, '_PyWarnings_Init()':
```
Breakpoint 1, _PyWarnings_Init() at Python/_warnings.c:886
886         m = Py_InitModule3(MODULE_NAME, warnings_functions, warnings__doc__);
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.4.x86_64
(gdb) bt
#0  _PyWarnings_Init () at Python/_warnings.c:886
#1  0x00000000004fc4db in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:242
#2  0x00000000004fcb03 in Py_Initialize () at Python/pythonrun.c:370
#3  0x00000000004154fd in Py_Main (argc=1, argv=0x7fffffffe428) at Modules/main.c:505
#4  0x00000000004145f0 in main (argc=1, argv=0x7fffffffe428) at ./Modules/python.c:23
```

Why? because pylifecycle.c and _imp extension module will call `_PyWarnings_Init()`.

isn't it?

----------
components: Extension Modules
messages: 362980
nosy: brett.cannon, shihai1991
priority: normal
severity: normal
status: open
title: warning extension module inited twice in python3.9
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39796>
_______________________________________

From report at bugs.python.org  Sat Feb 29 08:04:26 2020
From: report at bugs.python.org (Ama Aje My Fren)
Date: Sat, 29 Feb 2020 13:04:26 +0000
Subject: [issue39797] shutdown() in socketserver.BaseServer should be in a
 different thread from serve_forever()
Message-ID: <1582981466.61.0.0832265256128.issue39797@roundup.psfhosted.org>


New submission from Ama Aje My Fren <amaajemyfren at gmail.com>:

When a subclass of socketserver.BaseServer is running after calling serve_forever() and needs to be shutdown, it may be shut down by sending a [shutdown()](https://docs.python.org/3/library/socketserver.html#socketserver.BaseServer.shutdown). The thing is though that the shutdown() call must be run in a different thread than the one where the serve_forever() was called otherwise it will deadlock. This is documented in the [code](https://github.com/python/cpython/blob/3.8/Lib/socketserver.py#L244) but not in the documentation. It should be in the documentation as well as it is not obvious.

----------
assignee: docs at python
components: Documentation
messages: 362981
nosy: amaajemyfren, docs at python
priority: normal
severity: normal
status: open
title: shutdown() in socketserver.BaseServer should be in a different thread from serve_forever()
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/issue39797>
_______________________________________

From report at bugs.python.org  Sat Feb 29 08:07:28 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 29 Feb 2020 13:07:28 +0000
Subject: [issue39796] warning extension module inited twice in python3.9
In-Reply-To: <1582981417.61.0.704723505761.issue39796@roundup.psfhosted.org>
Message-ID: <1582981648.87.0.583366380305.issue39796@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +18062
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18700

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39796>
_______________________________________

From report at bugs.python.org  Sat Feb 29 08:48:37 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 13:48:37 +0000
Subject: [issue39798] Update and Improve README.AIX
Message-ID: <1582984117.38.0.490903429644.issue39798@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

I was building python on AIX but the old README.AIX file didn't help much. It would be super cool to someone who is familiar with AIX update and improve that file with all new additions and current issues about AIX.

----------
components: Build
messages: 362982
nosy: BTaskaya, David.Edelsohn
priority: normal
severity: normal
status: open
title: Update and Improve README.AIX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39798>
_______________________________________

From report at bugs.python.org  Sat Feb 29 08:55:34 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 29 Feb 2020 13:55:34 +0000
Subject: [issue39798] Update and Improve README.AIX
In-Reply-To: <1582984117.38.0.490903429644.issue39798@roundup.psfhosted.org>
Message-ID: <1582984534.51.0.920109068062.issue39798@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39798>
_______________________________________

From report at bugs.python.org  Sat Feb 29 10:04:08 2020
From: report at bugs.python.org (Open Close)
Date: Sat, 29 Feb 2020 15:04:08 +0000
Subject: [issue39799] Never return base's fragment from urljoin (urllib.parse)
Message-ID: <1582988648.13.0.340894927922.issue39799@roundup.psfhosted.org>


New submission from Open Close <openandclose23 at gmail.com>:

According to RFC3986 5.2.2.,
target fragment is always reference fragment
(T.fragment = R.fragment;).

This is different from RFC1808 (4. and 5.2.).
And it is not mentioned
in Modifications section in RFC2396 and RFC3986.

Current:
>>> import urllib.parse
>>> urllib.parse.urljoin('http://a/b#f', '')
'http://a/b#f'

Should return:
'http://a/b'

---

https://tools.ietf.org/html/rfc3986#section-5.2.2
https://tools.ietf.org/html/rfc1808.html#section-4
https://tools.ietf.org/html/rfc1808.html#section-5.2

----------
components: Library (Lib)
messages: 362983
nosy: op368
priority: normal
severity: normal
status: open
title: Never return base's fragment from urljoin (urllib.parse)
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39799>
_______________________________________

From report at bugs.python.org  Sat Feb 29 10:06:53 2020
From: report at bugs.python.org (Open Close)
Date: Sat, 29 Feb 2020 15:06:53 +0000
Subject: [issue39799] Never return base's fragment from urljoin (urllib.parse)
In-Reply-To: <1582988648.13.0.340894927922.issue39799@roundup.psfhosted.org>
Message-ID: <1582988813.44.0.349798359453.issue39799@roundup.psfhosted.org>


Open Close <openandclose23 at gmail.com> added the comment:

Uploaded the patch (1.patch).

----------
keywords: +patch
Added file: https://bugs.python.org/file48935/1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39799>
_______________________________________

From report at bugs.python.org  Sat Feb 29 10:27:53 2020
From: report at bugs.python.org (S Murthy)
Date: Sat, 29 Feb 2020 15:27:53 +0000
Subject: [issue39800] Inconsistent/incomplete disassembly of methods vs method
 source code
Message-ID: <1582990073.8.0.514436528319.issue39800@roundup.psfhosted.org>


New submission from S Murthy <smurthy at pm.me>:

I am using the dis module to look at source (and logical) lines of code vs corresponding bytecode instructions. I am bit confused by the output of dis.dis when disassembling a given method vs the corresponding source string, e.g.

>>> def f(x): return x**2
>>> dis.dis(f)
  1 0 LOAD_FAST              0 (x)
  2 LOAD_CONST               1 (2)
  4 BINARY_POWER
  6 RETURN_VALUE

This is the bytecode instruction block for the body only (not the method header), but dis.dis('def f(x): return x**2') produces the instructions for the header and body:

>>> dis.dis('def f(x): return x**2')
  1 0 LOAD_CONST               0 (<code object f at 0x10b0f7f60, file "<dis>", line 1>)
  2 LOAD_CONST               1 ('f')
  4 MAKE_FUNCTION            0
  6 STORE_NAME               0 (f)
  8 LOAD_CONST               2 (None)
 10 RETURN_VALUE

Disassembly of <code object f at 0x10b0f7f60, file "<dis>", line 1>:
  1 0 LOAD_FAST              0 (x)
  2 LOAD_CONST               1 (2)
  4 BINARY_POWER
  6 RETURN_VALUE

I have traced this difference to the different behaviour of dis.dis for methods vs source code strings:

def dis(x=None, *, file=None, depth=None):
    ...
    ...
    if hasattr(x, '__code__'):
        x = x.__code__
    ...
    # Perform the disassembly
    ...
    elif hasattr(x, 'co_code'): # Code object
        _disassemble_recursive(x, file=file, depth=depth)
    ...
    elif isinstance(x, str):    # Source code
        _disassemble_str(x, file=file, depth=depth)    
    ...

It appears as if the method body is contained in the code object produced from compiling the source (_try_compile(source, '<dis>', ...)) but not if the code object was obtained from f.__code__.

Why is this the case, and would it not be better to for dis.dis to behave consistently for methods and source strings of methods, and to generate/produce the complete instruction set, including for any headers? The current behaviour of dis.dis means that Bytecode(x) is also affected, as iterating over the instructions gives you different instructions depending on whether x is a method or a source string of x:

>>> for instr in dis.Bytecode(f): 
...     print(instr) 
...
Instruction(opname='LOAD_FAST', opcode=124, arg=0, argval='x', argrepr='x', offset=0, starts_line=1, is_jump_target=False)
Instruction(opname='LOAD_CONST', opcode=100, arg=1, argval=2, argrepr='2', offset=2, starts_line=None, is_jump_target=False)
Instruction(opname='BINARY_POWER', opcode=19, arg=None, argval=None, argrepr='', offset=4, starts_line=None, is_jump_target=False)
Instruction(opname='RETURN_VALUE', opcode=83, arg=None, argval=None, argrepr='', offset=6, starts_line=None, is_jump_target=False

>>> for instr in dis.Bytecode(inspect.getsource(f)): 
...     print(instr) 
...
Instruction(opname='LOAD_CONST', opcode=100, arg=0, argval=<code object f at 0x11e4036f0, file "<disassembly>", line 1>, argrepr='<code object f at 0x11e4036f0, file "<disassembly>", line 1>', offset=0, starts_line=1, is_jump_target=False)
Instruction(opname='LOAD_CONST', opcode=100, arg=1, argval='f', argrepr="'f'", offset=2, starts_line=None, is_jump_target=False)
Instruction(opname='MAKE_FUNCTION', opcode=132, arg=0, argval=0, argrepr='', offset=4, starts_line=None, is_jump_target=False)
Instruction(opname='STORE_NAME', opcode=90, arg=0, argval='f', argrepr='f', offset=6, starts_line=None, is_jump_target=False)
Instruction(opname='LOAD_CONST', opcode=100, arg=2, argval=None, argrepr='None', offset=8, starts_line=None, is_jump_target=False)
Instruction(opname='RETURN_VALUE', opcode=83, arg=None, argval=None, argrepr='', offset=10, starts_line=None, is_jump_target=False)

----------
components: Library (Lib)
messages: 362985
nosy: smurthy
priority: normal
severity: normal
status: open
title: Inconsistent/incomplete disassembly of methods vs method source code
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39800>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:11:28 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 16:11:28 +0000
Subject: [issue39801] list.insert is slow due to manual memmove
Message-ID: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>


New submission from Stefan Pochmann <stefan.pochmann at gmail.com>:

Using a list's insert function is much slower than using slice assignment:

> python -m timeit -n 100000 -s "a=[]" "a.insert(0,0)"
100000 loops, best of 5: 19.2 usec per loop

> python -m timeit -n 100000 -s "a=[]" "a[0:0]=[0]"
100000 loops, best of 5: 6.78 usec per loop

(Note that the list starts empty but grows to 100,000 elements.)

At first I thought maybe it's the attribute lookup or function call overhead or so, but inserting near the end shows that that's negligible:

> python -m timeit -n 100000 -s "a=[]" "a.insert(-1,0)"
100000 loops, best of 5: 79.1 nsec per loop

I asked at StackOverflow and someone pointed out that list.insert uses a manual loop instead of memmove: https://stackoverflow.com/a/60466572/12671057

----------
components: Interpreter Core
messages: 362986
nosy: Stefan Pochmann
priority: normal
severity: normal
status: open
title: list.insert is slow due to manual memmove
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:27:12 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 16:27:12 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1582993632.19.0.0958263712193.issue39801@roundup.psfhosted.org>


Change by Stefan Pochmann <stefan.pochmann at gmail.com>:


----------
title: list.insert is slow due to manual memmove -> list.insert is slow, likely due to manual memmove

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:27:53 2020
From: report at bugs.python.org (Michael Felt)
Date: Sat, 29 Feb 2020 16:27:53 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1582993673.98.0.693610709621.issue12915@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

PR18517 has, likely, a utf-8 dependency. AIX, default latin-1 does not accept the new test.

Starting with this merge AIX bot fails with:
======================================================================
ERROR: test_name_resolution (test.test_pkgutil.PkgutilTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_pkgutil.py", line 249, in test_name_resolution
    os.makedirs(d, exist_ok=True)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/os.py", line 223, in makedirs
    mkdir(name, mode)
UnicodeEncodeError: 'latin-1' codec can't encode characters in position 17-19: ordinal not in range(256)

Not completely resolved.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:34:22 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 29 Feb 2020 16:34:22 +0000
Subject: [issue39667] Update zipfile.Path with zipp 3.0
In-Reply-To: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>
Message-ID: <1582994062.96.0.484217721104.issue39667@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 0aeab5c4381f0cc11479362af2533b3a391312ac by Jason R. Coombs in branch 'master':
bpo-39667: Sync zipp 3.0 (GH-18540)
https://github.com/python/cpython/commit/0aeab5c4381f0cc11479362af2533b3a391312ac


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:34:40 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 16:34:40 +0000
Subject: [issue38527] configure script fails to detect "float word ordering"
 on Solaris
In-Reply-To: <1571496425.89.0.0695984738868.issue38527@roundup.psfhosted.org>
Message-ID: <1582994080.08.0.014166257049.issue38527@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38527>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:34:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Feb 2020 16:34:52 +0000
Subject: [issue39667] Update zipfile.Path with zipp 3.0
In-Reply-To: <1581978881.84.0.42755558271.issue39667@roundup.psfhosted.org>
Message-ID: <1582994092.15.0.0238212076131.issue39667@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +18063
pull_request: https://github.com/python/cpython/pull/18701

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39667>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:40:10 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Feb 2020 16:40:10 +0000
Subject: [issue39800] Inconsistent/incomplete disassembly of methods vs method
 source code
In-Reply-To: <1582990073.8.0.514436528319.issue39800@roundup.psfhosted.org>
Message-ID: <1582994410.24.0.141255984022.issue39800@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> would it not be better to for dis.dis to behave consistently for methods and source strings of methods

I don't think so. The inputs are different. One is a string containing a `def` statement, which is an executable statement. The other is a function or method object, which may or may not have been created by a `def` statement.

(You can, although not easily, assemble a function object yourself without using either `def` or `lambda` directly.)

The `def` statement assembles a function object out of a pre-compiled body, and that's what dis shows when you give it a source code string that happens to contain a `def`. It's just another statement, like an import or loop or assignment. The contents of the body (the code object) isn't shown because the byte-code generated for a `def` knows nothing about the contents of the body.

If you want to know the contents of the body, you have to look at the body (the code object) itself.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39800>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:40:36 2020
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Feb 2020 16:40:36 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1582994436.33.0.602405235515.issue39793@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't object to this patch, but that sure looks like a broken system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:54:25 2020
From: report at bugs.python.org (R. David Murray)
Date: Sat, 29 Feb 2020 16:54:25 +0000
Subject: [issue39771] EmailMessage may need to support RFC-non-compliant MIME
 parameter encoding (encoded words in quotes) for output.
In-Reply-To: <1582787552.48.0.364956702827.issue39771@roundup.psfhosted.org>
Message-ID: <1582995265.34.0.318578962463.issue39771@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I actually agree: if most (by market share) MUAs handle the RFC-incorrect parameter encoding style, and a significant portion does not handle the RFC correct style, then we should support the de-facto standard rather than the official standard as the default.  I just wish Microsoft would write better software :)  If on the other hand it is only microsoft out of the big market share players that is broken, I'm not sure I'd want it to be the default.  But we could still support it optionally.

So yeah, we could have a policy control that governs which one is actually used.

So this is a feature request, and ideally should be supported by an investigation of what MUAs support what, by market share.  And there's another question: does this only affect the filename parameter, or is it all MIME parameters?  I would expect it to be the latter, but someone should check at least a few examples of that to be sure.

----------
stage:  -> needs patch
title: EmailMessage.add_header doesn't work -> EmailMessage may need to support RFC-non-compliant MIME parameter encoding (encoded words in quotes) for output.
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________

From report at bugs.python.org  Sat Feb 29 11:57:50 2020
From: report at bugs.python.org (Malcolm Smith)
Date: Sat, 29 Feb 2020 16:57:50 +0000
Subject: [issue34271] Please support logging of SSL master secret by env
 variable SSLKEYLOGFILE
In-Reply-To: <1532867889.16.0.56676864532.issue34271@psf.upfronthosting.co.za>
Message-ID: <1582995470.22.0.325316487363.issue34271@roundup.psfhosted.org>


Malcolm Smith <malcolm.smith at gmail.com> added the comment:

It looks like this has now been done and released. Can the issue be closed?

----------
nosy: +Malcolm Smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34271>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:03:37 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 17:03:37 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1582995817.53.0.124329549468.issue39794@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
keywords: +patch
pull_requests: +18064
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18702

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:04:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Feb 2020 17:04:11 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1582995851.02.0.315611601504.issue39801@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/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:07:01 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 17:07:01 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1582996021.17.0.792517609269.issue39801@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

I believe it also affects bisect.insort, which I occasionally use when I need a "self-sorting list" (I can't easily test it, as I'm not set up to modify the C version of bisect.insort).

And also the popular sortedcontainers package, which relies on such list operations to be fast: http://www.grantjenks.com/docs/sortedcontainers/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:07:15 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 17:07:15 +0000
Subject: [issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with
 different domains
In-Reply-To: <1582970177.09.0.683840972158.issue39793@roundup.psfhosted.org>
Message-ID: <1582996035.68.0.368065388404.issue39793@roundup.psfhosted.org>


Batuhan Taskaya <batuhanosmantaskaya at gmail.com> added the comment:

> but that sure looks like a broken system.

These are all aliases to the same name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39793>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:09:54 2020
From: report at bugs.python.org (S Murthy)
Date: Sat, 29 Feb 2020 17:09:54 +0000
Subject: [issue39800] Inconsistent/incomplete disassembly of methods vs method
 source code
In-Reply-To: <1582990073.8.0.514436528319.issue39800@roundup.psfhosted.org>
Message-ID: <1582996194.04.0.173487936973.issue39800@roundup.psfhosted.org>


S Murthy <smurthy at pm.me> added the comment:

@steven.daprano In this case, the method f was created by via def. And calling dis.dis(s) where s is the source code of f (say s = inspect.getsource(f)) shows the bytecode both for the header and the body, as is clear enough from the example I first posted.

>>> dis.dis('def f(x): return x**2')
  1 0 LOAD_CONST               0 (<code object f at 0x10b0f7f60, file "<dis>", line 1>)
  2 LOAD_CONST               1 ('f')
  4 MAKE_FUNCTION            0
  6 STORE_NAME               0 (f)
  8 LOAD_CONST               2 (None)
 10 RETURN_VALUE

Disassembly of <code object f at 0x10b0f7f60, file "<dis>", line 1>:
  1 0 LOAD_FAST              0 (x)
  2 LOAD_CONST               1 (2)
  4 BINARY_POWER
  6 RETURN_VALUE

The first block of instructions here are for the def statement, and the second block for the return statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39800>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:14:26 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 17:14:26 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1582996466.3.0.511955373675.issue39801@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

Benchmarking with two *Python* versions of bisect.insort, the "insert" version takes 1.08 seconds to insort the shuffled range(10**5) while the slice assignment version only takes 0.46 seconds:

from timeit import timeit
import random
from bisect import bisect_right

def insort1(a, x):
    lo = bisect_right(a, x)
    a.insert(lo, x)

def insort2(a, x):
    lo = bisect_right(a, x)
    a[lo:lo] = [x]

for _ in range(3):
    a = list(range(10**5))
    random.shuffle(a)
    for insort in insort1, insort2:
        it = iter(a)
        s = []
        print(timeit(lambda: insort(s, next(it)), number=len(a)))
    print()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:21:30 2020
From: report at bugs.python.org (S Murthy)
Date: Sat, 29 Feb 2020 17:21:30 +0000
Subject: [issue39800] Inconsistent/incomplete disassembly of methods vs method
 source code
In-Reply-To: <1582990073.8.0.514436528319.issue39800@roundup.psfhosted.org>
Message-ID: <1582996890.73.0.351359856665.issue39800@roundup.psfhosted.org>


S Murthy <smurthy at pm.me> added the comment:

BTW how else are methods/functions are created in Python except via def?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39800>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:28:41 2020
From: report at bugs.python.org (Tim Peters)
Date: Sat, 29 Feb 2020 17:28:41 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1582997321.74.0.207133537601.issue39801@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Be cautious about this.  Many years ago I looked into this, mostly in the context of the list sort's binary insertion sort, and results were all over the map, depending on the compiler in use, the optimization level, and the range at which (if any!) memmove() was actually faster than a simple loop.  A fancy memmove() will (at least) arrange to copy (say) 8 bytes at a time, but the overhead of setting that up (+ the function call) made it a loser when the number of bytes to be moved was "too small".

Don't know whether the comment in listobject.c's binarysort() still applies:

           Caution: using memmove is much slower under MSVC 5;
           we're not usually moving many slots. */

Optimizing to move 100,000 elements isn't really sane - cutting the constant factor on an inherently quadratic-time too-simplistic basic approach isn't really doing you a favor ;-)

Also note that sortedcontainers does not use unbounded-length Python lists under the covers.  It puts an upper bound on the length of the Python lists it uses, precisely to avoid visibly quadratic-time behavior.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 12:50:09 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 29 Feb 2020 17:50:09 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1582998609.09.0.790297711355.issue39788@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

Sorry, but I can't figure out what code can break this change. Integers are implicitly converted to floats in operations with floats. How can this change break old code?

> if you are worried about the performance

No, I'm worried about the expectations of coders.
Personally, I expected that 1E2 returned a integer. And this is not true.
If I wanted a float, I'd wrote 1.0E2 . The fact the exponential notation returns always a float is really misleading, IMHO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:11:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Feb 2020 18:11:27 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1582999887.99.0.297972048755.issue39801@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's a diff you can try out:

diff --git a/Objects/listobject.c b/Objects/listobject.c
index 3c39c6444b..ac6c9cc07a 100644
--- a/Objects/listobject.c
+++ b/Objects/listobject.c
@@ -272,8 +272,7 @@ ins1(PyListObject *self, Py_ssize_t where, PyObject *v)
     if (where > n)
         where = n;
     items = self->ob_item;
-    for (i = n; --i >= where; )
-        items[i+1] = items[i];
+    memmove(items+where+1, items+where+0, (n - where) * sizeof(PyObject *));
     Py_INCREF(v);
     items[where] = v;
     return 0;

For me, that patch makes little difference in the timings.

Another thing that could be tried is to have ins1() call list_ass_slice() to do the work.  That way, both paths will use the same underlying insertion code.  It would be interesting to see if this makes any difference.

A few other thoughts:

* We usually prefer deques to lists when prepending because the former are O(1) and the latter are O(n).

* Modern compilers are very good at optimizing data movements in a simple for-loop.

* It is very difficult to get good timings for these kind of operations.  Internally, both make a call to list_resize() which in turn uses realloc().  The latter function can be very fast or very slow depending solely on whether it can resize in-place or has to move the data.  Accordingly, timings are easily confounded by minor changes to memory useage.  To get a clearcut timing, you would need to isolate just the for-loop or memmove operation and not include Python calling overhead, realloc operations, and everything else that is going on in the given timings.

* Another source of confounding is the compiler itself.  Changes that makes small improvements on Clang may hurt the GCC build or vice-versa.  The comparison can also be thrown-off by whether you're timing a PGO build (which tends to do an amazing job of optimizing for-foops).  The results may also differ between 32-bit builds and 64-builds.

* The timing isn't representative of how people use insert(x, 0).  It would be a mistake to optimize an uncommon case if it comes at the expense of the common case (insertions into small lists).  To guard against this, you would need to measure inserts into a small list to find-out whether memmove() has more setup time than the for-loop.  When we've done such investigations in the past, for-loops were found to beat memmove() for sizes under 16.  Almost certainly this changed as compilers and processors have changed over the years.

* For smaller list sizes, the calling overhead dominates the insertion time.  Disassembling the two different calls show a good deal of overhead for calls.

>>> from dis import dis
>>> dis('a.insert(0,0)')
  1           0 LOAD_NAME                0 (a)
              2 LOAD_METHOD              1 (insert)
              4 LOAD_CONST               0 (0)
              6 LOAD_CONST               0 (0)
              8 CALL_METHOD              2
             10 RETURN_VALUE
>>> dis('a[0:0]=[0]')
  1           0 LOAD_CONST               0 (0)
              2 BUILD_LIST               1
              4 LOAD_NAME                0 (a)
              6 LOAD_CONST               0 (0)
              8 LOAD_CONST               0 (0)
             10 BUILD_SLICE              2
             12 STORE_SUBSCR
             14 LOAD_CONST               1 (None)
             16 RETURN_VALUE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:15:18 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 18:15:18 +0000
Subject: [issue39740] Select module fails to build on Solaris 11.4
In-Reply-To: <1582564565.67.0.773509979349.issue39740@roundup.psfhosted.org>
Message-ID: <1583000118.46.0.845408046779.issue39740@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya, jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39740>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:24:52 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 18:24:52 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1583000692.58.0.0936457437763.issue39801@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

Good point, Tim. Although binarysort really moves very few slots (I think at most 62, and average like 13). That might not be representative for how people use list.insert, either. I think I mainly use it for the mentioned case of a "self-sorting list", either naively via bisect.insort with a single list or via sortedcontainers' SortedList using multiple lists (used it only once so far). If I'm not mistaken, SortedList has a default load factor of 1000 and splits at double that size.

I might do more reasonable benchmarks later (haven't read Raymond's reply yet).

In any case, binarysort does its own inserting, so at least it wouldn't be affected if list.insert were changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:30:24 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 29 Feb 2020 18:30:24 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582998609.09.0.790297711355.issue39788@roundup.psfhosted.org>
Message-ID: <20200229182958.GB4624@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Integers are implicitly converted to floats in operations with floats. 
> How can this change break old code?

# Status quo
print(1e60 + 1)
=> prints 1e+60

# In the future:
=> prints 1000000000000000000000000000000000000000000000000000000000001

# Status quo
1e300*1e300
=> returns inf (a float)

# In the future
=> returns 1000000...000000 (600 zeroes, an int)

# Status quo:
1e300**10000
=> instantly raises overflow error

# In the future
=> locks up the machine until you run out of memory

etc.

> > if you are worried about the performance
> 
> No, I'm worried about the expectations of coders.

Oh that's good then, because exponentional notation like 1e10 has been 
well known to return a float in Python for over a quarter of a century, 
and in dozens or hundreds of other languages too. It is, as far as I can 
tell, universally true that coders can distinguish floats from ints (in 
languages that distinguish them) using a simple test:

- if it contains a ".", "e" or "E", it's a float
- otherwise its an int

I don't know of any languages where numbers containing a dot or an "E" 
are ints. Do you?

> If I wanted a float, I'd wrote 1.0E2 

But by your own feature request, this would return an int and your 
"feature" would bite you:

    if the "base number" has a number of decimal places <= the
    exponent, the result should be an integer.

You would need to write 1.000E2 for it to work. Luckily for you, we're 
rejecting this idea, before it can fool you into writing buggy code :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:43:50 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 18:43:50 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1583001830.3.0.670680814997.issue39794@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 815280eb160af637e1347213659f9236adf78f80 by Stefan Krah in branch 'master':
bpo-39794: Add --without-decimal-contextvar (#18702)
https://github.com/python/cpython/commit/815280eb160af637e1347213659f9236adf78f80


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:47:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 29 Feb 2020 18:47:40 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1583002060.13.0.0138111009834.issue39801@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Marking this as "pending".  It is more of a personal research project than a bug report, feature request, or known optimization.

The underlying hypothesis is that compilers aren't smart enough to generate good code for a simple for-loop that moves data.

The evidence is weak as involves timing unusual cases, with significantly different calling patterns, and that make repeated calls to realloc() which can throw the results off wildly.

----------
priority: normal -> low
status: open -> pending
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:48:54 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 18:48:54 +0000
Subject: [issue39802] Ensure {get, set}_escdelay and {get,
 set}_tabsize only implemented when the extensions are activated
Message-ID: <1583002134.9.0.406998676979.issue39802@roundup.psfhosted.org>


New submission from Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:

Python can't build curses on Solaris because of extensions aren't activated

/export/home/isidentical/cpython/Modules/_cursesmodule.c: In function ?_curses_get_escdelay_impl?:
/export/home/isidentical/cpython/Modules/_cursesmodule.c:3272:28: error: ?ESCDELAY? undeclared (first use in this function)
     return PyLong_FromLong(ESCDELAY);
                            ^
/export/home/isidentical/cpython/Modules/_cursesmodule.c:3272:28: note: each undeclared identifier is reported only once for each function it appears in
/export/home/isidentical/cpython/Modules/_cursesmodule.c: In function ?_curses_set_escdelay_impl?:
/export/home/isidentical/cpython/Modules/_cursesmodule.c:3296:29: error: implicit declaration of function ?set_escdelay? [-Werror=implicit-function-declaration]
     return PyCursesCheckERR(set_escdelay(ms), "set_escdelay");
                             ^
/export/home/isidentical/cpython/Modules/_cursesmodule.c: In function ?_curses_set_tabsize_impl?:
/export/home/isidentical/cpython/Modules/_cursesmodule.c:3335:29: error: implicit declaration of function ?set_tabsize? [-Werror=implicit-function-declaration]
     return PyCursesCheckERR(set_tabsize(size), "set_tabsize");

----------
components: Build
messages: 363005
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Ensure {get,set}_escdelay and {get,set}_tabsize only implemented when the extensions are activated
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39802>
_______________________________________

From report at bugs.python.org  Sat Feb 29 13:50:51 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 18:50:51 +0000
Subject: [issue39802] Ensure {get, set}_escdelay and {get,
 set}_tabsize only implemented when the extensions are activated
In-Reply-To: <1583002134.9.0.406998676979.issue39802@roundup.psfhosted.org>
Message-ID: <1583002251.78.0.101308356181.issue39802@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +18065
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18705

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39802>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:04:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 29 Feb 2020 19:04:30 +0000
Subject: [issue39802] Ensure {get, set}_escdelay and {get,
 set}_tabsize only implemented when the extensions are activated
In-Reply-To: <1583002134.9.0.406998676979.issue39802@roundup.psfhosted.org>
Message-ID: <1583003070.19.0.793167134386.issue39802@roundup.psfhosted.org>


Change by Batuhan Taskaya <batuhanosmantaskaya at gmail.com>:


----------
nosy: +jcea
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39802>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:19:39 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 29 Feb 2020 19:19:39 +0000
Subject: [issue39803] _PyLong_FormatAdvancedWriter has an unnecessary str
Message-ID: <1583003979.36.0.40883960897.issue39803@roundup.psfhosted.org>


New submission from Andy Lester <andy at petdance.com>:

_PyLong_FormatAdvancedWriter has a PyObject *str that is never used.  Remove it.

----------
components: Interpreter Core
messages: 363006
nosy: petdance
priority: normal
severity: normal
status: open
title: _PyLong_FormatAdvancedWriter has an unnecessary str

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39803>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:22:52 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 29 Feb 2020 19:22:52 +0000
Subject: [issue39803] _PyLong_FormatAdvancedWriter has an unnecessary str
In-Reply-To: <1583003979.36.0.40883960897.issue39803@roundup.psfhosted.org>
Message-ID: <1583004172.19.0.320977384775.issue39803@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
keywords: +patch
pull_requests: +18066
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18707

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39803>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:25:50 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 29 Feb 2020 19:25:50 +0000
Subject: [issue39803] _PyLong_FormatAdvancedWriter has an unnecessary str
In-Reply-To: <1583003979.36.0.40883960897.issue39803@roundup.psfhosted.org>
Message-ID: <1583004350.04.0.0657538164625.issue39803@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -18066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39803>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:26:32 2020
From: report at bugs.python.org (Johannes Frank)
Date: Sat, 29 Feb 2020 19:26:32 +0000
Subject: [issue34271] Please support logging of SSL master secret by env
 variable SSLKEYLOGFILE
In-Reply-To: <1582995470.22.0.325316487363.issue34271@roundup.psfhosted.org>
Message-ID: <CAMgHmh_hwyAfeu66P8QV9qhhcfpESELbFjfeQ2nXLmWSxs35Ew@mail.gmail.com>


Johannes Frank <jmfrank63 at gmail.com> added the comment:

Yes, I didn't revisit the issue since, but Malcolm is right. Implemented in
python 3.8.

Thanks to all the contributors.

On Sat, Feb 29, 2020 at 8:58 AM Malcolm Smith <report at bugs.python.org>
wrote:

>
> Malcolm Smith <malcolm.smith at gmail.com> added the comment:
>
> It looks like this has now been done and released. Can the issue be closed?
>
> ----------
> nosy: +Malcolm Smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34271>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34271>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:27:16 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 29 Feb 2020 19:27:16 +0000
Subject: [issue39803] _PyLong_FormatAdvancedWriter has an unnecessary str
In-Reply-To: <1583003979.36.0.40883960897.issue39803@roundup.psfhosted.org>
Message-ID: <1583004436.36.0.215415440123.issue39803@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18067
pull_request: https://github.com/python/cpython/pull/18708

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39803>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:29:14 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 29 Feb 2020 19:29:14 +0000
Subject: [issue39803] _PyLong_FormatAdvancedWriter has an unnecessary str
In-Reply-To: <1583003979.36.0.40883960897.issue39803@roundup.psfhosted.org>
Message-ID: <1583004554.47.0.694291384589.issue39803@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests:  -18067

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39803>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:33:06 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 29 Feb 2020 19:33:06 +0000
Subject: [issue39803] _PyLong_FormatAdvancedWriter has an unnecessary str
In-Reply-To: <1583003979.36.0.40883960897.issue39803@roundup.psfhosted.org>
Message-ID: <1583004786.9.0.917527038172.issue39803@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
pull_requests: +18068
pull_request: https://github.com/python/cpython/pull/18709

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39803>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:46:04 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 29 Feb 2020 19:46:04 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1583005564.89.0.802306273552.issue39788@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

All the examples you mentioned seems to me to fix code, instead of breaking it.

About 1e300**10000, it's not a bug at all. No one can stop you to full your RAM in many other ways :-D

About conventions, it does not seems to me that Python cares about other languages very much, if it's more natural for normal people to expect a result instead of a consolidated one among devs. See `1 / 2 == 0.5`, for example.

> But by your own feature request, this would return an int and your 
"feature" would bite you

You're citing the *optional* extra to the original idea. We can agree it is not a good addition at all.

I continue to think that nE+m, where n and m are integers, should return an integer. If this can break old code, I'm the first to think it should not be implemented, but I don't see any problem (yet).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:48:14 2020
From: report at bugs.python.org (Tim Peters)
Date: Sat, 29 Feb 2020 19:48:14 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1583005694.44.0.189292873979.issue39788@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Ya, this change will never be made - give up gracefully :-)

1e100 and 10**100 aren't just of different types, they have different mathematical _values_ now:

>>> 1e100 == 10**100
False
>>> int(1e100)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104

Of course this has visible consequences, like:

>>> 1e100 % 1000
104.0
>>> int(1e100) % 1000
104
>>> 10**100 % 1000
0

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:53:50 2020
From: report at bugs.python.org (Marco Sulla)
Date: Sat, 29 Feb 2020 19:53:50 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1583006030.52.0.655167410467.issue39788@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

> >>> int(1e100)
> 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104

.........
Oh my God... I'm just more convinced than before :-D

> Ya, this change will never be made - give up gracefully :-)

Well, even if it's Tim Peters himself that ask it to me :-) I can't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Sat Feb 29 14:56:52 2020
From: report at bugs.python.org (Tim Peters)
Date: Sat, 29 Feb 2020 19:56:52 +0000
Subject: [issue39788] Exponential notation should return an int if it can
In-Reply-To: <1582925764.06.0.47669700025.issue39788@roundup.psfhosted.org>
Message-ID: <1583006212.48.0.556431647487.issue39788@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Then please take it to python-ideas?  The issue tracker isn't a right place for endless argument.  python-ideas is.  This is my last response here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39788>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:02:49 2020
From: report at bugs.python.org (Open Close)
Date: Sat, 29 Feb 2020 20:02:49 +0000
Subject: [issue39799] Never return base's fragment from urljoin (urllib.parse)
In-Reply-To: <1582988648.13.0.340894927922.issue39799@roundup.psfhosted.org>
Message-ID: <1583006569.26.0.675242616895.issue39799@roundup.psfhosted.org>


Change by Open Close <openandclose23 at gmail.com>:


----------
pull_requests: +18069
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18710

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39799>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:32:01 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 29 Feb 2020 20:32:01 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1583008321.77.0.159090779971.issue39548@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 5e260e0fde211829fcb67060cfd602f4b679f802 by Stephen Balousek in branch 'master':
bpo-39548: Fix handling of 'WWW-Authenticate' header for Digest Auth (GH-18338)
https://github.com/python/cpython/commit/5e260e0fde211829fcb67060cfd602f4b679f802


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39548>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:32:13 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Feb 2020 20:32:13 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1583008333.62.0.030407388348.issue39548@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +18070
pull_request: https://github.com/python/cpython/pull/18711

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39548>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:42:39 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 29 Feb 2020 20:42:39 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1583008959.72.0.475086836705.issue37266@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> To me, yes.

If Victor is also on-board with the idea, I can look into writing a patch for it (after testing to verify that it allows us to change the daemon threads to normal threads in concurrent.futures without issues).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:46:42 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Feb 2020 20:46:42 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1583009202.21.0.960795981679.issue39548@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +18071
pull_request: https://github.com/python/cpython/pull/18712

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39548>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:49:24 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Feb 2020 20:49:24 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1583009364.1.0.685241576992.issue39548@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cf347f3089631c3c2467e46ed609bfe67e539487 by Miss Islington (bot) in branch '3.7':
bpo-39548: Fix handling of 'WWW-Authenticate' header for Digest Auth (GH-18338)
https://github.com/python/cpython/commit/cf347f3089631c3c2467e46ed609bfe67e539487


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39548>
_______________________________________

From report at bugs.python.org  Sat Feb 29 15:52:34 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 20:52:34 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1583009554.75.0.821710681853.issue39794@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
pull_requests: +18072
pull_request: https://github.com/python/cpython/pull/18713

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:05:27 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 29 Feb 2020 21:05:27 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1583010327.24.0.299368674512.issue39548@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e4686b79798f7a492dcbaa62cf51f4d07fd5ae78 by Miss Islington (bot) in branch '3.8':
bpo-39548: Fix handling of 'WWW-Authenticate' header for Digest Auth (GH-18338)
https://github.com/python/cpython/commit/e4686b79798f7a492dcbaa62cf51f4d07fd5ae78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39548>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:09:53 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 21:09:53 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1583010593.62.0.316572971267.issue39794@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
pull_requests: +18074
pull_request: https://github.com/python/cpython/pull/18714

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:16:35 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 21:16:35 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1583010995.78.0.798952796514.issue39794@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 4d7012410cf4f91cbca4c406f4747289c2802333 by Stefan Krah in branch '3.8':
[3.8] bpo-39794: Add --without-decimal-contextvar (GH-18702)
https://github.com/python/cpython/commit/4d7012410cf4f91cbca4c406f4747289c2802333


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:25:11 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 29 Feb 2020 21:25:11 +0000
Subject: [issue39548] Request fails when 'WWW-Authenticate' header for Digest
 Authentication does not contain 'qop'
In-Reply-To: <1580772689.06.0.438668045886.issue39548@roundup.psfhosted.org>
Message-ID: <1583011511.49.0.484229166439.issue39548@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39548>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:31:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 21:31:19 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1583011879.32.0.380609156613.issue39763@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Note the original problem stems when you using "setup.py -j <NJOBS>".

setup.py doesn't use multiprocessing. multiprocessing is super complex. Would it be possible to write a reproducer which doesn't use multiprocessing?

> Stack trace: (...)

Can you try to get the Python traceback? Try py-bt command in gdb, or attempt to use faulthandler.dump_traceback_later().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:37:21 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 21:37:21 +0000
Subject: [issue24518] json.dumps should accept key function for ``sort_keys``
In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za>
Message-ID: <1583012241.27.0.631247436524.issue24518@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I've rebased Catherine Devlin's patch onto 3.9 (and adjusted the docs a tiny bit). If anyone still is interested, I can create a PR (for 3.9) for this.

----------
nosy: +erlendaasland
Added file: https://bugs.python.org/file48936/0001-bpo-24518-json.dumps-should-accept-key-function-for-.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24518>
_______________________________________

From report at bugs.python.org  Sat Feb 29 16:59:05 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 29 Feb 2020 21:59:05 +0000
Subject: [issue39769] compileall.compile_dir(...,
 ddir="<prefix>") omits the intermediate package paths when prepending
 the prefix
In-Reply-To: <1582780685.98.0.127631905646.issue39769@roundup.psfhosted.org>
Message-ID: <1583013545.1.0.240459379473.issue39769@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +18075
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/18718

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39769>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:10:29 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 22:10:29 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1583014229.79.0.252479185765.issue39794@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset c4ca1f8f24118dc5c29e16118fb35a13963af290 by Stefan Krah in branch '3.7':
[3.7] bpo-39794: Add --without-decimal-contextvar (GH-18702)
https://github.com/python/cpython/commit/c4ca1f8f24118dc5c29e16118fb35a13963af290


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:15:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:15:37 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1583014537.67.0.0175428605712.issue39379@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/issue39379>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:15:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:15:28 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1583014528.95.0.665865633609.issue39379@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is sys.path[0] always absolute, or is it just a side-effect of the site module (i.e. is it absolute even with -S)?

The absolute path is computed way before the site module is imported.

In Python 3.8, _PyPathConfig_ComputeSysPath0() computes sys.path[0] from sys.argv[0]. If the command line contains a script filename, this function uses realpath() on Unix and GetFullPathNameW() on Windows to get the absolute path. If -m is used, getcwd() is called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:16:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:16:15 +0000
Subject: [issue39766] unittest's assertRaises removes locals from tracebacks
In-Reply-To: <1582754471.69.0.783470624559.issue39766@roundup.psfhosted.org>
Message-ID: <1583014575.77.0.355896855361.issue39766@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39766>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:18:30 2020
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 29 Feb 2020 22:18:30 +0000
Subject: [issue39794] Add --without-decimal-contextvar option to use just
 threads in decimal
In-Reply-To: <1582975453.71.0.297927511147.issue39794@roundup.psfhosted.org>
Message-ID: <1583014710.69.0.643943601742.issue39794@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +boytsovea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39794>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:27:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:27:37 +0000
Subject: [issue39653] test_posix fails during make test
In-Reply-To: <1581873332.9.0.500912340754.issue39653@roundup.psfhosted.org>
Message-ID: <1583015257.85.0.326261993852.issue39653@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Which exception do you get for the following code?

import os
args=['no_such_executable']
os.execve(args[0], args, os.environ)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39653>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:28:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:28:57 +0000
Subject: [issue39653] test_posix fails during make test
In-Reply-To: <1581873332.9.0.500912340754.issue39653@roundup.psfhosted.org>
Message-ID: <1583015337.99.0.171789610786.issue39653@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

And for this one?

import os
args=['no_such_executable']
os.execvpe(args[0], args, os.environ)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39653>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:29:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:29:38 +0000
Subject: [issue39653] test_posix.TestPosixSpawnP.test_no_such_executable()
 fails with NotADirectoryError on Debian
In-Reply-To: <1581873332.9.0.500912340754.issue39653@roundup.psfhosted.org>
Message-ID: <1583015378.46.0.0263130780038.issue39653@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_posix fails during make test -> test_posix.TestPosixSpawnP.test_no_such_executable() fails with NotADirectoryError on Debian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39653>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:35:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:35:39 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1583015739.29.0.583147277621.issue12915@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_pkgutil.py", line 249, in test_name_resolution
>    os.makedirs(d, exist_ok=True)
(...)
> UnicodeEncodeError: 'latin-1' codec can't encode characters in position 17-19: ordinal not in range(256)

The test should be modified to skip the current uw value in the loop ("continue") if the filesystem encoding cannot encode the Unicode string (catch UnicodeEncodeError on the makedirs() call).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:37:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:37:27 +0000
Subject: [issue37266] Daemon threads must be forbidden in subinterpreters
In-Reply-To: <1560418565.72.0.288239825756.issue37266@roundup.psfhosted.org>
Message-ID: <1583015847.12.0.145486177936.issue37266@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> There will be a problem with `concurrent.futures.ProcessPoolExecutor`, which currently launches its management thread as a daemon thread.

Please don't discuss in closed issues.

If you want to support concurrent.futures in subinterpreters, please open a separated RFE issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37266>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:40:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:40:52 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1583016052.36.0.130797786987.issue39712@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> An exception to that is `-X dev`, which can also be triggered by the PYTHONDEVMODE variable, but that isn't mentioned in the CLI doc.

I wrote a whole new page for -X dev: https://docs.python.org/dev/library/devmode.html#devmode

This page starts with:

"It can be enabled using the -X dev command line option or by setting the PYTHONDEVMODE environment variable to 1."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:41:38 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 22:41:38 +0000
Subject: [issue35569] OSX: Enable IPV6_RECVPKTINFO
In-Reply-To: <1545566447.14.0.0770528567349.issue35569@roundup.psfhosted.org>
Message-ID: <1583016098.05.0.452190694646.issue35569@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35569>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:44:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:44:57 +0000
Subject: [issue39697] Failed to build with --with-cxx-main=g++-9.2.0
In-Reply-To: <1582198678.47.0.589589124523.issue39697@roundup.psfhosted.org>
Message-ID: <1583016297.51.0.945254790674.issue39697@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

_testembed is build by Makefile:

Programs/_testembed: Programs/_testembed.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
	$(LINKCC) $(PY_CORE_LDFLAGS) $(LINKFORSHARED) -o $@ Programs/_testembed.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS)

with:

MAINCC=		$(CC)
LINKCC=		$(PURIFY) $(MAINCC)

I'm not sure how g++ landed in LINKCC or MAINCC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39697>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:45:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:45:41 +0000
Subject: [issue39697] Failed to build with --with-cxx-main=g++-9.2.0
In-Reply-To: <1582198678.47.0.589589124523.issue39697@roundup.psfhosted.org>
Message-ID: <1583016341.5.0.374090292445.issue39697@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> See also https://bugs.python.org/issue23644

This issue is unrelated and has been fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39697>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:47:54 2020
From: report at bugs.python.org (signing_agreement)
Date: Sat, 29 Feb 2020 22:47:54 +0000
Subject: [issue39786] Have the heaps library support max heap
In-Reply-To: <1582919060.63.0.948721548128.issue39786@roundup.psfhosted.org>
Message-ID: <1583016474.01.0.304642601556.issue39786@roundup.psfhosted.org>


signing_agreement <kuglasses at gmail.com> added the comment:

Do you a suggestion for non-numeric types?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39786>
_______________________________________

From report at bugs.python.org  Sat Feb 29 17:49:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 22:49:21 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1583016561.45.0.641804578569.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Understood; thanks. I agree that there shouldn't be a guarantee for private undocumented calls.

I concur. That's a good summary. We don't provide ABI stability for Julien's use case.

Julien: You cannot use the same wheel package for all Python 3.7.x versions: you need to either always compile at the installation, or ship a different wheel package per micro Python 3.7.x version.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:00:44 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 23:00:44 +0000
Subject: [issue39712] Doc for `-X dev` option should mention PYTHONDEVMODE
In-Reply-To: <1582304259.52.0.96230176724.issue39712@roundup.psfhosted.org>
Message-ID: <1583017244.57.0.0598387569699.issue39712@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> I wrote a whole new page for -X dev: https://docs.python.org/dev/library/devmode.html#devmode

That's nice, but references for PYTHONFAULTHANDLER and PYTHONTRACEMALLOC are still missing. If you think the cross refs for -X dev and PYTHONDEVMODE clutters cmdline.html, I'll remove them from the PR.

Is it worth it adding https://docs.python.org/dev/library/devmode.html to 3.8 and possibly 3.7 as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39712>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:13:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 23:13:57 +0000
Subject: [issue30097] Command-line option to suppress "from None" for debugging
In-Reply-To: <1492553512.25.0.992335940269.issue30097@psf.upfronthosting.co.za>
Message-ID: <1583018037.37.0.250464026852.issue30097@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30097>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:19:29 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 29 Feb 2020 23:19:29 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1583018369.63.0.124788720453.issue39599@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Mark:
> Or am I misunderstanding?

No, you are not misunderstanding :)

> ABI breakage shouldn't happen *at all* in bugfix releases, whether stable ABI or not.

Absolutely.

Victor:
> Julien: You cannot use the same wheel package for all Python 3.7.x versions: you need to either always compile at the installation, or ship a different wheel package per micro Python 3.7.x version.

Just to be absolutely clear here, in general you *are* supposed to be able to use the same wheel package for all 3.7.x releases (or one built for any other 3.x.x release series) as long as the extension modules in the wheel follow certain rules and the rules include don't use any Include/internal headers. If the extension module violates that restriction (as is apparently the case here), ABI compatibility across bugfix releases cannot be assured.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:22:45 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 29 Feb 2020 23:22:45 +0000
Subject: [issue35569] OSX: Enable IPV6_RECVPKTINFO
In-Reply-To: <1545566447.14.0.0770528567349.issue35569@roundup.psfhosted.org>
Message-ID: <1583018565.08.0.848397834365.issue35569@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Proposed patch attached.

----------
keywords: +patch
Added file: https://bugs.python.org/file48937/0001-bpo-35569-Expose-RFC-3542-socket-options-on-macOS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35569>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:27:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 29 Feb 2020 23:27:49 +0000
Subject: [issue39599] ABI breakage between Python 3.7.4 and 3.7.5: change in
 PyGC_Head structure
In-Reply-To: <1581339256.79.0.552474006467.issue39599@roundup.psfhosted.org>
Message-ID: <1583018869.31.0.00234123984589.issue39599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This happens on a custom C module (built via Cython) when using including <internal/pystate.h> with -DPy_BUILD_CORE. I'm not sure it'd happen otherwise.

If you opt-in for the internal C API, you should be prepared to have such issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39599>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:35:28 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 23:35:28 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1583019328.82.0.0278990430963.issue39801@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

I have better benchmarks now and am trying some more, though I guess we roughly agree about when memmove is faster and when it's slower but that the real question is how large the common case is. 

Do you know where I can find those past investigations? Was memmove *faster* for sizes *over* 16? What is the common case, i.e., how do people use list.insert?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 18:36:51 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sat, 29 Feb 2020 23:36:51 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1583019411.63.0.267500194819.issue39801@roundup.psfhosted.org>


Change by Stefan Pochmann <stefan.pochmann at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 21:06:31 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sun, 01 Mar 2020 02:06:31 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1583028391.97.0.752129292214.issue39801@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

I think I have a decent way to isolate the memmove vs for-loop times, in Python code. Here are example results, five rounds of inserting with list.insert or with slice assignment. The times for each of the two ways are pretty stable:

  insert    slice
  0.024221  0.006754
  0.024157  0.006710
  0.024015  0.006734
  0.024206  0.006731
  0.024123  0.006769

For each run, I build a list of length 2**20 and append one value. Then I can insert 2**17 more values without the list internally resizing.

Then I measure inserting at index -1 and consider that the baseline, as it includes all the overhead costs like function calls and other differences between the two insertion methods.

Then I measure inserting at index -500 and subtract the baseline time. This difference should reflect how long the memmove or the for-loop took, as that's the difference between inserting at -1 and at -500. It's what I showed in those results above.

I chose -500 here because the use case I have in mind is sortedcontainers.SortedList, which I think mostly involves lists of length 1000 or more (up to 2000), and insertions somewhere in the middle.

Results for index -50 instead:

  insert    slice
  0.002479  0.002217
  0.002546  0.002113
  0.002566  0.002007
  0.002425  0.002081
  0.002555  0.002261

I'm btw running Python 3.8.1 32-bit on Windows 10 64-bit on an Intel i5-7200U.

Rest of this message is the benchmark code:

from timeit import repeat

statements = (
  'a.insert(-1,0)',
  'a.insert(-50,0)',
  'a[-1:0] = 0,',
  'a[-50:0] = 0,',
)

# Verify that the statements work and don't cause internal list resizes.
for stmt in statements:
    a = [0] * 2**20
    a.append(0)
    size_before = a.__sizeof__()
    stmt = compile(stmt, '', 'single')
    for _ in range(2**17):
        exec(stmt)
    assert len(a) == 2**20 + 1 + 2**17
    assert a.__sizeof__() == size_before

# Run the benchmark.
print('  insert    slice')
for _ in range(5):
    times = []
    for stmt in statements:
        t = min(repeat(stmt, 'a=[0]*2**20; a.append(0)', number=2**17, repeat=20))
        times.append(t)
    print('%10.6f' * 2 % (times[1] - times[0], times[3] - times[2]))

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 21:14:31 2020
From: report at bugs.python.org (Stefan Pochmann)
Date: Sun, 01 Mar 2020 02:14:31 +0000
Subject: [issue39801] list.insert is slow, likely due to manual memmove
In-Reply-To: <1582992688.24.0.071544861703.issue39801@roundup.psfhosted.org>
Message-ID: <1583028871.92.0.662051189993.issue39801@roundup.psfhosted.org>


Stefan Pochmann <stefan.pochmann at gmail.com> added the comment:

I misspoke. I do the insertions at -1 and -500 not on the same list but each on a fresh list (of length 2**20+1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39801>
_______________________________________

From report at bugs.python.org  Sat Feb 29 21:17:30 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 01 Mar 2020 02:17:30 +0000
Subject: [issue39804] timezone constants in time module inaccurate with
 negative DST (e.g. Ireland)
Message-ID: <1583029050.31.0.658413045225.issue39804@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

>From a report on the dateutil tracker today, I found that `time.timezone` and `time.altzone` are not accurate in Ireland (at least on Linux, not tested on other platforms): https://github.com/dateutil/dateutil/issues/1009

Europe/Dublin in the modern era has the exact same rules as Europe/London, but the values for `isdst` are switched, so for Ireland GMT is the "DST" zone with a DST offset of -1H, and IST is the standard zone, while London has GMT as the standard zone and BST as a DST zone of +1h.

The documentation for the timezone constants here pretty clearly say that the DST zone should be the *second* value in tzname, and should be the offset for altzone: https://docs.python.org/3/library/time.html#timezone-constants

But when setting my TZ variable to Europe/Dublin I get the same thing as for Europe/London:

$ TZ=Europe/Dublin python -c \
  "from time import *; print(timezone); print(altzone); print(tzname)"

0
-3600
('GMT', 'IST')
$ TZ=Europe/London python -c \
  "from time import *; print(timezone); print(altzone); print(tzname)"
0
-3600
('GMT', 'BST')

This would be less of a problem if localtime() were *also* getting isdst wrong in the same way, but it's not:


$ TZ=Europe/London python -c \
  "from time import *; print(localtime())"
time.struct_time(tm_year=2020, tm_mon=3, tm_mday=1, tm_hour=2, tm_min=5, tm_sec=6, tm_wday=6, tm_yday=61, tm_isdst=0)

$ TZ=Europe/Dublin python -c \
  "from time import *; print(localtime())"
time.struct_time(tm_year=2020, tm_mon=3, tm_mday=1, tm_hour=2, tm_min=5, tm_sec=18, tm_wday=6, tm_yday=61, tm_isdst=1)


So now it seems that there's no way to determine what the correct timezone offset and name are based on isdst. I'm not entirely sure if this is an issue in our code or a problem with the system APIs we're calling. This code looks like a *very* dicey heuristic (I expect it would also have some problems with Morocco in 2017, even before they were using a type of negative DST, since they used DST but turned it off from May 21st to July 2nd): https://github.com/python/cpython/blob/0b0d29fce568e61e0d7d9f4a362e6dbf1e7fb80a/Modules/timemodule.c#L1612

One option might be to deprecate these things as sort of very leaky abstractions *anyway* and be done with it, but it might be nice to fix it if we can.

----------
messages: 363037
nosy: belopolsky, lemburg, p-ganssle
priority: normal
severity: normal
status: open
title: timezone constants in time module inaccurate with negative DST (e.g. Ireland)
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/issue39804>
_______________________________________

From report at bugs.python.org  Sat Feb 29 21:51:56 2020
From: report at bugs.python.org (Elad Lahav)
Date: Sun, 01 Mar 2020 02:51:56 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1583031116.43.0.826816943319.issue39763@roundup.psfhosted.org>


Elad Lahav <e2lahav at gmail.com> added the comment:

"setup.py doesn't use multiprocessing. multiprocessing is super complex. Would it be possible to write a reproducer which doesn't use multiprocessing?"

But the problem is with the handling of fork() by Python modules, and specifically with multi-threaded fork()s. Without multiple processes there is no issue.

And setup.py does use use multiple processes via a thread pool, where each thread calls fork(), if it detects that "make" was invoked with the parallel (-j) option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Sat Feb 29 21:53:29 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 01 Mar 2020 02:53:29 +0000
Subject: [issue39763] distutils.spawn should use subprocess (hang in parallel
 builds on QNX)
In-Reply-To: <1582744715.59.0.836949225961.issue39763@roundup.psfhosted.org>
Message-ID: <1583031209.93.0.818836433066.issue39763@roundup.psfhosted.org>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
nosy:  -p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39763>
_______________________________________

From report at bugs.python.org  Sat Feb 29 22:42:42 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 01 Mar 2020 03:42:42 +0000
Subject: [issue39805] Copying functions doesn't actually copy them
Message-ID: <1583034162.79.0.0576327457429.issue39805@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Function objects are mutable, so I expected that a copy of a function should be an actual independent copy. But it isn't.

    py> from copy import copy
    py> a = lambda: 1
    py> b = copy(a)
    py> a is b
    True

This burned me when I modified the copy and the original changed too:

    py> a.attr = 27  # add extra data
    py> b.attr = 42
    py> a.attr
    42


`deepcopy` doesn't copy the function either.

----------
components: Library (Lib)
messages: 363039
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Copying functions doesn't actually copy them
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39805>
_______________________________________

From report at bugs.python.org  Sat Feb 29 22:48:39 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 01 Mar 2020 03:48:39 +0000
Subject: [issue39800] Inconsistent/incomplete disassembly of methods vs method
 source code
In-Reply-To: <1582996890.73.0.351359856665.issue39800@roundup.psfhosted.org>
Message-ID: <20200301034728.GC4624@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> BTW how else are methods/functions are created in Python except via def?

Functions are objects like everything else in Python, so they have a 
type, which has a constructor:

    from types import FunctionType

The documentation for FunctionType is a bit thin, so you may need to 
experiment a bit to get the details right, but it can be done.

Unfortunately copy.copy doesn't actually copy functions, which is in my 
opinion a bug (see #39805) but if you search the internet, you will find 
code that makes independent copies of function objects.

Methods are different from functions, and like functions, they 
too have a type with a constructor:

    from types import MethodType

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39800>
_______________________________________

From report at bugs.python.org  Sat Feb 29 23:14:36 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 01 Mar 2020 04:14:36 +0000
Subject: [issue39805] Copying functions doesn't actually copy them
In-Reply-To: <1583034162.79.0.0576327457429.issue39805@roundup.psfhosted.org>
Message-ID: <1583036076.94.0.162730222193.issue39805@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I think this is sufficient for a shallow copy.

import copy
import types

def copyfunction(func):
    new = types.FunctionType(
            func.__code__,
            func.__globals__,
            func.__name__,
            func.__defaults__,
            func.__closure__
            )
    vars(new).update(vars(func))
    new.__annotations__.update(func.__annotations__)
    if func.__kwdefaults__ is not None:
        new.__kwdefaults__ = func.__kwdefaults__.copy()
    return new

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39805>
_______________________________________

From report at bugs.python.org  Sat Feb 29 23:24:00 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 01 Mar 2020 04:24:00 +0000
Subject: [issue39800] Inconsistent/incomplete disassembly of methods vs method
 source code
In-Reply-To: <1582996194.04.0.173487936973.issue39800@roundup.psfhosted.org>
Message-ID: <20200301042335.GD4624@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Ah, I see now. I was using an older version of Python and the output of 
dis was different. It didn't recurse in to show the disassembly of the 
code object as well.

> The first block of instructions here are for the def statement, and 
> the second block for the return statement.

The first block of byte code is for the def statement, and the second 
block is for the code object, which may be more than just a return 
statement.

What would you expect the disassembly of this to show?

dis.dis("""
import y
def f(x):
    a = 2*x - 1
    return a**2

print('hello')
""")

Would you expect the disassembled code object to show up in that as 
well? I'm not sure what I would expect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39800>
_______________________________________