From report at bugs.python.org  Fri May  1 00:05:16 2020
From: report at bugs.python.org (wy7305e)
Date: Fri, 01 May 2020 04:05:16 +0000
Subject: [New-bugs-announce] [issue40463] csv.reader split error
Message-ID: <1588305916.81.0.836923186676.issue40463@roundup.psfhosted.org>


New submission from wy7305e <wy7305e at hotmail.com>:

#python 3.6 or python 3.8

csv.reader

delimiter=','
quotechar='"'

split this sentence:

"A word of encouragement and explanation, of pity for my childish ignorance, of welcome home, of reassurance to me that it was home, might have made me dutiful to him in my heart henceforth, instead of in my hypocritical&lt;eword w=\"hypocritical\"&gt;&lt;/eword&gt; outside, and might have made me respect instead of hate him. ","Part 1/CHAPTER 4. I FALL INTO DISGRACE/","David Copperfield"

return 4 columns, but it should return 3 columns.

----------
components: Library (Lib)
files: 01_test_code.py
messages: 367823
nosy: wy7305e
priority: normal
severity: normal
status: open
title: csv.reader split error
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file49104/01_test_code.py

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

From report at bugs.python.org  Fri May  1 03:04:01 2020
From: report at bugs.python.org (Dutcho)
Date: Fri, 01 May 2020 07:04:01 +0000
Subject: [New-bugs-announce] [issue40464] functools.singledispatch doesn't
 verify annotation is on FIRST parameter
Message-ID: <1588316641.36.0.617194746525.issue40464@roundup.psfhosted.org>


New submission from Dutcho <dutcho at ziggo.nl>:

>From Python 3.7, `functools.singledispatch` makes the `register()` attribute of the generic function infer the type of the first argument automatically for functions annotated with types. That's great for DRY.
However, in 3.7 and 3.8, no check is made that the *first* parameter of the registered function is actually annotated; *any* annotation suffices, even the *return* one.

Example:
    ```
    >>> @functools.singledispatch
    ... def func(arg):...
    >>> @func.register
    ... def _int(arg) -> int:...
    >>> @func.register
    ... def _str(arg) -> str:...
```
No errors happen, although the return type, *not* `arg`, is annotated.
This results in:
    ```
    >>> func.registry
    mappingproxy({<class 'object'>: <function func>, <class 'int'>: <function _int>, <class 'str'>: <function _str>})

    ```
Obviously, that doesn't dispatch correctly.

Note that un-annotated functions *are* caught:
    ```
    >>> @func.register
    ... def _no_annotation(arg): ...
    Traceback (most recent call last):
    ...
    TypeError: Invalid first argument to `register()`: <function _no_annotation at 0x000001D769A43D30>. Use either `@register(some_class)` or plain `@register` on an annotated function.
    ```

----------
components: Library (Lib)
messages: 367824
nosy: Dutcho
priority: normal
severity: normal
status: open
title: functools.singledispatch doesn't verify annotation is on FIRST parameter
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri May  1 04:31:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 May 2020 08:31:41 +0000
Subject: [New-bugs-announce] [issue40465] Deprecate the optional *random*
 argument to random.shuffle()
Message-ID: <1588321901.81.0.617278241299.issue40465@roundup.psfhosted.org>


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

shuffle(x, random=None)    ?    shuffle(x)

AFAICT, no one ever uses the optional parameter, nor would they have a valid reason to do so.  It is an ancient API oddity and is inconsistent with the other methods in the module.  I've long been annoyed by it and would like to see it cleaned-up before I retire ;-)

https://docs.python.org/3/library/random.html#random.shuffle

----------
components: Library (Lib)
messages: 367826
nosy: rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Deprecate the optional *random* argument to random.shuffle()
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri May  1 05:57:11 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 May 2020 09:57:11 +0000
Subject: [New-bugs-announce] [issue40466] asyncio.ensure_future() breaks
 implicit exception chaining
Message-ID: <1588327031.68.0.391066617052.issue40466@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is about how if a coroutine is wrapped in a Task with asyncio.ensure_future(), then portions of the exception chain can be lost.

Specifically, if you run the following code, then ValueError will be raised with exc.__context__ equal to the KeyError:

    import asyncio

    async def raise_error():
        raise ValueError

    async def main():
        try:
            raise KeyError
        except Exception as exc:
            future = raise_error()
            # Uncommenting the next line makes exc.__context__ None below.
            # future = asyncio.ensure_future(future)

            try:
                await future
            except Exception as exc:
                print(f'error: {exc!r}, context: {exc.__context__!r}')
                raise

    asyncio.get_event_loop().run_until_complete(main())

However, if you uncomment the `asyncio.ensure_future()` line, then the ValueError will be raised with no __context__.

I originally raised this issue a couple years ago here:
https://mail.python.org/pipermail/async-sig/2017-November/000403.html

There it was suggested that this was a special case of this issue:
https://bugs.python.org/issue29587

However, after writing code to fix that, this issue still exists.

----------
components: asyncio
messages: 367832
nosy: asvetlov, chris.jerdonek, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.ensure_future() breaks implicit exception chaining
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/issue40466>
_______________________________________

From report at bugs.python.org  Fri May  1 09:34:17 2020
From: report at bugs.python.org (Anish Athalye)
Date: Fri, 01 May 2020 13:34:17 +0000
Subject: [New-bugs-announce] [issue40467] subprocess: replacement shell on
 windows with executable="..." arg
Message-ID: <1588340057.85.0.281023369912.issue40467@roundup.psfhosted.org>


New submission from Anish Athalye <me at anishathalye.com>:

On Windows, using subprocess.call() and specifying both shell=True and the
executable='...' keyword arguments produces an undesirable result when the
specified shell is a POSIX-like shell rather than the standard cmd.exe.

I think the documentation is unclear on the semantics of Popen() when both
shell=True and executable= are specified on Windows. It does say the following
about POSIX systems:

> If shell=True, on POSIX the executable argument specifies a replacement shell
> for the default /bin/sh.

But the documentation doesn't say anything about Windows in this scenario, so
I'm not sure if this is a bug, or if it's undefined behavior.

Concretely, here's an example program that fails due to this:

    import subprocess
    bash = 'C:\\Program Files\\Git\\usr\\bin\\bash.exe'
    subprocess.call('f() { echo test; }; f', shell=True, executable=bash)

It prints out this mysterious-looking error:

    /c: /c: Is a directory

Tracing this into subprocess.py, it looks like it's because the executable bash
(as specified) is being called with the argv that's approximately ['cmd.exe',
'/c', 'f() { echo test; }; f'] (and the program being launched is indeed bash).

Bash doesn't expect a '/c' argument, it wants a '-c' there.

The problematic code in subprocess.py is here:
https://github.com/python/cpython/blob/1def7754b7a41fe57efafaf5eff24cfa15353444/Lib/subprocess.py#L1407
If the '/c' is replaced with a '-c', the example program above works (bash
doesn't seem to care that it's called with an argv[0] that doesn't make sense,
though presumably that should be fixed too).

I'm not sure how this could be fixed. It's unclear when '/c' should be used, as
opposed to '-c'. Doing it based on the contents of the executable= argument or
the SHELL environment variable or COMSPEC might be fragile? I couldn't find
much about this online, but I did find one project (in Ruby) that seems to have
run into a similar problem. See
https://github.com/kimmobrunfeldt/chokidar-cli/issues/15 and
https://github.com/kimmobrunfeldt/chokidar-cli/pull/16.

At the very least, even if this isn't fixed / can't be fixed, it might be nice
if it's possible to give some sort of useful warning/error when this happens --
perhaps say that specifying both shell=True and executable="..." isn't
supported on Windows?

I ran into this issue while while debugging an issue in a project of mine. In
case the additional context is useful, here is the discussion:
https://github.com/anishathalye/dotbot/issues/219

----------
components: Library (Lib), Windows
messages: 367844
nosy: anishathalye, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess: replacement shell on windows with executable="..." arg
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May  1 10:10:10 2020
From: report at bugs.python.org (E. Paine)
Date: Fri, 01 May 2020 14:10:10 +0000
Subject: [New-bugs-announce] [issue40468] IDLE split "general" into two tabs
Message-ID: <1588342210.52.0.776872841323.issue40468@roundup.psfhosted.org>


New submission from E. Paine <paineelisha at gmail.com>:

The proposed change to move some of the content in the "General" tab to a new tab. The need for this has been emphasised 
As a proof-of-concept, I moved the "Window Preferences" LabelFrame to a new tab titled "Window" (and did the minimum required to get the window to show).
The result can be seen in the "general_page.png" & "window_page.png" files.
Looking at the new general page, I felt that the "Editor Preferences" & "Shell Preferences" LabelFrames should not expand to fill the newly created space, and this should instead be taken up in the "Additional Help Sources" LabelFrame. The result can be seen in the ?general_page_pady.png? file.
Finally, I felt that we could now reduce the height of the window further by decreasing the font page Listbox height to 10 (from 15). The result can be seen in ?font_page_short.png?, ?general_page_short.png? & ?general_page_pady_short.png?.
As I said originally, this is just a proof-of-concept and we could easily move other options into a new tab (such as a ?Editor/Shell? tab ? though I think this is too long for a tab title).

----------
assignee: terry.reedy
components: IDLE
messages: 367846
nosy: epaine, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE split "general" into two tabs
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May  1 11:02:02 2020
From: report at bugs.python.org (Mark Hallett)
Date: Fri, 01 May 2020 15:02:02 +0000
Subject: [New-bugs-announce] [issue40469] TimedRotatingFileHandler rotating
 on use not time
Message-ID: <1588345322.69.0.523914781015.issue40469@roundup.psfhosted.org>


New submission from Mark Hallett <python at markhallett.co.uk>:

Using the attached confing ymal file, the log file only rolls if the log file is not written to for over a minute, logging regulary (eg every 30s)  prevents the correct rolling of the log.

----------
files: logging_config.ymal
messages: 367849
nosy: markhallett
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler rotating on use not time
versions: Python 3.8
Added file: https://bugs.python.org/file49111/logging_config.ymal

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

From report at bugs.python.org  Fri May  1 11:20:47 2020
From: report at bugs.python.org (Antony Lee)
Date: Fri, 01 May 2020 15:20:47 +0000
Subject: [New-bugs-announce] [issue40470] Make inspect.signature able to
 parse format strings.
Message-ID: <1588346447.38.0.355685422923.issue40470@roundup.psfhosted.org>


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

It would be nice if inspect.signature was able to understand bound str.format methods, e.g. `inspect.signature("{a} {b}".format) == inspect.signature(lambda *args, a, b, **kwargs: None)` (`*args, **kwargs` are there because str.format ignores additional arguments).  Right now I believe the only way to parse format strings is string.Formatter, which is slightly less discoverable and harder to use (although it certainly also provides more info, e.g. inspect.signature wouldn't be able to tell about format specifiers, but that's fine).

----------
messages: 367852
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Make inspect.signature able to parse format strings.
versions: Python 3.9

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

From report at bugs.python.org  Fri May  1 14:28:34 2020
From: report at bugs.python.org (alexpovel)
Date: Fri, 01 May 2020 18:28:34 +0000
Subject: [New-bugs-announce] [issue40471] Grammar typo in issubclass
 docstring
Message-ID: <1588357714.64.0.482700195727.issue40471@roundup.psfhosted.org>


New submission from alexpovel <python at alexpovel.de>:

Running `python -c "help(issubclass)"` will output:

  > Help on built-in function issubclass in module builtins:
  > 
  > issubclass(cls, class_or_tuple, /)
  >     Return whether 'cls' is a derived from another class or is the same class.
  >     
  >     A tuple, as in ``issubclass(x, (A, B, ...))``, may be given as the target to
  >     check against. This is equivalent to ``issubclass(x, A) or issubclass(x, B)
  >     or ...`` etc.

where it should probably read:

> Return whether 'cls' is derived from another class or is the same class.

over the current:

> Return whether 'cls' is a derived from another class or is the same class.

There are two occurrences of this string, one in `./Python/bltinmodule.c`, the other in `./Python/clinic/bltinmodule.c.h`.
I have to admit I cannot safely say which of these is the generated file through Argument Clinic and which is the source.
Is `./Python/bltinmodule.c` the source, aka where this would need to be changed?

Please let me know and I will create a PR.

Thanks!

----------
assignee: docs at python
components: Documentation
messages: 367871
nosy: alexpovel, docs at python
priority: normal
severity: normal
status: open
title: Grammar typo in issubclass docstring
versions: Python 3.8

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

From report at bugs.python.org  Fri May  1 15:35:30 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 May 2020 19:35:30 +0000
Subject: [New-bugs-announce] [issue40472] IDLE Shell not allowing more than
 two line inputs
Message-ID: <1588361730.23.0.0107658134744.issue40472@roundup.psfhosted.org>


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

In Python3.8 and prior, you can type this in a shell session
------------------------------------------------------------

Python 3.8.2 (v3.8.2:7b3ab5921f, Feb 24 2020, 17:52:18) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license()" for more information.
>>> def square(x):
	s = x ** 2
	return s


In Python3.9, the input is terminated prematurely
-------------------------------------------------

Python 3.9.0a6 (v3.9.0a6:bc1c8af8ef, Apr 27 2020, 17:05:28) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license()" for more information.
>>> def square(x):
	s = x ** 2             # <-- On first return, the statement evaluates
	
>>> 

>>> square(5)
25

----------
assignee: terry.reedy
components: IDLE
messages: 367875
nosy: rhettinger, terry.reedy
priority: high
severity: normal
status: open
title: IDLE Shell not allowing more than two line inputs
versions: Python 3.9

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

From report at bugs.python.org  Fri May  1 17:41:03 2020
From: report at bugs.python.org (Larry Kuhn)
Date: Fri, 01 May 2020 21:41:03 +0000
Subject: [New-bugs-announce] [issue40473] Universal newline not recognizing
 Mac newline (CR) when using CSV on Windows 10
Message-ID: <1588369263.41.0.526030000373.issue40473@roundup.psfhosted.org>


New submission from Larry Kuhn <larrykuhn at outlook.com>:

Running open with or without rU generates this message when reading a CSV file with CR line endings:
DeprecationWarning: 'U' mode is deprecated
  with open(csvfile, mode='rU', newline='') as cf:
Traceback (most recent call last):
  File "d:/Larry/Desktop/Python/profiler project/csvprofiler/csvpcg.py", line 245, in <module>
    main()
  File "d:/Larry/Desktop/Python/profiler project/csvprofiler/csvpcg.py", line 235, in main
    csv_input()
  File "d:/Larry/Desktop/Python/profiler project/csvprofiler/csvpcg.py", line 57, in csv_input
    config_dict['has_header'] = csv.Sniffer().has_header(cf.read(10240))
  File "C:\Program Files\Python38\lib\csv.py", line 395, in has_header
    header = next(rdr) # assume first row is header
_csv.Error: new-line character seen in unquoted field - do you need to open the file in universal-newline mode?

----------
components: Windows
messages: 367889
nosy: larrykuhn, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Universal newline not recognizing Mac newline (CR) when using CSV on Windows 10
type: behavior

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

From report at bugs.python.org  Fri May  1 21:11:22 2020
From: report at bugs.python.org (Lewis Ball)
Date: Sat, 02 May 2020 01:11:22 +0000
Subject: [New-bugs-announce] [issue40474] Code coverage report not entirely
 accurate
Message-ID: <1588381882.86.0.0551558198731.issue40474@roundup.psfhosted.org>


New submission from Lewis Ball <lrjball at gmail.com>:

The current reported code coverage stats on codecov.io miss some global statements of modules imported before coveragepy begins. This is documented in the dev guide, and the suggested fix is here: https://devguide.python.org/coverage/#coverage-results-for-modules-imported-early-on but that recommended fix doesn't seem to be included in the CI.

Using the recommended 'hack', the coverage report shows an extra 4k lines are coverage in Lib, increasing coverage percentage by around 3%. 

Having a more accurate view of the coverage makes it much easier to see which parts of the code need help with tests, without having to go into every individual report to see if global statements are misreported.

I'll raise a PR for this shortly

----------
components: Tests
messages: 367904
nosy: Lewis Ball
priority: normal
severity: normal
status: open
title: Code coverage report not entirely accurate
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May  2 00:02:50 2020
From: report at bugs.python.org (xie)
Date: Sat, 02 May 2020 04:02:50 +0000
Subject: [New-bugs-announce] [issue40475] json.JSONEncoder override default
 method
Message-ID: <1588392170.43.0.455373340888.issue40475@roundup.psfhosted.org>


New submission from xie <xsmyqf at qq.com>:

I see an example from here?https://docs.python.org/3/library/json.html
------It is about custom method from python object to json string:-----

import json
class ComplexEncoder(json.JSONEncoder):
    def default(self, obj):
        print("hi")
        if isinstance(obj, complex):
            return [obj.real, obj.imag]
        # Let the base class default method raise the TypeError
        return json.JSONEncoder.default(self, obj)

s2=json.dumps(2 + 1j, cls=ComplexEncoder)
print(s2)

-------I wrote an program like it,but not the result I want:-------
class MyEncoder(json.JSONEncoder):
    def default(self,obj):
        print("hi")
        if isinstance(obj,dict):
            print("it is dict!")
            return obj["name"]
        return json.JSONEncoder.default(self,obj)

print(MyEncoder().encode({"name":"sun","age":40}))
jsonStr=json.dumps({"name":"wang","age":30},cls=MyEncoder)
print(jsonStr)

--------the result of the program is:---------
{"name": "sun", "age": 40}
{"name": "wang", "age": 30}

--------I think it should be:---------
sun
wang

what I missed?I am very confused.

----------
messages: 367912
nosy: xsmyqf
priority: normal
severity: normal
status: open
title: json.JSONEncoder override default method
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat May  2 07:49:13 2020
From: report at bugs.python.org (=?utf-8?b?6Z+p5oyv5a6H?=)
Date: Sat, 02 May 2020 11:49:13 +0000
Subject: [New-bugs-announce] [issue40476] Write file failed on OS X 10.15.4
Message-ID: <1588420153.04.0.272722721403.issue40476@roundup.psfhosted.org>


New submission from ??? <0oshowero0 at gmail.com>:

When I write a long file using write() function, the resulting file is truncated into some specific level when the file is newly establised. However, when the file is existing, the full length can be achieved.

Here is the example code:

f = open('test_output','w')
length = 195364
for i in range(length):
    f.write(str(i)+'\r\n')

On my macOS 10.15.4 and conda virtual environment
conda create -n test python=3.7.4

When the test_output file is not existing, the content of the file is truncated into 195280, while i is 195364 after the writing process.

Then I re-run the code without deleting the file, the output is normal.

----------
components: IO
messages: 367927
nosy: ???
priority: normal
severity: normal
status: open
title: Write file failed on OS X 10.15.4
versions: Python 3.7

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

From report at bugs.python.org  Sat May  2 12:01:19 2020
From: report at bugs.python.org (Werner)
Date: Sat, 02 May 2020 16:01:19 +0000
Subject: [New-bugs-announce] [issue40477] Launcher on Catalina
Message-ID: <1588435279.1.0.0339863635356.issue40477@roundup.psfhosted.org>


New submission from Werner <we.hintze at gmail.com>:

I can?t figure out how to use Python Launcher on Catalina. Or it is broken. Anyway: It does absolutely nothing. When I double click a scriopt file, I se very shortly the preferences window of Launcher, and this is all. The script is not executed. I made a very simple script which writes a small text file. The script works flawlessly, when I call it in the terminal, but the Launcher seems not even to open it.

Is this a bug with Catalina, or what is to be done?

----------
components: macOS
messages: 367935
nosy: Auerhahn, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Launcher on Catalina
versions: Python 3.8

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

From report at bugs.python.org  Sat May  2 22:23:39 2020
From: report at bugs.python.org (japm48)
Date: Sun, 03 May 2020 02:23:39 +0000
Subject: [New-bugs-announce] [issue40478] allow finding nmake.exe executable
 in MSVCCompiler
Message-ID: <1588472619.67.0.562367362064.issue40478@roundup.psfhosted.org>


New submission from japm48 <japm48gh at gmail.com>:

Some toolchains (e.g. calibre) use a custom build system based on distutils to find the compiler tools.

For those, it is useful to have the path of nmake.exe easily discoverable.

----------
components: Distutils
messages: 367951
nosy: dstufft, eric.araujo, japm48
priority: normal
severity: normal
status: open
title: allow finding nmake.exe executable in MSVCCompiler
type: enhancement

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

From report at bugs.python.org  Sun May  3 05:23:23 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 03 May 2020 09:23:23 +0000
Subject: [New-bugs-announce] [issue40479] Port _hashlib to OpenSSL 3.0.0
Message-ID: <1588497803.18.0.937746880221.issue40479@roundup.psfhosted.org>


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

OpenSSL 3.0.0-alpha1 was releases about a week ago. OpenSSL 1.1.x APIs are still functional. However some APIs have been deprecated and FIPS (usedforsecurity flag) is no longer functional.

* One shot HMAC() is deprecated and should be replaced with EVP_MAC API calls
* ERR_func_error_string() is deprecated
* OpenSSL has introduced a new concept of crypto providers (OSSL_PROVIDER), library context (OPENSSL_CTX) and additional flags. A new function EVP_MD_fetch() has been introduced.
* FIPS support has been rewritten and is now shipped with OpenSSL 3.0.0. EVP_MD_CTX_FLAG_NON_FIPS_ALLOW is no longer supported. FIPS state is no longer part of EVP_MD_CTX but of EVP_MD.

See https://wiki.openssl.org/index.php/OpenSSL_3.0

----------
assignee: christian.heimes
components: SSL
messages: 367962
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: Port _hashlib to OpenSSL 3.0.0
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May  3 05:37:07 2020
From: report at bugs.python.org (kleshni)
Date: Sun, 03 May 2020 09:37:07 +0000
Subject: [New-bugs-announce] [issue40480] "fnmatch" exponential execution
 time
Message-ID: <1588498627.36.0.0280402477391.issue40480@roundup.psfhosted.org>


New submission from kleshni <kleshni at protonmail.ch>:

Hello. The following code hangs:

import fnmatch
fnmatch.fnmatchcase("a" * 32, "*" * 16 + "b")

Measurements show that its execution time rises exponentially with the number of asterisks. Bash and SQLite 3 process this glob instantly.

This is because "fnmatchcase" generates a regular expression with repeated dots:

(?s:.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*b)\\Z

It's equivalent to:

(?s:.*b)\\Z

But works in exponential time. So the solution is to replace multiple asterisks with a single one, so the latter regexp is generated instead.

----------
components: Library (Lib)
messages: 367963
nosy: kleshni
priority: normal
severity: normal
status: open
title: "fnmatch" exponential execution time
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Sun May  3 06:07:39 2020
From: report at bugs.python.org (=?utf-8?q?Jaros=C5=82aw_Wygoda?=)
Date: Sun, 03 May 2020 10:07:39 +0000
Subject: [New-bugs-announce] [issue40481] Add include and exclude filters to
 zipapp cli
Message-ID: <1588500459.46.0.573895829132.issue40481@roundup.psfhosted.org>


New submission from Jaros?aw Wygoda <jaroslaw at wygoda.me>:

Currently I can pass a filter function when creating archive but it's a bit cumbersome so I'd like to do it through cli.

Related issue:
https://bugs.python.org/issue31072

----------
components: Library (Lib)
messages: 367966
nosy: Jaros?aw Wygoda
priority: normal
severity: normal
status: open
title: Add include and exclude filters to zipapp cli
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun May  3 06:52:09 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 03 May 2020 10:52:09 +0000
Subject: [New-bugs-announce] [issue40482] _hashlib: register Python names as
 OpenSSL aliases
Message-ID: <1588503129.6.0.253291975104.issue40482@roundup.psfhosted.org>


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

Python uses valid Python identifiers for hashing algorithms while OpenSSL uses slightly different default names. For example OpenSSL uses "SHA3-256" while Python has "sha3_256". The function py_digest_by_name() in _hashopenssl.c maps from Python names to EVP_MD pointer.

It's possible to simplify the lookup by registering Python's aliases with OpenSSL, e.g. EVP_add_digest_alias(SN_sha3_512, "sha3_512").

Also see https://github.com/openssl/openssl/issues/11715

----------
assignee: christian.heimes
components: Library (Lib), SSL
messages: 367968
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: _hashlib: register Python names as OpenSSL aliases
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May  3 08:15:02 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 03 May 2020 12:15:02 +0000
Subject: [New-bugs-announce] [issue40483] Implementing a verifier function
 to verify integrity of AST nodes
Message-ID: <1588508102.78.0.391997005148.issue40483@roundup.psfhosted.org>


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

This is actually a problem that is existing for a long time. A recent example would be the discussion in the GH-19868.

Implementation
- It should check existence of all fields (like ast.Constant() wont verified)
- It should check types of all fields against their declarations in ASDL (this is actually depending on GH-19031) (like ast.List({ast.Constant(1)}, ctx=ast.Load()) wont pass, or the example in GH-19868)

After bpo-39981 resolved, I'll submit a patch.

----------
components: Library (Lib)
messages: 367969
nosy: BTaskaya, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Implementing a verifier function to verify integrity of AST nodes
type: enhancement

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

From report at bugs.python.org  Sun May  3 10:09:33 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 03 May 2020 14:09:33 +0000
Subject: [New-bugs-announce] [issue40484] Document existing compiler flags
 under ast
Message-ID: <1588514973.24.0.132527747949.issue40484@roundup.psfhosted.org>


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

PyCF_ALLOW_TOP_LEVEL_AWAIT, PyCF_TYPE_COMMENTS and PyCF_ONLY_AST should be documented just like CO_ flags under inspect module.

----------
assignee: docs at python
components: Documentation
messages: 367972
nosy: BTaskaya, docs at python
priority: normal
severity: normal
status: open
title: Document existing compiler flags under ast
versions: Python 3.9

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

From report at bugs.python.org  Sun May  3 11:33:27 2020
From: report at bugs.python.org (Faidon Liambotis)
Date: Sun, 03 May 2020 15:33:27 +0000
Subject: [New-bugs-announce] [issue40485] Provide an abstraction for a
 select-able Event
Message-ID: <1588520007.12.0.424273214975.issue40485@roundup.psfhosted.org>


New submission from Faidon Liambotis <paravoid at debian.org>:

In certain codebases, it's useful to be able to wait for input from one or more file descriptors (e.g. a socket), while at the same time waiting for an event triggered by another thread, or perhaps multiprocessing process.

To wait for one or more file descriptors to get ready, the select module can be used. However, neither threading.Event() nor multiprocessing.Event() are select-able, i.e. they provide no fileno() method.

The standard way one can implement this on Unix is with os.pipe(), but it can be tricky (forgetting to use non-blocking I/O etc.). It is also limited to a pair of processes at a time. On Linux systems from the past decade, one can also implement this much more efficiently using the eventfd() system calls. I think similar functionality exists in other Unixes with kqueue etc.

It'd be great if stdlib provided an abstraction over this mechanism. In fact, multiprocessing.Event() itself could probably be a thin abstraction over eventfd() on Linux? Perhaps even multiprocessing.Semaphore with EFD_SEMAPHORE, although I admit I'm less familiar with how all that works.

(Select-able Queues would be even neater, but that's a story for a different issue :)

----------
components: Extension Modules
messages: 367975
nosy: paravoid
priority: normal
severity: normal
status: open
title: Provide an abstraction for a select-able Event
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun May  3 12:36:28 2020
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 03 May 2020 16:36:28 +0000
Subject: [New-bugs-announce] [issue40486] pathlib's iterdir doesn't expecify
 what happens if directory content change
Message-ID: <1588523788.71.0.846056751312.issue40486@roundup.psfhosted.org>


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

Documentation for Path.iterdir ( https://docs.python.org/3/library/pathlib.html#pathlib.Path.iterdir ) doesn't specify what happens when the directory change.

This is important, as the function does NOT return a list (which would imply that a "snapshot" of the directory will be returned).

Also, it's not only relevant what would happen if somebody else changes the directory after the iteration is started (will that change be reflected?) but also if it's ALLOWED for the same code that iterates the dir content to change it (or problems would arise, like when changing a dictionary while being iterated).

----------
assignee: docs at python
components: Documentation
messages: 367981
nosy: docs at python, facundobatista
priority: normal
severity: normal
status: open
title: pathlib's iterdir doesn't expecify what happens if directory content change
versions: Python 3.9

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

From report at bugs.python.org  Sun May  3 13:36:41 2020
From: report at bugs.python.org (John Smith)
Date: Sun, 03 May 2020 17:36:41 +0000
Subject: [New-bugs-announce] [issue40487] Unexpected exception handler
 behavior in Jupyter when returning task objects created with create_task
Message-ID: <1588527401.93.0.870743970124.issue40487@roundup.psfhosted.org>


New submission from John Smith <jeanmonet at gmail.com>:

Hi,

I'm running the following code in a Jupyter notebook (so there is already a running loop).

`run_coro` (non-async function) adds given coroutines to the loop with `loop.create_task`. I want to return the task objects created by `loop.create_task` to check for result later in the code.

Adding the task objects to a list and returning the list has the exception handler behave differently than expected.


```
async def test1():
    ''' Enumerate numbers from 1 to 9'''
    n = 0
    while (n := n + 1) < 10:
        print(f'Test 1: {n}')
        await asyncio.sleep(0.3)
    return 'Test 1: DONE'


async def test2():
    ''' Enumerate numbers starting 1, raising exception at 5'''
    n = 0
    while (n := n + 1) < 10:
        if n == 5:
            raise ValueError('Test Exception')
        print(f'Test 2: {n}')
        await asyncio.sleep(0.2)


def handle_exception(loop, context):
    if context['exception']:
        print(f'Caught exception <{context["exception"]}> while executing {context["future"]}')


def run_coro(loop, coros):
    loop.set_exception_handler(handle_exception)
    tasks = deque()
    for coro in coros:
        task = loop.create_task(coro)
        #tasks.append(task)
        # ^--- if I uncomment, exc handler behaves strangely
    return tasks
    # ^-- BUT if I remove the "return" statement, it behaves correctly again


loop = asyncio.get_running_loop()   # retrieves Jupyter's running loop

tasks = run_coro(loop, [test1(), test2()])
```

Normal (expected output):

```
Test 1: 1
Test 2: 1
Test 2: 2
Test 1: 2
Test 2: 3
Test 1: 3
Test 2: 4
Caught exception <Test Exception> while executing <Task finished name='Task-214' coro=<test2() done, defined at <ipython-input-225-b5df8e07130e>:10> exception=ValueError('Test Exception')>
Test 1: 4
Test 1: 5
Test 1: 6
Test 1: 7
Test 1: 8
Test 1: 9
```

If I uncomment `tasks.append(task)` and return the list of task objects, output is:

```
Test 1: 1
Test 2: 1
Test 2: 2
Test 1: 2
Test 2: 3
Test 1: 3
Test 2: 4
Test 1: 4
Test 1: 5
Test 1: 6
Test 1: 7
Test 1: 8
Test 1: 9
```

If I re-run the code (re-run the Jupyter cell) the exception message would appear at the beginning of the output (as if it had been waiting in a queue somewhere), so for some reason it seems to get eaten-up somewhere.

The code works normally again if I remove the return statement from the `run_coro` function.

Is this expected behaviour? Am I missing something?

----------
components: asyncio
messages: 367988
nosy: asvetlov, jeanmonet, yselivanov
priority: normal
severity: normal
status: open
title: Unexpected exception handler behavior in Jupyter when returning task objects created with create_task
versions: Python 3.8

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

From report at bugs.python.org  Sun May  3 15:54:08 2020
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Sun, 03 May 2020 19:54:08 +0000
Subject: [New-bugs-announce] [issue40488] setup.py shall search by default
 for libffi.so in /usr/local/lib64
Message-ID: <1588535648.17.0.424777794849.issue40488@roundup.psfhosted.org>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

With libffi 3.3 doing `./configure && make install` puts  libffi.so in /usr/local/lib64/ . This can be found by pkgconfig.

But setup.py neither uses pkgconfig, nor checks by default /usr/local/lib64 for libffi

----------
components: Build
messages: 367990
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: setup.py shall search by default for libffi.so in /usr/local/lib64
versions: Python 3.8

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

From report at bugs.python.org  Sun May  3 17:41:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 May 2020 21:41:29 +0000
Subject: [New-bugs-announce] [issue40489] INCREF/DECREFs around the rich
 comparison needs tests
Message-ID: <1588542089.41.0.502312186848.issue40489@roundup.psfhosted.org>


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

In Objects/dictobject.c, if I remove the INCREF/DECREF pair around PyObject_RichCompareBool(), all the tests still pass:

-           Py_INCREF(startkey);
            cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
-           Py_DECREF(startkey);

It would be nice to have tests demonstrating why it is necessary.  IIRC the reason is that an object could have a custom comparison that clears the enclosing container and frees the element during the comparison.  

Also, it would be nice if PyObject_RichCompareBool() could be redesigned to not fail if a borrowed reference gets deallocated while the function is running.  The incref and decref occur on a hot path, and it is unfortunate that they cause extra writes to objects scattered all over memory, likely causing a lot of cache misses in real programs.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 367997
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: INCREF/DECREFs around the rich comparison needs tests

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

From report at bugs.python.org  Sun May  3 21:36:16 2020
From: report at bugs.python.org (anthony shaw)
Date: Mon, 04 May 2020 01:36:16 +0000
Subject: [New-bugs-announce] [issue40490] peg_generator module has unused
 imports
Message-ID: <1588556176.57.0.185247494944.issue40490@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

the tools/peg_generator package contains a number of unused imports

----------
components: Interpreter Core
messages: 368005
nosy: anthonypjshaw, pablogsal
priority: normal
severity: normal
stage: needs patch
status: open
title: peg_generator module has unused imports
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sun May  3 23:06:24 2020
From: report at bugs.python.org (Shantanu)
Date: Mon, 04 May 2020 03:06:24 +0000
Subject: [New-bugs-announce] [issue40491] Typo in SyntaxError produced by
 pegen for numeric literals
Message-ID: <1588561584.15.0.715391883465.issue40491@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

```
~ ? python3.9
Python 3.9.0a6+ (heads/master:c95e691, May  3 2020, 19:57:46) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse("1_2", feature_version=(3, 5))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/shantanu/.pyenv/versions/3.9-dev/lib/python3.9/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    1_2
    ^
SyntaxError: Underscores in numeric literals are only supportedin Python 3.6 and greater
```

----------
messages: 368006
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Typo in SyntaxError produced by pegen for numeric literals

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

From report at bugs.python.org  Sun May  3 23:36:27 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 04 May 2020 03:36:27 +0000
Subject: [New-bugs-announce] [issue40492] -m cProfile -o f.pstats with a
 script that does chdir() writes to the changed directory and not `.`
Message-ID: <1588563387.24.0.675526674384.issue40492@roundup.psfhosted.org>


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

just spent quite a bit of time debugging this, here's a minimal example:

```bash
# rm -rf a (if you want to reset)
cd /tmp
mkdir -p a/b
echo 'import os; os.chdir("..")' > a/b/c.py
cd a/b
python3 -m cProfile -o log.pstats c.py
ls -al
ls -al ..
```

example output:

```console
$ cd /tmp
$ mkdir -p a/b
$ echo 'import os; os.chdir("..")' > a/b/c.py
$ cd a/b
$ python3 -m cProfile -o log.pstats c.py
$ ls -al
total 12
drwxr-xr-x 2 asottile asottile 4096 May  3 20:35 .
drwxr-xr-x 3 asottile asottile 4096 May  3 20:35 ..
-rw-r--r-- 1 asottile asottile   26 May  3 20:35 c.py
$ ls -al ..
total 16
drwxr-xr-x  3 asottile asottile 4096 May  3 20:35 .
drwxrwxrwt 28 root     root     4096 May  3 20:35 ..
drwxr-xr-x  2 asottile asottile 4096 May  3 20:35 b
-rw-r--r--  1 asottile asottile  395 May  3 20:35 log.pstats
```

happy to work on a patch if this seems like a good idea to fix

----------
components: Library (Lib)
messages: 368008
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: -m cProfile -o f.pstats with a script that does chdir() writes to the changed directory and not `.`
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 00:21:40 2020
From: report at bugs.python.org (Shantanu)
Date: Mon, 04 May 2020 04:21:40 +0000
Subject: [New-bugs-announce] [issue40493] Pegen can't parse some function
 type comments
Message-ID: <1588566100.71.0.917063092257.issue40493@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

Currently fails if we don't have any arguments before *args and **kwargs

```
~ ? python3.9
Python 3.9.0a6+ (heads/master:c95e691, May  3 2020, 19:57:46) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast; ast.parse("(*int) -> None", mode="func_type", type_comments=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/shantanu/.pyenv/versions/3.9-dev/lib/python3.9/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    (*int) -> None
     ^
SyntaxError: invalid syntax
```

----------
messages: 368009
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Pegen can't parse some function type comments

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

From report at bugs.python.org  Mon May  4 04:07:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 May 2020 08:07:12 +0000
Subject: [New-bugs-announce] [issue40494] collections.abc.Callable and type
 variables
Message-ID: <1588579632.5.0.091811612876.issue40494@roundup.psfhosted.org>


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

There is a difference between typing.Callable and collections.abc.Callable.

>>> import typing, collections.abc
>>> T = typing.TypeVar('T')
>>> C1 = typing.Callable[[T], T]
>>> C2 = collections.abc.Callable[[T], T]
>>> C1
typing.Callable[[~T], ~T]
>>> C2
collections.abc.Callable[[~T], ~T]
>>> C1[int]
typing.Callable[[int], int]
>>> C2[int]
collections.abc.Callable[[~T], int]

----------
components: Library (Lib)
messages: 368015
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: collections.abc.Callable and type variables
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 05:08:41 2020
From: report at bugs.python.org (=?utf-8?q?Lum=C3=ADr_Balhar?=)
Date: Mon, 04 May 2020 09:08:41 +0000
Subject: [New-bugs-announce] [issue40495] compileall: option to hardlink
 duplicate optimization levels bytecode cache files
Message-ID: <1588583321.75.0.545037270294.issue40495@roundup.psfhosted.org>


New submission from Lum?r Balhar <frenzy.madness at gmail.com>:

We would like to include a possibility of hardlink deduplication of identical pyc files to compileall module in Python 3.9. We've discussed the change [0] and tested it in Fedora RPM build system via implementation in the compileall2 module [1].

The discussion [0] contains a lot of details so I mention here only the key features:
* the deduplication can be enabled only if multiple optimization levels are processed at once
* it generates a pyc file (optimization level 0) as usual but if it finds that optimized files (optimization levels 1 and 2) have the same content, it uses hardlinks (os.link) to prevents duplicates
* the deduplication is disabled by default

We believe that this might be handy for more Pythonistas. In our case, this functionality lowers the installation size of Python 3.9 from 125 MiB to 103 MiB.

[0] https://discuss.python.org/t/compileall-option-to-hardlink-duplicate-optimization-levels-bytecode-cache-files/3014
[1] https://github.com/fedora-python/compileall2

----------
components: Library (Lib)
messages: 368022
nosy: frenzy
priority: normal
severity: normal
status: open
title: compileall: option to hardlink duplicate optimization levels bytecode cache files
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 05:54:10 2020
From: report at bugs.python.org (Sergio Rael)
Date: Mon, 04 May 2020 09:54:10 +0000
Subject: [New-bugs-announce] [issue40496] re.findall() deadlock on Python
 3.6.10
Message-ID: <1588586050.03.0.673760016961.issue40496@roundup.psfhosted.org>


New submission from Sergio Rael <srael at onestic.com>:

I have found a deadlock using Python 3.6.10 that seems to have been solved on 3.7.x. probably related to capture groups. To reproduce the deadlock just do something like this:

re.findall(
    '\[et_pb_image(?:\w|=|"|\d|\.| |_|\/)*src="(https?:\/\/(?:www\.)?\w*\.\w*(?:\/|\w|\d|\.|-)*\.(?:png|jpg|jpeg|gif))"(?:\w|=|"|\d|\.| |_|\/|%|\|)*(?:\/?\])(?:\[\/et_pb_image\])?',
    '[et_pb_image _builder_version="3.27.2" src="https://www.somewhere.com/wp-content/uploads/2019/08/stabilizers.jpg" box_shadow_horizontal_tablet="0px" box_shadow_vertical_tablet="0px" box_shadow_blur_tablet="40px" box_shadow_spread_tablet="0px" z_index_tablet="500" url="https://youtu.be/fTrC5gkyYBM" url_new_window="on" /]',
)

I noticed that the problem is related to having two image urls on the content. The regex says to look only for the one starting with "src=" so the one starting with "url=" should be ignored. If "url=\"XXX\"" is removed from the tag it works fine.

----------
components: Regular Expressions
messages: 368026
nosy: ezio.melotti, mrabarnett, srael
priority: normal
severity: normal
status: open
title: re.findall() deadlock on Python 3.6.10
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon May  4 05:54:48 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 04 May 2020 09:54:48 +0000
Subject: [New-bugs-announce] [issue40497] subprocess.check_output() accept
 the check keyword argument
Message-ID: <1588586088.87.0.880898235091.issue40497@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

The subprocess.check_output() raises TypeError when given the `check` keyword-argument:

Python 3.8.2 (v3.8.2:7b3ab5921f, Feb 24 2020, 17:52:18) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output(['ls'], check=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/subprocess.py", line 411, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
TypeError: run() got multiple values for keyword argument 'check'

It should just use True as the default when it's not specified in kwargs.

----------
components: Library (Lib)
messages: 368027
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: subprocess.check_output() accept the check keyword argument
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May  4 07:23:16 2020
From: report at bugs.python.org (PythonAmateur742)
Date: Mon, 04 May 2020 11:23:16 +0000
Subject: [New-bugs-announce] [issue40498] Holding spacebar on button widget
 permanently makes it SUNKEN even after release (and wait).
Message-ID: <1588591396.15.0.77715019196.issue40498@roundup.psfhosted.org>


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

See my Stack Overflow question for an example code.

https://stackoverflow.com/questions/61588397/problems-with-tkinter-button-bindings-and-behaviour

Reproduction:

1. create a single button (even without command)
2. Use tab to navigate to the button.
3. Hold space for a bit.

result: Button is now SUNKEN. Even after clicking or pressing the space again.

----------
components: Tkinter
messages: 368036
nosy: PythonAmateur742
priority: normal
severity: normal
status: open
title: Holding spacebar on button widget permanently makes it SUNKEN even after release (and wait).
type: behavior

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

From report at bugs.python.org  Mon May  4 08:16:17 2020
From: report at bugs.python.org (Joel Rosdahl)
Date: Mon, 04 May 2020 12:16:17 +0000
Subject: [New-bugs-announce] [issue40499] asyncio.wait documentation on
 non-emptiness requirement lost in bpo-33649
Message-ID: <1588594577.55.0.625072789912.issue40499@roundup.psfhosted.org>


New submission from Joel Rosdahl <joel.rosdahl at gmail.com>:

bpo-21596 documented that the sequence of futures passed to asyncio.wait must not be empty:

    The sequence *futures* must not be empty.

This note was however lost in the bpo-33649 commit
(3faaa8857a42a36383bb18425444e597fc876797).

----------
assignee: docs at python
components: Documentation
messages: 368041
nosy: Joel Rosdahl, docs at python
priority: normal
severity: normal
status: open
title: asyncio.wait documentation on non-emptiness requirement lost in bpo-33649
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May  4 08:38:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 May 2020 12:38:50 +0000
Subject: [New-bugs-announce] [issue40500] test_multiprocessing_fork leaks
 processes on PPC64LE RHEL8 LTO + PGO 3.x
Message-ID: <1588595930.94.0.324889959771.issue40500@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

PPC64LE RHEL8 LTO + PGO 3.x:
https://buildbot.python.org/all/#/builders/450/builds/313

0:01:22 load avg: 7.01 [242/423/1] test_multiprocessing_fork failed (env changed) (1 min 17 sec) -- running: test_concurrent_futures (1 min 3 sec), test_multiprocessing_forkserver (1 min 19 sec)

Warning -- multiprocessing.Manager still has [<ForkProcess name='SyncManager-140' pid=225343 parent=219302 started>, <ForkProcess name='QueueManager-141' pid=225345 parent=219302 started>] active children after 5.1161000469874125 seconds

Warning -- Dangling processes: {<ForkProcess name='QueueManager-141' pid=225345 parent=219302 started>}

Warning -- multiprocessing.Manager still has [<ForkProcess name='QueueManager-141' pid=225345 parent=219302 started>, <ForkProcess name='SyncManager-143' pid=225542 parent=219302 started>] active children after 5.116447829990648 seconds

test__all__ (test.test_multiprocessing_fork.MiscTestCase) ... ok
test_answer_challenge_auth_failure (test.test_multiprocessing_fork.OtherTest) ... ok
test_deliver_challenge_auth_failure (test.test_multiprocessing_fork.OtherTest) ... ok
(...)

----------
components: Tests
messages: 368043
nosy: pitrou, tomMoral, vstinner
priority: normal
severity: normal
status: open
title: test_multiprocessing_fork leaks processes on PPC64LE RHEL8 LTO + PGO 3.x
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 12:34:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 04 May 2020 16:34:03 +0000
Subject: [New-bugs-announce] [issue40501] Deprecate and remove ctypes usage
 in uuid
Message-ID: <1588610043.03.0.653935213542.issue40501@roundup.psfhosted.org>


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

The uuid module uses ctypes to try and load likely system libraries to provide some functionality of the uuid module.

This is a security risk (depending on your sensitivity to DLL hijacking), but it also seems to be not very necessary? It would be nice to remove the ctypes usage from an otherwise (almost) pure Python module.

----------
components: Library (Lib)
messages: 368066
nosy: steve.dower
priority: normal
severity: normal
stage: test needed
status: open
title: Deprecate and remove ctypes usage in uuid
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 14:26:58 2020
From: report at bugs.python.org (Tomasz Pytel)
Date: Mon, 04 May 2020 18:26:58 +0000
Subject: [New-bugs-announce] [issue40502] PyNode_New() does not initialize
 n->n_col_offset
Message-ID: <1588616818.22.0.942372238929.issue40502@roundup.psfhosted.org>


New submission from Tomasz Pytel <tompytel at gmail.com>:

I found this by accident by compiling empty strings since I use column information from the AST tree, if not initialized I get a starting column of -842150451. The easy fix is to initialize n->n_col_offset = 0; in Parser/node.c:PyNode_New().

----------
components: Interpreter Core
messages: 368074
nosy: Tomasz Pytel
priority: normal
severity: normal
status: open
title: PyNode_New() does not initialize n->n_col_offset
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 14:51:21 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 04 May 2020 18:51:21 +0000
Subject: [New-bugs-announce] [issue40503] PEP 615: Add zoneinfo module
Message-ID: <1588618281.16.0.913416553136.issue40503@roundup.psfhosted.org>


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

This is an issue to track the implementation of PEP 615: https://www.python.org/dev/peps/pep-0615/

It should mostly involve migrating from the reference implementation: https://github.com/pganssle/zoneinfo/

----------
assignee: p-ganssle
components: Library (Lib)
messages: 368076
nosy: belopolsky, lemburg, p-ganssle
priority: high
severity: normal
stage: needs patch
status: open
title: PEP 615: Add zoneinfo module
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 16:36:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 May 2020 20:36:26 +0000
Subject: [New-bugs-announce] [issue40504] Restore weakref support for
 lru_cache wrappers
Message-ID: <1588624586.76.0.0628520967833.issue40504@roundup.psfhosted.org>


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

The pure python version of lru_cache() wrappers supported weak references.  It's not essential, but I have used it a couple of times.  In the spirit of PEP 399, the C version should add back the weakref support (and a test).

----------
components: Extension Modules
keywords: easy (C)
messages: 368081
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Restore weakref support for lru_cache wrappers
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May  4 17:51:07 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 May 2020 21:51:07 +0000
Subject: [New-bugs-announce] [issue40505] getpath.c doesn't know about lib64
Message-ID: <1588629067.84.0.887023365467.issue40505@roundup.psfhosted.org>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

On platforms which configure identifies as bi-arch platform, libdir is set to $[exec_prefix}/lib64, which results in the C extensions to get installed in e.g. /usr/local/lib64/python3.8/lib-dynload/.

However, the getpath.c routines use a fixed "lib/python" VERSION (see https://github.com/python/cpython/blob/3.8/Modules/getpath.c#L1200) path to build sys.path. As a result, the built Python binary cannot load the builtin C extensions.

A work-around on OpenSUSE is to set CONFIG_SITE="" when configuring Python. This disables the bi-arch support and has libdir default to ${exec_prefix}/lib again.

Looking at the master branch, this may already have been fixed for 3.9, since a PLATLIBDIR variable is used instead. The patch would have to be backported to earlier Python versions as well.

----------
components: Interpreter Core
messages: 368086
nosy: lemburg
priority: normal
severity: normal
status: open
title: getpath.c doesn't know about lib64
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon May  4 22:12:03 2020
From: report at bugs.python.org (Domenico Ragusa)
Date: Tue, 05 May 2020 02:12:03 +0000
Subject: [New-bugs-announce] [issue40506] add support for os.Pathlike
 filenames in zipfile.ZipFile.writestr
Message-ID: <1588644723.41.0.516863649113.issue40506@roundup.psfhosted.org>


New submission from Domenico Ragusa <domenicoragusa at gmail.com>:

ZipFile seems to support Pathlike objects pretty well, except in ZipFile.writestr.
For example:

>>> a = ZipFile(Path('test.zip'), 'w') # this works ok
>>> a.write(Path('./foo.jpeg'), arcname=PurePath('/some/thing.jpeg')) # this works as well
>>> a.writestr(PurePath('/test.txt'), 'idk') # this doesn't
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/zipfile.py", line 1788, in writestr
    zinfo = ZipInfo(filename=zinfo_or_arcname,
  File "/usr/lib/python3.8/zipfile.py", line 349, in __init__
    null_byte = filename.find(chr(0))
AttributeError: 'PurePosixPath' object has no attribute 'find'

I think it would be more consistent if it accepted any kind of paths, it would suffice to call os.fspath in ZipInfo.__init__ when the filename is a Pathlike-object, it's just 2 lines (+ tests, of course).

Can I go ahead and prepare a patch for this?

----------
components: Library (Lib)
messages: 368098
nosy: d.ragusa
priority: normal
severity: normal
status: open
title: add support for os.Pathlike filenames in zipfile.ZipFile.writestr
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 01:56:58 2020
From: report at bugs.python.org (Russell Davis)
Date: Tue, 05 May 2020 05:56:58 +0000
Subject: [New-bugs-announce] [issue40507] FileNotFound error raised by
 os.exec* doesn't contain filename
Message-ID: <1588658218.29.0.0740534174098.issue40507@roundup.psfhosted.org>


New submission from Russell Davis <russell.davis at gmail.com>:

To repro:

>>> import os, sys
>>> os.execv("nosuchfile", ["nosuchfile"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [Errno 2] No such file or directory
>>> print(sys.last_value.filename)
None

----------
components: Library (Lib)
messages: 368106
nosy: russelldavis
priority: normal
severity: normal
status: open
title: FileNotFound error raised by os.exec* doesn't contain filename
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/issue40507>
_______________________________________

From report at bugs.python.org  Tue May  5 03:06:33 2020
From: report at bugs.python.org (Louis)
Date: Tue, 05 May 2020 07:06:33 +0000
Subject: [New-bugs-announce] [issue40508] IDLE won't open
Message-ID: <1588662393.26.0.656755064199.issue40508@roundup.psfhosted.org>


Change by Louis <kingofnoobz4123.yeet at gmail.com>:


----------
components: macOS
files: IDLE.app.zip
nosy: Louis, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE won't open
type: performance
versions: Python 3.6
Added file: https://bugs.python.org/file49120/IDLE.app.zip

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

From report at bugs.python.org  Tue May  5 06:30:44 2020
From: report at bugs.python.org (Shani Armon)
Date: Tue, 05 May 2020 10:30:44 +0000
Subject: [New-bugs-announce] [issue40509] In argparse,
 allow REMAINDER(...) arguments in a mutually exclusive group
Message-ID: <1588674644.49.0.299540849008.issue40509@roundup.psfhosted.org>


New submission from Shani Armon <armonshanid+development at gmail.com>:

Options specified with the REMAINDER nargs should be treated as optional.
And an empty list should be treated as default.

----------
components: Library (Lib)
messages: 368126
nosy: Shani Armon, rhettinger
priority: normal
severity: normal
status: open
title: In argparse, allow REMAINDER(...) arguments in a mutually exclusive group
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 07:31:57 2020
From: report at bugs.python.org (David Naylor)
Date: Tue, 05 May 2020 11:31:57 +0000
Subject: [New-bugs-announce] [issue40510] [regression] ZipFile fails to
 round trip on some files
Message-ID: <1588678317.42.0.364207173861.issue40510@roundup.psfhosted.org>


New submission from David Naylor <naylor.b.david at gmail.com>:

With commit 18ee29d0b8 [1] a change was introduced that prevents a round-trip of some zip files (i.e. files generated by Microsoft Excel) due to the clobbering of `ZipInfo.flag_bits`[2] and `external_attr`[3].  

For example:
```python[name=zip-round-trip.py]
#!/usr/bin/env python3
import io
import sys
import zipfile

compression = zipfile.ZIP_STORED

source = sys.stdin
dest = sys.stdout

with io.BytesIO(source.buffer.read()) as source, io.BytesIO() as buffer:
    with zipfile.ZipFile(source, "r") as source_zip, zipfile.ZipFile(buffer, "w") as dest_zip:
        dest_zip.comment = source_zip.comment
        for info in source_zip.infolist():
            content = source_zip.read(info)
            dest_zip.writestr(info, content, compression)

    buffer.seek(0)
    dest.buffer.write(buffer.read())
```

```shell
> python3.5 zip-round-trip.py < Book1.zip > Python.zip
> diff Book1.zip Python.zip
> python3.6 zip-round-trip.py < Book1.zip > Python.zip
> diff Book1.zip Python.zip
Binary files Book1.zip and Python.zip differ
```

[1] https://github.com/python/cpython/commit/18ee29d0b870caddc0806916ca2c823254f1a1f9
[2] https://github.com/python/cpython/blob/f01d1be97d740ea0369379ca305646a26694236e/Lib/zipfile.py#L1579
[3] https://github.com/python/cpython/blob/f01d1be97d740ea0369379ca305646a26694236e/Lib/zipfile.py#L1586

----------
components: Library (Lib)
files: Book1.zip
messages: 368130
nosy: DragonSA
priority: normal
severity: normal
status: open
title: [regression] ZipFile fails to round trip on some files
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49121/Book1.zip

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

From report at bugs.python.org  Tue May  5 08:09:51 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 05 May 2020 12:09:51 +0000
Subject: [New-bugs-announce] [issue40511] Yellow hint frame blinks when
 entering () in strings
Message-ID: <1588680591.22.0.16376057042.issue40511@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

The yellow frame blinks as shown in mp4. It's annoying and isn't good to the eyes.

----------
assignee: terry.reedy
components: IDLE
messages: 368133
nosy: terry.reedy, wyz23x2
priority: normal
severity: normal
status: open
title: Yellow hint frame blinks when entering () in strings
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May  5 08:51:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2020 12:51:15 +0000
Subject: [New-bugs-announce] [issue40512] Meta issue: per-interpreter GIL
Message-ID: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

To be able to run multiple (sub)interpreters in parallel, the unique global interpreter lock aka "GIL" should be replace with multiple GILs: one "GIL" per interpreter. The scope of such per-interpreter GIL would be a single interpreter.

The current CPython code base is not fully read to have one GIL per interpreter. TODO:

* Move signals pending and gil_drop_request from _PyRuntimeState.ceval to PyInterpreterState.ceval: https://github.com/ericsnowcurrently/multi-core-python/issues/34
* Add a lock to pymalloc, or disable pymalloc when subinterpreters are used: https://github.com/ericsnowcurrently/multi-core-python/issues/30
* Make free lists per interpreters: tuple, dict, frame, etc.
* Make Unicode interned strings per interpreter
* Make Unicode latin1 single character string singletons per interpreter
* None, True, False, ... singletons: make them per-interpreter (bpo-39511) or immortal (bpo-40255)
* etc.

Until we can ensure that no Python object is shared between two interpreters, we might make PyObject.ob_refcnt, PyGC_Head (_gc_next and _gc_prev) and _dictkeysobject.dk_refcnt atomic.

C extension modules should be modified as well:

* Convert to PEP 489 multi-phase initialization
* Replace globals ("static" variables) with a module state, or design a new "per-interpreter" local storage similar to Thread Local Storage (TLS). There is already PyInterpreterState.dict which is convenient to use in "Python" code, but it's not convenient to use in "C" code (code currently using "static int ..." for example).

I'm not sure how to handle C extensions which are binding for a C library which has a state and so should not be used multiple times in parallel. Some C extensions use a "global lock" for that. The question is how to get 

Most of these tasks are already tracked in Eric Snow's "Multi Core Python" project:
https://github.com/ericsnowcurrently/multi-core-python/issues

This issue is related to PEP 554 "Multiple Interpreters in the Stdlib", but not required by this PEP.

This issue is a tracker for sub-issues related to the goal "have one GIL per interpreter".

--

Some changes have a negative impact on "single threaded" Python application. Even if the overhead is low, one option to be able to move faster on this issue may be to add a new temporary configure option to have an opt-in build mode to better isolate subinterpreters. Examples:

* disable pymalloc
* atomic reference counters
* disable free lists

That would be a temporary solution to "unblock" the development on this list. For the long term, free lists should be made per-interpreter, pymalloc should support multiple interpreters, no Python object must be shared by two interpreters, etc.

--

One idea to detect if a Python object is shared by two interpreters *in debug mode* would be to store a reference to the interpreter which created it, and then check if the current interpreter is the same. If not, fail with a Python Fatal Error.

--

During Python 3.9 development cycle, many states moved from the global _PyRuntimeState to per-interpreter PyInterpreterState:

* GC state (bpo-36854)
* warnings state (bpo-36737)
* small integer singletons (bpo-38858)
* parser state (bpo-36876)
* ceval pending calls and "eval breaker" (bpo-39984)
* etc.

Many corner cases related to daemon threads have also been fixed:

* https://vstinner.github.io/daemon-threads-python-finalization-python32.html
* https://vstinner.github.io/threading-shutdown-race-condition.html
* https://vstinner.github.io/gil-bugfixes-daemon-threads-python39.html

And more code is now shared for the initialization and finalization of the main interpreter and subinterpreters (ex: see bpo-38858).

Subinterpreters builtins and sys are now really isolated from the main interpreter (bpo-38858).

--

Obviously, there are likely tons of other issues which are not known at this stage. Again, this issue is a placeholder to track them all. It may be more efficient to create one sub-issue per sub-task, rather than discussing all tasks at the same place.

----------
components: Interpreter Core
messages: 368136
nosy: vstinner
priority: normal
severity: normal
status: open
title: Meta issue: per-interpreter GIL
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 08:56:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2020 12:56:32 +0000
Subject: [New-bugs-announce] [issue40513] Move _PyRuntimeState.ceval to
 PyInterpreterState
Message-ID: <1588683392.98.0.918387482163.issue40513@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

To get one GIL per interpreter (bpo-40512), remaining _PyRuntimeState.ceval members should be moved to PyInterpreterState.ceval. The work started in bpo-39984 with ceval "pending calls" and ceval "eval breaker".

There are 4 remaining fields:

struct _ceval_runtime_state {
    int recursion_limit;
    /* Request for dropping the GIL */
    _Py_atomic_int gil_drop_request;
    /* Request for checking signals. */
    _Py_atomic_int signals_pending;
    struct _gil_runtime_state gil;
};

The most complex part will be to move the "gil" member: bpo-40512 lists all sub-tasks which must be completed before being able to have one GIL per interpreter without crashing.

----------
components: Interpreter Core
messages: 368137
nosy: vstinner
priority: normal
severity: normal
status: open
title: Move _PyRuntimeState.ceval to PyInterpreterState
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 09:13:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2020 13:13:51 +0000
Subject: [New-bugs-announce] [issue40514] Add
 --experimental-isolated-subinterpreters build option
Message-ID: <1588684431.91.0.693668036583.issue40514@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Modifying Python internals to have one GIL per interpreter (bpo-40512) is a large project which requires to modify many small things (again, see bpo-40512).

I propose to add a temporary build --experimental-isolated-subinterpreters build option to configure for developers who want to hack on isolated subinterpreters. The intent is to speedup bpo-40512 development by making some practice compromises, to have more time to properly design the real fixes.

For example, tuple, dict and frame have free lists which are shared by subinterpreters. A practical solution is to simply disable them at build time to avoid the need to have per-interpreter free lists.

Another example is pymalloc which is shared by all subinterpreters and rely on the unique global interpreter lock (GIL) to protect its internal states. A practical solution is to disable it and force the usage of libc malloc() function instead.

Some compromosises cannot be the default since they have a significant negative impact on performances. So I propose to add a temporary build option until all these small issues will be fixed.

----------
components: Build
messages: 368141
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add --experimental-isolated-subinterpreters build option
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 09:20:24 2020
From: report at bugs.python.org (Miguel)
Date: Tue, 05 May 2020 13:20:24 +0000
Subject: [New-bugs-announce] [issue40515] test_ssl.py hangs with SSL 1.1
 built with no threads
Message-ID: <1588684824.78.0.561425398379.issue40515@roundup.psfhosted.org>


New submission from Miguel <mig28suarez at hotmail.com>:

Hello, this is my first python bug report!

I've been running builds of Python 3.7.x on CentOS Linux release 7.7 (64bit/Intel Core
2 Duo) 
and I ran into hangs with test_ssl.py when using latest SSL 1.1.1d sources.

I've done a full compilation from source for Python 3.7.7 and SSL 1.1 in my
workspaces.

>From what I can tell the problem is when SSL 1.1 is built with no threading
there is no locking enabled by python.

This one line change will make the hangs in test_ssl.py  go away:

Index: Modules/_ssl.c

--- Modules/_ssl.c      (revision 70)
+++ Modules/_ssl.c      (working copy)
@@ -5875,7 +5875,7 @@
     if (!_setup_ssl_threads()) {
         return NULL;
     }
-#elif OPENSSL_VERSION_1_1 && defined(OPENSSL_THREADS)
+#elif OPENSSL_VERSION_1_1
     / OpenSSL 1.1.0 builtin thread support is enabled /
     _ssl_locks_count++;

# endif

There appears to be an assumption in _ssl.c and test_ssl.y that SSL 1.1 will be
threaded
but this may not be true (as in my case).

Appreciate any feedback. Thanks!

----------
assignee: christian.heimes
components: SSL
messages: 368143
nosy: christian.heimes, mig28suarez
priority: normal
severity: normal
status: open
title: test_ssl.py hangs with SSL 1.1 built with no threads
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/issue40515>
_______________________________________

From report at bugs.python.org  Tue May  5 09:32:24 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 05 May 2020 13:32:24 +0000
Subject: [New-bugs-announce] [issue40516] GCC 9 compiler warnings on MacOS
 Catalina
Message-ID: <1588685544.13.0.656606061052.issue40516@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Building master with GCC 9.3.0 gives some warnings on posix and nis:

./Modules/posixmodule.c: In function 'os_chown_impl':
./Modules/posixmodule.c:3397:39: warning: the comparison will always evaluate as 'false' for the address of 'lchown' will never be NULL [-Waddress]
 3397 |     if ((!follow_symlinks) && (lchown == NULL)) {
      |                                       ^~
./Modules/posixmodule.c: In function 'PyInit_posix':
./Modules/posixmodule.c:14939:16: warning: the comparison will always evaluate as 'false' for the address of 'lchown' will never be NULL [-Waddress]
14939 |     if (lchown == NULL) {
      |                ^~
/Users/remi/src/cpython/Modules/nismodule.c: In function 'nis_cat':
/Users/remi/src/cpython/Modules/nismodule.c:216:18: warning: cast between incompatible function types from 'int (*)(int,  char *, int,  char *, int,  struct ypcallback_data *)' to 'int (*)(long unsigned int,  char *, int,  char *, int,  void *)' [-Wcast-function-type]
  216 |     cb.foreach = (foreachfunc)nis_foreach;
      |                  ^
/Users/remi/src/cpython/Modules/nismodule.c: In function 'nis_xdr_ypmaplist':
/Users/remi/src/cpython/Modules/nismodule.c:302:42: warning: cast between incompatible function types from 'int (*)(XDR *, nismaplist *)' {aka 'int (*)(struct __rpc_xdr *, struct nismaplist *)'} to 'int (*)(XDR *, void *, unsigned int)' {aka 'int (*)(struct __rpc_xdr *, void *, unsigned int)'} [-Wcast-function-type]
  302 |                      sizeof(nismaplist), (xdrproc_t)nis_xdr_ypmaplist))
      |                                          ^
/Users/remi/src/cpython/Modules/nismodule.c: In function 'nis_xdr_ypresp_maplist':
/Users/remi/src/cpython/Modules/nismodule.c:328:42: warning: cast between incompatible function types from 'int (*)(XDR *, nismaplist *)' {aka 'int (*)(struct __rpc_xdr *, struct nismaplist *)'} to 'int (*)(XDR *, void *, unsigned int)' {aka 'int (*)(struct __rpc_xdr *, void *, unsigned int)'} [-Wcast-function-type]
  328 |                      sizeof(nismaplist), (xdrproc_t)nis_xdr_ypmaplist))
      |                                          ^
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/rpc/rpc.h:76,
                 from /Users/remi/src/cpython/Modules/nismodule.c:17:
/Users/remi/src/cpython/Modules/nismodule.c: In function 'nisproc_maplist_2':
/Users/remi/src/cpython/Modules/nismodule.c:344:19: warning: cast between incompatible function types from 'int (*)(XDR *, char **)' {aka 'int (*)(struct __rpc_xdr *, char **)'} to 'int (*)(XDR *, void *, unsigned int)' {aka 'int (*)(struct __rpc_xdr *, void *, unsigned int)'} [-Wcast-function-type]
  344 |                   (xdrproc_t)nis_xdr_domainname, (caddr_t)argp,
      |                   ^
/Users/remi/src/cpython/Modules/nismodule.c:345:19: warning: cast between incompatible function types from 'int (*)(XDR *, nisresp_maplist *)' {aka 'int (*)(struct __rpc_xdr *, struct nisresp_maplist *)'} to 'int (*)(XDR *, void *, unsigned int)' {aka 'int (*)(struct __rpc_xdr *, void *, unsigned int)'} [-Wcast-function-type]
  345 |                   (xdrproc_t)nis_xdr_ypresp_maplist, (caddr_t)&res,
      |                   ^


I'm not sure about the fix, especially for nis but I will propose a PR. There is also some warnings concerning libffi_osx but this looks like a vendored dependency so I left it untouched.

----------
components: Build
messages: 368146
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: GCC 9 compiler warnings on MacOS Catalina
type: behavior

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

From report at bugs.python.org  Tue May  5 09:51:02 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 05 May 2020 13:51:02 +0000
Subject: [New-bugs-announce] [issue40517] Syntax highlighting for ASDL
Message-ID: <1588686662.66.0.89093613583.issue40517@roundup.psfhosted.org>


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

ASDL is around here for a long time, and it was showed as raw text on documentation (under library/ast), IMHO it would be great to highlight it.

----------
assignee: docs at python
components: Documentation
messages: 368148
nosy: BTaskaya, docs at python, eric.araujo, ezio.melotti, mdk, willingc
priority: normal
severity: normal
status: open
title: Syntax highlighting for ASDL
type: enhancement

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

From report at bugs.python.org  Tue May  5 09:57:38 2020
From: report at bugs.python.org (Shota Iwamoto)
Date: Tue, 05 May 2020 13:57:38 +0000
Subject: [New-bugs-announce] [issue40518] ValueError when using
 resource.setrlimit on macOS Catalina
Message-ID: <1588687058.44.0.691468502141.issue40518@roundup.psfhosted.org>


New submission from Shota Iwamoto <morio.prog at gmail.com>:

Hello, I'm having trouble when using `resource.setrlimit` on macOS.

```
import resource
resource.setrlimit(resource.RLIMIT_STACK, resource.getrlimit(resource.RLIMIT_STACK))
```

Running this code gives the following error:

```
Traceback (most recent call last):
  File "main.py", line 2, in <module>
    resource.setrlimit(resource.RLIMIT_STACK, resource.getrlimit(resource.RLIMIT_STACK))
ValueError: current limit exceeds maximum limit
```

I ran the same code in my linux environment and it worked.

* macOS Catalina 10.15.4 (19E287)
* `python --version` : Python 3.7.7

Thanks.

----------
components: macOS
messages: 368149
nosy: morioprog, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: ValueError when using resource.setrlimit on macOS Catalina
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue May  5 10:32:40 2020
From: report at bugs.python.org (Arusekk)
Date: Tue, 05 May 2020 14:32:40 +0000
Subject: [New-bugs-announce] [issue40519] Preserve AttributeError exception
 context in __getattr__
Message-ID: <1588689160.61.0.0507579486079.issue40519@roundup.psfhosted.org>


New submission from Arusekk <arek_koz at o2.pl>:

This is another attempt at issue 39865, but with a different attitude. Please see that issue for some extra motivation for this change.

My suggestion is to change getattr logic, which now is (in this case):

def getattr(obj, attr):
    try:
        return normal_getattr(obj, attr)
    except AttributeError:
        pass
    return obj.__getattr__(attr)

to be more like:

def getattr(obj, attr):
    try:
        return normal_getattr(obj, attr)
    except AttributeError:
        return obj.__getattr__(attr)

A __getattr__ function would then be able to know the exception context
(through sys.exc_info()) and to have the context automatically attached to all the exceptions raised (still respecting raise ... from None).

This particular issue only lies in Objects/typeobject.c, but is probably valid for other uses of PyErr_Clear() in the interpreter.
I checked some using a simple shell pipeline:

$ grep -r -A5 PyErr_ExceptionMatches |grep -C5 PyErr_Clear

And found some interesting examples of what be worth looking into:
Python/sysmodule.c:708
Parser/tokenizer.c:1110
Objects/memoryobject.c:fix_error_int

I prepared two patches for this (please forgive if I violated code style somewhere, I am not saying that they are a final version ready to be merged): a simple one, addressing just this very issue, and a robust one, allowing other places (e.g. from the list above) to reuse it.

----------
components: Interpreter Core
files: typeobject.patch
keywords: patch
messages: 368152
nosy: Arusekk, ammar2, pasenor
priority: normal
severity: normal
status: open
title: Preserve AttributeError exception context in __getattr__
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49122/typeobject.patch

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

From report at bugs.python.org  Tue May  5 10:45:19 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 05 May 2020 14:45:19 +0000
Subject: [New-bugs-announce] [issue40520] port the declartions in pydebug.h
 to initconfig.h
Message-ID: <1588689919.11.0.704783497449.issue40520@roundup.psfhosted.org>


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

Nick left a comment in `pydebug.h`
/* These global variable are defined in pylifecycle.c */
/* XXX (ncoghlan): move these declarations to pylifecycle.h? */

I have checked those global variables are not only debug variables and they are defined in `Python/initconfig.c` now.
If I understand clearly, those declarations should moved to `Include/cpython/initconfig.h` and `pydebug.h` could be deleted.

ref: https://github.com/python/cpython/commit/d600951748d7a19cdb3e58a376c51ed804b630e6

----------
components: Interpreter Core
messages: 368158
nosy: ncoghlan, shihai1991, vstinner
priority: normal
severity: normal
status: open
title: port the declartions in pydebug.h to initconfig.h
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 11:48:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2020 15:48:02 +0000
Subject: [New-bugs-announce] [issue40521] Make tuple, dict, frame free lists,
 unicode interned strings, unicode latin1 singletons per-interpreter
Message-ID: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

tuple, dict and frame use free lists to optimize the creation of objects.

Unicode uses "interned" strings to reduce the Python memory footprint and speedup dictionary lookups.

Unicode also uses singletons for single letter Latin1 characters ([U+0000; U+00FF] range).

All these optimizations are incompatible with isolated subinterpreters, since caches are currently shared by all inteprepreters. These caches should be made per-intepreter. See bpo-40512 "Meta issue: per-interpreter GIL" for the rationale.

I already made small integer singletons per interpreter in bpo-38858:

* commit 5dcc06f6e0d7b5d6589085692b86c63e35e2325e
* commit 630c8df5cf126594f8c1c4579c1888ca80a29d59.

----------
components: Interpreter Core
messages: 368175
nosy: vstinner
priority: normal
severity: normal
status: open
title: Make tuple, dict, frame free lists, unicode interned strings, unicode latin1 singletons per-interpreter
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 13:12:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 May 2020 17:12:14 +0000
Subject: [New-bugs-announce] [issue40522] Subinterpreters: get the current
 Python interpreter state from Thread Local Storage (autoTSSkey)
Message-ID: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

_PyThreadState_GET() gets the current Python thread state from _PyRuntime.gilstate.tstate_current atomic variable.

When I experimented per-interpreter GIL (bpo-40512), I got issues with _PyThreadState_GET() which didn't return the expected Python thread state.

I propose to modify _PyThreadState_GET() in the exprimental isolated subinterpreters mode to get and set the current Python thread state using a Thread Local Storage: autoTSSkey.

----------
components: Interpreter Core
messages: 368182
nosy: vstinner
priority: normal
severity: normal
status: open
title: Subinterpreters: get the current Python interpreter state from Thread Local Storage (autoTSSkey)
versions: Python 3.9

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

From report at bugs.python.org  Tue May  5 14:34:38 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 May 2020 18:34:38 +0000
Subject: [New-bugs-announce] [issue40523] Weakref proxy missing pass
 throughs for hash() and reversed()
Message-ID: <1588703678.72.0.637534837496.issue40523@roundup.psfhosted.org>


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

from weakref import proxy

class Alpha:
    def __len__(self):
        return 3
    def __reversed__(self):
        return iter('cba')
    def __hash__(self):
        return hash('abc')

a = Alpha()

# Direct use of the instance works
print(len(a))
print(list(reversed(a)))
print(hash(a))

# Proxies can use the dunder methods directly
r = proxy(a)
print(r.__len__())
print(list(r.__reversed__()))
print(r.__hash__())

# Proxy fails for __reversed__ and __hash__
print(len(r), 'This succeeds')
try:
    print(list(reversed(r)))
except TypeError:
    print('reverse(r) failed')
try:
    print(hash(r))
except TypeError:
    print('hash(r) failed')

----------
components: Library (Lib)
messages: 368197
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Weakref proxy missing pass throughs for hash() and reversed()
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May  5 14:46:18 2020
From: report at bugs.python.org (Code436)
Date: Tue, 05 May 2020 18:46:18 +0000
Subject: [New-bugs-announce] [issue40524] Print() issue
Message-ID: <1588704378.01.0.0352511120518.issue40524@roundup.psfhosted.org>


Change by Code436 <pwpablowills at gmail.com>:


----------
components: Regular Expressions
files: Python bug.png
nosy: Coder436, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Print() issue
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49125/Python bug.png

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

From report at bugs.python.org  Tue May  5 18:55:41 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 05 May 2020 22:55:41 +0000
Subject: [New-bugs-announce] [issue40525] zipapps execute symlinks as if
 they are code
Message-ID: <1588719341.33.0.757930708567.issue40525@roundup.psfhosted.org>


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

```console
$ ln -s 'import os; os.system("echo hi")' __main__.py
$ ls -al
total 8
drwxr-xr-x 2 asottile asottile 4096 May  5 15:55 .
drwxr-xr-x 3 asottile asottile 4096 May  5 14:50 ..
lrwxrwxrwx 1 asottile asottile   31 May  5 15:55 __main__.py -> 'import os; os.system("echo hi")'
$ zip --symlinks out.zip __main__.py 
  adding: __main__.py (stored 0%)
$ python3 out.zip
hi
```

I expect the output to be similar to running `__main__.py`:

```
$ python3 __main__.py 
python3: can't open file '__main__.py': [Errno 2] No such file or directory
```

(real usecase, I wanted `__main__.py` to be a symlink but got a very strange NameError and traced it down to executing the symlink target  name instead of the symlink destination)

----------
components: Interpreter Core
messages: 368212
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: zipapps execute symlinks as if they are code
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed May  6 00:06:03 2020
From: report at bugs.python.org (Chris Drake)
Date: Wed, 06 May 2020 04:06:03 +0000
Subject: [New-bugs-announce] [issue40526] documentation bad on asyncio
Message-ID: <1588737963.7.0.298937096343.issue40526@roundup.psfhosted.org>


New submission from Chris Drake <cnd at geek.net.au>:

> The sample on this page is not demonstrating anything asynchronous:
> https://docs.python.org/3/library/asyncio.html

Put something that is relevant please.  e.g.

import asyncio
import time

async def say_after(delay, what):
    await asyncio.sleep(delay)
    print(what)

async def main():
    print(f"started at {time.strftime('%X')}")
    await say_after(2, 'world')
    await say_after(1, 'hello')
    print(f"finished at {time.strftime('%X')}")

asyncio.run(main())

----------
components: asyncio
messages: 368223
nosy: asvetlov, cnd, yselivanov
priority: normal
severity: normal
status: open
title: documentation bad on asyncio
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 05:32:05 2020
From: report at bugs.python.org (Florian Bruhin)
Date: Wed, 06 May 2020 09:32:05 +0000
Subject: [New-bugs-announce] [issue40527] Multiple "unknown option" errors
 when passing unknown arguments to the interpreter
Message-ID: <1588757525.36.0.428936320881.issue40527@roundup.psfhosted.org>


New submission from Florian Bruhin <python.org at the-compiler.org>:

A minor issue I just discovered today: When e.g. doing "python3 --foo", the output is:

  unknown option --foo
  unknown option --foo
  unknown option --foo
  usage: /usr/bin/python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...

With more dashes in the options, it seems to get worse:

  unknown option --foo-bar-baz
  unknown option --foo-bar-baz
  unknown option --foo-bar-baz
  unknown option --foo-bar-baz
  unknown option --foo-bar-baz
  unknown option --foo-bar-baz
  unknown option --foo-bar-baz
  usage: /usr/bin/python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...

This seems very similar to issue16306 (thus why I added people involved there to the nosy list), except that it happens with long rather than short arguments.

This only happens with Python 3.8/3.9, not 3.7 or older. I was able to bisect this to the following commit:

commit 6dcb54228e7520abd058897440c26e323f62afcd
Author: Victor Stinner <vstinner at redhat.com>
Date:   Tue Mar 5 02:44:12 2019 +0100

    bpo-36142: Add _PyPreConfig_ReadFromArgv() (GH-12173)
    
    The new function is now responsible to parse -E and -I command line
    arguments.

----------
components: Interpreter Core
messages: 368231
nosy: The Compiler, hieu.nguyen, serhiy.storchaka, tweksteen, vstinner
priority: normal
severity: normal
status: open
title: Multiple "unknown option" errors when passing unknown arguments to the interpreter
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed May  6 07:17:00 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 06 May 2020 11:17:00 +0000
Subject: [New-bugs-announce] [issue40528] Improve / Clear ASDL generator
Message-ID: <1588763820.27.0.218398998224.issue40528@roundup.psfhosted.org>


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

- Better error messages with punctuation
- Py_UNREACHABLE() for unreachable states
- Removal of several 'unused' and 'undocumented (in Zephyr ASDL spec) built-in types.

----------
components: Interpreter Core
messages: 368235
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Improve / Clear ASDL generator
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 08:34:19 2020
From: report at bugs.python.org (Madhusudhan Kasula)
Date: Wed, 06 May 2020 12:34:19 +0000
Subject: [New-bugs-announce] [issue40529] Auto Completions with case
 insensitive
Message-ID: <1588768459.35.0.455156839892.issue40529@roundup.psfhosted.org>


New submission from Madhusudhan Kasula <kasula.madhusudhan at gmail.com>:

Now, we don't have user option to make completions with case insensitive.
It would be nice if user have option to enable/disable case insensitive completions.

----------
components: Library (Lib)
messages: 368241
nosy: mkasula
priority: normal
severity: normal
status: open
title: Auto Completions with case insensitive
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/issue40529>
_______________________________________

From report at bugs.python.org  Wed May  6 08:39:03 2020
From: report at bugs.python.org (Vadim Godunko)
Date: Wed, 06 May 2020 12:39:03 +0000
Subject: [New-bugs-announce] [issue40530] distutils/cygwinccompiler.py
 doesn't support recent msvc versions
Message-ID: <1588768743.33.0.586739194503.issue40530@roundup.psfhosted.org>


New submission from Vadim Godunko <godunko at adacore.com>:

Prebuild Python 3.7 package can't be used with GObjectIntrospection library on Windows due to miss of support of used MSVC compiler by distutils/cygwinccompiler.py module.

sys.version returns:

3.7.6 (tags/v3.7.6:43364a7ae0, Dec 19 2019, 00:42:30) [MSC v.1916 64 bit 
(AMD64)]

so, compiler version is detected as 1916, while get_msvcr() function supports only versions up to '1600'.

----------
messages: 368242
nosy: Vadim Godunko
priority: normal
severity: normal
status: open
title: distutils/cygwinccompiler.py doesn't support recent msvc versions
versions: Python 3.7

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

From report at bugs.python.org  Wed May  6 09:49:00 2020
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Marcos?=)
Date: Wed, 06 May 2020 13:49:00 +0000
Subject: [New-bugs-announce] [issue40531] Adding the method find() to list
Message-ID: <1588772940.44.0.121672930635.issue40531@roundup.psfhosted.org>


New submission from Jo?o Marcos <jmpb190900 at gmail.com>:

"""
PROBLEM:

When trying to search the position of an element inside a list, we should use the `in` operator to first check if the element exists, and then use the `index` method to obtain the index.

`in` (__contains__) runs a linear search to return the boolean.
`index`        also runs a linear search to return the index.

This makes the code slower, because we need to search for the same item twice.


FEATURE PROPOSAL:

Similar to str.find(), list.find() should be implemented, where -1 is returned when the element isn't present
"""


# Since there's no list.find(), this is my workaround to achieve making only one linear search per query
def find(container: list, index: int) -> int:
    """ Str.find() behavior but for lists """
    try:
        return container.index(index)
    except ValueError:
        return -1

# Example driver code:
index = find(list, possible_element)
if index_of_element == -1:
    pass # Not found
else:
    pass # Found

----------
messages: 368254
nosy: Jo?o Marcos
priority: normal
severity: normal
status: open
title: Adding the method find() to list
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 10:28:45 2020
From: report at bugs.python.org (Code436)
Date: Wed, 06 May 2020 14:28:45 +0000
Subject: [New-bugs-announce] [issue40532] Persmission error
Message-ID: <1588775325.08.0.437728334126.issue40532@roundup.psfhosted.org>


New submission from Code436 <pwpablowills at gmail.com>:

When I try to edit a module *as an administrator* is show permission denied even tho in permissions administrator is set to full control

----------
messages: 368256
nosy: Coder436
priority: normal
severity: normal
status: open
title: Persmission error
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed May  6 11:11:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 May 2020 15:11:35 +0000
Subject: [New-bugs-announce] [issue40533] Subinterpreters: don't share
 Python objects between interpreters
Message-ID: <1588777895.61.0.395509624257.issue40533@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

To get one GIL per interpreter (bpo-40512), either PyObject.ob_refcnt member must become an atomic variable, or subinterpreters must not share any object.

Right now, subinterpreters share Python objects. For example, PyModule_Type is declared statically and so shared by all interpreters and so PyModule_Type.tp_mro tuple is accessed in parallel by multiple interpreters. If PyObject.ob_refcnt is not atomic, Py_INCREF() and Py_DECREF() are unsafe and tp_mro tuple can be destroyed whereas it is still used.

I propose to make PyObject.ob_refcnt atomic for now, when Python is built with EXPERIMENTAL_ISOLATED_SUBINTERPRETERS macro defined. It's a temporary workaround until subinterpreters stop sharing objects.

----------
components: Interpreter Core
messages: 368262
nosy: vstinner
priority: normal
severity: normal
status: open
title: Subinterpreters: don't share Python objects between interpreters
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 11:43:49 2020
From: report at bugs.python.org (T UA)
Date: Wed, 06 May 2020 15:43:49 +0000
Subject: [New-bugs-announce] [issue40534] ShUtil doc deficiencies
Message-ID: <1588779829.75.0.0438051451832.issue40534@roundup.psfhosted.org>


New submission from T UA <kai.peters at gmail.com>:

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

The operational outcome for the various copy functions is not described for the cases in which the target file already exists. Do they overwrite, do they raise exceptions and if so, which ones?

----------
messages: 368270
nosy: T UA
priority: normal
severity: normal
status: open
title: ShUtil doc deficiencies

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

From report at bugs.python.org  Wed May  6 12:23:03 2020
From: report at bugs.python.org (Ajaya)
Date: Wed, 06 May 2020 16:23:03 +0000
Subject: [New-bugs-announce] [issue40535] While build python 3.8.2 in linux
 ctypes.so is using libffi.so.6 instead of libffi.so.7
Message-ID: <1588782183.35.0.376036230435.issue40535@roundup.psfhosted.org>


New submission from Ajaya <ajayakumars265 at gmail.com>:

i am using libffi-3.3.tgz for building python 3.8.2 in Linux. In windows there is no problem it is using libffi-7.dll.In linux it is using libffi.so.6 instead of libffi.so.7.
i am using "./configure --prefix=/u/$loginID/Python$pythonVersion --enable-debug".

----------
components: Build
messages: 368277
nosy: Ajaya
priority: normal
severity: normal
status: open
title: While build python 3.8.2 in linux  ctypes.so is using libffi.so.6 instead of libffi.so.7
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Wed May  6 13:19:51 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 06 May 2020 17:19:51 +0000
Subject: [New-bugs-announce] [issue40536] Addition of a "list of available
 time zones" function to zoneinfo
Message-ID: <1588785591.81.0.248136692657.issue40536@roundup.psfhosted.org>


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

One thing that I sort of overlooked in PEP 615 that I think will be a common feature request for zoneinfo is the ability to get a list of time zones available on the current TZPATH.

This is more complicated to implement than it sounds like, but luckily I already did it in order to implement the property tests for the zoneinfo module:

https://github.com/pganssle/zoneinfo/blob/ffd21a6d065e04725e04b37bb430c2559fefd5fa/tests/test_zoneinfo_property.py#L23-L70

The biggest complication is that there are files on TZPATH that are not necessarily time zones, and when I looked I couldn't easily find a list of all available time zones, so the only way to tell which ones are time zones and which ones aren't is to open each one and read the first 4 bytes. However, `tzdata` does ship with a list of available time zones, so the way I've got the function working right now is:

1. If `tzdata` is installed ? despite the fact that it's technically the end of the search path, convert the list of available zones that ships with `tzdata` to your starting set (since you know these are all valid zones).
2. Walk the `tzpath`, and every time you find something not in the set of valid keys, open it and read the first 4 bytes, then add that to the set.

The common cases will be that `tzdata` is not available (in which case no harm done), or `tzdata` has the same set of keys as the TZPATH, in which case you never have to open any of the TZif files. The fact that the search order is inverted from what it normally is doesn't matter because the output is the union of all the sets anyway.

I don't know that the PEP needs to be amended ? if this were a feature request for Python 3.10 I don't think it would need a PEP to go through, but I don't mind amending the PEP to document it.

Design decisions (with my initial answers, loosely held):

1. Should this be a classmethod or a free-standing function?

I'm inclined towards free-standing function because zoneinfo.TZPATH is at the module level and not the class level.

2. What should the return type be?

I think frozenset() or set(); a sorted list is also a reasonable option, but for people who just want to use "in" or show some subset of available zones, that would be wasteful.

We should go with frozenset() if we want there to be some possibility of caching the result in the future.

3. Should we try to cache the result?

I would say no, at least for now. It would not be super easy to get the cache invalidation right in the general case, and not many people are likely to be sensitive to the performance of this operation ? the people who are can easily create their own cache.

4. What should it be called?

Naming things is hard. Options:

- zoneinfo.timezones()
- zoneinfo.all_timezones()
- zoneinfo.timezone_{list,set}()
- zoneinfo.valid_timezones()
- zoneinfo.valid_keys()
- zoneinfo.available_timezones()

`pytz` has a similar thing and calls it all_timezones. It also has something called common_timezones, but that is a bit harder to pull off and I'm not confident that we'll get something satisfactory before the feature freeze.

----------
components: Library (Lib)
messages: 368285
nosy: belopolsky, lemburg, p-ganssle
priority: normal
severity: normal
status: open
title: Addition of a "list of available time zones" function to zoneinfo
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 15:49:02 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 06 May 2020 19:49:02 +0000
Subject: [New-bugs-announce] [issue40537] Typo in  Doc/library/sqlite3.rst
Message-ID: <1588794542.32.0.922466933824.issue40537@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

>From this:

Now you want to store the point in a single SQLite column.  First you'll have to
choose one of the supported types first to be used for representing the point.

First looks repeated.

----------
assignee: docs at python
components: Documentation
messages: 368295
nosy: docs at python, nanjekyejoannah
priority: normal
severity: normal
status: open
title: Typo in  Doc/library/sqlite3.rst
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 16:59:14 2020
From: report at bugs.python.org (Jo King)
Date: Wed, 06 May 2020 20:59:14 +0000
Subject: [New-bugs-announce] [issue40538] struct.calcsize('L')== 8 but 4 is
 specified in documentation
Message-ID: <1588798754.7.0.999279988731.issue40538@roundup.psfhosted.org>


Change by Jo King <jk.temp at go4more.de>:


----------
nosy: JoKing
priority: normal
severity: normal
status: open
title: struct.calcsize('L')== 8 but 4 is specified in documentation
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed May  6 18:21:15 2020
From: report at bugs.python.org (Lewis Ball)
Date: Wed, 06 May 2020 22:21:15 +0000
Subject: [New-bugs-announce] [issue40539] Docs - difflib.SequenceMatcher
 quick_ratio and real_quick_ratio improved docs
Message-ID: <1588803675.88.0.74490317192.issue40539@roundup.psfhosted.org>


New submission from Lewis Ball <lrjball at gmail.com>:

Currently the docs for `difflib.SequenceMatcher.quick_ratio()` just says 'Return an upper bound on ratio() relatively quickly', which doesn't give much of an idea about how that upper bound is calculated. `real_quick_ratio` has similarly brief documentation.

I'll raise a PR shortly to add a more verbose description to each of these ratios, so that it is clear when each should be used.

My current suggestions would be:

quick_ratio
    Return an upper bound on ratio() relatively quickly. This is the highest possible ratio() given these letters, regardless of their order.

real_quick_ratio
    Return an upper bound on ratio() very quickly. This is the highest possible ratio() given the lengths of a and b, regardless of their letters. i.e. 2*(min(len(a), len(b))/(len(a) + len(b))

----------
assignee: docs at python
components: Documentation
messages: 368305
nosy: Lewis Ball, docs at python
priority: normal
severity: normal
status: open
title: Docs - difflib.SequenceMatcher quick_ratio and real_quick_ratio improved docs
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 18:32:58 2020
From: report at bugs.python.org (Peter Law)
Date: Wed, 06 May 2020 22:32:58 +0000
Subject: [New-bugs-announce] [issue40540] inconstent stdin buffering/seeking
 behaviour
Message-ID: <1588804378.46.0.584037601686.issue40540@roundup.psfhosted.org>


New submission from Peter Law <PeterJCLaw+py at gmail.com>:

`sys.stdin` (on Windows, tested Pythons 3.6-3.8) appears to have different seeking behaviour depending on the source of the incoming data. This seems arguably reasonable given that `stdin` isn't always seekable, however even in the failing case `sys.stdin.seekable()` returns `True`.

Given the `reader.py` source:

``` python
import sys


def coding_check(lines, default='utf-8'):
    for line_number, line in enumerate(lines, 1):
        print((line_number, line))
        if line_number > 2:
            break
    return default


stdin = sys.stdin
print(stdin.seekable())

stdin.seek(0)

coding_check(stdin)

stdin.seek(0)
print(stdin.read())
```

then for two similar invocations we get differing results:

```
> python reader.py < reader.py
True
(1, 'import sys\n')
(2, '\n')
(3, '\n')
import sys


def coding_check(lines, default='utf-8'):

<... etc. redacted for brevity>

>
```

```
> type reader.py | python reader.py
True
(1, 'import sys\n')
(2, '\n')
(3, '\n')

>
```

I realise that raw standard input isn't always seekable, however I would hope that in the case that it isn't seekable that `.seekable()` would tell us that.

I also tried wrapping `stdin.buffer` in an `io.BufferedReader` and using that, however for short files (three lines or less) this issue is still present. I'm not sure if this is something I'm misunderstanding around buffered readers, a variation on this issue or another issue though.

----------
components: Windows
messages: 368306
nosy: PeterJCLaw, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: inconstent stdin buffering/seeking behaviour
type: behavior

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

From report at bugs.python.org  Wed May  6 18:35:20 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 May 2020 22:35:20 +0000
Subject: [New-bugs-announce] [issue40541] Add optional weights parameter to
 random.sample()
Message-ID: <1588804520.3.0.249071627671.issue40541@roundup.psfhosted.org>


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

I've seen multiple requests for this and it isn't obvious how to do it with the existing tooling.  

The example currently given in the recipes section isn't scalable because it involves expanding the population into a big list with repeated elements:

      sample(['x', 'x', 'x', 'x', 'y', 'y', 'z'], k=5)

Example task:  Given an urn with 8 red balls, 2 white balls, and 3 green balls, choose ten without replacement:

    >>> population = ['red', 'blue', 'green']
    >>> weights =    [  8,      5,      3   ]
    >>> sample(population, weights=weights, k=10)
    ['red', 'green', 'blue', 'red', 'green', 'blue', 'red', 'blue', 'red', 'blue']

I could also add *cum_weights* as an optional optimization but think it best to wait until someone asks for it ;-)

----------
components: Library (Lib)
messages: 368307
nosy: rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add optional weights parameter to random.sample()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May  6 19:19:40 2020
From: report at bugs.python.org (Roman)
Date: Wed, 06 May 2020 23:19:40 +0000
Subject: [New-bugs-announce] [issue40542] path environment variable not
 created correctly
Message-ID: <1588807180.48.0.747657967597.issue40542@roundup.psfhosted.org>


New submission from Roman <niborjus at gmail.com>:

The Python 3.8 for Windows installer has an option to add the install folder to the path environment variable. It adds the path to the front of the list so that it is the first item. According to my understanding, this is bad behavior. It should add new path items to the end of the list because Windows searches in order. c:\windows\system32 should remain the first item in the list. This is a classic mistake of installers.

----------
components: Installation
messages: 368312
nosy: Roman
priority: normal
severity: normal
status: open
title: path environment variable not created correctly
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu May  7 03:41:48 2020
From: report at bugs.python.org (Muthu A)
Date: Thu, 07 May 2020 07:41:48 +0000
Subject: [New-bugs-announce] [issue40543] Tamil locale is using outdated
 encoding
Message-ID: <1588837308.8.0.873026053476.issue40543@roundup.psfhosted.org>


New submission from Muthu A <ezhillang at gmail.com>:

Tamil locale (TA_IN, TA_SL, TA_SG, TA_MY) is using outdated encoding of TSCII. Tamil community is widely using UTF-8 encoding.
Further, the 'locale' standard library package in Python3 should be updated with these strings.

Should the maintainers desire assistance on this task, as a native speaker of the language, I can propose a patch or recommed other native speakers for this task.

----------
files: Screen Shot 2020-05-06 at 11.04.18 PM.png
messages: 368325
nosy: Muthu A
priority: normal
severity: normal
status: open
title: Tamil locale is using outdated encoding
Added file: https://bugs.python.org/file49137/Screen Shot 2020-05-06 at 11.04.18 PM.png

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

From report at bugs.python.org  Thu May  7 04:22:24 2020
From: report at bugs.python.org (mirii1994)
Date: Thu, 07 May 2020 08:22:24 +0000
Subject: [New-bugs-announce] [issue40544] Formatter exception when using
 logging.config.fileConfig
Message-ID: <1588839744.95.0.946020207504.issue40544@roundup.psfhosted.org>


New submission from mirii1994 <miri.ignatiev at logz.io>:

In Python 3.8, a "validate" key was added to the Formatter, with a default value of True (https://docs.python.org/3/library/logging.html#formatter-objects).
When using the "logging.config.fileConfig()" method, there is no way to set the "validate" field to "False" if needed, thus making the code to throw an exception.
In "logging.config.dictConfig()" it is possible, since there is an "if" statement that checks the validate field was given a value in the configuration.
It would be useful to add the option to set the "validate" field through "logging.config.fileConfig" like it is on "logging.config.dictConfig", since it's breaking the code for many users who want to upgrade to python 3.8.

----------
messages: 368326
nosy: mirii1994
priority: normal
severity: normal
status: open
title: Formatter exception when using logging.config.fileConfig
versions: Python 3.8

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

From report at bugs.python.org  Thu May  7 05:29:58 2020
From: report at bugs.python.org (Julien Danjou)
Date: Thu, 07 May 2020 09:29:58 +0000
Subject: [New-bugs-announce] [issue40545] Expose _PyErr_GetTopmostException
Message-ID: <1588843798.84.0.388180612972.issue40545@roundup.psfhosted.org>


New submission from Julien Danjou <julien at danjou.info>:

The function _PyErr_GetTopmostException() is not exported and is useful to get access to exceptions info from a PyThreadState.

----------
components: C API
messages: 368327
nosy: jd
priority: normal
severity: normal
status: open
title: Expose _PyErr_GetTopmostException
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu May  7 12:05:21 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 07 May 2020 16:05:21 +0000
Subject: [New-bugs-announce] [issue40546] Inconsistencies between pegen and
 traceback SyntaxErrors
Message-ID: <1588867521.75.0.200197181166.issue40546@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

Since traceback is programmed to match the SyntaxErrors emitted by the old parser, there are some inconsistencies between how it formats SyntaxErrors and how the new parser does it. One example for such behaviour is the following:

New Parser:
?? ./python.exe
Python 3.9.0a6+ (heads/master:4638c64295, May  7 2020, 16:47:53)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1 | 2 |
  File "<stdin>", line 1
    x = 1 | 2 |
               ^
SyntaxError: invalid syntax

Old parser and traceback module:
?? ./python.exe -X oldparser
Python 3.9.0a6+ (heads/master:4638c64295, May  7 2020, 16:47:53)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 1 | 2 |
  File "<stdin>", line 1
    x = 1 | 2 |
              ^
SyntaxError: invalid syntax

We actually think that the new parser does a better job here, since there is nothing wrong with the `|` itself, the error is that a newline follows it and that's where the caret should point to.

Tests that are testing this are currently skipped. I think we should change traceback to match the new parser, wherever we think the new parser does a better job, and "unskip" these tests.

----------
components: Library (Lib)
messages: 368353
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Inconsistencies between pegen and traceback SyntaxErrors
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu May  7 12:37:14 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9my_Oudompheng?=)
Date: Thu, 07 May 2020 16:37:14 +0000
Subject: [New-bugs-announce] [issue40547] 2to3 raise can silently remove
 code from old 2.4 string exceptions
Message-ID: <1588869434.41.0.260360648069.issue40547@roundup.psfhosted.org>


New submission from R?my Oudompheng <remyoudompheng at gmail.com>:

When running "2to3 -f raise" on the following code, which uses an old Python 2.4 raise of a string:

def f():
    raise ("message %s %s" % (1, 2))

try:
    f()
finally:
    pass

I obtain the following quite surprising result. I would have expected to get either an error or leave the original file unchanged, because "raise (s)" is syntactically valid although incorrect. 

$ 2to3 -f raise w.py
RefactoringTool: Refactored w.py
--- w.py	(original)
+++ w.py	(refactored)
@@ -1,5 +1,5 @@
 def f():
-    raise ("message %s %s" % (1, 2))
+    raise "message %s %s"
 
 try:
     f()

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 368355
nosy: R?my Oudompheng
priority: normal
severity: normal
status: open
title: 2to3 raise can silently remove code from old 2.4 string exceptions
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu May  7 13:39:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 May 2020 17:39:37 +0000
Subject: [New-bugs-announce] [issue40548] Always run GitHub action jobs,
 even on documentation-only jobs
Message-ID: <1588873177.1.0.956855864504.issue40548@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

bpo-39837 made Azure Pipelines CI non-mandatory. Travis CI was made mandatory to have at least one mandatory job: https://github.com/python/core-workflow/issues/365

I would prefer to have at least one mandatory Windows CI running on Python pull requests. Before we had pre-commit checks, it was too common to break Windows. I would prefer to not regress on that aspect.

--

Currently, GitHub action jobs ignore "documentation-only" changes. Extract of .github/workflows/build.yml:

on:
  push:
    branches:
    - master
    - 3.8
    - 3.7
    paths-ignore:
    - 'Doc/**'
    - 'Misc/**'
    - '**/*.md'
    - '**/*.rst'

If a job is marked as mandatory but the GitHub action is skipped because of paths-ignore, the PR cannot be merged :-( It seems to be a known GitHub limitation which is not going to be fixed soon:
https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047/6

To workaround is to always run GitHub action jobs, even on documentation-only jobs.

I propose to always run GitHub actions and then make the Windows (64 bit) job mandatory.

--

Sadly, it will waste resources for documentation-only jobs. To avoid that, the Windows job can be modified later to be skipped if it detects that the PR is a documentation-only change.

Steve Dower wrote:
"That workaround looks roughly like what is in the Azure Pipelines files. Someone just needs the time to go and migrate it."
https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047/6

Note: the Travis CI job (.travis.yml) uses the following check:

      # Pull requests are slightly complicated because $TRAVIS_COMMIT_RANGE
      # may include more changes than desired if the history is convoluted.
      # Instead, explicitly fetch the base branch and compare against the
      # merge-base commit.
      git fetch -q origin +refs/heads/$TRAVIS_BRANCH
      changes=$(git diff --name-only HEAD $(git merge-base HEAD FETCH_HEAD))
      echo "Files changed:"
      echo "$changes"
      if ! echo "$changes" | grep -qvE '(\.rst$)|(^Doc)|(^Misc)'
      then
        echo "Only docs were updated, stopping build process."
        exit
      fi

--

More background on these CI issues:

* https://bugs.python.org/issue39837
* https://github.com/python/core-workflow/issues/365
* https://discuss.python.org/t/make-one-windows-ci-job-mandatory/4047

----------
components: Build
messages: 368357
nosy: vstinner
priority: normal
severity: normal
status: open
title: Always run GitHub action jobs, even on documentation-only jobs
versions: Python 3.9

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

From report at bugs.python.org  Thu May  7 14:05:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 May 2020 18:05:48 +0000
Subject: [New-bugs-announce] [issue40549] Convert posixmodule.c to
 multiphase initialization (PEP 489)
Message-ID: <1588874748.21.0.997527577662.issue40549@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Attached PR converts posixmodule.c to multiphase initialization (PEP 489).

It uses the new shiny PyType_FromModuleAndSpec() and PyType_GetModule() of the PEP 573 added by bpo-38787.

The PR removes the following macro :-)

#define _posixstate_global ((_posixstate *)PyModule_GetState(PyState_FindModule(&posixmodule)))

----------
components: Interpreter Core
messages: 368362
nosy: vstinner
priority: normal
severity: normal
status: open
title: Convert posixmodule.c to multiphase initialization (PEP 489)
versions: Python 3.9

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

From report at bugs.python.org  Thu May  7 16:01:24 2020
From: report at bugs.python.org (Alexander Overvoorde)
Date: Thu, 07 May 2020 20:01:24 +0000
Subject: [New-bugs-announce] [issue40550] Popen.terminate fails with
 ProcessLookupError under certain conditions
Message-ID: <1588881684.43.0.416849020134.issue40550@roundup.psfhosted.org>


New submission from Alexander Overvoorde <overv161 at gmail.com>:

The following program frequently raises a ProcessLookupError exception when calling proc.terminate():

```
import threading
import subprocess
import multiprocessing

proc = subprocess.Popen(["sh", "-c", "exit 0"])

q = multiprocessing.Queue()

def communicate_thread(proc):
    proc.communicate()

t = threading.Thread(target=communicate_thread, args=(proc,))
t.start()

proc.terminate()

t.join()
```

I'm reproducing this with Python 3.8.2 on Arch Linux by saving the script and rapidly executing it like this:

$ bash -e -c "while true; do python3 test.py; done

The (unused) multiprocessing.Queue seems to play a role here because the problem vanishes when removing that one line.

----------
components: Library (Lib)
messages: 368370
nosy: Alexander Overvoorde
priority: normal
severity: normal
status: open
title: Popen.terminate fails with ProcessLookupError under certain conditions
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu May  7 16:09:53 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Thu, 07 May 2020 20:09:53 +0000
Subject: [New-bugs-announce] [issue40551] PRs should be rebased on top of
 master before running the build/tests
Message-ID: <1588882193.5.0.928762641921.issue40551@roundup.psfhosted.org>


New submission from Filipe La?ns <filipe.lains at gmail.com>:

Let's imagine this scenario:

(master history)
abcd - some commit
hijk - change something

(pull request history)
abcd - some commit
defg - add feature


      master                                  pull request

abcd - some commit           -------      defg - add feature
hijk - change something


Currently in the CI we checkout defg and run the tests. If hijk introduces some change that breaks defg, we only know about it after defg is in master.

I propose pull requests to be automatically rebased on top of master, so that the resulting story becomes:

abcd - some commit
hijk - change something
defg - add feature

Now defg is properly tested :)

This may not be an issue in smaller projects, but in cpython where most things are a moving target, it should make a difference. Here I am referring to master but applies to all other maintained branches.

Github can't merge if the PR doesn't cleanly rebase to master, or rather, it will ask you to resolve conflicts, so I don't think there should be any problem.

Keep in mind that this only works at the time the pull request is created. To check against the latest master the build needs to be retriggered, which you should be able to do manually.
Even if we don't check against the latest master when the PR is merged, this is already an improvement. After this we could look into maybe automatically retriggering the CI on approvals, or better, managing merges with a bot.

----------
components: Build
messages: 368371
nosy: FFY00
priority: normal
severity: normal
status: open
title: PRs should be rebased on top of master before running the build/tests
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Thu May  7 16:48:23 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 07 May 2020 20:48:23 +0000
Subject: [New-bugs-announce] [issue40552] Enhance for loop and copy example
 in tutorial
Message-ID: <1588884503.92.0.729674513869.issue40552@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

During the past few weeks we got two reports of an example not working in the tutorial: [1], [2].


[1]: https://mail.python.org/archives/list/docs at python.org/message/ZJM3S2TE5UPFYIII5R4VQ4KY2WN4TKVO/
[2]: https://mail.python.org/archives/list/docs at python.org/thread/6FZ55HTMILK4P6EOYLAI7WXAY427NKQU/

Problem is: the example uses a `users` variable that is not defined.

users should be a dict, which is not straightforward for newcomers neither, so I propose to define it to:

    users = {"Hans": "active", "Andrea": "inactive", "Nils": "active"}

in the example, to make it work.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 368373
nosy: docs at python, mdk
priority: low
severity: normal
status: open
title: Enhance for loop and copy example in tutorial
type: enhancement

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

From report at bugs.python.org  Thu May  7 16:55:32 2020
From: report at bugs.python.org (Zain Said)
Date: Thu, 07 May 2020 20:55:32 +0000
Subject: [New-bugs-announce] [issue40553] Python 3.8.2 Mac freezing/not
 responding when saving new programs
Message-ID: <1588884932.92.0.367303002443.issue40553@roundup.psfhosted.org>


New submission from Zain Said <zaine19992 at gmail.com>:

What I'm currently using: 
Mid 2012 13'' MacBook Pro OS Catalina 10.15.4
Python 3.8.2

I'm having an issue with saving a new python program. When I go to "save as" a program python seems to freeze/not . The only way I've been able to get python working again is to "Force Quit" the existing process and reopen IDLE. Running and writing existing programs seems to be working fine.

----------
messages: 368375
nosy: Zain
priority: normal
severity: normal
status: open
title: Python 3.8.2 Mac freezing/not responding when saving new programs
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu May  7 17:36:57 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 07 May 2020 21:36:57 +0000
Subject: [New-bugs-announce] [issue40554] Add escape to the glossary?
Message-ID: <1588887417.08.0.726428643093.issue40554@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

Geoff Cutter noticed via docs@ that escape is not defined in the glossary.

I concur with the idea of adding it, opening as an "easy" issue, even if finding a good definition might not be that easy.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 368382
nosy: docs at python, mdk
priority: low
severity: normal
status: open
title: Add escape to the glossary?

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

From report at bugs.python.org  Thu May  7 19:48:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 May 2020 23:48:56 +0000
Subject: [New-bugs-announce] [issue40555] pegen (PEP 617): bug in error
 handling
Message-ID: <1588895336.21.0.583196255938.issue40555@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

autopep8 test suite does crash on Python 3.9.0a6. The bug can be reproduced with:

Python 3.9.0a6+ (heads/master:b7a78ca74a, May  8 2020, 01:46:01) 
[GCC 10.0.1 20200430 (Red Hat 10.0.1-0.14)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> compile('"\\xhh" \\',  '<string>', 'exec', dont_inherit=True)
python: Objects/typeobject.c:984: type_call: Assertion `!_PyErr_Occurred(tstate)' failed.
 Abandon (core dumped)

It seems like p->error_condition should be checked more often in Parser/pegen/parse.c.

----------
components: Interpreter Core
messages: 368391
nosy: gvanrossum, lys.nikolaou, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: pegen (PEP 617): bug in error handling
versions: Python 3.9

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

From report at bugs.python.org  Thu May  7 23:04:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 08 May 2020 03:04:25 +0000
Subject: [New-bugs-announce] [issue40556] test__xxsubinterpreters leaked
 [1486, 1484, 1484, 1484] references
Message-ID: <1588907065.92.0.443788591369.issue40556@roundup.psfhosted.org>


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

Minimal reproducer:

./python -m test test__xxsubinterpreters -m test_custom___reduce__ -R :
0:00:00 load avg: 3.20 Run tests sequentially
0:00:00 load avg: 3.20 [1/1] test__xxsubinterpreters
beginning 9 repetitions
123456789
.........
test__xxsubinterpreters leaked [1486, 1484, 1484, 1484] references, sum=5938
test__xxsubinterpreters leaked [399, 398, 398, 398] memory blocks, sum=1593
test__xxsubinterpreters failed

== Tests result: FAILURE ==

1 test failed:
    test__xxsubinterpreters

Total duration: 2.2 sec

Bisecting points to:

commit a1d9e0accd33af1d8e90fc48b34c13d7b07dcf57
Author: Eric Snow <ericsnowcurrently at gmail.com>
Date:   Thu May 7 08:56:01 2020 -0600

    bpo-32604: [_xxsubinterpreters] Propagate exceptions. (GH-19768)

    (Note: PEP 554 is not accepted and the implementation in the code base is a private one for use in the test suite.)

    If code running in a subinterpreter raises an uncaught exception then the "run" call in the calling interpreter fails. A RunFailedError is raised there that summarizes the original exception as a string. The actual exception type, __cause__, __context__, state, etc. are all discarded. This turned out to be functionally insufficient in practice. There is a more helpful solution (and PEP 554 has been updated appropriately).

    This change adds the exception propagation behavior described in PEP 554 to the _xxsubinterpreters module. With this change a copy of the original exception is set to __cause__ on the RunFailedError. For now we are using "pickle", which preserves the exception's state. We also preserve the original __cause__, __context__, and __traceback__ (since "pickle" does not preserve those).

    https://bugs.python.org/issue32604

 Lib/test/test__xxsubinterpreters.py |  301 ++++++++-
 Modules/_xxsubinterpretersmodule.c  | 1139 +++++++++++++++++++++++++++++++----
 2 files changed, 1317 insertions(+), 123 deletions(-)
bisect run success

----------
components: Interpreter Core
messages: 368411
nosy: eric.snow, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters leaked [1486, 1484, 1484, 1484] references
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 01:12:03 2020
From: report at bugs.python.org (Mariusz Felisiak)
Date: Fri, 08 May 2020 05:12:03 +0000
Subject: [New-bugs-announce] [issue40557] Move captured_stdin(),
 captured_stdout(), and captured_stderr() to the public API.
Message-ID: <1588914723.68.0.692041381493.issue40557@roundup.psfhosted.org>


New submission from Mariusz Felisiak <felisiak.mariusz at gmail.com>:

I would like to propose making test.support.captured_stdin(), captured_stdout(), and captured_stderr() public APIs with guaranteed stability.

These helpers are really useful and are stable for the last ~10 years.

----------
components: Tests
messages: 368419
nosy: felixxm
priority: normal
severity: normal
status: open
title: Move captured_stdin(), captured_stdout(), and captured_stderr() to the public API.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 01:30:03 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 08 May 2020 05:30:03 +0000
Subject: [New-bugs-announce] [issue40558] update CONTRIBUTING.rst docs
Message-ID: <1588915803.68.0.575667736057.issue40558@roundup.psfhosted.org>


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

update the links of buildbot in CONTRIBUTING.rst.

I don't know why I can not visit `http://buildbot.python.org/3.8.stable/`

----------
assignee: docs at python
components: Documentation
messages: 368422
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: update CONTRIBUTING.rst docs
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 03:40:03 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 08 May 2020 07:40:03 +0000
Subject: [New-bugs-announce] [issue40559] Missing Py_DECREF in
 task_step_impl() in _asynciomodule.c
Message-ID: <1588923603.03.0.898484918662.issue40559@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

There is a missing Py_DECREF in task_step_impl() in _asynciomodule.c:
https://github.com/python/cpython/blob/02fa0ea9c1073e4476c9bde3d7112f5dd964aa57/Modules/_asynciomodule.c#L2641

It should have the form:

    if (clear_exc) {
        Py_DECREF(exc);
    }

This was introduced here in 3.7:
https://github.com/python/cpython/commit/bca4939d806170c3ca5d05f23710d11a8f1669cf

I'm not sure of the likelihood of this ever getting triggered (it appears to be unlikely), but it should still be addressed.

I will file a patch shortly.

----------
components: asyncio
messages: 368425
nosy: asvetlov, chris.jerdonek, yselivanov
priority: normal
severity: normal
status: open
title: Missing Py_DECREF in task_step_impl() in _asynciomodule.c
type: resource usage
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May  8 04:37:48 2020
From: report at bugs.python.org (Lars)
Date: Fri, 08 May 2020 08:37:48 +0000
Subject: [New-bugs-announce] [issue40560] uuid.uuid4().hex not random
Message-ID: <1588927068.65.0.578551628055.issue40560@roundup.psfhosted.org>


New submission from Lars <lars at k0nig.de>:

Hi everybody

I just noticed that the uuid.uuid4().hex command does not create fully random hex values. The character on the 13th position is always 4 and the 17th position is equally distributed 8,9,a,b.
One million uuids follow following distribution. 

{'0': 62312, '1': 62626, '2': 62308, '3': 62801, '4': 62173, '5': 62622, '6': 62527, '7': 62310, '8': 62574, '9': 62314, 'a': 62575, 'b': 62472, 'c': 62500, 'd': 62229, 'e': 62813, 'f': 62844}
{'0': 62239, '1': 63002, '2': 62551, '3': 62601, '4': 62075, '5': 62314, '6': 62584, '7': 62184, '8': 62359, '9': 62637, 'a': 63100, 'b': 62782, 'c': 62097, 'd': 62359, 'e': 62487, 'f': 62629}
{'0': 62647, '1': 62649, '2': 62924, '3': 62555, '4': 62683, '5': 62435, '6': 62403, '7': 63010, '8': 62235, '9': 62412, 'a': 62320, 'b': 62081, 'c': 62795, 'd': 62329, 'e': 62420, 'f': 62102}
{'0': 62641, '1': 62772, '2': 62458, '3': 62483, '4': 62201, '5': 62564, '6': 62307, '7': 62822, '8': 62102, '9': 62284, 'a': 62561, 'b': 62749, 'c': 62264, 'd': 62732, 'e': 62445, 'f': 62615}
{'0': 62433, '1': 62815, '2': 62761, '3': 62355, '4': 62526, '5': 62464, '6': 62494, '7': 62116, '8': 62813, '9': 62556, 'a': 62722, 'b': 62440, 'c': 62634, 'd': 61967, 'e': 62425, 'f': 62479}
{'0': 62544, '1': 62573, '2': 62774, '3': 62143, '4': 62814, '5': 62144, '6': 62207, '7': 62605, '8': 62567, '9': 62689, 'a': 62500, 'b': 62631, 'c': 62460, 'd': 62156, 'e': 62613, 'f': 62580}
{'0': 62707, '1': 62315, '2': 62698, '3': 62260, '4': 62634, '5': 62145, '6': 62358, '7': 62725, '8': 61971, '9': 62559, 'a': 62341, 'b': 62846, 'c': 62650, 'd': 62527, 'e': 62712, 'f': 62552}
{'0': 62477, '1': 62571, '2': 62672, '3': 62207, '4': 62798, '5': 62338, '6': 62381, '7': 62490, '8': 62478, '9': 62434, 'a': 62391, 'b': 62397, 'c': 62870, 'd': 62550, 'e': 62679, 'f': 62267}
{'0': 62238, '1': 62361, '2': 62895, '3': 62525, '4': 62799, '5': 62763, '6': 62422, '7': 62621, '8': 62446, '9': 62160, 'a': 62636, 'b': 62601, 'c': 62331, 'd': 62342, 'e': 62156, 'f': 62704}
{'0': 62668, '1': 62824, '2': 61820, '3': 62839, '4': 62107, '5': 62527, '6': 62497, '7': 62287, '8': 62881, '9': 62455, 'a': 62742, 'b': 62590, 'c': 62278, 'd': 62419, 'e': 62550, 'f': 62516}
{'0': 62889, '1': 62561, '2': 62428, '3': 62696, '4': 63173, '5': 62220, '6': 62831, '7': 62762, '8': 62267, '9': 62065, 'a': 62737, 'b': 62064, 'c': 62520, 'd': 62593, 'e': 61960, 'f': 62234}
{'0': 62441, '1': 62602, '2': 62799, '3': 62707, '4': 62200, '5': 62562, '6': 62359, '7': 62760, '8': 62530, '9': 62726, 'a': 62210, 'b': 62299, 'c': 62068, 'd': 62702, 'e': 62551, 'f': 62484}
{'0': 0, '1': 0, '2': 0, '3': 0, '4': 1000000, '5': 0, '6': 0, '7': 0, '8': 0, '9': 0, 'a': 0, 'b': 0, 'c': 0, 'd': 0, 'e': 0, 'f': 0}
{'0': 62660, '1': 62302, '2': 62128, '3': 62184, '4': 62560, '5': 62455, '6': 62847, '7': 62020, '8': 62474, '9': 62731, 'a': 61928, 'b': 62928, 'c': 62873, 'd': 62700, 'e': 62333, 'f': 62877}
{'0': 62624, '1': 62754, '2': 62145, '3': 63135, '4': 62234, '5': 62211, '6': 62522, '7': 62568, '8': 62399, '9': 62343, 'a': 62628, 'b': 62299, 'c': 62575, 'd': 62551, 'e': 62516, 'f': 62496}
{'0': 62395, '1': 62461, '2': 62466, '3': 62501, '4': 62121, '5': 62691, '6': 62874, '7': 62683, '8': 62553, '9': 62640, 'a': 62748, 'b': 62110, 'c': 62301, 'd': 62152, 'e': 62366, 'f': 62938}
{'0': 0, '1': 0, '2': 0, '3': 0, '4': 0, '5': 0, '6': 0, '7': 0, '8': 251093, '9': 249017, 'a': 249806, 'b': 250084, 'c': 0, 'd': 0, 'e': 0, 'f': 0}
{'0': 62685, '1': 62833, '2': 61989, '3': 62360, '4': 62187, '5': 62702, '6': 62745, '7': 62988, '8': 62085, '9': 62504, 'a': 62657, 'b': 62472, 'c': 62194, 'd': 62381, 'e': 62474, 'f': 62744}
{'0': 63046, '1': 62392, '2': 62144, '3': 62466, '4': 62042, '5': 62444, '6': 62820, '7': 62685, '8': 62528, '9': 62596, 'a': 62354, 'b': 62885, 'c': 62151, 'd': 62183, 'e': 62568, 'f': 62696}
{'0': 62775, '1': 62743, '2': 61955, '3': 62635, '4': 62272, '5': 62251, '6': 62697, '7': 62829, '8': 62668, '9': 62860, 'a': 62579, 'b': 62267, 'c': 62457, 'd': 62267, 'e': 62288, 'f': 62457}
{'0': 62195, '1': 62646, '2': 62442, '3': 62798, '4': 62356, '5': 62739, '6': 62541, '7': 62298, '8': 62400, '9': 62496, 'a': 62418, 'b': 62329, 'c': 62786, 'd': 62668, 'e': 62183, 'f': 62705}
{'0': 62390, '1': 62260, '2': 62653, '3': 62376, '4': 63093, '5': 62338, '6': 62342, '7': 62834, '8': 62499, '9': 62300, 'a': 62585, 'b': 62358, 'c': 62625, 'd': 62720, 'e': 62433, 'f': 62194}
{'0': 62224, '1': 62687, '2': 62713, '3': 62294, '4': 62880, '5': 62143, '6': 62584, '7': 62577, '8': 62526, '9': 62433, 'a': 62771, 'b': 62751, 'c': 62546, 'd': 62465, 'e': 62192, 'f': 62214}
{'0': 62567, '1': 62452, '2': 62627, '3': 62544, '4': 62417, '5': 62019, '6': 62439, '7': 62482, '8': 62420, '9': 62874, 'a': 62716, 'b': 62342, 'c': 62550, 'd': 62387, 'e': 62672, 'f': 62492}
{'0': 62314, '1': 62519, '2': 62718, '3': 62564, '4': 62209, '5': 62574, '6': 63005, '7': 62524, '8': 62115, '9': 62935, 'a': 62558, 'b': 62266, 'c': 62186, 'd': 61994, 'e': 62924, 'f': 62595}
{'0': 62564, '1': 62153, '2': 62690, '3': 62979, '4': 62226, '5': 62520, '6': 62391, '7': 62340, '8': 62323, '9': 62260, 'a': 62433, 'b': 62860, 'c': 62526, 'd': 62725, 'e': 62853, 'f': 62157}
{'0': 62362, '1': 62677, '2': 62611, '3': 62040, '4': 62471, '5': 62357, '6': 62707, '7': 62403, '8': 62644, '9': 62516, 'a': 62395, 'b': 62521, 'c': 62543, 'd': 62762, 'e': 62271, 'f': 62720}
{'0': 62645, '1': 62458, '2': 62556, '3': 62666, '4': 62522, '5': 62381, '6': 62372, '7': 62609, '8': 62760, '9': 62325, 'a': 62294, 'b': 62771, 'c': 62094, 'd': 62811, 'e': 62389, 'f': 62347}
{'0': 62112, '1': 62630, '2': 62546, '3': 62684, '4': 62646, '5': 62590, '6': 62593, '7': 62800, '8': 62462, '9': 62216, 'a': 62166, 'b': 62629, 'c': 62160, 'd': 62106, 'e': 62567, 'f': 63093}
{'0': 61958, '1': 62520, '2': 62275, '3': 62671, '4': 62677, '5': 62971, '6': 62886, '7': 62383, '8': 62533, '9': 62743, 'a': 62678, 'b': 62361, 'c': 62598, 'd': 62047, 'e': 62654, 'f': 62045}
{'0': 62483, '1': 62714, '2': 62778, '3': 62095, '4': 62633, '5': 62754, '6': 62677, '7': 62335, '8': 62313, '9': 62631, 'a': 62604, 'b': 62282, 'c': 62564, 'd': 62597, 'e': 62222, 'f': 62318}
{'0': 62413, '1': 62459, '2': 62568, '3': 62493, '4': 62413, '5': 62809, '6': 63157, '7': 62755, '8': 62592, '9': 62153, 'a': 62097, 'b': 62332, 'c': 62628, 'd': 62258, 'e': 62371, 'f': 62502}

----------
components: Extension Modules
messages: 368428
nosy: KingUdo
priority: normal
severity: normal
status: open
title: uuid.uuid4().hex not random
versions: Python 3.8

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

From report at bugs.python.org  Fri May  8 08:34:40 2020
From: report at bugs.python.org (Brad Solomon)
Date: Fri, 08 May 2020 12:34:40 +0000
Subject: [New-bugs-announce] [issue40561] Provide docstrings for
 public-facing webbrowser functions
Message-ID: <1588941280.97.0.150032786212.issue40561@roundup.psfhosted.org>


New submission from Brad Solomon <brad.solomon.1124 at gmail.com>:

Currently 'pydoc webbrowser.open' simply displays the function signature without a useful explanation of what 'new' does (and the parameter name/value set is not intuitive by name alone).

----------
assignee: docs at python
components: Documentation
messages: 368435
nosy: bsolomon1124, docs at python
priority: normal
severity: normal
status: open
title: Provide docstrings for public-facing webbrowser functions
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri May  8 10:35:12 2020
From: report at bugs.python.org (Simon Willison)
Date: Fri, 08 May 2020 14:35:12 +0000
Subject: [New-bugs-announce] [issue40562] SEO: differentiate between Python
 2 and Python 3 docs on Google SERP
Message-ID: <1588948512.43.0.0539170221338.issue40562@roundup.psfhosted.org>


New submission from Simon Willison <swillison at gmail.com>:

When I search Google for a Python related term (e.g. "sqlite3 row" - see attached screenshot) I get back two results - one for the Python 2 documentation and one for the Python 3 documentation.

There is currently no indicator which result is for which version of Python.

Comparing https://docs.python.org/3/library/sqlite3.html with https://docs.python.org/2/library/sqlite3.html I think the problem is the way the title elements are designed:

sqlite3 ? DB-API 2.0 interface for SQLite databases ? Python 3.8.3rc1 documentation

v.s.

11.13. sqlite3 ? DB-API 2.0 interface for SQLite databases - Python 2.7.18 documentation

As you can see in the attached screenshot, Google (at least in my desktop browser) chooses to truncate those titles before they get to the bit indicating the version of Python.

It may be worth consulting with Google directly about the best way to address this. Moving the Python version indicator to the start of the title may or may not be the best approach.

----------
assignee: docs at python
components: Documentation
files: sqlite3_row_-_Google_Search.png
messages: 368442
nosy: docs at python, simonw
priority: normal
severity: normal
status: open
title: SEO: differentiate between Python 2 and Python 3 docs on Google SERP
versions: Python 3.9
Added file: https://bugs.python.org/file49141/sqlite3_row_-_Google_Search.png

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

From report at bugs.python.org  Fri May  8 10:55:55 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 08 May 2020 14:55:55 +0000
Subject: [New-bugs-announce] [issue40563] Support pathlike objects on
 dbm/shelve
Message-ID: <1588949755.54.0.0616905460961.issue40563@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

>>> dbm.open("/tmp/x.db", "n").close()
>>> from pathlib import Path
>>> tmp = Path("/tmp")
>>> dbm.open(tmp / "x.db", "n").close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/dbm/__init__.py", line 95, in open
    return mod.open(file, flag, mode)
TypeError: open() argument 1 must be str, not PosixPath

----------
components: Library (Lib)
keywords: easy
messages: 368446
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Support pathlike objects on dbm/shelve
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 11:47:01 2020
From: report at bugs.python.org (Xavier)
Date: Fri, 08 May 2020 15:47:01 +0000
Subject: [New-bugs-announce] [issue40564] Using zipfile.Path with several
 files prematurely closes zip
Message-ID: <1588952821.29.0.991302590341.issue40564@roundup.psfhosted.org>


New submission from Xavier <xavier at bustawin.com>:

Given a .zip file with more than one inner file, when reading those inner files using zipfile.Path the zip module closes the .zip file prematurely, causing an error.

Given the following code (example zipfile is attached, but any should work).

with zipfile.ZipFile('foo.zip') as file:
    for name in ['file-1.txt', 'file-2.txt']:
        p = zipfile.Path(file, name)
        with p.open() as inner:
            print(list(inner)) # ValueError: seek of closed file

But the following code does not fail:

with zipfile.ZipFile('foo.zip') as file:
    for name in ['file-1.txt', 'file-2.txt']:
        with file.open(name) as inner:
            print(list(inner)) # Works!


Python 3.8.2 macOS 10.15.4.

----------
components: IO
files: zipfile.zip
messages: 368449
nosy: bustawin
priority: normal
severity: normal
status: open
title: Using zipfile.Path with several files prematurely closes zip
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49142/zipfile.zip

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

From report at bugs.python.org  Fri May  8 12:06:59 2020
From: report at bugs.python.org (=?utf-8?b?aGFsaWwgaWJyYWhpbSB5xLFsZMSxcsSxbQ==?=)
Date: Fri, 08 May 2020 16:06:59 +0000
Subject: [New-bugs-announce] [issue40565] is comparison returns False while
 ids are the same.
Message-ID: <1588954019.78.0.804890045362.issue40565@roundup.psfhosted.org>


New submission from halil ibrahim y?ld?r?m <hyildirim at socialthinks.com>:

While id(a[:]) and id(a[0:3]) are the same however is comparison returns False. I thought it could be a bug.

>>> a = [1, 2, 3]
>>> id(a[:]) == id(a[0:3])
True
>>> a[:] is a[0:3]
False

----------
files: 2020-05-07_16-47-56-afa654f51735fad98b3a593a2ea539fd.png
messages: 368450
nosy: ihalil95
priority: normal
pull_requests: 19316
severity: normal
status: open
title: is comparison returns False while ids are the same.
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49143/2020-05-07_16-47-56-afa654f51735fad98b3a593a2ea539fd.png

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

From report at bugs.python.org  Fri May  8 12:37:38 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 08 May 2020 16:37:38 +0000
Subject: [New-bugs-announce] [issue40566] Apply PEP 573 to abc module
Message-ID: <1588955858.55.0.304534831437.issue40566@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Since PEP 573 is landed, we can apply the PEP 573 to abc module.

----------
assignee: corona10
components: Interpreter Core
messages: 368452
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: Apply PEP 573 to abc module
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 14:51:03 2020
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 08 May 2020 18:51:03 +0000
Subject: [New-bugs-announce] [issue40567] asyncio.StreadReader `async for
 line in reader` is not documented
Message-ID: <1588963863.42.0.83198949226.issue40567@roundup.psfhosted.org>


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

Actually it works. But it is not documented. Please ad docs.

----------
components: asyncio
messages: 368453
nosy: asvetlov, socketpair, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.StreadReader     `async for line in reader` is not documented
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May  8 15:08:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 May 2020 19:08:57 +0000
Subject: [New-bugs-announce] [issue40568] Modify -c command-line option to
 accept multiple inputs
Message-ID: <1588964937.68.0.986339822686.issue40568@roundup.psfhosted.org>


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

It would be nice to write this:

    $ python -c 'from math import *' 'print(e**(1j * pi))'

Instead of this:

    $ python -c 'from math import *; print(e**(1j * pi))'
    (-1+1.22464679915e-16j)

That would also make it possible input an indented block:

    $ python -c 'with open("somefile.txt") as f:'  '  s = f.read()' '  print(len(s))'

This feature would be especially useful in bash scripts.

FWIW, the timeit module already supports this convenience:

    $ python -m timeit -s 'from math import sqrt' -s 'x = 5' 'y = x ** 2' 'z = sqrt(y)'
    10000000 loops, best of 3: 0.0819 usec per loop

----------
components: Interpreter Core
messages: 368454
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Modify -c command-line option to accept multiple inputs
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 15:56:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 May 2020 19:56:47 +0000
Subject: [New-bugs-announce] [issue40569] Add optional weights to
 random.sample()
Message-ID: <1588967807.85.0.49094872953.issue40569@roundup.psfhosted.org>


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

Weighted sampling without replacement isn't easy for a user to do with the current tooling. There is a StackOverflow question about how to do it.  Also, this service is currently offered by numpy.

Use it like this:

    >>> sample(['katniss', 'prim', 'gale', 'peeta'] , weights=[20, 1, 42, 10], k=2)
    ['prim', 'peeta']

Here's an efficient implementation similar to how numpy does it:

--- a/Lib/random.py
+++ b/Lib/random.py
@@ -331,7 +331,7 @@ class Random(_random.Random):
                 j = _int(random() * (i+1))
                 x[i], x[j] = x[j], x[i]

-    def sample(self, population, k, *, counts=None):
+    def sample(self, population, k, *, counts=None, weights=None):
         """Chooses k unique random elements from a population sequence or set.

         Returns a new list containing elements from the population while
@@ -392,6 +392,18 @@ class Random(_random.Random):
         if not isinstance(population, _Sequence):
             raise TypeError("Population must be a sequence.  For dicts or sets, use sorted(d).")
         n = len(population)
+        if weights is not None:
+            if counts is not None:
+                raise TypeError('Cannot specify both counts and weights')
+            weights = list(weights)
+            positions = range(n)
+            indices = []
+            while (needed := k - len(indices)):
+                for i in choices(positions, weights, k=needed):
+                    if weights[i]:
+                        weights[i] = 0.0
+                        indices.append(i)
+            return [population[i] for i in indices]
         if counts is not None:
             cum_counts = list(_accumulate(counts))
             if len(cum_counts) != n:

----------
components: Library (Lib)
messages: 368458
nosy: mark.dickinson, rhettinger, tim.peters
priority: normal
severity: normal
status: open
title: Add optional weights to random.sample()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 16:02:20 2020
From: report at bugs.python.org (David Tucker)
Date: Fri, 08 May 2020 20:02:20 +0000
Subject: [New-bugs-announce] [issue40570] len(platform.uname()) has changed
 in Python 3.9
Message-ID: <1588968140.85.0.743964408101.issue40570@roundup.psfhosted.org>


New submission from David Tucker <david.tucker at dell.com>:

https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00#diff-47c8e5750258a08a6dd9de3e9c3774acL741-R804

That diff changed len(platform.uname()) to 5 (from 6).

I noticed because we have some code that checks for 6 strs (arguably unnecessary),
but I can also think of contrived examples that would break (e.g. platform.uname()[-3]).
Interestingly, platform.uname()[5] still works.

Was this effect intentional?

----------
components: Library (Lib)
messages: 368459
nosy: tucked
priority: normal
severity: normal
status: open
title: len(platform.uname()) has changed in Python 3.9
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 17:22:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 May 2020 21:22:40 +0000
Subject: [New-bugs-announce] [issue40571] Make lru_cache(maxsize=None) more
 discoverable
Message-ID: <1588972960.42.0.924669050455.issue40571@roundup.psfhosted.org>


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

The recent discussions on python-ideas showed that people have a hard time finding the infinity-cache option for lru_cache().  Also, in the context of straight caching without limits, the name *lru_cache()* makes the tool seem complex and heavy when in fact, it is simple, lightweight, and fast (doing no more than a simple dictionary lookup).

We could easily solve both problems with a helper function:

    def cache(func):
        'Simple unbounded cache.  Sometimes called "memoize".'
        return lru_cache(maxsize=None, typed=False)

It would be used like this:

     @cache
     def configure_server():
         ...
         return server_instance

There was some discussion about a completely new decorator with different semantics (holding a lock across a call to an arbitrary user function and being limited to zero argument functions).  It all the examples that were presented, this @cache decorator would suffice.  None of examples presented actually locking behavior.

----------
components: Library (Lib)
messages: 368469
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make lru_cache(maxsize=None) more discoverable
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 18:28:51 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 May 2020 22:28:51 +0000
Subject: [New-bugs-announce] [issue40572] Support basic asynchronous
 cross-interpreter operations.
Message-ID: <1588976931.16.0.539865430025.issue40572@roundup.psfhosted.org>


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

(This is a continuation of the work from bpo-33608.  That issue ended up with a lot of baggage and clutter (due to problems that have since been resolved), so we closed it.  This issue is where we're picking it up fresh.)

When two interpreters are cooperating, there are sometimes operations that one of them needs the other to perform.  Thus far this is limited to mutation or release of data/objects owned by that "other" interpreter.  We need safe, reliable public C-API to facilitate such operations.

All the necessary machinery already exists ("pending calls"), exposed in the internal C-API: _Py_AddPendingCall().  (There is a public Py_AddPendingCall(), but it should be removed.)  That API adds a function to a per-interpreter queue, from which it is executed later (asynchronously) by the ceval loop of the interpreter's main thread.  The challenge is that the repercussions of such async operations within the eval loop are not fully explored.  We have some confidence because this is the same machinery used to handle signals.  However, it's better avoid as much complexity in those async operations as possible.  That is why we don't just expose `_Py_AddPendingCall()` in the public C-API.

Instead the plan is to add a small number of public C-API functions that are each specific to a focused use case, ideally with with little/no chance of errors or other side effects.  Initially we will target `Py_DECREF()`, `PyMem_Free()`, and `PyBuffer_Release()`.  If we need more then we can assess those needs later.

----------
assignee: eric.snow
components: C API
messages: 368476
nosy: eric.snow, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Support basic asynchronous cross-interpreter operations.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May  8 23:14:12 2020
From: report at bugs.python.org (Moriyoshi Koizumi)
Date: Sat, 09 May 2020 03:14:12 +0000
Subject: [New-bugs-announce] [issue40573] inspect.iscorutinefunction()
 returns False for unittest.mock.AsyncMock instances
Message-ID: <1588994052.01.0.365173220946.issue40573@roundup.psfhosted.org>


New submission from Moriyoshi Koizumi <mozo+python at mozo.jp>:

inspect.iscoroutinefunction() returns False for unittest.mock.AsyncMock instances while asyncio.iscoroutinefunction() returns True.

```
>>> import unittest.mock
>>> import inspect
>>> import asyncio
>>> inspect.iscoroutinefunction(unittest.mock.AsyncMock())
False
>>> asyncio.iscoroutinefunction(unittest.mock.AsyncMock())
True
```

Confirmed with 3.8.2 and 3.9dev

----------
components: Tests
messages: 368497
nosy: moriyoshi
priority: normal
severity: normal
status: open
title: inspect.iscorutinefunction() returns False for unittest.mock.AsyncMock instances
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May  9 00:08:44 2020
From: report at bugs.python.org (Thomas Caswell)
Date: Sat, 09 May 2020 04:08:44 +0000
Subject: [New-bugs-announce] [issue40574] segfault causing regression from
 PEP 573 implementation
Message-ID: <1588997324.8.0.612961250405.issue40574@roundup.psfhosted.org>


New submission from Thomas Caswell <tcaswell at gmail.com>:

https://github.com/python/cpython/commit/e1becf46b4e3ba6d7d32ebf4bbd3e0804766a423 causes pyqt5 to segfault an accessing an attribute

To reproduce this:


pip install pyqt5
pip install sip
python -c "import PyQt5.QtCore; PyQt5.QtCore.Qt.Key_Control"  # this segfaults

Setting up faulthandler gives:

jupiter at 23:54  ?  python -X faulthandler -c "import PyQt5.QtCore; PyQt5.QtCore.Qt.Key_Control"
Fatal Python error: Segmentation fault

Current thread 0x00007f52111cd740 (most recent call first):
<no Python frame>
Segmentation fault (core dumped)

It is likely that this should also be reported to riverbank as a pyqt/sip bug, but I'm starting here.  I apologize for not having a simpler reproducing case.




jupiter at 00:01  ? git bisect log
git bisect start
# good: [2d8757758d0d75882fef0fe0e3c74c4756b3e81e] bpo-40286: Remove C implementation of Random.randbytes() (GH-19797)
git bisect good 2d8757758d0d75882fef0fe0e3c74c4756b3e81e
# bad: [d10091aa171250c67a5079abfe26b8b3964ea39a] bpo-40502: Initialize n->n_col_offset (GH-19988)
git bisect bad d10091aa171250c67a5079abfe26b8b3964ea39a
# good: [c3f001461d5794c81cf5f70e08ae5435fe935ceb] bpo-40491: Fix typo in syntax error for numeric literals (GH-19893)
git bisect good c3f001461d5794c81cf5f70e08ae5435fe935ceb
# good: [c21c51235aa8061da6b0593d6f857f42fd92fd8b] bpo-40355: Improve error messages in ast.literal_eval with malformed Dict nodes (GH-19868)
git bisect good c21c51235aa8061da6b0593d6f857f42fd92fd8b
# good: [c1c7d8ead9eb214a6149a43e31a3213c52448877] bpo-40397: Refactor typing._GenericAlias (GH-19719)
git bisect good c1c7d8ead9eb214a6149a43e31a3213c52448877
# bad: [c068b53a0ca6ebf740d98e422569d2f705e54f93] bpo-38787: Update structures.rst docs (PEP 573) (GH-19980)
git bisect bad c068b53a0ca6ebf740d98e422569d2f705e54f93
# good: [4638c6429575bd6de26b12b2af5df74d6568b553] bpo-40334: Error message for invalid default args in function call (GH-19973)
git bisect good 4638c6429575bd6de26b12b2af5df74d6568b553
# bad: [8963a7f1f84a05412178b56629508b660d38861b] bpo-40545: Export _PyErr_GetTopmostException() function (GH-19978)
git bisect bad 8963a7f1f84a05412178b56629508b660d38861b
# bad: [e1becf46b4e3ba6d7d32ebf4bbd3e0804766a423] bpo-38787: C API for module state access from extension methods (PEP 573) (GH-19936)
git bisect bad e1becf46b4e3ba6d7d32ebf4bbd3e0804766a423
# first bad commit: [e1becf46b4e3ba6d7d32ebf4bbd3e0804766a423] bpo-38787: C API for module state access from extension methods (PEP 573) (GH-19936)

----------
components: C API
messages: 368499
nosy: tcaswell
priority: normal
severity: normal
status: open
title: segfault causing regression from PEP 573 implementation
versions: Python 3.9

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

From report at bugs.python.org  Sat May  9 05:47:09 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 09 May 2020 09:47:09 +0000
Subject: [New-bugs-announce] [issue40575] _PyDict_GetItemIdWithError()
 should call _PyDict_GetItem_KnownHash()
Message-ID: <1589017629.56.0.630851682841.issue40575@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

_PyDict_GetItemIdWithError() looks up interned strings, which always have their hash value initialised. It can call _PyDict_GetItem_KnownHash() directly.

----------
messages: 368506
nosy: scoder
priority: low
severity: normal
stage: needs patch
status: open
title: _PyDict_GetItemIdWithError() should call _PyDict_GetItem_KnownHash()
type: performance
versions: Python 3.9

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

From report at bugs.python.org  Sat May  9 06:30:31 2020
From: report at bugs.python.org (Sam Lijin)
Date: Sat, 09 May 2020 10:30:31 +0000
Subject: [New-bugs-announce] [issue40576] Align docs for list.sort, sorted,
 and on the website
Message-ID: <1589020231.08.0.0102454961056.issue40576@roundup.psfhosted.org>


New submission from Sam Lijin <python at sxlijin.com>:

It's mildly confusing to see `pydoc sorted` and `pydoc list.sort` to look so different, esp. since sorted just delegates to list.sort.

By extension, https://docs.python.org/3/library/functions.html#sorted should also be aligned with this, but I'm not super familiar with what the distinction content in the docstrings and the website is intended to be, if there is any guiding philosophy there.

sorted() appears to have been documented as an afterthought as part of this commit:
https://github.com/python/cpython/commit/f9e227e5a9d7a74393ef259c861660c3d1f36f83

list.sort was last updated in 2018 by https://github.com/python/cpython/pull/8516

I have an incoming PR for this.

----------
assignee: docs at python
components: Documentation
messages: 368508
nosy: docs at python, sxlijin
priority: normal
severity: normal
status: open
title: Align docs for list.sort, sorted, and on the website
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May  9 07:22:29 2020
From: report at bugs.python.org (Abhinav Vikram)
Date: Sat, 09 May 2020 11:22:29 +0000
Subject: [New-bugs-announce] [issue40577] Spyder doesn't launch from
 Anaconda on MacBook
Message-ID: <1589023349.3.0.301161845856.issue40577@roundup.psfhosted.org>


New submission from Abhinav Vikram <abhinav.vikram at gmail.com>:

I just installed Anaconda to start coding in Python. However, after installing, the moment I launch Spyder I get the error "Python quit unexpectedly" error. I have tried running "conda update --all" and even reinstalling anaconda but no help.

Just for sanity check i looked up python version in the Terminal it is 3.7.6. If anyone can suggest a way to fix it it'll be most helpful.

Process:               python [6870]
Path:                  /opt/anaconda3/python.app/Contents/MacOS/python
Identifier:            python
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        ??? [6869]
Responsible:           python [6870]
User ID:               501

Date/Time:             2020-05-09 16:12:47.228 +0530
OS Version:            Mac OS X 10.13.6 (17G12034)
Time Awake Since Boot: 19000 seconds

System Integrity Protection: enabled

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

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   _multiarray_umath.cpython-37m-darwin.so	0x00000001075b144b npy_cpu_supports + 139
1   _multiarray_umath.cpython-37m-darwin.so	0x000000010742f0fe InitOperators + 94
2   _multiarray_umath.cpython-37m-darwin.so	0x000000010742dc00 PyInit__multiarray_umath + 160
3   com.continuum.python          	0x0000000105bc3c1d _PyImport_LoadDynamicModuleWithSpec + 557
4   com.continuum.python          	0x0000000105bc3033 _imp_create_dynamic + 243
5   com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
6   com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
7   com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
8   com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
9   com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
10  com.continuum.python          	0x0000000105b95d67 call_function + 183
11  com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
12  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
13  com.continuum.python          	0x0000000105b95d67 call_function + 183
14  com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
15  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
16  com.continuum.python          	0x0000000105b95d67 call_function + 183
17  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
18  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
19  com.continuum.python          	0x0000000105b95d67 call_function + 183
20  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
21  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
22  com.continuum.python          	0x0000000105b95d67 call_function + 183
23  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
24  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
25  com.continuum.python          	0x0000000105a5a978 object_vacall + 248
26  com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
27  com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
28  com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
29  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
30  com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
31  com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
32  com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
33  com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
34  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
35  com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
36  com.continuum.python          	0x0000000105b95d67 call_function + 183
37  com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
38  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
39  com.continuum.python          	0x0000000105b95d67 call_function + 183
40  com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
41  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
42  com.continuum.python          	0x0000000105b95d67 call_function + 183
43  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
44  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
45  com.continuum.python          	0x0000000105b95d67 call_function + 183
46  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
47  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
48  com.continuum.python          	0x0000000105a5a978 object_vacall + 248
49  com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
50  com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
51  com.continuum.python          	0x0000000105b809d5 builtin___import__ + 149
52  com.continuum.python          	0x0000000105a59388 PyCFunction_Call + 168
53  com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
54  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
55  com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
56  com.continuum.python          	0x0000000105b95d67 call_function + 183
57  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
58  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
59  com.continuum.python          	0x0000000105a577c7 _PyFunction_FastCallDict + 231
60  com.continuum.python          	0x0000000105a5a978 object_vacall + 248
61  com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
62  com.continuum.python          	0x0000000105bbbd03 PyImport_ImportModuleLevelObject + 931
63  com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
64  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
65  com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
66  com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
67  com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
68  com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
69  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
70  com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
71  com.continuum.python          	0x0000000105b95d67 call_function + 183
72  com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
73  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
74  com.continuum.python          	0x0000000105b95d67 call_function + 183
75  com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
76  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
77  com.continuum.python          	0x0000000105b95d67 call_function + 183
78  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
79  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
80  com.continuum.python          	0x0000000105b95d67 call_function + 183
81  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
82  com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
83  com.continuum.python          	0x0000000105a5a978 object_vacall + 248
84  com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
85  com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
86  com.continuum.python          	0x0000000105b809d5 builtin___import__ + 149
87  com.continuum.python          	0x0000000105a59388 PyCFunction_Call + 168
88  com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
89  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
90  com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
91  com.continuum.python          	0x0000000105b95d67 call_function + 183
92  com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
93  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
94  com.continuum.python          	0x0000000105a577c7 _PyFunction_FastCallDict + 231
95  com.continuum.python          	0x0000000105a5a978 object_vacall + 248
96  com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
97  com.continuum.python          	0x0000000105bbbd03 PyImport_ImportModuleLevelObject + 931
98  com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
99  com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
100 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
101 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
102 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
103 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
104 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
105 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
106 com.continuum.python          	0x0000000105b95d67 call_function + 183
107 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
108 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
109 com.continuum.python          	0x0000000105b95d67 call_function + 183
110 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
111 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
112 com.continuum.python          	0x0000000105b95d67 call_function + 183
113 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
114 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
115 com.continuum.python          	0x0000000105b95d67 call_function + 183
116 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
117 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
118 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
119 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
120 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
121 com.continuum.python          	0x0000000105b809d5 builtin___import__ + 149
122 com.continuum.python          	0x0000000105a59388 PyCFunction_Call + 168
123 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
124 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
125 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
126 com.continuum.python          	0x0000000105b95d67 call_function + 183
127 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
128 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
129 com.continuum.python          	0x0000000105a577c7 _PyFunction_FastCallDict + 231
130 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
131 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
132 com.continuum.python          	0x0000000105bbbd03 PyImport_ImportModuleLevelObject + 931
133 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
134 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
135 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
136 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
137 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
138 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
139 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
140 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
141 com.continuum.python          	0x0000000105b95d67 call_function + 183
142 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
143 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
144 com.continuum.python          	0x0000000105b95d67 call_function + 183
145 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
146 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
147 com.continuum.python          	0x0000000105b95d67 call_function + 183
148 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
149 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
150 com.continuum.python          	0x0000000105b95d67 call_function + 183
151 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
152 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
153 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
154 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
155 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
156 com.continuum.python          	0x0000000105b809d5 builtin___import__ + 149
157 com.continuum.python          	0x0000000105a58bd8 _PyMethodDef_RawFastCallKeywords + 392
158 com.continuum.python          	0x0000000105b95de2 call_function + 306
159 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
160 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
161 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
162 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
163 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
164 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
165 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
166 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
167 com.continuum.python          	0x0000000105b95d67 call_function + 183
168 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
169 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
170 com.continuum.python          	0x0000000105b95d67 call_function + 183
171 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
172 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
173 com.continuum.python          	0x0000000105b95d67 call_function + 183
174 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
175 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
176 com.continuum.python          	0x0000000105b95d67 call_function + 183
177 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
178 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
179 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
180 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
181 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
182 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
183 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
184 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
185 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
186 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
187 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
188 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
189 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
190 com.continuum.python          	0x0000000105b95d67 call_function + 183
191 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
192 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
193 com.continuum.python          	0x0000000105b95d67 call_function + 183
194 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
195 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
196 com.continuum.python          	0x0000000105b95d67 call_function + 183
197 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
198 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
199 com.continuum.python          	0x0000000105b95d67 call_function + 183
200 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
201 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
202 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
203 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
204 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
205 com.continuum.python          	0x0000000105b809d5 builtin___import__ + 149
206 com.continuum.python          	0x0000000105a59388 PyCFunction_Call + 168
207 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
208 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
209 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
210 com.continuum.python          	0x0000000105b95d67 call_function + 183
211 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
212 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
213 com.continuum.python          	0x0000000105a577c7 _PyFunction_FastCallDict + 231
214 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
215 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
216 com.continuum.python          	0x0000000105bbbd03 PyImport_ImportModuleLevelObject + 931
217 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
218 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
219 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
220 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
221 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
222 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
223 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
224 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
225 com.continuum.python          	0x0000000105b95d67 call_function + 183
226 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
227 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
228 com.continuum.python          	0x0000000105b95d67 call_function + 183
229 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
230 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
231 com.continuum.python          	0x0000000105b95d67 call_function + 183
232 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
233 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
234 com.continuum.python          	0x0000000105b95d67 call_function + 183
235 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
236 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
237 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
238 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
239 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
240 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
241 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
242 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
243 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
244 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
245 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
246 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
247 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
248 com.continuum.python          	0x0000000105b95d67 call_function + 183
249 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
250 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
251 com.continuum.python          	0x0000000105b95d67 call_function + 183
252 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
253 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
254 com.continuum.python          	0x0000000105b95d67 call_function + 183
255 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
256 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
257 com.continuum.python          	0x0000000105b95d67 call_function + 183
258 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
259 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
260 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
261 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
262 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
263 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
264 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
265 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
266 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
267 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
268 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
269 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
270 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
271 com.continuum.python          	0x0000000105b95d67 call_function + 183
272 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
273 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
274 com.continuum.python          	0x0000000105b95d67 call_function + 183
275 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
276 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
277 com.continuum.python          	0x0000000105b95d67 call_function + 183
278 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
279 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
280 com.continuum.python          	0x0000000105b95d67 call_function + 183
281 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
282 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
283 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
284 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
285 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
286 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
287 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
288 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
289 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
290 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
291 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
292 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
293 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
294 com.continuum.python          	0x0000000105b95d67 call_function + 183
295 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
296 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
297 com.continuum.python          	0x0000000105b95d67 call_function + 183
298 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
299 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
300 com.continuum.python          	0x0000000105b95d67 call_function + 183
301 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
302 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
303 com.continuum.python          	0x0000000105b95d67 call_function + 183
304 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
305 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
306 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
307 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
308 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
309 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
310 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
311 com.continuum.python          	0x0000000105b81e9b builtin_exec + 347
312 com.continuum.python          	0x0000000105a57c0f _PyMethodDef_RawFastCallDict + 255
313 com.continuum.python          	0x0000000105a5931d PyCFunction_Call + 61
314 com.continuum.python          	0x0000000105b93d9d _PyEval_EvalFrameDefault + 46845
315 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
316 com.continuum.python          	0x0000000105a58a03 _PyFunction_FastCallKeywords + 195
317 com.continuum.python          	0x0000000105b95d67 call_function + 183
318 com.continuum.python          	0x0000000105b92b92 _PyEval_EvalFrameDefault + 42226
319 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
320 com.continuum.python          	0x0000000105b95d67 call_function + 183
321 com.continuum.python          	0x0000000105b92afc _PyEval_EvalFrameDefault + 42076
322 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
323 com.continuum.python          	0x0000000105b95d67 call_function + 183
324 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
325 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
326 com.continuum.python          	0x0000000105b95d67 call_function + 183
327 com.continuum.python          	0x0000000105b93ad4 _PyEval_EvalFrameDefault + 46132
328 com.continuum.python          	0x0000000105a582d5 function_code_fastcall + 117
329 com.continuum.python          	0x0000000105a5a978 object_vacall + 248
330 com.continuum.python          	0x0000000105a5ab83 _PyObject_CallMethodIdObjArgs + 243
331 com.continuum.python          	0x0000000105bbc798 PyImport_ImportModuleLevelObject + 3640
332 com.continuum.python          	0x0000000105b91919 _PyEval_EvalFrameDefault + 37497
333 com.continuum.python          	0x0000000105b8746e _PyEval_EvalCodeWithName + 414
334 com.continuum.python          	0x0000000105beace0 PyRun_FileExFlags + 256
335 com.continuum.python          	0x0000000105bea157 PyRun_SimpleFileExFlags + 391
336 com.continuum.python          	0x0000000105c17dc3 pymain_main + 9635
337 com.continuum.python          	0x0000000105a2af2d main + 125
338 libdyld.dylib                 	0x00007fff6c4bb015 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00000001076a0650  rbx: 0x00000001076341f1  rcx: 0x0000000000000000  rdx: 0x00000000bfebfbff
  rdi: 0x00000001076341f9  rsi: 0x00000001076341f9  rbp: 0x00007ffeea1c62c0  rsp: 0x00007ffeea1c62b0
   r8: 0x0000000000000000   r9: 0x00000000000001ff  r10: 0x00007f83e581a028  r11: 0x000000000041d9fc
  r12: 0x0000000107316da0  r13: 0x0000000107319790  r14: 0x0000000107327f00  r15: 0x000000010731f0b0
  rip: 0x00000001075b144b  rfl: 0x0000000000010246  cr2: 0x00000001076341ed

----------
components: macOS
messages: 368513
nosy: Abhinav Vikram, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Spyder doesn't launch from Anaconda on MacBook
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Sat May  9 10:06:56 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 09 May 2020 14:06:56 +0000
Subject: [New-bugs-announce] [issue40578] Deprecate numeric item access for
 platform.uname()
Message-ID: <1589033216.57.0.707246281717.issue40578@roundup.psfhosted.org>


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

In issue40570, I learned that some users are still relying on legacy tuple-like behaviors of `platform.uname()`, namely the access by item position and length:

```
platform.uname()[0]
len(platform.uname())
```

I propose to deprecate these behaviors and constrain the supported interface to the following:

```
platform.uname().attribute
items = tuple(platform.uname())
```

In other words, the `uname_result` would only support access of the items by attribute or iteration of all attributes.

Any users wishing to access items by position or to calculate the length of the result would need to explicitly construct a tuple from the result.

----------
messages: 368517
nosy: jaraco, lemburg
priority: normal
severity: normal
status: open
title: Deprecate numeric item access for platform.uname()
type: enhancement

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

From report at bugs.python.org  Sat May  9 11:00:43 2020
From: report at bugs.python.org (Andrew Black)
Date: Sat, 09 May 2020 15:00:43 +0000
Subject: [New-bugs-announce] [issue40579] Second argument to iterator.next
 not described
Message-ID: <1589036443.24.0.81733349638.issue40579@roundup.psfhosted.org>


New submission from Andrew Black <apblack at pdx.edu>:

The documentation for the built-in function next (which calls the __next__ method on an iterator) discusses its behavior when the iterator is exhausted.
It talks about the StopIteration exception.  However, it does not say anything about calling next with two arguments.  See the library documentation at https://docs.python.org/3/library/stdtypes.html#iterator-types

My impression was that the presence of the second argument would suppress the StopIteration exception; instead next would return the value of the second argument.  That is the way that list iterators behave, for example.  This behavior should be documented.

----------
assignee: docs at python
components: Documentation
messages: 368525
nosy: Andrew Black, docs at python
priority: normal
severity: normal
status: open
title: Second argument to iterator.next not described
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat May  9 15:22:57 2020
From: report at bugs.python.org (Glenn Travis)
Date: Sat, 09 May 2020 19:22:57 +0000
Subject: [New-bugs-announce] [issue40580] Macintosh Documentation Still Bad
Message-ID: <1589052177.46.0.304784096206.issue40580@roundup.psfhosted.org>


New submission from Glenn Travis <pbfuddle at comcast.net>:

This was reported two years ago, and still is not fixed

https://bugs.python.org/issue32824#msg312028

and the documentation is even older.  It starts off referencing
"Mac OS X 10.8" and Apple Documents that are archived.

Then the section referencing using the Finder and Python Launcher does not work with macOS Catalina. 

Can this finally be corrected?

----------
messages: 368536
nosy: TotallyLost
priority: normal
severity: normal
status: open
title: Macintosh Documentation Still Bad
type: resource usage
versions: Python 3.8

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

From report at bugs.python.org  Sat May  9 16:43:17 2020
From: report at bugs.python.org (Mike)
Date: Sat, 09 May 2020 20:43:17 +0000
Subject: [New-bugs-announce] [issue40581] scipy's differential_evolution bug
Message-ID: <1589056997.86.0.98493009825.issue40581@roundup.psfhosted.org>


New submission from Mike <mikha.myara at gmail.com>:

I have a random bug with scipy's optimize . 
I use it in the context of SageMath (Python 3.7.3).
I checked 3 algorithms  : shgo, dual_annealing and full_optimize.
All don't work well (at all !).

I optimise with a 3 parameters functions with given bounds. The algorithm randomly sends to my error function the "1e-8" value for any of the 3 parameters. I displayed the vector + error to understand it. AS you can see, in this case, the first parameter is 1e-8 whereas it is outside the bounds. Sometimes it happens for the second parameter, or the 3rd ....

------
[3.95049282e-19 3.03055607e-20 1.96212098e+29] 0.0030238733573031864
[3.95273920e-19 3.05821352e-20 1.90997635e+29] 0.002957956545311753
[3.95037412e-19 3.04080173e-20 1.93312145e+29] 0.0029572689364709224
sage.all_cmdline:33: IntegrationWarning: The occurrence of roundoff error is detected, which prevents 
  the requested tolerance from being achieved.  The error may be 
  underestimated.
[1.00000000e-08 3.04080173e-20 1.93312145e+29] 1.0713560755245306
Overflow
[3.95037412e-19 3.04080173e-20 1.93312145e+29] 0.0029572689364709224
-----
The behaviour is the same for all of them. However the value inserted is not always the same, I noticed 3 : 1e-10, 1e-8 and 1.49011612e-08

Moreover, all do not send nice values. For example, the full_optimize always send values close to the highest bound. Perhaps are the value computed with a simple linear average and I guess it should not be the case.

my bounds are :
bounds = [(1*e,4*e),(0.1*e,0.5*e),(1e5,1e40)]
with e=1.6e-19

Is there an alternative for optimization in python ?

regards,
    Mike

----------
messages: 368540
nosy: mmyara
priority: normal
severity: normal
status: open
title: scipy's differential_evolution bug
versions: Python 3.7

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

From report at bugs.python.org  Sat May  9 19:39:06 2020
From: report at bugs.python.org (Ruairidh MacLeod)
Date: Sat, 09 May 2020 23:39:06 +0000
Subject: [New-bugs-announce] [issue40582] Inconsistent exceptions caused by
 typing + tuple subclasses
Message-ID: <1589067546.73.0.526678062232.issue40582@roundup.psfhosted.org>


New submission from Ruairidh MacLeod <r.macleod at epcc.ed.ac.uk>:

When incorrectly defining a function with a typed List[T] argument where T is a tuple instance, a TypeError is correctly raised:

t = (1,)
def f(a: List[t]): ...
# => TypeError: Parameters to generic types must be types. Got 1.


When t is an instance of a tuple subclass though, and one of its items is an empty string, a SyntaxError is raised instead in the typing module:

class T(tuple):
    def __new__(cls):
        return tuple.__new__(cls, ("",))

t = T()
def f(a: List[t]): ...
# => SyntaxError: Forward reference must be an expression -- got ''

Full stack trace:

Traceback (most recent call last):
  File "/opt/python37/lib/python3.7/typing.py", line 449, in __init__
    code = compile(arg, '<string>', 'eval')
  File "<string>", line 0

    ^
SyntaxError: unexpected EOF while parsing

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 5, in <module>
    def f(a: List[call]):
  File "/opt/python37/lib/python3.7/typing.py", line 254, in inner
    return func(*args, **kwds)
  File "/opt/python37/lib/python3.7/typing.py", line 631, in __getitem__
    params = tuple(_type_check(p, msg) for p in params)
  File "/opt/python37/lib/python3.7/typing.py", line 631, in <genexpr>
    params = tuple(_type_check(p, msg) for p in params)
  File "/opt/python37/lib/python3.7/typing.py", line 132, in _type_check
    return ForwardRef(arg)
  File "/opt/python37/lib/python3.7/typing.py", line 451, in __init__
    raise SyntaxError(f"Forward reference must be an expression -- got {arg!r}")
SyntaxError: Forward reference must be an expression -- got ''


Lastly, a different TypeError is raised for an empty subclass:

class C(tuple): ...
c = C()
def f(a: List[c]): ...
# => TypeError: Too few parameters for typing.List; actual 0, expected 1

This exception behavior seems inconsistent, although it's definitely a minor issue.

----------
components: Interpreter Core
messages: 368554
nosy: rkm
priority: normal
severity: normal
status: open
title: Inconsistent exceptions caused by typing + tuple subclasses
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun May 10 03:40:57 2020
From: report at bugs.python.org (Saumitro Dasgupta)
Date: Sun, 10 May 2020 07:40:57 +0000
Subject: [New-bugs-announce] [issue40583] Runtime type annotation mutation
 leads to inconsistent behavior
Message-ID: <1589096457.86.0.369001499523.issue40583@roundup.psfhosted.org>


New submission from Saumitro Dasgupta <ethereon at gmail.com>:

Adding type annotations at runtime may lead to inconsistent results. Consider the following example:

    class Base:
        base: int

    class Alpha(Base):
        pass

    class Beta(Base):
        foobar: int

    # Case 1: This mutates Base's __annotations__
    Alpha.__annotations__['injected'] = bool
    assert Alpha.__annotations__ is Base.__annotations__

    # Case 2: This mutates Beta's own copy of __annotations__
    Beta.__annotations__['injected'] = bool

Such mutations of __annotations__ seem to be perfectly legal (https://www.python.org/dev/peps/pep-0526/#runtime-effects-of-type-annotations).

However:
1. In case 1, this leads to the accidental mutation of Base's annotations. Not entirely certain if that's expected, but seems undesirable.

2. There are further differences when looking at `__dict__['__annotations__']`: for Alpha, there is no __annotations__ entry in __dict__. However, for Beta, it's set to `{'foobar': <class 'int'>, 'injected': <class 'bool'>}`. This discrepancy leads to further inconsistent results. In particular, when transforming these classes to dataclasses, which specifically looks at __dict__['__annotations__'](https://github.com/python/cpython/blob/3.8/Lib/dataclasses.py#L856). Converting Alpha to a dataclass leads to no fields. Converting Beta to a dataclass leads to two fields (foobar and injected).  It's worth noting that typing.get_type_hints produces reasonable results here.

----------
components: Interpreter Core, Library (Lib)
messages: 368569
nosy: Saumitro Dasgupta
priority: normal
severity: normal
status: open
title: Runtime type annotation mutation leads to inconsistent behavior
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun May 10 13:07:23 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 10 May 2020 17:07:23 +0000
Subject: [New-bugs-announce] [issue40584] PyType_FromModuleAndSpec function
 should add the process of tp_vectorcall_offset
Message-ID: <1589130443.67.0.341454082707.issue40584@roundup.psfhosted.org>


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

some typeobject using `tp_vectorcall_offset`, if we use `PyType_FromModuleAndSpec` to create the the typeobject, it will be faild due to `PyType_FromModuleAndSpec` lack the process of `tp_vectorcall_offset`.

so we should adding some process  like https://github.com/python/cpython/blob/master/Objects/typeobject.c#L2966-L2976.

----------
components: Interpreter Core
messages: 368589
nosy: petr.viktorin, shihai1991, vstinner
priority: normal
severity: normal
status: open
title: PyType_FromModuleAndSpec function should add the process of tp_vectorcall_offset
versions: Python 3.9

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

From report at bugs.python.org  Sun May 10 19:03:34 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sun, 10 May 2020 23:03:34 +0000
Subject: [New-bugs-announce] [issue40585] compile_command exec not raising
 syntax error with new PGEN Parser
Message-ID: <1589151814.99.0.293887376017.issue40585@roundup.psfhosted.org>


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

compile_command  used to produce syntax error in exec mode:

```
$ python -c "import codeop; codeop.compile_command('raise = 2', symbol='exec')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "...python3.8/codeop.py", line 125, in compile_command
    return _maybe_compile(_compile, source, filename, symbol)
  File "...python3.8/codeop.py", line 100, in _maybe_compile
    raise err1
  File "...python3.8/codeop.py", line 87, in _maybe_compile
    code1 = compiler(source + "\n", filename, symbol)
  File "...python3.8/codeop.py", line 105, in _compile
    return compile(source, filename, symbol, PyCF_DONT_IMPLY_DEDENT)
  File "<input>", line 1
    raise = 2
          ^
SyntaxError: invalid syntax
```

This happens to not be the case anymore in master, where it simply return `None` for above invalid input. 

```
$ python -c "import codeop; codeop.CommandCompiler()('raise = 2', symbol='exec')"
```

or many other:

```
 $ python
Python 3.9.0a6+ (heads/master:2cc9b8486d, May 10 2020, 15:52:00)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codeop;
>>> codeop.compile_command('def a-b', symbol='exec')
>>> codeop.compile_command('await?', symbol='exec')
>>> codeop.compile_command('=!=', symbol='exec')
>>> codeop.compile_command('a await raise b', symbol='exec')
>>> codeop.compile_command('a await raise b?+1', symbol='exec')
```


It is problematic as this is used in many places to decide whether code is valid, and for example in IPython to know wether we should insert a new line, or try to execute the code. 

It seem to be due to the new PGEN parser as setting PYTHONOLDPARSER solve the issue:

```
$ PYTHONOLDPARSER=1 python -c "import codeop; codeop.CommandCompiler()('raise = 2', symbol='exec')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 171, in __call__
    return _maybe_compile(self.compiler, source, filename, symbol)
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 100, in _maybe_compile
    raise err1
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 87, in _maybe_compile
    code1 = compiler(source + "\n", filename, symbol)
  File "/Users/bussonniermatthias/dev/cpython/Lib/codeop.py", line 136, in __call__
    codeob = compile(source, filename, symbol, self.flags, True)
  File "<input>", line 1
    raise = 2
          ^
SyntaxError: invalid syntax
```

`single` and `eval` appear to behave fine.

----------
components: Interpreter Core
messages: 368594
nosy: mbussonn
priority: normal
severity: normal
status: open
title: compile_command exec not raising syntax error with new PGEN Parser
versions: Python 3.9

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

From report at bugs.python.org  Sun May 10 20:50:31 2020
From: report at bugs.python.org (Gianni Mariani)
Date: Mon, 11 May 2020 00:50:31 +0000
Subject: [New-bugs-announce] [issue40586] Pydoc should support https for
 hyperlinks.
Message-ID: <1589158231.48.0.0342376329959.issue40586@roundup.psfhosted.org>


New submission from Gianni Mariani <owebeeone at gmail.com>:

pydoc has a regex hard coded for supporting hyperlinks. It supports http and ftp. It should support https.

----------
components: Demos and Tools
messages: 368601
nosy: owebeeone
priority: normal
severity: normal
status: open
title: Pydoc should support https for hyperlinks.
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/issue40586>
_______________________________________

From report at bugs.python.org  Sun May 10 23:56:20 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 11 May 2020 03:56:20 +0000
Subject: [New-bugs-announce] [issue40587] [regression] inspect.getdoc not
 returning docstring.
Message-ID: <1589169380.19.0.988807060363.issue40587@roundup.psfhosted.org>


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

In python 3.8:

```
>>> class A(object):
...     """standard docstring"""
...     pass
...
>>> import inspect
>>> inspect.getdoc(A())
'standard docstring'
```

In 3.9:

```
$ python
Python 3.9.0a6+ (heads/master:5b956ca42d, May 10 2020, 20:31:26)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
KeyboardInterrupt
>>> class A(object):
...     """standard docstring"""
...     pass
...
>>> import inspect
>>> inspect.getdoc(A())
>>>
```

----------
messages: 368603
nosy: mbussonn
priority: normal
severity: normal
status: open
title: [regression] inspect.getdoc not returning docstring.

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

From report at bugs.python.org  Mon May 11 00:58:29 2020
From: report at bugs.python.org (Shengjun Zhu)
Date: Mon, 11 May 2020 04:58:29 +0000
Subject: [New-bugs-announce] [issue40588] Creating Virtual Environments Does
 Not Work (Not Creating Folder)
Message-ID: <1589173109.69.0.907519965881.issue40588@roundup.psfhosted.org>


New submission from Shengjun Zhu <zhushengjun1 at gmail.com>:

I followed the instructions,  run "python3 -m venv tutorial-env" , but the command doesn't create any directory.

https://docs.python.org/3.8/tutorial/venv.html

I followed the instructions in the post below to remove the "Application Execution Aliases" for python.exe and python3.exe. That got rid of the exe files in WindowsApps. However, now when I type where python3 in CMD, I get: INFO: Could not find files for the given pattern(s).
https://superuser.com/questions/1437590/typing-python-on-windows-10-version-1903-command-prompt-opens-microsoft-stor

I changed python3 in the command to python, it worked.
python -m venv tutorial-env

I think in version python3.8, instead python3 , we should use python, right?

----------
assignee: docs at python
components: Documentation
messages: 368610
nosy: Shengjun Zhu, docs at python
priority: normal
severity: normal
status: open
title: Creating Virtual Environments Does Not Work (Not Creating Folder)
versions: Python 3.8

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

From report at bugs.python.org  Mon May 11 01:09:40 2020
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Mon, 11 May 2020 05:09:40 +0000
Subject: [New-bugs-announce] [issue40589] Missing path-like versionchanged
 in shutil.rmtree
Message-ID: <1589173780.72.0.321228140828.issue40589@roundup.psfhosted.org>


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

shutil.rmtree takes a path-like object starting from 3.6 (due to internal use of os.lstat which does that too).

----------
assignee: docs at python
components: Documentation
messages: 368613
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Missing path-like versionchanged in shutil.rmtree

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

From report at bugs.python.org  Mon May 11 01:44:58 2020
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 11 May 2020 05:44:58 +0000
Subject: [New-bugs-announce] [issue40590] test_subprocess stuck on Windows,
 x64
Message-ID: <1589175898.73.0.75396943112.issue40590@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

The windows test got stuck in my PR, and I'm pretty sure my change is not to blame.

The test log looks like this:

0:11:10 load avg: 6.42 [421/423] test_importlib passed
0:11:40 load avg: 5.40 running: test_subprocess (58.5 sec), test_multiprocessing_spawn (53.0 sec)
0:12:10 load avg: 5.48 running: test_subprocess (1 min 28 sec), test_multiprocessing_spawn (1 min 23 sec)
0:12:40 load avg: 5.44 running: test_subprocess (1 min 58 sec), test_multiprocessing_spawn (1 min 53 sec)
0:12:57 load avg: 4.58 [422/423] test_multiprocessing_spawn passed (2 min 10 sec) -- running: test_subprocess (2 min 16 sec)
0:13:27 load avg: 2.89 running: test_subprocess (2 min 46 sec)
0:13:57 load avg: 2.11 running: test_subprocess (3 min 16 sec)
0:14:27 load avg: 1.54 running: test_subprocess (3 min 46 sec)
...
5:53:33 load avg: 0.48 running: test_subprocess (5 hour 42 min)
5:54:03 load avg: 0.51 running: test_subprocess (5 hour 43 min)
5:54:33 load avg: 0.31 running: test_subprocess (5 hour 43 min)
Terminate batch job (Y/N)? 

https://github.com/python/cpython/pull/19402/checks?check_run_id=658308339

----------
components: Tests
messages: 368614
nosy: Dima.Tisnek, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_subprocess stuck on Windows, x64
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 03:43:55 2020
From: report at bugs.python.org (wyz23x2)
Date: Mon, 11 May 2020 07:43:55 +0000
Subject: [New-bugs-announce] [issue40591] \r broken in IDLE
Message-ID: <1589183035.92.0.395871361419.issue40591@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

When you run this code:

import time
for i in range(10):
    print(f"\r{i}", end='', flush=True)
    time.sleep(1)
print('\n')

On CMD it prints 0 at the first time, then it will erase it and print the increased i. But on IDLE it just prints "0123456789" -- that isn't right.

----------
assignee: terry.reedy
components: IDLE
messages: 368616
nosy: terry.reedy, wyz23x2
priority: normal
severity: normal
status: open
title: \r broken in IDLE
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 11 04:50:15 2020
From: report at bugs.python.org (=?utf-8?q?Dawid_Gos=C5=82awski?=)
Date: Mon, 11 May 2020 08:50:15 +0000
Subject: [New-bugs-announce] [issue40592] `Shutil.which` incosistent with
 windows's `where`
Message-ID: <1589187015.71.0.593402074503.issue40592@roundup.psfhosted.org>


New submission from Dawid Gos?awski <alkuzad at gmail.com>:

Shutil's which implementation does not work correctly when someone set's empty item in `PATHEXT` environment variable. Example:

set PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.RB;.RBW;

I'm not 100% sure how I got this in my PATHEXT config, I wasn't changing that so maybe some bugged uninstaller not removed it's extension correctly.

This makes things confusing as Windows will find correctly binary, but Python will return nothing, due to this part:

```
if any(cmd.lower().endswith(ext.lower()) for ext in pathext):
            files = [cmd]
```

pathext is initialized as `pathext = os.environ.get("PATHEXT", "").split(os.pathsep)`, which ends producing '' as last element

Because any string ends with empty string (''), files list will have plain version added like `git`, which will then fail executable check.

Workaround is to use full name `git.exe`

Filtering out empty strings would fix that.

----------
components: Library (Lib)
messages: 368620
nosy: alkuzad
priority: normal
severity: normal
status: open
title: `Shutil.which` incosistent with windows's `where`

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

From report at bugs.python.org  Mon May 11 06:49:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 May 2020 10:49:33 +0000
Subject: [New-bugs-announce] [issue40593] Improve error reporting for
 invalid character in source code
Message-ID: <1589194173.64.0.264266598183.issue40593@roundup.psfhosted.org>


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

Currently you get SyntaxError with message "invalid character in identifier" in two cases:

1. The source code contains some non-ASCII non-identifier character. Usually it happens when you copy code from internet page or PDF file which was "improved" by some enhachaizer which replaces spaces with non-breacking  spaces, ASCII minus with a dash or Unicode minus, ASCII quotes with fancy Unicode quotes. They do not look like a part of identifier at all. The error message also does not say what character is invalid, and it is hard to find the culprit because they look too similar to correct characters (especially with some monospace fonts).

See https://mail.python.org/archives/list/python-ideas at python.org/thread/ILMNJ46EAL4ENYK7LLDLGIMYQKZAMMWU/ for discussion.

2. Other case is very special -- when the source code contains the declaration for the utf-8 encoding followed by non-UTF-8 bytes sequences. It is rarely happen in real world.

The proposed PR improves errors for these cases.

>>> print(123?45)
  File "<stdin>", line 1
    print(123?45)
             ^
SyntaxError: invalid character '?' (U+2014)

* The error message no longer contains misleading "in identifier".

* The error message contains the invalid character, literal and its hexcode.

* The caret points on the invalid character. Previously it pointed on the last non-ascii or non-alphabetical character followed the invalid character (5 in the above example).

* For the special case of non-decodable UTF-8 sequence the syntax error message is more informative: "(unicode error) 'utf-8' codec can't decode byte 0xff ...". Although this case needs further improvements.

----------
components: Interpreter Core
messages: 368622
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve error reporting for invalid character in source code
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 07:53:50 2020
From: report at bugs.python.org (David Bell)
Date: Mon, 11 May 2020 11:53:50 +0000
Subject: [New-bugs-announce] [issue40594] urljoin since 3.5 incorrectly
 filters out double slashes
Message-ID: <1589198030.38.0.614579410038.issue40594@roundup.psfhosted.org>


New submission from David Bell <david.bell at hotjar.com>:

In Python 3.5 the urljoin function was rewritten to be RFC 3986 compliant and fix long standing issues. In the initial rewrite duplicate slashes were added by accident, and so code was added to prevent that. The discussion is here: https://bugs.python.org/issue22118

The code within urljoin is this:

# filter out elements that would cause redundant slashes on re-joining
# the resolved_path
segments[1:-1] = filter(None, segments[1:-1])

This seems sensible, you would not want double slashes in a URL, right? The problem is: double slashes are perfectly legal in a URI/URL, and for reasons I don't understand, they are in use in the wild. The code above was written to remove them because urljoin accidentally introduced them, the problem is that it also removes intentional double slashes:

>>> urljoin("http://www.example.com/", "this//double/path")
'http://www.example.com/this/double/path'

Where as the expected result should be:

'http://www.example.com/this//double/path'

I suggest that the fix for this is to remove the aforementioned filter code, e.g. remove this:

# filter out elements that would cause redundant slashes on re-joining
# the resolved_path
segments[1:-1] = filter(None, segments[1:-1])

...and remove this code too:

if base_parts[-1] != '':
    # the last item is not a directory, so will not be taken into account
    # in resolving the relative path
    del base_parts[-1]

and instead simply add:

del base_parts[-1]

...because the last part of the split base URL should always be deleted. If the last element of the list (the base URL split) is an empty string, then the URL ended with a slash, and so we should remove the last element otherwise a double slash will occur when we combine it with the second parameter to urljoin. If the last element is not an empty string then the last part of the URL was not a directory, and should be removed. Thus the last element should always be removed. 

By following this logic the "remove all double slashes" filter is not necessary, because the cause of the accidental addition of double slashes is removed.

----------
components: Library (Lib)
messages: 368623
nosy: David Bell
priority: normal
severity: normal
status: open
title: urljoin since 3.5 incorrectly filters out double slashes
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/issue40594>
_______________________________________

From report at bugs.python.org  Mon May 11 13:19:58 2020
From: report at bugs.python.org (Taylor Robie)
Date: Mon, 11 May 2020 17:19:58 +0000
Subject: [New-bugs-announce] [issue40595] AttributeError from type annotation
Message-ID: <1589217598.74.0.170713443577.issue40595@roundup.psfhosted.org>


New submission from Taylor Robie <taylor.aiken.robie at gmail.com>:

Consider the following:
```
import re

class MyClass(object):
    def re(self):
        pass

    def foo(self, m: re.Match):
        pass
```

Even though `re` and `MyClass.re` are distinct namespaces, the type annotation misses that fact (presumably there is an issue with how it is parsing the AST) and attempts to access MyClass.re.Match, resulting in:

`AttributeError: 'function' object has no attribute 'Match'`

Commenting out the definition of `MyClass.re` or reversing the definition order resolves the issue.

----------
components: Interpreter Core
messages: 368635
nosy: robieta
priority: normal
severity: normal
status: open
title: AttributeError from type annotation
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon May 11 13:50:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 May 2020 17:50:16 +0000
Subject: [New-bugs-announce] [issue40596] str.isidentifier() does not work
 with non-BMP non-canonicalized strings on Windows
Message-ID: <1589219416.15.0.470461181739.issue40596@roundup.psfhosted.org>


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

>>> import _testcapi
>>> u = '\U0001d580\U0001d593\U0001d58e\U0001d588\U0001d594\U0001d589\U0001d58a'
>>> u.isidentifier()
True
>>> _testcapi.unicode_legacy_string(u).isidentifier()
False

----------
components: Interpreter Core
messages: 368637
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: str.isidentifier() does not work with non-BMP non-canonicalized strings on Windows
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 15:00:19 2020
From: report at bugs.python.org (Arkadiusz Hiler)
Date: Mon, 11 May 2020 19:00:19 +0000
Subject: [New-bugs-announce] [issue40597] generated email message exceeds
 RFC-mandated limit of 998 characters
Message-ID: <1589223619.93.0.38032538849.issue40597@roundup.psfhosted.org>


New submission from Arkadiusz Hiler <arek at hiler.eu>:

RFC5322[0] in section 2.1.1 mandates that the line cannot be longer than 998 characters and should not be longer than 78 characters (excluding CRLF). When we use raw_data_manager (default for EmailPolicy, EmailMessage) it does the correct thing as long as the message contains characters outside of 7bit US-ASCII set - base64 or qp Content-Transfer-Encoding which respects the line wrapping at 78 characters.

However if our message is limited the characters from the 7bit US-ASCII set no transfer encoding is applied, and such messages can easily go beyond 78 or even 998 characters.


[0]: https://tools.ietf.org/html/rfc5322.html#section-2.1.1

----------
components: email
messages: 368641
nosy: barry, ivyl, r.david.murray
priority: normal
severity: normal
status: open
title: generated email message exceeds RFC-mandated limit of 998 characters
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/issue40597>
_______________________________________

From report at bugs.python.org  Mon May 11 17:19:36 2020
From: report at bugs.python.org (Michael Garbutt)
Date: Mon, 11 May 2020 21:19:36 +0000
Subject: [New-bugs-announce] [issue40598] round() does not return an integer
 when given a numpy float64
Message-ID: <1589231976.76.0.869776426798.issue40598@roundup.psfhosted.org>


New submission from Michael Garbutt <michael.c.garbutt at gmail.com>:

The round() helptext states "The return value is an integer if ndigits is omitted or None.  Otherwise the return value has the same type as the number."

When given a numpy float64, the return type is also float64, rather than the expected int.

>>> import numpy as np
>>> value = np.float64(2.1)
>>> round(value)
2.0
>>> type(round(value))
<class 'numpy.float64'>

Observed in Python 3.8.2, output of pip freeze:
certifi==2020.4.5.1
mkl-fft==1.0.15
mkl-random==1.1.0
mkl-service==2.3.0
numpy==1.18.1
six==1.14.0

Also in Python 3.7.2, output of pip freeze:

----------
components: Library (Lib)
messages: 368654
nosy: MichaelCG8
priority: normal
severity: normal
status: open
title: round() does not return an integer when given a numpy float64
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon May 11 18:10:51 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 11 May 2020 22:10:51 +0000
Subject: [New-bugs-announce] [issue40599] Improve error messages with
 expected keywords
Message-ID: <1589235051.21.0.907092056655.issue40599@roundup.psfhosted.org>


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

Using the new parser, we could improve the plain "syntax error" messages with the tokens/keywords that would have made the parser advance. There is a proof of concept in https://github.com/python/cpython/pull/20039 you can play with.

I would like to get some initial opinions on the idea before going deeper in the issue :)

----------
components: Interpreter Core
messages: 368664
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Improve error messages with expected keywords
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 18:12:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 May 2020 22:12:29 +0000
Subject: [New-bugs-announce] [issue40600] Add an option to disallow creating
 more than one instance of a module
Message-ID: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

When a C extension module is created with PyModuleDef_Init(), it becomes possible to create more than one instance of the module.

It would take significant effort to modify some extensions to make their code fully ready to have two isolated module.

For example, the atexit module calls _Py_PyAtExit() to register itself into the PyInterpreterState. If the module is created more than once, the most recently created module wins, and calls registered on other atexit instances are ignore: see bpo-40288.

One simple option would be to simply disallow loading the module more than once per interpreter.

Also, some extensions are not fully compatible with subinterpreters. It may be interesting to allow to load them in a subinterpreter if it's not already loaded in another interpreter, like another subinterpreter or the main interpreter. It would be only load it once per Python *process*. For example, numpy would be a good candidate for such option.

I'm not sure fow a module should announced in its definition that it should not be loaded more than once.

----------
components: Extension Modules
messages: 368665
nosy: corona10, eric.snow, vstinner
priority: normal
severity: normal
status: open
title: Add an option to disallow creating more than one instance of a module
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 18:23:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 May 2020 22:23:25 +0000
Subject: [New-bugs-announce] [issue40601] [C API] Hide static types from the
 limited C API
Message-ID: <1589235805.82.0.0888479979707.issue40601@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

"Statically allocated types" prevents to get per-interpreter GIL: bpo-40512. These types are currently shared by all interpreters.

Eric Snow proposed the idea of creating a heap allocated type in subintepreters. But we should take care of direct usage of the statically allocated type.

For example, Objects/longobject.c defines "PyTypeObject PyLong_Type = {...};". This type is exposed in the limited C API (!) in Include/longobject.c:

PyAPI_DATA(PyTypeObject) PyLong_Type;

It's used but such macro:

#define PyLong_CheckExact(op) Py_IS_TYPE(op, &PyLong_Type)

I don't think that these types are directly accessed in C extensions built with the limited C API. My expectation is that the type is only exposed for "CheckExact" macros.

Currently, 100 statically allocated types are declared in Python header files:

$ grep -F '(PyTypeObject)' Include/ -R
Include/cpython/fileobject.h:PyAPI_DATA(PyTypeObject) PyStdPrinter_Type;
(...)
Include/object.h:PyAPI_DATA(PyTypeObject) PySuper_Type; /* built-in 'super' */
Include/methodobject.h:PyAPI_DATA(PyTypeObject) PyCFunction_Type;

Most of them seem to be exposed in the limited C API.

I propose to break the limited C API backward compatibility on purpose by removing these type definitions form the limited C API.

For "CheckExact" macros, we can continue to provide them in the limited C API but as function calls. So a built C extension would no longer access directly the type, but only do function calls.

----------
components: C API
messages: 368667
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Hide static types from the limited C API
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 20:01:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 May 2020 00:01:24 +0000
Subject: [New-bugs-announce] [issue40602] Move Modules/hashtable.h to
 Include/internal/pycore_hashtable.h
Message-ID: <1589241684.81.0.926948421821.issue40602@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Python/mashal.c uses Modules/hashtable.h.

Python/mashal.c indirectly gets Modules/hashtable.c implementation via Modules/_tracemalloc.c which is built as a builtin module.

I propose to make the "hashtable" more standard:

* Move Modules/hashtable.h to Include/internal/pycore_hashtable.h
* Move Modules/hashtable.c to Python/hashtable.c

Attached PR implements this change but also changes the default memory allocator to PyMem_Malloc/PyMem_Free which is faster than PyMem_RawMalloc/PyMem_RawFree (current default) for memory blocks <= 512 bytes.

It remains an internal C API which cannot be used outside CPython.

----------
components: C API
messages: 368685
nosy: vstinner
priority: normal
severity: normal
status: open
title: Move Modules/hashtable.h to Include/internal/pycore_hashtable.h
versions: Python 3.9

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

From report at bugs.python.org  Mon May 11 21:23:39 2020
From: report at bugs.python.org (Will Bradshaw)
Date: Tue, 12 May 2020 01:23:39 +0000
Subject: [New-bugs-announce] [issue40603] slice does not slice
Message-ID: <1589246619.29.0.982913175965.issue40603@roundup.psfhosted.org>


New submission from Will Bradshaw <defenastrator at gmail.com>:

slice cannot be hashed which make some operations significantly more annoying. see https://groups.google.com/forum/#!topic/comp.lang.python/SvhkWwSDeIw

----------
components: ctypes
files: patches.zip
messages: 368693
nosy: Will Bradshaw
priority: normal
severity: normal
status: open
title: slice does not slice
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49149/patches.zip

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

From report at bugs.python.org  Tue May 12 02:55:45 2020
From: report at bugs.python.org (Case Van Horsen)
Date: Tue, 12 May 2020 06:55:45 +0000
Subject: [New-bugs-announce] [issue40604] Regression in 3.8.3rc1 - error in
 tests run via doctest
Message-ID: <1589266545.17.0.802278962638.issue40604@roundup.psfhosted.org>


New submission from Case Van Horsen <casevh at gmail.com>:

An error in the gmpy2 test suite was reported at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960201
 
The test suite is run using doctest and has been running without issues for many years. The first failure occurs when running the following fragment:

>>> x = xmpz(16)
>>> iter = x.iter_bits()
>>> [b for b in iter]
[False, False, False, False, True]

The output is as expected when run interactively on 3.8.3rc1 but generated the following error message:

/home/case/local/lib/python3.8/doctest.py:1336: RuntimeWarning: coroutine '<module>' was never awaited
  exec(compile(example.source, filename, "single",
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
**********************************************************************
File "test_gmpy2_xmpz_misc.txt", line 91, in test_gmpy2_xmpz_misc.txt
Failed example:
    [b for b in iter]
Differences (ndiff with -expected +actual):
    - [False, False, False, False, True]
**********************************************************************

Note the runtime warning for doctest.py.

----------
components: Library (Lib)
messages: 368703
nosy: casevh
priority: normal
severity: normal
status: open
title: Regression in 3.8.3rc1 - error in tests run via doctest
versions: Python 3.8

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

From report at bugs.python.org  Tue May 12 04:19:01 2020
From: report at bugs.python.org (Isa)
Date: Tue, 12 May 2020 08:19:01 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlNDA2MDVdIMKrcHl0aG9uwrs6?=
 =?utf-8?q?_Aucun_fichier_ou_dossier_de_ce_type?=
Message-ID: <1589271541.65.0.191752664403.issue40605@roundup.psfhosted.org>


New submission from Isa <isabar1703 at gmail.com>:

OS: X-Ubuntu 20.04 LTS
Python's version: 3.8.2 (default, Apr 27 2020, 15:53:34) [GCC 9.3.0] on linux

Since the last update I receive the following message:
/usr/bin/env: ?python?: Aucun fichier ou dossier de ce type

Thank you in advance for helping.

----------
messages: 368706
nosy: sab1703
priority: normal
severity: normal
status: open
title: ?python?: Aucun fichier ou dossier de ce type
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue May 12 05:11:47 2020
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 12 May 2020 09:11:47 +0000
Subject: [New-bugs-announce] [issue40606] Copy property return annotations
 to __annotations__
Message-ID: <1589274707.18.0.747615311988.issue40606@roundup.psfhosted.org>


New submission from Eric Wieser <wieser.eric at gmail.com>:

Consider a class like

    class MyClass:
        x: int
        y: int

Which has

    >>> MyClass.__annotations__
    {'x': int, 'y': int}

In future, it might change to

    class MyClass:
        @property
        def x(self) -> int:
            ...
        @functools.cached_property
        def x(self) -> int:
            ...

Most code won't be able to tell the difference, as properties are already a mostly-transparent replacement for attributes - but any code looking at `__annotations__` will find it is now absent.

It would be handy if `property.__set_name__` and `cachedproperty.__set_name__` could populate the `__annotations__` dict from their return type annotation.

This isn't just hypothetically useful - `sphinx` master as of https://github.com/sphinx-doc/sphinx/pull/7564 is able to retrieve the type of any descriptor with this behavior.

----------
components: Library (Lib)
messages: 368710
nosy: Eric Wieser
priority: normal
severity: normal
status: open
title: Copy property return annotations to __annotations__
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/issue40606>
_______________________________________

From report at bugs.python.org  Tue May 12 07:33:07 2020
From: report at bugs.python.org (Roman Skurikhin)
Date: Tue, 12 May 2020 11:33:07 +0000
Subject: [New-bugs-announce] [issue40607] asyncio.wait_for should reraise
 future exception even if timeout expires
Message-ID: <1589283187.27.0.827786043193.issue40607@roundup.psfhosted.org>


New submission from Roman Skurikhin <roman.skurikhin at cruxlab.com>:

In https://bugs.python.org/issue32751 asyncio.wait_for behaviour was changed that when we use timeout=... and the timeout expires, it waits until task is canceled. However, in some cases inner task can trigger exception while it handles cancellation. Check the following code:


import asyncio


async def ignore_cancel_and_raise():
    try:
        await asyncio.sleep(20)
    except asyncio.CancelledError:
        raise Exception('Cancellation failed')


async def main():
    try:
        await asyncio.wait_for(ignore_cancel_and_raise(), timeout=1)
    except asyncio.TimeoutError:
        print('Timeout')

asyncio.run(main())


It will print "Timeout" and log a warning that "Task exception was never retrieved".

I think that in case inner task cancelation fails with some error, asyncio.wait_for should reraise it instead of silently losing it.

----------
components: asyncio
messages: 368723
nosy: Roman Skurikhin, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait_for should reraise future exception even if timeout expires
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue May 12 14:07:29 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 12 May 2020 18:07:29 +0000
Subject: [New-bugs-announce] [issue40608] PY3.8 GC segfault
 (Py_TRASHCAN_SAFE_BEGIN/END are not backwards compatible)
Message-ID: <1589306849.27.0.146369076662.issue40608@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at yahoo.com>:

While migrating our codebase from python 3.7 to python 3.8, one of our unit tests segfaulted and I?ve narrowed it down to the change of typeobject.c in:

  commit 351c67416ba4451eb3928fa0b2e933c2f25df1a3
  Author: Jeroen Demeyer <J.Demeyer at UGent.be>
  Date:   Fri May 10 19:21:11 2019 +0200
  bpo-35983: skip trashcan for subclasses (GH-11841)   

It seems that Py_TRASHCAN_SAFE_BEGIN/END are not backwards compatible (as claimed in the comment above their definition in object.h).

This patch has a unit test that currently fails, along with the change in typeobject.c that restores the code that broke it: 

https://github.com/iritkatriel/cpython/commit/d962dd7f800fdaaeacd5748c6e3d38bf1f5053c1

I believe that this change needs to be pushed until the Py_TRASHCAN_SAFE_BEGIN/END are removed and all users are forced to migrate to the new Py_TRASHCAN_BEGIN/END.

----------
components: Interpreter Core
messages: 368740
nosy: iritkatriel, jdemeyer, pablogsal, pitrou
priority: normal
severity: normal
status: open
title: PY3.8 GC segfault  (Py_TRASHCAN_SAFE_BEGIN/END are not backwards compatible)
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue May 12 18:47:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 May 2020 22:47:15 +0000
Subject: [New-bugs-announce] [issue40609] _tracemalloc: remove pointer_t type
Message-ID: <1589323635.37.0.444781514034.issue40609@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In bpo-26588, I modified the _tracemalloc module to support tracing memory allocations in multiple "domains" for numpy. I modified hashtable.c to support keys larger than void*, and I modified _tracemalloc.c to use a new pointer_t structure which is made of (domain: unsigned int, ptr: void*).

These changes made hashtable.c way more complicated than what it should be. I would like to reuse hashtable.c in more places. I am working on a change to remove the pointer_t type from _tracemalloc.c, and instead use a hash table for traces of domains other than the default domain (0). The new hash table maps a domain to a hash table: traces of a domain.

tracemalloc_traces remains the default hash table for traces of the default domain. Since it's the most common case, it doesn't go through the new hash table.

----------
components: Library (Lib)
messages: 368747
nosy: vstinner
priority: normal
severity: normal
status: open
title: _tracemalloc: remove pointer_t type
versions: Python 3.9

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

From report at bugs.python.org  Tue May 12 19:04:27 2020
From: report at bugs.python.org (Jack Jansen)
Date: Tue, 12 May 2020 23:04:27 +0000
Subject: [New-bugs-announce] [issue40610] ctypes on Windows: error message
 on DLL load failure is misleading
Message-ID: <1589324667.53.0.244331207103.issue40610@roundup.psfhosted.org>


New submission from Jack Jansen <Jack.Jansen at cwi.nl>:

On Windows, when ctypes fails to load a DLL, the error message is misleading. If a dependency of the DLL cannot be found if appears as if the DLL itself cannot be found.

This issue has always existed on Windows (and I know it is due to what the OS provides by default as its error message) but it is exacerbated by the DLL loading rules in Python 3.8 (the `os.add_dll_directory()` changes), because now importing a DLL into Python will follow different rules than those followed by, for example, command line utilities shipped with the DLL you are loading follow.

An ideal fix would be a message of the form "xxx.dll failed to load because its dependency yyy.dll is not on the current Python DLL search path, see zzzz for details". But I am not well-versed enough in Windows APIs to know whether that is even possible.

A fix that is minimal and at least not misleading would be a message "xxx.dll (or one of its dependencies) failed to load. See zzzz for details".

----------
components: ctypes
messages: 368748
nosy: jackjansen
priority: normal
severity: normal
status: open
title: ctypes on Windows: error message on DLL load failure is misleading
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue May 12 20:16:37 2020
From: report at bugs.python.org (Ethan Steinberg)
Date: Wed, 13 May 2020 00:16:37 +0000
Subject: [New-bugs-announce] [issue40611] Add MAP_POPULATE to the mmap
 library
Message-ID: <1589328997.25.0.34201550923.issue40611@roundup.psfhosted.org>


New submission from Ethan Steinberg <ethan.steinberg at gmail.com>:

This issue (and corresponding pull request) adds MAP_POPULATE to the set of flags exported by the mmap module. This flag is incredibly handy for speeding up data processing and is available on most Linux systems.

----------
components: Library (Lib)
messages: 368752
nosy: Ethan Steinberg
priority: normal
severity: normal
status: open
title: Add MAP_POPULATE to the mmap library
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/issue40611>
_______________________________________

From report at bugs.python.org  Wed May 13 00:18:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 May 2020 04:18:55 +0000
Subject: [New-bugs-announce] [issue40612] Make traceback module's formatting
 of SyntaxError more similar to system formatting
Message-ID: <1589343535.08.0.511471445795.issue40612@roundup.psfhosted.org>


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

The traceback module formats several edge cases of SyntaxError different than CPython's default formatting.

- There's an off-by-one error if the column offset (printed as a caret) points past the last character (example: 'a +='). The clipping is wrong and the caret points to the last character.

- If the offset is <= 0, it appears the code silently adds the length of the source text.

- The system formatting suppresses the caret if the offset is -1; the only way to suppress the caret with the traceback module is setting the offset to None (or setting the source text to None).

- The system formatting can position the caret way past the end of the source text; the traceback module clips (also see the first bullet).

I propose to make the traceback module behave the same way as the system module in all cases. I also propose to make both suppress the caret if the offset is <= 0. Finally I propose to make the system formatting limit the offset to just past the end of the source text.

I propose not to bother changing anything in 3.8 or before.

----------
messages: 368759
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Make traceback module's formatting of SyntaxError more similar to system formatting
versions: Python 3.9

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

From report at bugs.python.org  Wed May 13 02:26:16 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 13 May 2020 06:26:16 +0000
Subject: [New-bugs-announce] [issue40613] gcc 10 emits error for unused
 function: _xxsubinterpretersmodule
Message-ID: <1589351176.2.0.303752022619.issue40613@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

/oss/cpython/Modules/_xxsubinterpretersmodule.c:1089:1: warning: ?_sharedexception_is_clear? defined but not used [-Wunused-function]
 1089 | _sharedexception_is_clear(_sharedexception *she)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~
/oss/cpython/Modules/_xxsubinterpretersmodule.c:601:1: warning: ?_tbsnapshot_is_clear? defined but not used [-Wunused-function]
  601 | _tbsnapshot_is_clear(_tbsnapshot *tbs)
      | ^~~~~~~~~~~~~~~~~~~~

Both functions are used by the assert statement.
IMHO, it should be replaced by if statement.

----------
components: C API
messages: 368762
nosy: corona10, eric.snow, vstinner
priority: normal
severity: normal
status: open
title: gcc 10 emits error for unused function: _xxsubinterpretersmodule
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May 13 03:17:35 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 13 May 2020 07:17:35 +0000
Subject: [New-bugs-announce] [issue40614] ast.parse doesn't respect
 feature_version for debug f-strings
Message-ID: <1589354255.32.0.89059001676.issue40614@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

```
~master ? python3.8             
Python 3.8.2 (default, Apr 21 2020, 00:39:48) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse('''f"{x=}"''')  # should work
<_ast.Module object at 0x10f81af40>
>>> ast.parse('''f"{x=}"''', feature_version=(3, 6))  # should fail, but doesn't
<_ast.Module object at 0x10f857d00>
```

----------
messages: 368763
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: ast.parse doesn't respect feature_version for debug f-strings
type: behavior

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

From report at bugs.python.org  Wed May 13 07:49:46 2020
From: report at bugs.python.org (gaborbernat)
Date: Wed, 13 May 2020 11:49:46 +0000
Subject: [New-bugs-announce] [issue40615] argparse
Message-ID: <1589370586.91.0.862968954668.issue40615@roundup.psfhosted.org>


New submission from gaborbernat <gaborjbernat at gmail.com>:

Consider the following code:

from argparse import ArgumentParser

parser = ArgumentParser()
parser.add_argument("--clear-magic", action="store_true")
print(parser.parse_args(["--clear"]))

parser.add_argument("--clear", action="store_true")
print(parser.parse_args(["--clear"]))

This has the following output:

Namespace(clear_magic=True)
Namespace(clear=True, clear_magic=False)

I find it surprising and confusing why the clear magic option is accepted when clear is not defined. I'm tempted to say it's a bug. This unstable behaviour is very surprising when iteratively building up the parser.  

Discovered with https://github.com/pypa/virtualenv/issues/1824#issuecomment-627919033

----------
messages: 368776
nosy: gaborbernat
priority: normal
severity: normal
status: open
title: argparse

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

From report at bugs.python.org  Wed May 13 12:50:03 2020
From: report at bugs.python.org (Serge Matveenko)
Date: Wed, 13 May 2020 16:50:03 +0000
Subject: [New-bugs-announce] [issue40616] Add `asyncio.BufferQueue`
Message-ID: <1589388603.33.0.701691851283.issue40616@roundup.psfhosted.org>


New submission from Serge Matveenko <serge at matveenko.ru>:

It looks handy to be able to leverage `collections.deque` ability to be sized it `asyncio.Queue`.

This could provide the ability to implement backpressure in the queue or just use it as a buffer in messaging systems.

The implementation provided in the linked PR.

----------
components: asyncio
messages: 368788
nosy: asvetlov, lig, yselivanov
priority: normal
pull_requests: 19377
severity: normal
status: open
title: Add `asyncio.BufferQueue`

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

From report at bugs.python.org  Wed May 13 14:52:51 2020
From: report at bugs.python.org (Ilja Umov)
Date: Wed, 13 May 2020 18:52:51 +0000
Subject: [New-bugs-announce] [issue40617] sqlite3: expose
 sqlite3_create_window_function
Message-ID: <1589395971.17.0.715578976108.issue40617@roundup.psfhosted.org>


New submission from Ilja Umov <ilja.umov at gmail.com>:

Expose sqlite3_create_window_function as sqlite3.create_window_function.

There already exists sqlite3.create_aggregate, which uses sqlite3_create_function_v2 and is conceptually similar.

Window functions are available in sqlite starting from 2018-09-15 (3.25.0) release.

References:
https://www.sqlite.org/c3ref/create_function.html
https://www.sqlite.org/changes.html

----------
components: Library (Lib)
messages: 368794
nosy: Ilja Umov
priority: normal
severity: normal
status: open
title: sqlite3: expose sqlite3_create_window_function
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed May 13 20:15:04 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 14 May 2020 00:15:04 +0000
Subject: [New-bugs-announce] [issue40618] PEG Parser: Invalid targets for
 augassign and except succeed
Message-ID: <1589415304.05.0.507277584586.issue40618@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

Tuples and lists, which are invalid augmented assignment targets, currently get successfully parsed, without failing.

?  cpython git:(targets-fix) ? ./python -X oldparser              
Python 3.9.0a6+ (heads/master-dirty:75cd8e48c6, May 14 2020, 03:01:42) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> (a, b) += (1, 2)
  File "<stdin>", line 1
SyntaxError: illegal expression for augmented assignment


?  cpython git:(pr/20076) ./python             
Python 3.9.0a6+ (heads/pr/20076:bcf5be2772, May 14 2020, 02:15:37) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> (a, b) += 1
SystemError: invalid node type (26) for augmented assignment

We also accept arbitrary targets in `except` clauses, while we should only be accepting NAME nodes:

?  cpython git:(master) ./python 
Python 3.9.0a6+ (heads/master:75cd8e48c6, May 14 2020, 03:14:03) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> try:
...     pass
... except Exception as a.b:
...     pass
... 
[1]    135956 segmentation fault (core dumped)  ./python

----------
assignee: lys.nikolaou
components: Interpreter Core
messages: 368809
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: PEG Parser: Invalid targets for augassign and except succeed
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Wed May 13 23:57:30 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 May 2020 03:57:30 +0000
Subject: [New-bugs-announce] [issue40619] compile() passes rest of file as
 SyntaxError().text when file unreadable
Message-ID: <1589428650.19.0.472919567451.issue40619@roundup.psfhosted.org>


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

Example:

>>> compile("pass\n(1+)\npass", "<string>", "exec")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 2
    (1+)
pass
       ^
SyntaxError: invalid syntax
>>> 

Note that the input is

pass
(1+)
pass

The second "pass" (and in fact the entire file) leaks into the SyntaxError object's text attribute.

This only happens when the file (here "<string>") cannot be read.

It's not specific to compile(), it seems fundamental in the C-level pegen API.

----------
keywords: 3.4regression
messages: 368815
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: compile() passes rest of file as SyntaxError().text when file unreadable
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu May 14 02:12:52 2020
From: report at bugs.python.org (Chas Belov)
Date: Thu, 14 May 2020 06:12:52 +0000
Subject: [New-bugs-announce] [issue40620] Range tutorial shorthand could be
 made clearer
Message-ID: <1589436772.42.0.96031331267.issue40620@roundup.psfhosted.org>


New submission from Chas Belov <docorbit at sonic.net>:

I found https://docs.python.org/3.7/tutorial/controlflow.html#the-range-function section 4.3 confusing. The range() Function shows the following example:

>>> for i in range(5):
...     print(i)
...
0
1
2
3
4

[some instructional text]

range(5, 10)
   5, 6, 7, 8, 9

range(0, 10, 3)
   0, 3, 6, 9

range(-10, -100, -30)
  -10, -40, -70

This appears to be an instruction to type, for example:
range(5, 10)
at the prompt, and that the response will be:
   5, 6, 7, 8, 9

leading to a perceived bug when I type at the prompt:
>>> range(5, 10)
and receive the response
range(5, 10)

I ultimately figured out that the example is a shorthand to substitute
range(5, 10)
for the original 
range(5)

>>> for i in range(5, 10):
...     print(i)
...
5
6
7
8
9

It would be less confusing if the example instead read:

----------------------------

Substituting "range(5, 10)" for "range(5)" results in (one number per line)
5, 6, 7, 8, 9

Substituting "range(0, 10, 3)" results in
0, 3, 6, 9

and substituting "range(-10, -100, -30)" results in
-10, -40, -70

---------------------------

such that it is clear that the statements are not meant to be taken as literal stand-alone entries to be typed at the prompt but are instead substitutions.

----------
messages: 368817
nosy: docorbit at sonic.net
priority: normal
severity: normal
status: open
title: Range tutorial shorthand could be made clearer
versions: Python 3.7

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

From report at bugs.python.org  Thu May 14 03:40:23 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 14 May 2020 07:40:23 +0000
Subject: [New-bugs-announce] [issue40621] Python crashes with new parser on
 invalid exception handlers
Message-ID: <1589442023.75.0.251315852279.issue40621@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

```
~/dev/cpython master ? ./python.exe --version --version                                           
Python 3.9.0a6+ (heads/master:a15c9b3a05, May 14 2020, 00:31:47) 
[Clang 11.0.0 (clang-1100.0.33.17)]



# should raise a syntax error, instead crashes
~/dev/cpython master ? cat test.py 
try:
    1 / 0
except Exception as a.b:
    pass
~/dev/cpython master ? ./python.exe test.py            
[1]    63986 bus error  ./python.exe test.py
~/dev/cpython master ? ./python.exe -Xoldparser test.py
  File "/Users/shantanu/dev/cpython/test.py", line 3
    except Exception as a.b:
                         ^
SyntaxError: invalid syntax



# should raise a syntax error, instead passes
~/dev/cpython master ? cat test2.py
try:
    1 / 0
except Exception as (a):
    pass
~/dev/cpython master ? ./python.exe test2.py
~/dev/cpython master ? ./python.exe -Xoldparser test2.py
  File "/Users/shantanu/dev/cpython/test2.py", line 3
    except Exception as (a):
                        ^
SyntaxError: invalid syntax



# should raise a syntax error, instead crashes
~/dev/cpython master ? cat test3.py
try:
    1 / 0
except Exception as a[0]:
    pass
~/dev/cpython master ? ./python.exe test3.py
[1]    64206 bus error  ./python.exe test3.py
~/dev/cpython master ? ./python.exe -Xoldparser test3.py
  File "/Users/shantanu/dev/cpython/test3.py", line 3
    except Exception as a[0]:
                         ^
SyntaxError: invalid syntax
```

The old grammar expects a NAME here, but the new grammar attempts to use a target (https://docs.python.org/3/reference/grammar.html). Seems like we should just go back to using NAME.

----------
messages: 368818
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: Python crashes with new parser on invalid exception handlers

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

From report at bugs.python.org  Thu May 14 06:24:57 2020
From: report at bugs.python.org (Lin Gao)
Date: Thu, 14 May 2020 10:24:57 +0000
Subject: [New-bugs-announce] [issue40622] Using VS2019 to automatically
 build Python3 and Runtest and it failed to Runtest
Message-ID: <1589451897.46.0.783197129325.issue40622@roundup.psfhosted.org>


New submission from Lin Gao <gaolin01 at beyondsoft.com>:

Here is repro steps:
1. git clone -b "3.6" -c core.autocrlf=true https://github.com/python/cpython.git F:\gitP\python\cpython
2. Open a VS 2019 16.4.5 x86 command prompt and browse to F:\gitP\python\cpython
3. checkout the revision to f3a5b7a.
4. Add #include <windows.h> to the _iomodule.c.
5. cd F:\gitP\python\cpython\PCBuild
6. devenv /upgrade pcbuild.sln
7. build -e -r --no-tkinter -v "/p:PlatformToolset=v142" "/p:WindowsTargetPlatformVersion=10.0.18362.0" 
8.cd F:\gitP\python\cpython\PCBuild
9.rt -q -x test_math test_cmath test_distutils test_codecencodings_iso2022 test_random test_sax test_enum test_re test_subprocess test_socket
Error:
4 tests failed:
    test_binhex test_importlib test_peg_generator test_tools
Please see the attachment for details

----------
components: Tests
files: test.log.2.out
messages: 368822
nosy: Lin
priority: normal
severity: normal
status: open
title: Using VS2019 to automatically build Python3 and Runtest and it failed to Runtest
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49152/test.log.2.out

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

From report at bugs.python.org  Thu May 14 06:35:58 2020
From: report at bugs.python.org (paul rubin)
Date: Thu, 14 May 2020 10:35:58 +0000
Subject: [New-bugs-announce] [issue40623] JSON streaming
Message-ID: <1589452558.91.0.037983714251.issue40623@roundup.psfhosted.org>


New submission from paul rubin <phr-pythonbugs at nightsong.com>:

This is a well-explored issue in other contexts: https://en.wikipedia.org/wiki/JSON_streaming

There is also a patch for it in json.tool, for release in 3.9: https://bugs.python.org/issue31553

Basically it's often convenient to have a file containing a list of json docs, one per line.  However, there is no convenient way to read them back in one by one, since json.load(filehandle) barfs when it sees the unexpected newline at the end of the first doc.

It would be great if the json module itself had a function to handle this.  I have an awful hack that I use myself, that is not suitable for a production library, but I'll attach it to show what functionality I'm suggesting.  I hope this is simple enough to not need a PEP.  Thanks!

----------
components: Library (Lib)
files: jsonstream.py
messages: 368823
nosy: phr
priority: normal
severity: normal
status: open
title: JSON streaming
type: enhancement
Added file: https://bugs.python.org/file49153/jsonstream.py

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

From report at bugs.python.org  Thu May 14 07:25:02 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 14 May 2020 11:25:02 +0000
Subject: [New-bugs-announce] [issue40624] add support for != (not-equals) in
 ElementTree XPath
Message-ID: <1589455502.16.0.216786525166.issue40624@roundup.psfhosted.org>


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

It would be a small usability improvement if ElementTree's XPath support also supported the != (not-equals) operator.
I am specifically mentioning only != and not >/</... because != can be defined as the opposite of =, whereas other operators appear to run into questions of what to do with coercion of strings to numbers, etc.  (I guess that depends on the version of XPath, which may be a question we want to avoid for now.)

----------
components: XML
messages: 368829
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: add support for != (not-equals) in ElementTree XPath
versions: Python 3.9

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

From report at bugs.python.org  Thu May 14 07:46:04 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 14 May 2020 11:46:04 +0000
Subject: [New-bugs-announce] [issue40625] Autogenerate signature for
 METH_NOARGS and perhaps METH_O extension functions
Message-ID: <1589456764.49.0.198184837014.issue40625@roundup.psfhosted.org>


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

It would be nice if METH_NOARGS extension methods had an autogenerated signature (or rather, autogenerated __text_signature__ that gets picked up by inspect.signature).  After all, the signature is trivially known at compile time.

The same *could* possibly be done for METH_O methods, for which the effective signature is known too.  The *name* of the sole parameter is not known, but given that the parameter is (I believe?) positional only, that name "shouldn't" really matter (in the sense, e.g., that whether `signature.bind()` succeeds or not doesn't depend on the parameter name).

----------
components: C API
messages: 368830
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Autogenerate signature for METH_NOARGS and perhaps METH_O extension functions
versions: Python 3.9

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

From report at bugs.python.org  Thu May 14 10:47:06 2020
From: report at bugs.python.org (MARK SCHWAB)
Date: Thu, 14 May 2020 14:47:06 +0000
Subject: [New-bugs-announce] [issue40626] application/x-hdf5 mime type
 missing from mimetypes library
Message-ID: <1589467626.22.0.421412195691.issue40626@roundup.psfhosted.org>


New submission from MARK SCHWAB <schwabm at nsidc.org>:

The HDF data group relased HDF5 many years ago, it is a common data type for many science files.

Their recommendation for file extension is '.h5', and mimetype 'application/x-hdf5'.

See 'Recommendations' section for mime types from the HDF group here: https://www.hdfgroup.org/2018/06/citations-for-hdf-data-and-software/

Update mimetypes.py #20042

----------
components: Extension Modules
messages: 368843
nosy: schwabm
priority: normal
pull_requests: 19391
severity: normal
status: open
title: application/x-hdf5 mime type missing from mimetypes library
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/issue40626>
_______________________________________

From report at bugs.python.org  Thu May 14 14:27:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 May 2020 18:27:40 +0000
Subject: [New-bugs-announce] [issue40627] Bus error on 'except E as a.b:'
Message-ID: <1589480860.81.0.165403364835.issue40627@roundup.psfhosted.org>


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

This seems due to some new check in pegen:

>>> try:
...   pass
... except E as a.b:
...   pass
... 
Bus error: 10

----------
messages: 368860
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
stage: needs patch
status: open
title: Bus error on 'except E as a.b:'
type: crash

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

From report at bugs.python.org  Thu May 14 14:55:17 2020
From: report at bugs.python.org (Ryan C. Gordon)
Date: Thu, 14 May 2020 18:55:17 +0000
Subject: [New-bugs-announce] [issue40628] sockmodule.c: sock_connect vs
 negative errno values...
Message-ID: <1589482517.06.0.439871312188.issue40628@roundup.psfhosted.org>


New submission from Ryan C. Gordon <icculus at icculus.org>:

(Forgive any obvious mistakes in this report, I'm almost illiterate with Python, doubly so with Python internals.)

In trying to get buildbot-worker running on Haiku ( https://haiku-os.org/ ), it runs into a situation where it tries to connect a non-blocking TCP socket, which correctly reports EINPROGRESS, and cpython/Modules/sockmodule.c's internal_connect() returns this error code to sock_connect() and sock_connect_ex().

Both of the sock_connect* functions will return NULL if the error code is negative, but on Haiku, all the errno values are negative (EINPROGRESS, for example, is -2147454940).

I _think_ what sock_connect is intending to do here...

    res = internal_connect(s, SAS2SA(&addrbuf), addrlen, 1);
    if (res < 0)
        return NULL;

...is say "if we had a devastating and unexpected system error, give up immediately." Buildbot-worker seems to confirm this by throwing this exception in response:

  builtins.SystemError: <method 'connect_ex' of '_socket.socket' objects> returned NULL without setting an error

internal_connect returns -1 in those devastating-and-unexpected cases--namely when an exception is to be raised--and does not ever use that to otherwise signify a legit socket error. Linux and other systems don't otherwise fall into this "res < 0" condition because errno values are positive on those systems.

So I believe the correct fix here, in sock_connect() and sock_connect_ex(), is to check "if (res == -1)" instead of "res < 0" and let all other negative error codes carry on.

If this seems like the correct approach, I can assemble a pull request, but I don't know the full ramifications of this small change, so I thought I'd report it here first.

--ryan.

----------
components: Extension Modules
messages: 368863
nosy: icculus
priority: normal
severity: normal
status: open
title: sockmodule.c: sock_connect vs negative errno values...
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu May 14 19:25:06 2020
From: report at bugs.python.org (veganaiZe)
Date: Thu, 14 May 2020 23:25:06 +0000
Subject: [New-bugs-announce] [issue40629] Error MSB4086 (numeric comparison)
Message-ID: <1589498706.71.0.441152981554.issue40629@roundup.psfhosted.org>


New submission from veganaiZe <veganaiZe-bot at yahoo.com>:

I'm getting an "error MSB4086: A numeric comparison was attempted ..." while attempting to build Python 3.8.3 (branch `3.8` from github) on Windows 8.1 (64-bit) with VC++ Build Tools 14.0 (2015 R3), at the command line.

I'm guessing that I might have an incorrect (ie. too old) version of the .NET tools?

I've attach the `PCBuild\clean.bat -vv` output.

I can provide many more details but I didn't want to overwhelm.

----------
components: Windows
files: clean_out.txt
messages: 368877
nosy: paul.moore, steve.dower, tim.golden, veganaiZe, zach.ware
priority: normal
severity: normal
status: open
title: Error MSB4086 (numeric comparison)
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49155/clean_out.txt

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

From report at bugs.python.org  Thu May 14 22:12:36 2020
From: report at bugs.python.org (Huon Wilson)
Date: Fri, 15 May 2020 02:12:36 +0000
Subject: [New-bugs-announce] [issue40630] tracemalloc: allow resetting peak
 memory metric without touching other traces
Message-ID: <1589508756.01.0.239997467276.issue40630@roundup.psfhosted.org>


New submission from Huon Wilson <wilson.huon at gmail.com>:

Per https://mail.python.org/archives/list/python-ideas at python.org/thread/QDWI37A4TJXOYUKULGPY2GKD7IG2JNDC/ , it would be helpful to have a function that resets the peak memory usage of the tracemalloc module, without changing all the traces.

This allows for recording the peak memory usage of a specific region of code, rather than only the peak since the last tracemalloc.start() or tracemalloc.clear_traces() call.

----------
components: Library (Lib)
messages: 368916
nosy: huonw, vstinner
priority: normal
severity: normal
status: open
title: tracemalloc: allow resetting peak memory metric without touching other traces
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May 15 08:04:27 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Fri, 15 May 2020 12:04:27 +0000
Subject: [New-bugs-announce] [issue40631] PEG Parser: Cannot used starred
 expression in parenthesised expr
Message-ID: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

The new PEG parser fails when a parenthesised expression with a single child (a group) contains a starred expression. Example:

?? ./python.exe
Python 3.9.0a6+ (heads/master-dirty:4a12d12186, May 15 2020, 14:53:45)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.parse('(*a)')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/lysnikolaou/Repositories/cpython/Lib/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    (*a)
        ^
SyntaxError: invalid syntax

This was valid syntax up until now:

?? ./python.exe -X oldparser
Python 3.9.0a6+ (heads/master-dirty:4a12d12186, May 15 2020, 14:53:45)
[Clang 11.0.0 (clang-1100.0.33.8)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.dump(ast.parse('(*a)'))
"Module(body=[Expr(value=Starred(value=Name(id='a', ctx=Load()), ctx=Load()))], type_ignores=[])"

----------
assignee: lys.nikolaou
components: Interpreter Core
messages: 368936
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: PEG Parser: Cannot used starred expression in parenthesised expr
versions: Python 3.9

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

From report at bugs.python.org  Fri May 15 09:41:24 2020
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Fri, 15 May 2020 13:41:24 +0000
Subject: [New-bugs-announce] [issue40632] AttributeError: type object
 'Callable' has no attribute '_abc_registry'
Message-ID: <1589550084.49.0.00476080862108.issue40632@roundup.psfhosted.org>


New submission from ????? ???????? <dilyan.palauzov at aegee.org>:

I have the newest cpython 3.8 (07bd5cf3d9551ae), installed with `./configure --enable-loadable-sqlite-extensions --disable-ipv6 --with-system-expat --with-system-libmpdec --enable-shared && make && make install`.

Calling `pip-20.1 install -U meson` prints:

Collecting meson
  Using cached meson-0.54.2.tar.gz (1.7 MB)
  Installing build dependencies: started
  Installing build dependencies: finished with status 'error'
  ERROR: Command errored out with exit status 1:
   command: /usr/local/bin/python3 /usr/local/lib/python3.8/site-packages/pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-to_qzg_r/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel
       cwd: None
  Complete output (44 lines):
  Traceback (most recent call last):
    File "/usr/local/lib/python3.8/runpy.py", line 194, in _run_module_as_main
      return _run_code(code, main_globals, None,
    File "/usr/local/lib/python3.8/runpy.py", line 87, in _run_code
      exec(code, run_globals)
    File "/usr/local/lib/python3.8/site-packages/pip/__main__.py", line 26, in <module>
      sys.exit(_main())
    File "/usr/local/lib/python3.8/site-packages/pip/_internal/cli/main.py", line 73, in main
      command = create_command(cmd_name, isolated=("--isolated" in cmd_args))
    File "/usr/local/lib/python3.8/site-packages/pip/_internal/commands/__init__.py", line 104, in create_command
      module = importlib.import_module(module_path)
    File "/usr/local/lib/python3.8/importlib/__init__.py", line 127, in import_module
      return _bootstrap._gcd_import(name[level:], package, level)
    File "<frozen importlib._bootstrap>", line 1014, in _gcd_import
    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 783, in exec_module
    File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
    File "/usr/local/lib/python3.8/site-packages/pip/_internal/commands/install.py", line 24, in <module>
      from pip._internal.cli.req_command import RequirementCommand, with_cleanup
    File "/usr/local/lib/python3.8/site-packages/pip/_internal/cli/req_command.py", line 16, in <module>
      from pip._internal.index.package_finder import PackageFinder
    File "/usr/local/lib/python3.8/site-packages/pip/_internal/index/package_finder.py", line 21, in <module>
      from pip._internal.index.collector import parse_links
    File "/usr/local/lib/python3.8/site-packages/pip/_internal/index/collector.py", line 14, in <module>
      from pip._vendor import html5lib, requests
    File "/usr/local/lib/python3.8/site-packages/pip/_vendor/requests/__init__.py", line 114, in <module>
      from . import utils
    File "/usr/local/lib/python3.8/site-packages/pip/_vendor/requests/utils.py", line 25, in <module>
      from . import certs
    File "/usr/local/lib/python3.8/site-packages/pip/_vendor/requests/certs.py", line 15, in <module>
      from pip._vendor.certifi import where
    File "/usr/local/lib/python3.8/site-packages/pip/_vendor/certifi/__init__.py", line 1, in <module>
      from .core import contents, where
    File "/usr/local/lib/python3.8/site-packages/pip/_vendor/certifi/core.py", line 12, in <module>
      from importlib.resources import read_text
    File "/usr/local/lib/python3.8/importlib/resources.py", line 11, in <module>
      from typing import Iterable, Iterator, Optional, Set, Union   # noqa: F401
    File "/usr/local/lib/python3.8/site-packages/typing.py", line 1357, in <module>
      class Callable(extra=collections_abc.Callable, metaclass=CallableMeta):
    File "/usr/local/lib/python3.8/site-packages/typing.py", line 1005, in __new__
      self._abc_registry = extra._abc_registry
  AttributeError: type object 'Callable' has no attribute '_abc_registry'
  ----------------------------------------
ERROR: Command errored out with exit status 1: /usr/local/bin/python3 /usr/local/lib/python3.8/site-packages/pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-to_qzg_r/overlay --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel Check the logs for full command output.

----------
components: Installation
messages: 368941
nosy: dilyan.palauzov
priority: normal
severity: normal
status: open
title: AttributeError: type object 'Callable' has no attribute '_abc_registry'
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri May 15 09:42:04 2020
From: report at bugs.python.org (Haoyu SUN)
Date: Fri, 15 May 2020 13:42:04 +0000
Subject: [New-bugs-announce] [issue40633] json.dumps() should encode float
 number NaN to null
Message-ID: <1589550124.35.0.830023884715.issue40633@roundup.psfhosted.org>


New submission from Haoyu SUN <raptorsun at gmail.com>:

Float numbers in Python can have 3 special number: nan, inf, -inf, which are encoded by json module as "NaN", "Infinity", "-Infinity". These representations are not compatible with JSON specifications RFC7159:
https://tools.ietf.org/html/rfc7159.html#page-6

These values are not correctly parsed by most JavaScript JSON encoders.

It is better to encode "NaN" to "null" which is a valid JSON keyword representing "Not a Number".

Here is an example how json.dumps() encodes NaN to NaN in JSON:
Python 3.6.9 (default, Apr 18 2020, 01:56:04)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> dct = {'a': None, 'b' : float('nan')}
>>> dct
{'a': None, 'b': nan}
>>> import json
>>> json.dumps(dct)
'{"a": null, "b": NaN}'

----------
components: Library (Lib)
messages: 368942
nosy: Haoyu SUN
priority: normal
severity: normal
status: open
title: json.dumps() should encode float number NaN to null
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri May 15 11:30:02 2020
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Fri, 15 May 2020 15:30:02 +0000
Subject: [New-bugs-announce] [issue40634] Ignored "BlockingIOError: [Errno
 11] Resource temporarily unavailable" are still haunting us
Message-ID: <1589556602.37.0.773453748753.issue40634@roundup.psfhosted.org>


New submission from Yaroslav Halchenko <yarikoptic at gmail.com>:

This is a reincarnation of previous issues such as 

- older https://bugs.python.org/issue21595 which partially (with ack on that) addressed the issue awhile back
- more recent https://bugs.python.org/issue38104 which was closed as "wont fix" since "the provided example finishes without any warning" on 3.8 (verified -- true for me with 3.8.3rc1); and with the explanation that "You spawn too many subprocesses that finish virtually at the same time. It leads to wakeup_fd overrun."
- additional similar reports could be found online, e.g. https://stackoverflow.com/a/52391791/1265472 .

In our project we are slowly introducing use of asyncio and have a mix of execution with asyncio and regular subprocess.Popen.  We do run lots of short lived processes serially, and I think it should be Ok, i.e. it should not cause underlying libraries to spit out some output to ignore unless we indeed just using them incorrectly somehow.

If we recreate the SelectorEventLoop for every separate execution via asyncio -- no ignored exception messages are displayed.  But if we start to reuse the same loop -- they eventually emerge.  If I enable asyncio debug and log it along with our own debug messages, the strange thing that they come around the points where we run using regular subprocess.Popen, not asyncio. See https://github.com/datalad/datalad/pull/4527#issuecomment-629289819 for more information.

Unfortunately I do not have (yet) any short script to reproduce it, but I would appreciate possible hints on how to figure out what is actually causing them in our particular case.  May be additional logging within asyncio could assist?

----------
components: asyncio
messages: 368953
nosy: Yaroslav.Halchenko, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Ignored "BlockingIOError: [Errno 11] Resource temporarily unavailable" are still haunting us
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri May 15 13:02:26 2020
From: report at bugs.python.org (Chris Herdt)
Date: Fri, 15 May 2020 17:02:26 +0000
Subject: [New-bugs-announce] [issue40635] Documentation for socket.getfqdn
 incorrect?
Message-ID: <1589562146.75.0.739099613667.issue40635@roundup.psfhosted.org>


New submission from Chris Herdt <cherdt at gmail.com>:

The documentation for socket.getfqdn() includes this info:

"In case no fully qualified domain name is available, the hostname as returned by gethostname() is returned."

However, that does not appear to be correct. To reproduce a case that exhibits contrary behavior:

>>> import socket
>>> socket.getfqdn("test")
'test'
>>> socket.gethostname()
'centos7minimal.osric.net'

----------
assignee: docs at python
components: Documentation
messages: 368960
nosy: cherdt, docs at python
priority: normal
severity: normal
status: open
title: Documentation for socket.getfqdn incorrect?
versions: Python 3.6

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

From report at bugs.python.org  Fri May 15 15:25:39 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 15 May 2020 19:25:39 +0000
Subject: [New-bugs-announce] [issue40636] Provide a strict form of zip
 (PEP-618) requiring same length inputs
Message-ID: <1589570739.4.0.582573486837.issue40636@roundup.psfhosted.org>


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

PEP 618 https://www.python.org/dev/peps/pep-0618 discussions are still on going.  This issue is being filed to track an implementation, assuming the PEP is accepted and one is decided upon.

I'm filing it now, as I can at least use the issue for documentation enhancements of the existing zip() behavior.

----------
messages: 368965
nosy: brandtbucher, gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide a strict form of zip (PEP-618) requiring same length inputs
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May 15 15:54:37 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 May 2020 19:54:37 +0000
Subject: [New-bugs-announce] [issue40637] Allow users to disable builtin
 hash modules on compile time
Message-ID: <1589572477.51.0.0723794421446.issue40637@roundup.psfhosted.org>


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

Python has a couple of builtin hash module: md5, sha1, sha256/224, sha512/383, sha3/shake family, and blake2b/s. Most of them are used as fallbacks in case OpenSSL bindings are not available.

In some scenarios it is useful or required to disable the custom implementations and only offer libcrypto based implementations. Let's add a build option to disable modules.

----------
assignee: christian.heimes
components: Build
messages: 368966
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Allow users to disable builtin hash modules on compile time
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Fri May 15 18:17:06 2020
From: report at bugs.python.org (Maxwell Bernstein)
Date: Fri, 15 May 2020 22:17:06 +0000
Subject: [New-bugs-announce] [issue40638] input() with malformed input
 stream triggers assertion failure
Message-ID: <1589581026.88.0.827798305344.issue40638@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

builtin_input_impl does multiple attribute lookups in a row assuming they will succeed, but part of attribute lookup assumes that there is no pending exception.

I propose doing the lookups one by one and checking for an error after each. There is an upcoming patch.

----------
components: Interpreter Core, Library (Lib)
messages: 368982
nosy: tekknolagi
priority: normal
severity: normal
status: open
title: input() with malformed input stream triggers assertion failure
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 16 01:02:29 2020
From: report at bugs.python.org (Jacob Underwood)
Date: Sat, 16 May 2020 05:02:29 +0000
Subject: [New-bugs-announce] [issue40639] Strange behavior in changing
 nested dictionaries
Message-ID: <1589605349.29.0.839939005018.issue40639@roundup.psfhosted.org>


New submission from Jacob Underwood <jacobu002 at gmail.com>:

I was experimenting with nested dictionaries when I came across strange behavior that I can not figure out at all. The following function, at least for me, has some weird behavior. Originally, it was a bit longer, but somehow it achieved its intended purpose in a strange way, allowing me to cut off the rest of the correct code and to leave only the following with the code still continuing to work:

My original intention was to make a function that would use the provided keys (in the "keys" argument of the following function) in the form of a list to use all but the last key in the list to get to a nested dictionary within the provided dictionary arg. Then, using the last key in the list, set the key to the information provided. Finally, the function should have returned the full dictionary originally provided, but with the one change within one of the nested dictionaries of the provided dictionary.

def input_into_nested_dict(dictionary, keys, information):
    its = information
    cdip = dictionary
    for key in keys[:-1]:
            cdip = cdip[key]
    cdip[keys[-1]] = its
    return dictionary

So, an example dictionary of
m = {'a':{'b':{'c':{'d':30}}}}

An example list of
y = ['a','b','c','test']

Test of
n = input_into_nested_dict(m, y, 'hello')

The strange thing is, n now correctly has
{'a': {'b': {'c': {'d': 30, 'test': 'hello'}}}}
which does not correspond to what this weird cut off function should do, as it should only provide
{'d': 30, 'test': 'hello'}

Furthermore, somehow this changes the global m, the dictionary provided to the function, making it
{'a': {'b': {'c': {'d': 30, 'test': 'hello'}}}}


(The strange variable names are left over from my original code, though removing them as they are now unnecessary changes the behavior again, even though I am pretty sure it should not (?))

Same function without the beginning variables:

def b(dictionary, keys, information):
    for key in keys[:-1]:
            dictionary = dictionary[key]
    dictionary[keys[-1]] = information
    return dictionary

Now, when ran with the same m (reset back to the original dictionary before it was somehow changed), y, and an n of
n = b(m, y, 'hello')
The result is now that n gets the correct dictionary it should get
{'d': 30, 'test': 'hello'}

Though, somehow m changing also continues, with it again getting
{'a': {'b': {'c': {'d': 30, 'test': 'hello'}}}}

If this makes no sense, I'm sorry I am new to Python and am not really good really giving this kind of information

In addition to that, this is probably not even a bug at all and I am probably just missing something big? If true, I'm sorry about this post...

I do not know if this happens to just me, this originally happened in 3.7.7 but I tried upgrading and it continued in the most recent version (3.8.3)

Thank you!

----------
messages: 369008
nosy: jacob.underwood
priority: normal
severity: normal
status: open
title: Strange behavior in changing nested dictionaries
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat May 16 02:02:21 2020
From: report at bugs.python.org (Chas Belov)
Date: Sat, 16 May 2020 06:02:21 +0000
Subject: [New-bugs-announce] [issue40640] Tutorial for Continue missing ...
 line
Message-ID: <1589608941.53.0.91951505263.issue40640@roundup.psfhosted.org>


New submission from Chas Belov <docorbit at sonic.net>:

The tutorial code for Continue at https://docs.python.org/3.7/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops is missing a
...
null statement.

Actual code/result:

>>> for num in range(2, 10):
...     if num % 2 == 0:
...         print("Found an even number", num)
...         continue
...     print("Found a number", num)
Found an even number 2
Found a number 3
Found an even number 4
Found a number 5
Found an even number 6
Found a number 7
Found an even number 8
Found a number 9

Expected code/result:

>>> for num in range(2, 10):
...     if num % 2 == 0:
...         print("Found an even number", num)
...         continue
...     print("Found a number", num)
...
Found an even number 2
Found a number 3
Found an even number 4
Found a number 5
Found an even number 6
Found a number 7
Found an even number 8
Found a number 9

----------
assignee: docs at python
components: Documentation
messages: 369014
nosy: docorbit at sonic.net, docs at python
priority: normal
severity: normal
status: open
title: Tutorial for Continue missing ... line
versions: Python 3.7

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

From report at bugs.python.org  Sat May 16 02:57:50 2020
From: report at bugs.python.org (Chas Belov)
Date: Sat, 16 May 2020 06:57:50 +0000
Subject: [New-bugs-announce] [issue40641] Reserved word pair used in lambda
 tutorial without being noted as a reserved word
Message-ID: <1589612270.24.0.155728110455.issue40641@roundup.psfhosted.org>


New submission from Chas Belov <docorbit at sonic.net>:

In the tutorial for lambda expressions at https://docs.python.org/3.7/tutorial/controlflow.html#lambda-expressions the reserved word pair is introduced without noting that it is a reserved word. In the example given, I wasn't sure whether pair was a reserved word or whether the interpreter was parsing the plural "pairs" which is presumable an arbitrary name.

Actual content:

The above example uses a lambda expression to return a function. Another use is to pass a small function as an argument:

>>> pairs = [(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
>>> pairs.sort(key=lambda pair: pair[1])
>>> pairs
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]

Candidate expected content:

The above example uses a lambda expression to return a function. Another use is to pass a small function as an argument, for example, the reserved word pair to designate the position in a tuple pair:

>>> items = [(1, 'one'), (2, 'two'), (3, 'three'), (4, 'four')]
>>> items.sort(key=lambda pair: pair[1])
>>> items
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]

----------
assignee: docs at python
components: Documentation
messages: 369017
nosy: docorbit at sonic.net, docs at python
priority: normal
severity: normal
status: open
title: Reserved word pair used in lambda tutorial without being noted as a reserved word
versions: Python 3.7

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

From report at bugs.python.org  Sat May 16 03:40:57 2020
From: report at bugs.python.org (jpelizza)
Date: Sat, 16 May 2020 07:40:57 +0000
Subject: [New-bugs-announce] [issue40642] Cpython "pystate.h" subdirectory
 wrong
Message-ID: <1589614857.55.0.73631693439.issue40642@roundup.psfhosted.org>


New submission from jpelizza <joaogpelizza at gmail.com>:

Line 9 of pystate.h is:
#include "cpython/initconfig.h"
should be:
#include "./initconfig.h"
since pystate.h is already inside cpython dir.

----------
components: C API
messages: 369019
nosy: jpelizza
priority: normal
severity: normal
status: open
title: Cpython "pystate.h" subdirectory wrong
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Sat May 16 07:29:24 2020
From: report at bugs.python.org (Edison Abahurire)
Date: Sat, 16 May 2020 11:29:24 +0000
Subject: [New-bugs-announce] [issue40643] Improve doc-strings for
 datetime.strftime & strptime
Message-ID: <1589628564.12.0.439754688359.issue40643@roundup.psfhosted.org>


New submission from Edison Abahurire <abahedison at gmail.com>:

The docstring for strftime is:
    ```def strftime(self, fmt):
        "Format using strftime()."
    ```

And that of strptime:
    ````def strptime(cls, date_string, format):
        'string, format -> new datetime parsed from a string (like time.strptime()).'
    ````

I feel like both could use a better explanation for users who will access them using >>> help(datetime.strftime) and users using IDEs that provide doc-strings on-hover over a function.

----------
messages: 369040
nosy: edison.abahurire, nanjekyejoannah
priority: normal
severity: normal
status: open
title: Improve doc-strings for datetime.strftime & strptime

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

From report at bugs.python.org  Sat May 16 07:44:47 2020
From: report at bugs.python.org (=?utf-8?q?Pavol_Babin=C4=8D=C3=A1k?=)
Date: Sat, 16 May 2020 11:44:47 +0000
Subject: [New-bugs-announce] [issue40644] Text representation of Windows'
 file attributes similar to stat.filemode()
Message-ID: <1589629487.36.0.146516661583.issue40644@roundup.psfhosted.org>


New submission from Pavol Babin??k <scroolik at gmail.com>:

I'm using Windows and lets' say I have this directory structure listed with cmd:

> dir /A
...

16.05.20  11:15    <DIR>          directory
16.05.20  10:47                 0 hidden
16.05.20  11:25    <SYMLINK>      link [regular]
16.05.20  10:47                 0 readonly
16.05.20  11:15                 0 regular
16.05.20  10:48                 0 system

...

or PowerShell:

PS > dir -Force

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----          16.5.20     11:15                directory
-a-h--          16.5.20     10:47              0 hidden
-a---l          16.5.20     11:25              0 link
-ar---          16.5.20     10:47              0 readonly
-a----          16.5.20     11:15              0 regular
-a--s-          16.5.20     10:48              0 system

or attrib:

> attrib
A   H                hidden
A                    link
A    R               readonly
A                    regular
A  S                 system




I'd like to print file attributes in a text form. If I use stat.filemode():

>>> import os, stat
>>> print("\n".join(["{} {}".format(stat.filemode(os.stat(n).st_mode), n) for n in os.listdir('.')])) 
drwxrwxrwx directory
-rw-rw-rw- hidden
-rw-rw-rw- link
-r--r--r-- readonly
-rw-rw-rw- regular
-rw-rw-rw- system
>>>

not surprisingly I miss all windows attributes. On the top of that I get only values of stat.S_IWRITE and stat.S_IREAD as documented in os.chmod().


I'd like to have a new function, let's say fileattributes() which would behave like this:

>>> print("\n".join(["{} {}".format(stat.fileattributes(os.stat(n).st_file_attributes), n) for n in os.listdir('.')]))
d----- directory
-a-h-- hidden
-a---l link
-ar--- readonly
-a---- regular
-a--s- system
>>>

In this example I have used same format of attributes as in PowerShell because it is most similar to filemode().

I guess link cannot be currently identified with contants in stat module.

----------
components: Library (Lib)
messages: 369041
nosy: scrool
priority: normal
severity: normal
status: open
title: Text representation of Windows' file attributes similar to stat.filemode()
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May 16 11:01:31 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 May 2020 15:01:31 +0000
Subject: [New-bugs-announce] [issue40645] Use OpenSSL's HMAC API
Message-ID: <1589641291.33.0.635001105595.issue40645@roundup.psfhosted.org>


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

Python's hmac module provides a pure Python based implementation on top of the hashlib module. OpenSSL offers a dedicated HMAC implementation that has a couple of benefits over pure Python implementation:

- OpenSSL HMAC is slightly faster and requires slightly less memory and allocations.
- Python's HMAC only works for RFC 2104 HMACs with digests like MD5, SHA1, SHA2, and SHA3. Other digests types like Blake2 use a completely different style of HMAC. OpenSSL's HMAC API works for all sorts of digests. OpenSSL 3.0.0 also supports Blake2 MAC with its standard API.
- OpenSSL HMAC is standard and compliance conform. Certain compliance restrictions require that MAC and keyed hashing is implemented in a certain way. Our HMAC code is considered a custom implementation of a crypto primitive and in violation of compliance rules.

For 3.9 I plan to deprecate hmac.HMAC.digest_con, hmac.HMAC.inner, and hmac.HMAC.outer attributes. They are implementation specific details any way. I'm also going to provide a _hashlib.hmac_new() function so we can test the new code.

For 3.10 I'll be switching over to _haslib.hmac_new() when the digestmod is a string or a callable that returns _hashlib.HASH code.

----------
assignee: christian.heimes
components: Extension Modules
messages: 369050
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: Use OpenSSL's HMAC API
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May 16 11:26:40 2020
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Sat, 16 May 2020 15:26:40 +0000
Subject: [New-bugs-announce] [issue40646] Builtins in doc show signature in
 documentation
Message-ID: <1589642800.95.0.83659669973.issue40646@roundup.psfhosted.org>


New submission from Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com>:

Due to a certain discussion on extending zip, I was having looking at this page:

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

It lists the builtins at the top as e.g. all() which I think is confusing: running all() will actually fail.

I think it should either (using "all" as example):
1. display as "all"
2. display as "all(iterable)" (what to do about 'overloaded' functions like e.g. range?)

I am happy to provide a PR for the preferred option.

----------
assignee: docs at python
components: Documentation
messages: 369053
nosy: cryvate, docs at python
priority: normal
severity: normal
status: open
title: Builtins in doc show signature in documentation
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May 16 11:27:30 2020
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 16 May 2020 15:27:30 +0000
Subject: [New-bugs-announce] [issue40647] Building with a libreadline.so
 located outside the ld.so.conf search path fails
Message-ID: <1589642850.04.0.521709964482.issue40647@roundup.psfhosted.org>


New submission from Martijn Pieters <mj at python.org>:

This issue goes back a long time. The libreadline handling in the modules setup.py doesn't add the location of the readline library to the runtime library paths:

    self.add(Extension('readline', ['readline.c'],
                       library_dirs=['/usr/lib/termcap'],
                       extra_link_args=readline_extra_link_args,
                       libraries=readline_libs))

This requires the readline library to have been added to a traditional location or has taken care of either ld.so.conf or LD_LIBRARY_PATH.

I'm building a series of Python binaries with a custom `--prefix` where I also installed a local copy of readline (so both are configured with the same prefix), and while setup.py finds the correct library, importing the compiled result fails because no `RPATH` is set.

This could be fixed by adding the parent path of the located `libreadline` shared library as a `runtime_library_dirs` entry:

    readline_libdirs = None
    if do_readline not in self.lib_dirs:
        readline_libdirs = [
            os.path.abspath(os.path.dirname(do_readline))
        ]

    self.add(Extension('readline', ['readline.c'],
                       library_dirs=['/usr/lib/termcap'],
                       extra_link_args=readline_extra_link_args,
                       runtime_library_dirs=readline_libdirs,
                       libraries=readline_libs))

----------
components: Extension Modules
messages: 369054
nosy: mjpieters
priority: normal
severity: normal
status: open
title: Building with a libreadline.so located outside the ld.so.conf search path fails
type: compile error
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 16 11:47:26 2020
From: report at bugs.python.org (=?utf-8?q?Pavol_Babin=C4=8D=C3=A1k?=)
Date: Sat, 16 May 2020 15:47:26 +0000
Subject: [New-bugs-announce] [issue40648] File mode is not tested on Windows
Message-ID: <1589644046.09.0.00935722474106.issue40648@roundup.psfhosted.org>


New submission from Pavol Babin??k <scroolik at gmail.com>:

>From what I can tell only place where file mode is tested is test_mode() method of class TestFilemode in test_stat.py. Relevant section for Windows (os.name != 'posix'):

with open(TESTFN, 'w'):
  pass

...

os.chmod(TESTFN, 0o700)
st_mode, modestr = self.get_mode()
self.assertEqual(modestr[:3], '-rw')
self.assertS_IS("REG", st_mode)
self.assertEqual(self.statmod.S_IFMT(st_mode),
                 self.statmod.S_IFREG)

Doesn't test that files under Windows can have only two modes:
- 0o444 - If os.chmod() is missing stat.S_IWRITE. Effectively readonly.
- 0o666 - Regular file by default.

On the top of that I believe last two assertions are equivalent - test file is regular. But that would be for a different issue, I guess.

----------
components: Tests
messages: 369056
nosy: scrool
priority: normal
severity: normal
status: open
title: File mode is not tested on Windows
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat May 16 16:09:24 2020
From: report at bugs.python.org (Glenn Travis)
Date: Sat, 16 May 2020 20:09:24 +0000
Subject: [New-bugs-announce] [issue40649] [Errno 1}
Message-ID: <1589659764.36.0.211928166783.issue40649@roundup.psfhosted.org>


New submission from Glenn Travis <pbfuddle at comcast.net>:

A fellow on the X-Plane forum reported getting this:

cd desktop/Ortho4XP-130

ianrobertson at Ians-iMac Ortho4XP-130 % python3 Ortho4XP_v130.py

/Library/Frameworks/Python.framework/Versions/3.8/bin/python3: can't open file 'Ortho4XP_v130.py': [Errno 1] Operation not permitted

he is able to run python3.8.2 from the terminal and get it to work with the interpreter for a print('Howdy') but Ortho4Xp not.

is this a python thing, an ortho thing or some root cause from installing python?

----------
messages: 369065
nosy: TotallyLost
priority: normal
severity: normal
status: open
title: [Errno 1}

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

From report at bugs.python.org  Sat May 16 19:30:59 2020
From: report at bugs.python.org (Minmin Gong)
Date: Sat, 16 May 2020 23:30:59 +0000
Subject: [New-bugs-announce] [issue40650] Pytime.c doesn't need to include
 windows.h
Message-ID: <1589671859.24.0.478073605849.issue40650@roundup.psfhosted.org>


New submission from Minmin Gong <minmin.gong at gmail.com>:

Python/pytime.c includes windows.h for timeval. But it's not necessary to include the full header, because timeval is defined in winsock headers.

----------
messages: 369082
nosy: Minmin.Gong
priority: normal
severity: normal
status: open
title: Pytime.c doesn't need to include windows.h

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

From report at bugs.python.org  Sat May 16 19:33:27 2020
From: report at bugs.python.org (Dongfang Qu)
Date: Sat, 16 May 2020 23:33:27 +0000
Subject: [New-bugs-announce] [issue40651] class:`OrderedDict` Examples: LRU
 implementation has a bug.
Message-ID: <1589672007.55.0.638241402645.issue40651@roundup.psfhosted.org>


New submission from Dongfang Qu <qudongfang at gmail.com>:

class:`OrderedDict` Examples: LRU implementation has a bug.
Details: 
The calls to the `__setitem__` method should also count as usages.

----------
assignee: docs at python
components: Documentation
messages: 369083
nosy: Dongfang Qu, docs at python
priority: normal
severity: normal
status: open
title: class:`OrderedDict` Examples: LRU implementation has a bug.

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

From report at bugs.python.org  Sat May 16 22:30:47 2020
From: report at bugs.python.org (kpysoze)
Date: Sun, 17 May 2020 02:30:47 +0000
Subject: [New-bugs-announce] [issue40652] Test test_locale failed when
 running cpython test on Windows 10 x64 for version 3.9.0a6+
Message-ID: <1589682647.75.0.547799731095.issue40652@roundup.psfhosted.org>


New submission from kpysoze <kpysose at gmail.com>:

Test test_locale failed when running cpython test on Windows 10 x64 python.bat -m test -j3 on version Python 3.9.0a6+

0:19:51 load avg: 0.00 [209/423/2] test_locale failed
test test_locale failed -- Traceback (most recent call last):
  File "C:\personal\cpython\cpython\lib\test\test_locale.py", line 566, in test_getsetlocale_issue1813
    locale.setlocale(locale.LC_CTYPE, loc)
  File "C:\personal\cpython\cpython\lib\locale.py", line 610, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

----------
components: Windows
messages: 369087
nosy: kpysoze, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Test test_locale failed when running cpython test on Windows 10 x64 for version 3.9.0a6+
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sat May 16 23:05:19 2020
From: report at bugs.python.org (Minmin Gong)
Date: Sun, 17 May 2020 03:05:19 +0000
Subject: [New-bugs-announce] [issue40653] _dirnameW is used outside
 HAVE_SYMLINK
Message-ID: <1589684719.69.0.769333707176.issue40653@roundup.psfhosted.org>


New submission from Minmin Gong <minmin.gong at gmail.com>:

_dirnameW is defined inside #ifdef HAVE_SYMLINK/#endif, but it's used in os__getdiskusage_impl, which is outside HAVE_SYMLINK. So if HAVE_SYMLINK is not defined (e.g., on UWP), it'll have compiling issues.

----------
components: Windows
messages: 369089
nosy: Minmin.Gong, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: _dirnameW is used outside HAVE_SYMLINK
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Sat May 16 23:26:35 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 17 May 2020 03:26:35 +0000
Subject: [New-bugs-announce] [issue40654] shutil.copyfile mutates symlink
 for absolute path
Message-ID: <1589685995.41.0.350903765679.issue40654@roundup.psfhosted.org>


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

In https://github.com/jaraco/path/issues/186, the Path project discovered a regression with Python 3.8. It seems that if one creates a symlink with an absolute path. I used `shutil.copytree('temp', 'temp2', True)` and it produced this result:

```
~ # dir temp
 Volume in drive C has no label.
 Volume Serial Number is B8F4-40BB

 Directory of C:\Users\jaraco\temp

2020-05-16  11:05 PM    <DIR>          .
2020-05-16  11:05 PM    <DIR>          ..
2020-05-16  11:05 PM    <SYMLINK>      bar [c:\Users\jaraco\temp\foo]
2020-05-16  11:04 PM                 0 foo
               2 File(s)              0 bytes
               2 Dir(s)  17,495,805,952 bytes free
~ # dir temp2
 Volume in drive C has no label.
 Volume Serial Number is B8F4-40BB

 Directory of C:\Users\jaraco\temp2

2020-05-16  11:05 PM    <DIR>          .
2020-05-16  11:05 PM    <DIR>          ..
2020-05-16  11:06 PM    <SYMLINK>      bar [\\?\c:\Users\jaraco\temp\foo]
2020-05-16  11:04 PM                 0 foo
               2 File(s)              0 bytes
               2 Dir(s)  17,495,846,912 bytes free
```

As you can see, in the copy, bar has an additional `\\?\` prefix on the symlink path. On Python 3.7 and earlier, the copy was made without mutating the metadata.

----------
components: Windows
keywords: 3.8regression
messages: 369091
nosy: jaraco, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: shutil.copyfile mutates symlink for absolute path
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun May 17 02:46:10 2020
From: report at bugs.python.org (Hakan)
Date: Sun, 17 May 2020 06:46:10 +0000
Subject: [New-bugs-announce] [issue40655] Fix from a bad programming
 practice 'from x import *', 'Lib / ctypes / test /'.
Message-ID: <1589697970.08.0.120528668652.issue40655@roundup.psfhosted.org>


New submission from Hakan <hakancelik96 at outlook.com>:

When I use [unimport](https://github.com/hakancelik96/unimport), I saw this problem and I am sending a PR to fix it.

----------
components: Tests
messages: 369097
nosy: hakancelik
priority: normal
severity: normal
status: open
title: Fix from a bad programming practice 'from x import *', 'Lib / ctypes / test /'.
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/issue40655>
_______________________________________

From report at bugs.python.org  Sun May 17 04:06:44 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 17 May 2020 08:06:44 +0000
Subject: [New-bugs-announce] [issue40656] Clean up detect_socket() in
 setup.py
Message-ID: <1589702804.71.0.337147119677.issue40656@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Rewrite to use `if cond`, iso. `if not cond`

----------
components: Build
files: 0001-Clean-up-detect_socket.patch
keywords: patch
messages: 369101
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Clean up detect_socket() in setup.py
type: enhancement
versions: Python 3.9
Added file: https://bugs.python.org/file49161/0001-Clean-up-detect_socket.patch

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

From report at bugs.python.org  Sun May 17 04:07:51 2020
From: report at bugs.python.org (Rosen Tomov)
Date: Sun, 17 May 2020 08:07:51 +0000
Subject: [New-bugs-announce] [issue40657] Resource leaks with
 threading.Thread
Message-ID: <1589702871.42.0.415645279958.issue40657@roundup.psfhosted.org>


New submission from Rosen Tomov <poceh at yahoo.com>:

In my project I'm using intensively threading to transfer HTTP data - reading is in separate thread and the process run smoothly. However when I've try to optimize stopping of the process and attempt to use the daemon threads. The result was 'Can't start new thread' error under Linux. In order to investigate the issue I've create small test program and found more interesting problem: using non daemon threads leaks handles (under Windows/x64 Semaphore type), while under Linux looks like leaks some other resource, can't say exactly what. When using a daemon threads no leaks handles under Windows but under Linux, after long time running the problem arrives, the only one solution is to reboot of Linux/ARM64, restarting the Python process didn't help! Of course the problem could be race condition or some locking problem, didn't investigate further and in Python's core source. 
Attached test programs reveals the problem very quickly, using Python 3.8.x interpreters. Also I've testing with lambdas and deletion and found that they do not influence the behavior.

----------
components: Interpreter Core
files: thread.py
messages: 369102
nosy: POCEH
priority: normal
severity: normal
status: open
title: Resource leaks with threading.Thread
type: resource usage
versions: Python 3.8
Added file: https://bugs.python.org/file49162/thread.py

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

From report at bugs.python.org  Sun May 17 12:01:10 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 17 May 2020 16:01:10 +0000
Subject: [New-bugs-announce] [issue40661] The new parser segfaults when
 parsing invalid input
Message-ID: <1589731270.13.0.765270340718.issue40661@roundup.psfhosted.org>


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

The new peg parser segfaults when parsing the attached reproducer.

this is due to the fact that the exception set by `tokenizer_error` is not properly propagated.

----------
components: Interpreter Core
files: reproducer.py
messages: 369132
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: release blocker
severity: normal
stage: needs patch
status: open
title: The new parser segfaults when parsing invalid input
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49169/reproducer.py

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

From report at bugs.python.org  Sun May 17 13:35:18 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 17 May 2020 17:35:18 +0000
Subject: [New-bugs-announce] [issue40662] ast.get_source_segment behaviour
 with missing location info doesn't match doctoring
Message-ID: <1589736918.78.0.989051663687.issue40662@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at yahoo.com>:

The doctoring says "If some location information (lineno, end_lineno, col_offset, or end_col_offset) is missing, return None."

However:

>>> s = "12"
>>> node = ast.parse(s).body[0]
>>> ast.get_source_segment(s, node)
'12'
>>> del node.lineno
>>> ast.get_source_segment(s, node)
>>> node = ast.parse(s).body[0]
>>> del node.end_lineno
>>> ast.get_source_segment(s, node)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/iritkatriel/src/cpython/Lib/ast.py", line 336, in get_source_segment
    end_lineno = node.end_lineno - 1
TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'

In other parts of ast.py there are hasattr checks for lineno/col_offset alongside checks for None for end_lineno/end_col_offset. So this difference in behaviour of the end_ fields seems intended.

----------
components: Library (Lib)
messages: 369139
nosy: benjamin.peterson, brett.cannon, iritkatriel, pablogsal, yselivanov
priority: normal
pull_requests: 19458
severity: normal
status: open
title: ast.get_source_segment behaviour with missing location info doesn't match doctoring
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun May 17 13:36:39 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 17 May 2020 17:36:39 +0000
Subject: [New-bugs-announce] [issue40663] Wrong generated annotation on
 subscripting
Message-ID: <1589736999.01.0.252396126207.issue40663@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

>>> from __future__ import annotations
>>> a: Type[int, str]
>>> b: Type[(int, str, *types)]
>>> __annotations__
{'a': 'Type[int, str]', 'b': 'Type[int, str, *types]'}
>>> ast.parse(__annotations__["b"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/isidentical/cpython/master/Lib/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    Type[int, str, *types]
                   ^
SyntaxError: invalid syntax

----------
messages: 369140
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Wrong generated annotation on subscripting

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

From report at bugs.python.org  Sun May 17 15:16:27 2020
From: report at bugs.python.org (Nicolas Gimenez)
Date: Sun, 17 May 2020 19:16:27 +0000
Subject: [New-bugs-announce] [issue40664] Documentation error:
 itertools.dropwhile(is_even, itertools.count()) output
Message-ID: <1589742987.46.0.19794536776.issue40664@roundup.psfhosted.org>


New submission from Nicolas Gimenez <n.gimenez66 at gmail.com>:

On this page:
https://docs.python.org/3/howto/functional.html
The example:

"itertools.dropwhile(is_even, itertools.count()) =>
  1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ..."

is wrong. It should be:

"itertools.dropwhile(is_even, itertools.count()) =>
  1, 3, 5, 7, 9, ..."

----------
assignee: docs at python
components: Documentation
messages: 369146
nosy: docs at python, nicobao
priority: normal
severity: normal
status: open
title: Documentation error:  itertools.dropwhile(is_even, itertools.count()) output
versions: Python 3.8

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

From report at bugs.python.org  Sun May 17 17:31:08 2020
From: report at bugs.python.org (Shantanu)
Date: Sun, 17 May 2020 21:31:08 +0000
Subject: [New-bugs-announce] [issue40665] Use Argument Clinic for bisect
Message-ID: <1589751068.08.0.269643939265.issue40665@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

As the title says! Am submitting a PR.

----------
components: Argument Clinic
messages: 369153
nosy: hauntsaninja, larry
priority: normal
severity: normal
status: open
title: Use Argument Clinic for bisect

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

From report at bugs.python.org  Mon May 18 04:01:55 2020
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 18 May 2020 08:01:55 +0000
Subject: [New-bugs-announce] [issue40666] TarFile.add does not support
 pathlib.Path as a value to first argument.
Message-ID: <1589788915.52.0.458653938585.issue40666@roundup.psfhosted.org>


Change by ???? ????????? <socketpair at gmail.com>:


----------
components: Library (Lib)
nosy: socketpair
priority: normal
severity: normal
status: open
title: TarFile.add does not support pathlib.Path as a value to first argument.
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 18 05:06:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 May 2020 09:06:49 +0000
Subject: [New-bugs-announce] [issue40667] [Windows] Add global python and
 python3 commands
Message-ID: <1589792809.51.0.970244169965.issue40667@roundup.psfhosted.org>


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

So I'm totally sick of being abused on the internet about the whole PATH issue, and want to put this up as an alternative. I'm willing to do the work, but I'm worried that my emotional state about the whole thing is blinding me to obvious issues.

In short, add a new option to the installer to "Add global python3.exe and python.exe commands". Also replace the current PATH option on the first page (not under Customize) with this. I'll also embed a "Learn More" link to the (new) doc page that explains the impact.

The option will pass an extra flag to the *launcher* installer to include more copies of py.exe, renamed to python3.exe and python.exe (we already pass a similar option to add file associations). These additional copies will be just as global as py.exe (depending on whether the user is admin or not) and obviously work identically.

Importantly, this does *not* drop an arbitrary/writable directory on PATH, and it keeps the DLLs out of the search path. 

There are some risks:
* these may overtake people's existing installs and replace them with something more clever (this annoys people)
* these add an extra process in the chain, which can break callers who need the process ID/handle (this annoys people)
* this won't put Scripts on PATH (this annoys people)
* changing anything at all annoys people
* would remove python3.dll and python39.dll from PATH (probably for the best), and also vcruntime*.dll (which is a *good* thing) and anything installed by packages/tools into sys.prefix (which is a *massive* security vulnerability)
* the help text for the launcher is not obvious above the help for the default Python interpreter
* shebang lines will start being noticed
* things should work in a venv because of both PATH and VIRTUALENV variables, but I'm not going to stake my life on this
* "python3.exe" could launch Python 2, but I'm not too concerned by this

I feel like this option is the best of a bad lot. But if people weigh in and say it's worse than doing nothing, then I'll do nothing.

(Including ?ukasz in case he wants to veto adding this to 3.9 after beta 1. It's not a language change, and barely even an installer change - just a few optional copies of the existing launcher plus some docs. But as I mentioned above it *will* break some people.)

----------
components: Windows
messages: 369196
nosy: lukasz.langa, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] Add global python and python3 commands
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May 18 05:10:27 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 18 May 2020 09:10:27 +0000
Subject: [New-bugs-announce] [issue40668] Catastrophic loss of precision in
 colorsys module
Message-ID: <1589793027.58.0.382499292423.issue40668@roundup.psfhosted.org>


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

As part of the Mentored Sprints at PyCon US, Marielle wrote some property-based tests [1] for the colorsys module [2], which found two bugs.


Taking a YIQ color, converting to RGB, and back to YIQ can result in the Y coordinate varying by more 0.1 (where [0, 1] is the range of possible values).
For example: (0.0 1.0 2.2204460492503136e-16) -> RGB -> (0.0 1.1102230246251568e-16 1.0)

Taking an RGB color and converting though HSV-RBG-HSV can result in very different saturation values - up to having S1==0 and S2==1.
For example: (0.0 1.0 2.2204460492503136e-16) -> RGB -> (0.0 1.1102230246251568e-16 1.0)


You can reproduce additional examples and get error bounds from [3].


[1] https://pyfound.blogspot.com/2020/05/property-based-testing-for-python.html
[2] https://docs.python.org/3/library/colorsys.html
[3] https://github.com/Zac-HD/stdlib-property-tests/pull/13

----------
components: Library (Lib)
messages: 369197
nosy: Zac Hatfield-Dodds
priority: normal
severity: normal
status: open
title: Catastrophic loss of precision in colorsys module
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/issue40668>
_______________________________________

From report at bugs.python.org  Mon May 18 06:52:40 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 18 May 2020 10:52:40 +0000
Subject: [New-bugs-announce] [issue40669] PEG Parser benchmarks fail if
 memory_profiler is not installed
Message-ID: <1589799160.45.0.969493803644.issue40669@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

Running the PEG Parser benchmarks requires having memory_profiler installed.

In Tools/peg_generator:

?  peg_generator git:(master) make time_stdlib
../../python -m zipfile -e data/xxl.zip data
../../python scripts/benchmark.py --parser=cpython --target=xxl compile
Traceback (most recent call last):
  File "/home/lysnikolaou/repos/cpython/Tools/peg_generator/scripts/benchmark.py", line 9, in <module>
    import memory_profiler
ModuleNotFoundError: No module named 'memory_profiler'

I propose to make that optional and only compute the timing benchmarks, in case memory_profiler is not available, since it's these benchmarks that are most important and most frequently run.

----------
assignee: lys.nikolaou
messages: 369204
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: PEG Parser benchmarks fail if memory_profiler is not installed

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

From report at bugs.python.org  Mon May 18 08:44:21 2020
From: report at bugs.python.org (Edison Abahurire)
Date: Mon, 18 May 2020 12:44:21 +0000
Subject: [New-bugs-announce] [issue40670] supplying an empty string to
 timeit causes an IndentationError
Message-ID: <1589805861.06.0.616610250992.issue40670@roundup.psfhosted.org>


New submission from Edison Abahurire <abahedison1 at outlook.com>:

The Error can be evidenced below:

```
>>>
>>> import timeit
>>>
>>> timeit.timeit('', number=10000)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/timeit.py", line 232, in timeit
    return Timer(stmt, setup, timer, globals).timeit(number)
  File "/usr/lib/python3.8/timeit.py", line 131, in __init__
    code = compile(src, dummy_src_name, "exec")
  File "<timeit-src>", line 7
    _t1 = _timer()
    ^
IndentationError: expected an indented block
>>>
```

----------
messages: 369208
nosy: anthonypjshaw, edison.abahurire
priority: normal
severity: normal
status: open
title: supplying an empty string to timeit causes an IndentationError

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

From report at bugs.python.org  Mon May 18 09:07:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 May 2020 13:07:20 +0000
Subject: [New-bugs-announce] [issue40671] Convert _hashlib to PEP 489
 multiphase initialization
Message-ID: <1589807240.02.0.725265164424.issue40671@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In Modules/_hashopenssl.c:PyInit__hashlib(), PyModule_AddObject() can be replaced with PyModule_AddType() to add the 3 types: this function does the Py_INCREF for us, which reduces errors if the function fails.

The results of other PyModule_AddObject() calls should also be checked to handle errors.

The following _hashlibstate_global macro is no longer used:

#define _hashlibstate_global ((_hashlibstate *)PyModule_GetState(PyState_FindModule(&_hashlibmodule)))

EVPnew() got a module parameter, so it doesn't need _hashlibstate_global anymore.

Dong-hee, Hai: Maybe it's time to convert this module to PEP 489 multiphase initialization?

Hai: do you want to work on a PR?

--

Question: do EVPobject and HMACobject rely on a global state somewhere in OpenSSL? Or is it safe to use them in subinterpreters, with multiple instances of _hashlib?

EVPobject and HMACobject have "lock" member.

Even if converting the module to PEP 489 is not enough to make it compatible with subinterpreters (I don't know, maybe it's enought, see my question), it should help for that :-)

Note: the current code is already quite clean, I like it :-)

cc Petr & Christian.

----------
components: Library (Lib)
messages: 369211
nosy: christian.heimes, corona10, petr.viktorin, shihai1991, vstinner
priority: normal
severity: normal
status: open
title: Convert _hashlib to PEP 489 multiphase initialization
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May 18 13:23:20 2020
From: report at bugs.python.org (Roman Skurikhin)
Date: Mon, 18 May 2020 17:23:20 +0000
Subject: [New-bugs-announce] [issue40672] asyncio.wait_for: process future
 result produced during cancelation
Message-ID: <1589822600.1.0.30867318872.issue40672@roundup.psfhosted.org>


New submission from Roman Skurikhin <romasku135 at gmail.com>:

In https://bugs.python.org/issue40607 asyncio.wait_for behavior was changed so it propagates exceptions that happened during cancellation. But it still raises `TimeoutError` if cancelation ends with some value being returned. In the following example value `42` is lost:

import asyncio


async def return_42_on_cancel():
    try:
        await asyncio.sleep(20)
    except asyncio.CancelledError:
        return 42  # `return` is useless in this block.


async def main():
    try:
        await asyncio.wait_for(return_42_on_cancel(), timeout=1)
    except asyncio.TimeoutError:
        print('Timeout')

asyncio.run(main())


I think it's better to either:

1) Return that value from `asyncio.wait_for`.

The motivation here is that if the task returns something, we shouldn't conceal it. I also searched through GitHub and found some places where others catch `CancelledError` and return value (https://github.com/grpc/grpc/blob/44fb37c99f2853cc23f04fba15468980d9e28e41/src/python/grpcio/grpc/experimental/aio/_interceptor.py#L328).

It can also be used with some coroutines developed to be wrapped with `wait_for`, for example suppose the following equation solving function:

async def solve_iteratively(initial_x, next_approximation):
    result = initial_x
    try:
        while True:
            result = next_approximation(result)
            await asyncio.sleep(0)
    except asyncio.CancelledError:
        return result

It allows us to control its execution time using asyncio.wait_for.


2) Add some warning about the value is thrown away (in debug mode) and document it somewhere.

===

I am a newbie here, so sorry if it is wrong to create such "proposal" issues.

----------
components: asyncio
messages: 369278
nosy: Roman Skurikhin, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait_for: process future result produced during cancelation
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon May 18 17:30:13 2020
From: report at bugs.python.org (Petter S)
Date: Mon, 18 May 2020 21:30:13 +0000
Subject: [New-bugs-announce] [issue40673] UrlOpener raises different
 exceptions based on implementation detail
Message-ID: <1589837413.34.0.736050920356.issue40673@roundup.psfhosted.org>


New submission from Petter S <petter.strandmark at gmail.com>:

The following code crashes with TypeError:

URLopener().open("unknown_proxy://test")

the expected behavior is an OSError, which is normally raised for unknown protocols.

This implementation of directly calling a method called "unknown_proxy" is fragile and was recently the subject of a security issue: https://bugs.python.org/issue35907 (CVE-2019-9948)

Would be good to make this more robust.

----------
components: Library (Lib)
messages: 369291
nosy: Petter S
priority: normal
severity: normal
status: open
title: UrlOpener raises different exceptions based on implementation detail
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/issue40673>
_______________________________________

From report at bugs.python.org  Mon May 18 18:39:16 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 18 May 2020 22:39:16 +0000
Subject: [New-bugs-announce] [issue40674] Deprecate
 urllib.request.urlretrieve() and cleanup()
Message-ID: <1589841556.43.0.170691169258.issue40674@roundup.psfhosted.org>


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


----------
components: Library (Lib)
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: Deprecate urllib.request.urlretrieve() and cleanup()
type: behavior

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

From report at bugs.python.org  Mon May 18 21:08:13 2020
From: report at bugs.python.org (Sahil)
Date: Tue, 19 May 2020 01:08:13 +0000
Subject: [New-bugs-announce] [issue40675] Add missing mimetypes for fonts
Message-ID: <1589850493.36.0.16198127877.issue40675@roundup.psfhosted.org>


New submission from Sahil <sahilprjpt206 at gmail.com>:

Currently guess_type method of mimetype fails to identity fonts from their extensions.

----------
components: Library (Lib)
messages: 369312
nosy: sahil.prajapati
priority: normal
pull_requests: 19498
severity: normal
status: open
title: Add missing mimetypes for fonts

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

From report at bugs.python.org  Mon May 18 21:36:49 2020
From: report at bugs.python.org (Shantanu)
Date: Tue, 19 May 2020 01:36:49 +0000
Subject: [New-bugs-announce] [issue40676] Use Argument Clinic for csv
Message-ID: <1589852209.46.0.104557950942.issue40676@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

To do all the functions in csv, we'd need to have support for **kwargs, tracked in https://bugs.python.org/issue20291. Am attaching a PR for the ones that can be made to work today.

----------
components: Argument Clinic
messages: 369314
nosy: hauntsaninja, larry
priority: normal
severity: normal
status: open
title: Use Argument Clinic for csv

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

From report at bugs.python.org  Tue May 19 00:08:16 2020
From: report at bugs.python.org (Minmin Gong)
Date: Tue, 19 May 2020 04:08:16 +0000
Subject: [New-bugs-announce] [issue40677] IO_REPARSE_TAG_APPEXECLINK is not
 defined in old Windows SDK
Message-ID: <1589861296.48.0.956665413821.issue40677@roundup.psfhosted.org>


New submission from Minmin Gong <minmin.gong at gmail.com>:

Python 3.8 introduces IO_REPARSE_TAG_APPEXECLINK, but this macro is not defined in Windows SDKs before 10. Need to manually define it.

----------
components: Windows
messages: 369319
nosy: Minmin.Gong, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: IO_REPARSE_TAG_APPEXECLINK is not defined in old Windows SDK
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Tue May 19 02:05:54 2020
From: report at bugs.python.org (Ram Rachum)
Date: Tue, 19 May 2020 06:05:54 +0000
Subject: [New-bugs-announce] [issue40678] Full list of Python lexical rules
Message-ID: <1589868354.8.0.399926907796.issue40678@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I'm a noob on parsing, learning about it, so it's possible I've made a mistake somewhere.

I know there's this page: https://docs.python.org/3/reference/grammar.html

Which is a full listing of Python's grammar. However, looking at this page: https://docs.python.org/3/reference/lexical_analysis.html I see rules that aren't written there, like longstringitem.

I'm guessing that's because these are lexing rules, while the former was a list of parsing rules?

If that's the case, shouldn't there also be a full, authoritative list of Python's lexical rules? Possibly alongside the parsing rules?

----------
assignee: docs at python
components: Documentation
messages: 369320
nosy: cool-RR, docs at python, georg.brandl, gvanrossum
priority: normal
severity: normal
status: open
title: Full list of Python lexical rules
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/issue40678>
_______________________________________

From report at bugs.python.org  Tue May 19 03:57:29 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 19 May 2020 07:57:29 +0000
Subject: [New-bugs-announce] [issue40679] show class name in method
 invocation TypeError
Message-ID: <1589875049.34.0.573346435361.issue40679@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

When calling an instance method incorrectly, you will often get a TypeError that is some variation of the following:

    Traceback (most recent call last):
      File "/.../test.py", line 6, in <module>
        a.foo(1)
    TypeError: foo() takes 1 positional argument but 2 were given

However, when multiple classes have method foo() and the type of "a" isn't immediately obvious, this often isn't enough to know what method was being called. Thus, it would be more helpful if the error message includes also the class that foo() belongs to, or alternatively the type of the object. (These can be different when subclasses are involved.)

For comparison, if you call a method that doesn't exist, you will get a message that looks like the following:

    Traceback (most recent call last):
      File "/.../test.py", line 6, in <module>
        a.bar(1)
    AttributeError: 'A' object has no attribute 'bar'

So taking from this as an example, the message in the first case could be something like--

    TypeError: foo() for 'A' object takes 1 positional argument but 2 were given

----------
messages: 369324
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: show class name in method invocation TypeError
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue May 19 07:49:51 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 19 May 2020 11:49:51 +0000
Subject: [New-bugs-announce] [issue40680] thread_cputime isn't supported by
 AIX5
Message-ID: <1589888991.61.0.317317587375.issue40680@roundup.psfhosted.org>


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

issue40192 introduced the use of nanosecond reporting of time.

The new routine called is not available in AIX 5.3:

        xlc_r  -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O    -I../git/python-3.9/Include/internal -IObjects -IInclude -IPython -I. -I../git/python-3.9/Include -I/opt/include   -DPy_BUILD_CORE_BUILTIN  -DPy_BUILD_CORE_BUILTIN -I../git/python-3.9/Include/internal -c ../git/python-3.9/Modules/timemodule.c -o Modules/timemodule.o
"../git/python-3.9/Modules/timemodule.c", line 1358.22: 1506-275 (S) Unexpected text tc encountered.
"../git/python-3.9/Modules/timemodule.c", line 1358.5: 1506-045 (S) Undeclared identifier thread_cputime_t.
"../git/python-3.9/Modules/timemodule.c", line 1359.29: 1506-045 (S) Undeclared identifier tc.
"../git/python-3.9/Modules/timemodule.c", line 1861.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed.
make: 1254-004 The error code from the last command is 1.

----------
components: Build, Library (Lib)
messages: 369335
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: thread_cputime isn't supported by AIX5
versions: Python 3.9

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

From report at bugs.python.org  Tue May 19 08:43:30 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 19 May 2020 12:43:30 +0000
Subject: [New-bugs-announce] [issue40681] shelve.open() should accept
 pathlib.Path
Message-ID: <1589892210.12.0.905216269999.issue40681@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

This should target Python3.10, current behavior is:

Python 3.10.0a0 (heads/master:19e3e00264, May 19 2020, 14:40:31) 
[Clang 11.0.3 (clang-1103.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shelve, pathlib
>>> shelve.open(pathlib.Path('spam'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/remi/src/cpython/Lib/shelve.py", line 243, in open
    return DbfilenameShelf(filename, flag, protocol, writeback)
  File "/Users/remi/src/cpython/Lib/shelve.py", line 227, in __init__
    Shelf.__init__(self, dbm.open(filename, flag), protocol, writeback)
  File "/Users/remi/src/cpython/Lib/dbm/__init__.py", line 78, in open
    result = whichdb(file) if 'n' not in flag else None
  File "/Users/remi/src/cpython/Lib/dbm/__init__.py", line 113, in whichdb
    f = io.open(filename + ".pag", "rb")
TypeError: unsupported operand type(s) for +: 'PosixPath' and 'str'
>>>

----------
components: Library (Lib)
messages: 369349
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: shelve.open() should accept pathlib.Path
type: behavior

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

From report at bugs.python.org  Tue May 19 10:32:46 2020
From: report at bugs.python.org (Micah R Ledbetter)
Date: Tue, 19 May 2020 14:32:46 +0000
Subject: [New-bugs-announce] [issue40682] random.Random.seed() with
 version=1 does not consistently match Python 2 behavior
Message-ID: <1589898766.59.0.355441549613.issue40682@roundup.psfhosted.org>


New submission from Micah R Ledbetter <me at micahrl.com>:

When using the random.Random class, using the .seed() method with version=1 does not always reproduce the same results as the .seed() method did in Python 2.

>From the docs, I did expect this, but on closer inspection, I can't tell whether I made a bad assumption or whether there is a bug in the module.

The docs state an intention of compatibility with older versions of Python:
https://docs.python.org/3.9/library/random.html#notes-on-reproducibility

> Most of the random module?s algorithms and seeding functions are subject to change across Python versions, but two aspects are guaranteed not to change:
>
> If a new seeding method is added, then a backward compatible seeder will be offered.
>
> The generator?s random() method will continue to produce the same sequence when the compatible seeder is given the same seed.

It's not clear from the docstring in the code whether this is intended to cover Python 2.7 behavior:
https://github.com/python/cpython/blob/3.9/Lib/random.py#L134

> For version 2 (the default), all of the bits are used if *a* is a str,
> bytes, or bytearray.  For version 1 (provided for reproducing random
> sequences from older versions of Python), the algorithm for str and
> bytes generates a narrower range of seeds.

But the results I've spot checked sometimes do match the Python 2 results, and sometimes are the Python 2 result +1.



I wrote a python script that calls the .seed() method with version=1 under Python 3, and without a version= argument under Python 2. It uses a wordlist I happen to have in /usr/share/dict that I copied to $PWD.

#!/usr/bin/env python
import os, random, sys
mydir = os.path.dirname(os.path.abspath(__file__))
r = random.Random()
maxidx = None
with open('{}/web2'.format(mydir)) as webdict:
  for idx, raw_word in enumerate(webdict.readlines()):
    word = raw_word.strip()
    if sys.version_info[0] == 2:
      r.seed(word)
    elif sys.version_info[0] == 3:
      r.seed(word, version=1)
    else:
      raise Exception("Unexpected python version")
    print("{}: {}".format(word, r.randrange(0, 65535, 1)))
    if maxidx != None and idx >= maxidx:
      break



I also wrote a shell script to run my Python script with the Python versions I happen to have installed locally, along with Python 2.7 and 3.4-3.9 in the ci-image Docker container linked from the Python download page.

#!/bin/sh
set -eux
mkdir -p results
/usr/bin/python test.py > results/macos10.15.4.system.python2.7.16
/Library/Frameworks/Python.framework/Versions/3.8/bin/python3 test.py > results/macos10.15.4.system.python3.8.2
docker run -v $PWD:/testpy:rw -u root -it --rm quay.io/python-devs/ci-image sh -c 'python3.9 /testpy/test.py > /testpy/results/ci-image.python3.9'
docker run -v $PWD:/testpy:rw -u root -it --rm quay.io/python-devs/ci-image sh -c 'python3.8 /testpy/test.py > /testpy/results/ci-image.python3.8'
docker run -v $PWD:/testpy:rw -u root -it --rm quay.io/python-devs/ci-image sh -c 'python3.7 /testpy/test.py > /testpy/results/ci-image.python3.7'
docker run -v $PWD:/testpy:rw -u root -it --rm quay.io/python-devs/ci-image sh -c 'python3.6 /testpy/test.py > /testpy/results/ci-image.python3.6'
docker run -v $PWD:/testpy:rw -u root -it --rm quay.io/python-devs/ci-image sh -c 'python3.5 /testpy/test.py > /testpy/results/ci-image.python3.5'
docker run -v $PWD:/testpy:rw -u root -it --rm quay.io/python-devs/ci-image sh -c 'python2.7 /testpy/test.py > /testpy/results/ci-image.python2.7'



I've made a github repo that contains both scripts and the results:
https://github.com/mrled/random-Random-seed-version-testing

I ran the script on my Mac, which means I used the system installed Python binaries that came with macOS x86_64, but the ci-image Python versions are running under an x86_64 Linux virtual machine (because of how Docker for Mac works).
 
To summarize the results:

* The Python 2.7 on my Mac works the same as the Python 2.7 on the ci-image
* The Python 3.8 on my Mac works the same as Pythons 3.5-3.9 on the ci-image
* Python 3.4 is different from both (although it is now unsupported anyway)

A sample of the results. I haven't programmatically analyzed them, but from my spot checks, they all appear to be like this:

> head results.ci-image.python2.7  |  > head results.ci-image.python3.9
A: 8866                            |  A: 8867
a: 56458                           |  a: 56459
aa: 29724                          |  aa: 29724
aal: 11248                         |  aal: 11248
aalii: 16623                       |  aalii: 16623
aam: 62302                         |  aam: 62303
Aani: 31381                        |  Aani: 31381
aardvark: 6397                     |  aardvark: 6397
aardwolf: 32525                    |  aardwolf: 32526
Aaron: 32019                       |  Aaron: 32019

----------
components: Library (Lib)
messages: 369356
nosy: mrled
priority: normal
severity: normal
status: open
title: random.Random.seed() with version=1 does not consistently match Python 2 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/issue40682>
_______________________________________

From report at bugs.python.org  Tue May 19 10:32:55 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 19 May 2020 14:32:55 +0000
Subject: [New-bugs-announce] [issue40683] Beta release does not distribute
 zoneinfo
Message-ID: <1589898775.24.0.801857102039.issue40683@roundup.psfhosted.org>


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

Apparently something is wrong with make install for beta 1 and the `zoneinfo` module is not installed with it (only _zoneinfo).

When I run a local build `./python -c "import zoneinfo"` works, but when I do `make install` I get ImportError:

  $ bin/python3 -c "import zoneinfo"
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  ModuleNotFoundError: No module named 'zoneinfo'

I assume this wasn't caught earlier because Lib/test/test_zoneinfo is *also* not being installed.

The C extension, _zoneinfo, is installed properly. I don't know if it is working on Windows.

----------
assignee: p-ganssle
messages: 369357
nosy: lukasz.langa, p-ganssle
priority: critical
severity: normal
stage: needs patch
status: open
title: Beta release does not distribute zoneinfo
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Tue May 19 11:00:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 May 2020 15:00:31 +0000
Subject: [New-bugs-announce] [issue40684] make install doesn't respect
 configure --with-platlibdir=lib64
Message-ID: <1589900431.1.0.74204081601.issue40684@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

bpo-1294959 added --with-platlibdir option to configure, but "make install" doesn't fully respect it. Example:

./configure --prefix /opt/py39b1 --with-platlibdir=lib64
make
make install

I get:

/opt/py39b1/lib/python3.9/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so

whereas Python doesn't use this directory:

$ /opt/py39b1/bin/python3.9 -m site
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
sys.path = [
    '/home/vstinner/Python-3.9.0b1',
    '/opt/py39b1/lib64/python39.zip',
    '/opt/py39b1/lib64/python3.9',
    '/opt/py39b1/lib64/lib-dynload',
    '/home/vstinner/.local/lib/python3.9/site-packages',
    '/opt/py39b1/lib64/python3.9/site-packages',
]
USER_BASE: '/home/vstinner/.local' (exists)
USER_SITE: '/home/vstinner/.local/lib/python3.9/site-packages' (exists)
ENABLE_USER_SITE: True


Python looks into /opt/py39b1/lib64/lib-dynload ("lib64")

make install writes into /opt/py39b1/lib/python3.9/lib-dynload/ ("lib")

----------
components: Build
messages: 369362
nosy: vstinner
priority: normal
severity: normal
status: open
title: make install doesn't respect configure --with-platlibdir=lib64
versions: Python 3.9

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

From report at bugs.python.org  Tue May 19 11:04:49 2020
From: report at bugs.python.org (Code436)
Date: Tue, 19 May 2020 15:04:49 +0000
Subject: [New-bugs-announce] [issue40685] IDLE not working
Message-ID: <1589900689.83.0.325441243452.issue40685@roundup.psfhosted.org>


New submission from Code436 <pwpablowills at gmail.com>:

Randomlly Python IDLE doesn't launch (not even the editor)

----------
assignee: terry.reedy
components: IDLE
messages: 369364
nosy: Coder436, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE not working
versions: Python 3.8

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

From report at bugs.python.org  Tue May 19 12:41:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 May 2020 16:41:28 +0000
Subject: [New-bugs-announce] [issue40686] Compiler warnings in _zoneinfo.c
 on Windows build in 64-bit
Message-ID: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

c:\vstinner\python\3.9\modules\_zoneinfo.c(903): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data [C:\vstinner\python\3.9\PCbuild\_ 
zoneinfo.vcxproj]
c:\vstinner\python\3.9\modules\_zoneinfo.c(904): warning C4267: '=': conversion from 'size_t' to 'unsigned int', possible loss of data [C:\vstinner\python\3.9\PCbuild\_ 
zoneinfo.vcxproj]
c:\vstinner\python\3.9\modules\_zoneinfo.c(1224): warning C4068: unknown pragma [C:\vstinner\python\3.9\PCbuild\_zoneinfo.vcxproj]
c:\vstinner\python\3.9\modules\_zoneinfo.c(1225): warning C4068: unknown pragma [C:\vstinner\python\3.9\PCbuild\_zoneinfo.vcxproj]
c:\vstinner\python\3.9\modules\_zoneinfo.c(1227): warning C4068: unknown pragma [C:\vstinner\python\3.9\PCbuild\_zoneinfo.vcxproj]
c:\vstinner\python\3.9\modules\_zoneinfo.c(1770): warning C4244: '=': conversion from 'ssize_t' to 'uint8_t', possible loss of data [C:\vstinner\python\3.9\PCbuild\_zon 
einfo.vcxproj]
c:\vstinner\python\3.9\modules\_zoneinfo.c(2408): warning C4028: formal parameter 2 different from declaration [C:\vstinner\python\3.9\PCbuild\_zoneinfo.vcxproj]

----------
components: Build
messages: 369374
nosy: p-ganssle, vstinner
priority: normal
severity: normal
status: open
title: Compiler warnings in _zoneinfo.c on Windows build in 64-bit
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue May 19 13:20:47 2020
From: report at bugs.python.org (Ben Spiller)
Date: Tue, 19 May 2020 17:20:47 +0000
Subject: [New-bugs-announce] [issue40687] Windows py.exe launcher interacts
 badly with Windows store python.exe shim
Message-ID: <1589908847.77.0.104996036032.issue40687@roundup.psfhosted.org>


New submission from Ben Spiller <spiller.ben at gmail.com>:

The py.exe launcher doc states "If no relevant options are set, the commands python and python2 will use the latest Python 2.x version installed" ... which was indeed working reliably until Microsoft added their weird python.exe shim (which either terminates with no output or brings up the Microsoft Store page) as part of https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/

Now, I find scripts that start with "#!/usr/bin/env python" cause py.exe to run the Windows python.exe shim which confusingly terminates with no output (unless run with no arguments). 

I think to stop lots of developers banging theirs heads against this brick wall, py.exe should include some logic to ignore the C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe shim, since for someone with py.exe installed, running that is _never_ what you'd want. (or alternatively, work with Microsoft to get this decision reversed, but that may be harder!)

Lots of people are hitting this e.g. https://superuser.com/questions/1437590/typing-python-on-windows-10-version-1903-command-prompt-opens-microsoft-stor , https://stackoverflow.com/questions/57485491/python-python3-executes-in-command-prompt-but-does-not-run-correctly

Here's the output:

py myscript.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\XXX\AppData\Local\py.ini' non-existent
Using global configuration file 'C:\WINDOWS\py.ini'
Called with command line: apama-build\build.py   -h
maybe_handle_shebang: read 256 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python
searching PATH for python executable
Python on path: C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe
located python on PATH: C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe
run_child: about to run 'C:\Users\XXX\AppData\Local\Microsoft\WindowsApps\python.exe myscript.py'
child process exit code: 9009

>py -0
Installed Pythons found by py Launcher for Windows
 -3.8-64 *
 -3.7-64
 -3.6-64
 -2.7-64

(nb: was surprising that it didn't run any of those installed versions!)

----------
components: Windows
messages: 369379
nosy: benspiller, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows py.exe launcher interacts badly with Windows store python.exe shim
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue May 19 15:05:35 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 19 May 2020 19:05:35 +0000
Subject: [New-bugs-announce] [issue40688] PEG Generator: Fix scripts to
 always use the correct parser
Message-ID: <1589915135.03.0.240212573029.issue40688@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

All the scripts in Tools/peg_generator/scripts need to be updated, since they mostly assume that ast.parse and compile use the old parser. We can use the _peg_parser extension module instead, but it well need some enhancements so that it also supports compilation to bytecode.

----------
assignee: lys.nikolaou
components: Demos and Tools
messages: 369381
nosy: gvanrossum, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: PEG Generator: Fix scripts to always use the correct parser
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Tue May 19 15:55:58 2020
From: report at bugs.python.org (Niels Thykier)
Date: Tue, 19 May 2020 19:55:58 +0000
Subject: [New-bugs-announce] [issue40689] The only supported minidom
 attribute iteration (NamedNodeMap) is O(n^2)
Message-ID: <1589918158.28.0.599642797497.issue40689@roundup.psfhosted.org>


New submission from Niels Thykier <niels at thykier.net>:

Hi,

The only official supported iteration over all attributes on an element via the minidom XML API require an O(n?) iterator.  It happens because the `item` method generates a list of all attribute names, look up the attribute name at the given index and then throws away the list (only to recompute it on next lookup).

There are also a `.values()` method that looks very promising, only it has "strings-attached" in the form of the following disclaimer:

"""There are also experimental methods that give this class more mapping behavior. [...]"""  
(source: https://docs.python.org/3/library/xml.dom.html)

The word "experimental" makes it hard for me to ask projects to migrate to `.values()` because I have to convince them to accept the risk of adopting the "unsupported APIs".


For me, any of the following would solve the issue:

 * Bless the mapping based API as supported to the same extend as `item` + `length` in the DOM API.

 * Optimize `item` to avoid the performance issue.

 * Provide an alternative (but supported) way of iterating over all attributes.  Preferably one that enables you to get the node directly without having to use `Element.getAttributeNode()` or similar.



The code in question highlighting the problematic code in the minidom API:

```
class NamedNodeMap(object):

[...]

    def item(self, index):
        try:
            return self[list(self._attrs.keys())[index]]
        except IndexError:
            return None
```

----------
components: XML
messages: 369384
nosy: nthykier
priority: normal
severity: normal
status: open
title: The only supported minidom attribute iteration (NamedNodeMap) is O(n^2)
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Tue May 19 16:17:05 2020
From: report at bugs.python.org (Vitalii)
Date: Tue, 19 May 2020 20:17:05 +0000
Subject: [New-bugs-announce] [issue40690] unittest: if FunctionTestCase is
 imported, the loader loads "tests" from it
Message-ID: <1589919425.78.0.0609580372109.issue40690@roundup.psfhosted.org>


New submission from Vitalii <abvit89 at gmail.com>:

In [2]: from unittest import FunctionTestCase                                                                                                                                                                                  

In [3]: loader.loadTestsFromTestCase(FunctionTestCase)                                                                                                                                                                              
Out[3]: <unittest.suite.TestSuite tests=[<unittest.case.FunctionTestCase tec=runTest>]>

In [4]: test = _._tests[0]; test 
Out[4]: <unittest.case.FunctionTestCase tec=runTest>

In [5]: test._testFunc                                                                                                                                                                                                                
Out[5]: 'runTest'

In [6]: test._testFunc.__name__                                                                                                                                                                                                       
*** AttributeError: 'str' object has no attribute '__name__'

----------
components: Tests
messages: 369386
nosy: pwtail
priority: normal
severity: normal
status: open
title: unittest: if FunctionTestCase is imported, the loader loads "tests" from it
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 19 16:57:46 2020
From: report at bugs.python.org (Chris Danis)
Date: Tue, 19 May 2020 20:57:46 +0000
Subject: [New-bugs-announce] [issue40691] misleading output from difflib
 unified_diff
Message-ID: <1589921866.61.0.952751122807.issue40691@roundup.psfhosted.org>


New submission from Chris Danis <cdanis at wikimedia.org>:

When difflib.unified_diff is asked to produce a diff of inputs a.txt and b.txt (attached), with 10 context lines, it produces the following:

--- codfw/groupLoadsBySection live
+++ codfw/groupLoadsBySection generated
@@ -90,37 +90,31 @@
     },
     "s4": {
         "api": {
             "db2106": 300,
             "db2110": 100
         },
         "contributions": {
             "db2084:3314": 100,
             "db2091:3314": 100
         },
-        "dump": {
-            "db2073": 100
-        },
-        "logpager": {
-            "db2084:3314": 100,
-            "db2091:3314": 100
-        },
-        "recentchanges": {
-            "db2084:3314": 100,
-            "db2091:3314": 100
-        },
-        "recentchangeslinked": {
-            "db2084:3314": 100,
-            "db2091:3314": 100
-        },
-        "vslow": {
-            "db2073": 100
+        "logpager": {
+            "db2084:3314": 100,
+            "db2091:3314": 100
+        },
+        "recentchanges": {
+            "db2084:3314": 100,
+            "db2091:3314": 100
+        },
+        "recentchangeslinked": {
+            "db2084:3314": 100,
+            "db2091:3314": 100
         },
         "watchlist": {
             "db2084:3314": 100,
             "db2091:3314": 100
         }
     },
     "s5": {
         "api": {
             "db2075": 300,
             "db2128": 100


However, this could simply and much more readably be rendered as:

@@ -90,38 +90,32 @@
   },
   "s4": {
     "api": {
       "db2106": 3,
       "db2110": 1
     },
     "contributions": {
       "db2084:3314": 1,
       "db2091:3314": 1
     },
-    "dump": {
-      "db2073": 1
-    },
     "logpager": {
       "db2084:3314": 1,
       "db2091:3314": 1
     },
     "recentchanges": {
       "db2084:3314": 1,
       "db2091:3314": 1
     },
     "recentchangeslinked": {
       "db2084:3314": 1,
       "db2091:3314": 1
     },
-    "vslow": {
-      "db2073": 1
-    },
     "watchlist": {
       "db2084:3314": 1,
       "db2091:3314": 1
     }
   },
   "s5": {
     "api": {
       "db2059": 1,
       "db2066": 1
     },

(This is what diff -u10 produces.)

----------
components: Library (Lib)
files: a.txt
messages: 369390
nosy: cdanis
priority: normal
severity: normal
status: open
title: misleading output from difflib unified_diff
versions: Python 3.7
Added file: https://bugs.python.org/file49171/a.txt

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

From report at bugs.python.org  Tue May 19 17:07:44 2020
From: report at bugs.python.org (Asheesh Laroia)
Date: Tue, 19 May 2020 21:07:44 +0000
Subject: [New-bugs-announce] [issue40692] Adjust test_concurrent_futures to
 run more of its tests if multiprocessing.synchronize is missing
Message-ID: <1589922464.68.0.792694033918.issue40692@roundup.psfhosted.org>


New submission from Asheesh Laroia <asheesh at asheesh.org>:

Some parts of test_concurrent_futures make sense to run even on Python builds where multiprocessing.synchronize is absent. At the moment, test_concurrent_futures.py skips all tests in the file if multiprocessing.synchronize is missing from the Python build. I have a patch to enable more tests, which I'll submit as a GitHub pull request.

The reason I want this patch is while working on CPython on Android, I saw that test_concurrent_futures refused to run its test suite, and I became very afraid that this meant that asyncio on CPython on Android was doomed. In fact, I was afraid for no reason. I want future people porting CPython to be less scared than I was. :)

I discovered that the only part of concurrent.futures that requires multiprocessing.synchronize is concurrent.futures.ProcessPoolExecutor.

concurrent.futures.ProcessPoolExecutor already has a way to check at runtime if it can work on the host system, so this patch leans on that.

This patch fixes a few other tests to skip themselves in the case that ProcessPoolExecutor cannot function.

I tested this by building CPython (with my patch) with adding a configure flag on macOS:

$ ./configure --with-pydebug --with-openssl=$(brew --prefix openssl) ac_cv_posix_semaphores_enabled=no

Why multiprocessing.synchronize is missing
------------------------------------------

multiprocessing.synchronize imports _multiprocessing.SemLock, which is based on a libc function called sem_open(), which implements named semaphores, which allows the creation of lock-esque counters that can be used from multiple processes. multiprocessing.c currently only creates the SemLock property if sem_open() is considered "working" through a check in ./configure; I've short-circuited that check above to be a "no".

On Android, sem_open() exists but simply returns ENOSYS; see its implementation here: https://android.googlesource.com/platform/external/pthreads/+/master/sem_open.c

Android isn't the only platform missing sem_open()

Past work
---------

issue3770 is an older conversation about a related issue. issue3770 has also attracted comments from someone who wants CPython's test suite to run to completion on their platform lacking sem_open() and therefore lacking multiprocessing.synchronize. This patch should solve their problem, I hope.

Future work
-----------

Automated testing: In order to prevent regressions, I'm interested in hosting a buildbot for at least one year, hopefully in perpetuity, on which we call ./configure with ac_cv_posix_semaphores_enabled=no.

I'd like to improve the error message when the user imports multiprocessing.synchronize so it points at some new documentation text that I (or someone) adds to CPython, rather than the issue number. I'm OK taking on the work of writing those docs in a follow-up issue if we merge this.

Thanks
------

Thanks to Zachary Ware for discussing this with me in an CPython contributor office hours time slot before I filed the issue. Thanks to Dr. Russell Keith-Magee, Glyph Lefkowitz, Nathaniel Smith, and Geoffrey Thomas for informal conversations and technical research.

----------
components: Tests, asyncio
messages: 369393
nosy: asheesh, asvetlov, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Adjust test_concurrent_futures to run more of its tests if multiprocessing.synchronize is missing
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Tue May 19 20:50:18 2020
From: report at bugs.python.org (Y Ono)
Date: Wed, 20 May 2020 00:50:18 +0000
Subject: [New-bugs-announce] [issue40693] pathlib.Path will be broken with
 os.chdir command.
Message-ID: <1589935818.51.0.287299786193.issue40693@roundup.psfhosted.org>


New submission from Y Ono <ono.kirin at gmail.com>:

```
import os
from pathlib import Path

os.chdir(Path(__file__).parent)
print(Path(__file__).absolute())
```
I put the code into a file in `/tmp/test.py`, and execute it from `/tmp/` directory like below. Then the output showed `/tmp/scripts/scripts/test.py`.

```
$ python scripts/test.py
/tmp/scripts/scripts/test.py
```


After executing `os.chdir`, pathlib's path handling is completely broken.

----------
components: C API
messages: 369410
nosy: Y Ono
priority: normal
severity: normal
status: open
title: pathlib.Path will be broken with os.chdir command.
versions: Python 3.8

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

From report at bugs.python.org  Wed May 20 00:47:05 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 20 May 2020 04:47:05 +0000
Subject: [New-bugs-announce] [issue40694] gen.throw() with multiple yield
 froms skips intermediate exceptions
Message-ID: <1589950025.34.0.136144385368.issue40694@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

Here is another gen.throw() exception chain example similar to the examples in issue 29587: https://bugs.python.org/issue29587

def f():
    yield

def g():
    try:
        raise RuntimeError('a')
    except Exception as exc:
        print(f'handling: {exc!r}')
        yield from f()

def h():
    try:
        raise RuntimeError('b')
    except Exception as exc:
        print(f'handling: {exc!r}')
        yield from g()

gen = h()
gen.send(None)
gen.throw(ValueError)

Output:

handling: RuntimeError('b')
handling: RuntimeError('a')
Traceback (most recent call last):
  File "/.../test.py", line 13, in h
    raise RuntimeError('b')
RuntimeError: b

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/.../test.py", line 20, in <module>
    gen.throw(ValueError)
  File "/.../test.py", line 16, in h
    yield from g()
  File "/.../test.py", line 9, in g
    yield from f()
  File "/.../test.py", line 2, in f
    yield
ValueError

The issue is that "RuntimeError: a" is skipped. It should also appear in the exception chain.

I believe this has the same root cause as issue 29590: https://bugs.python.org/issue29590

----------
components: Interpreter Core
messages: 369416
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: gen.throw() with multiple yield froms skips intermediate exceptions
versions: Python 3.10

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

From report at bugs.python.org  Wed May 20 04:07:57 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 May 2020 08:07:57 +0000
Subject: [New-bugs-announce] [issue40695] hashlib: OpenSSL hash detection
 should obey security policy
Message-ID: <1589962077.62.0.0858651561695.issue40695@roundup.psfhosted.org>


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

The hashlib module prefers hash implementations from OpenSSL. In case OpenSSL is not available or OpenSSL does not provide a hash algorithm, hashlib falls back to builtin implementations for MD5, SHA1, SHA2 family, SHA3/SHAKE family, and Blake2. The __get_openssl_constructor [1] function checks OpenSSL by retrieving the constructor and calling it. The calls fails if OpenSSL doesn't implement the EVP digest.

It also fails when the EVP digest is available but blocked by a security policy. In this case it falls back to the builtin implementation. If the builtin implementation has been removed by the package builder or --with-builtin-hashlib-hashes, then Python considers the hash algorithm as broken.

I propose to change the detection code so that Python uses OpenSSL implementation although it's blocked by the current system policy. 

Current behavior:

$ rpm -qa openssl
openssl-1.1.1g-1.fc32.x86_64
$ /configure -C --with-builtin-hashlib-hashes=blake2
$ make -j4
$ ./python
>>> import hashlib
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/root/cpython/Lib/hashlib.py", line 131, in __get_openssl_constructor
    f()
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/root/cpython/Lib/hashlib.py", line 251, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/root/cpython/Lib/hashlib.py", line 135, in __get_openssl_constructor
    return __get_builtin_constructor(name)
  File "/root/cpython/Lib/hashlib.py", line 118, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
>>> hashlib.md5()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'hashlib' has no attribute 'md5'


Proposed behavior:

$ ./python
>>> import hashlib
>>> hashlib.md5()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: [digital envelope routines: EVP_DigestInit_ex] disabled for FIPS
>>> hashlib.md5(usedforsecurity=False)
<md5 _hashlib.HASH object @ 0x7fb9d44b9b30>


Related issue:

bpo-9216 added the new hash constructor argument "usedforsecurity".
bpo-40637 added a new configure option --with-builtin-hashlib-hashes

[1] https://github.com/python/cpython/blob/97fe9cfd9f81fe96a70e1ce80fce04b0c937bfac/Lib/hashlib.py#L121-L135

----------
assignee: christian.heimes
components: Library (Lib)
messages: 369428
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
status: open
title: hashlib: OpenSSL hash detection should obey security policy
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed May 20 04:08:03 2020
From: report at bugs.python.org (Mariusz Felisiak)
Date: Wed, 20 May 2020 08:08:03 +0000
Subject: [New-bugs-announce] [issue40696] "await" hangs in Python3.9.0b1.
Message-ID: <1589962083.82.0.703924093729.issue40696@roundup.psfhosted.org>


New submission from Mariusz Felisiak <felisiak.mariusz at gmail.com>:

We noticed a behavior change in Python3.9.0b1 (it works properly in Python3.9.0a6). One of our tests `handlers.tests.AsyncHandlerRequestTests.test_suspiciousop_in_view_returns_400`[1] hangs on `await`. `/suspicious/`?is a view that raises a custom exception `SuspiciousOperation`.

[1] https://github.com/django/django/blob/8328811f048fed0dd22573224def8c65410c9f2e/tests/handlers/tests.py#L258-L260

----------
components: asyncio
messages: 369429
nosy: asvetlov, carltongibson, felixxm, yselivanov
priority: normal
severity: normal
status: open
title: "await" hangs in Python3.9.0b1.
versions: Python 3.9

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

From report at bugs.python.org  Wed May 20 06:21:58 2020
From: report at bugs.python.org (Thomas Grainger)
Date: Wed, 20 May 2020 10:21:58 +0000
Subject: [New-bugs-announce] [issue40697] add fissix as a lib2to3 alternative
Message-ID: <1589970118.75.0.588225923307.issue40697@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

now that lib2to3 is deprecated, the stdlib should point to alternatives

currently the docs point to libcst or parso, however neither is a drop-in replacement for lib2to3

the docs should add fissix as a lib2to3 alternative, because it is a drop-in replacement

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 369438
nosy: graingert
priority: normal
pull_requests: 19543
severity: normal
status: open
title: add fissix as a lib2to3 alternative
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed May 20 07:32:43 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 May 2020 11:32:43 +0000
Subject: [New-bugs-announce] [issue40698] distutils.command.upload md5_digest
Message-ID: <1589974363.4.0.0200698249561.issue40698@roundup.psfhosted.org>


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

The distutils upload command creates a MD5 digest of the file content. This is not compatible with systems with systems that run under a strict security policy that blocks MD5.

Possible fixes are:

* declare that the MD5 digest is not used for security. Security is provided by TLS/SSL and HTTPS. The digest is just a simple checksum to detect file corruption during upload.
* Remove MD5 digest completely
* Don't create a MD5 digest if ``hashlib.md5(content)`` fails
* Skip the test case if MD5 is not available

Does PyPI support other digests, e.g. SHA2-256 digest?

----------
components: Library (Lib)
messages: 369442
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: distutils.command.upload md5_digest
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed May 20 07:35:48 2020
From: report at bugs.python.org (Cristian Martinez de Morentin)
Date: Wed, 20 May 2020 11:35:48 +0000
Subject: [New-bugs-announce] [issue40699] Memory leak in threading library
 with Python 3.6-3.8
Message-ID: <1589974548.09.0.894000250375.issue40699@roundup.psfhosted.org>


New submission from Cristian Martinez de Morentin <cmartinez at das-nano.com>:

Hi everyone,

I have found a memory leak when using Queue and Condition from threading library.

The issue can be reproduced with the following code:

========================================================
import queue
import threading


class MemoryTest(threading.Thread):

    def __init__(self):
        threading.Thread.__init__(self)
        self.queue = queue.Queue()
        self.cv = threading.Condition()

    def put(self, msg):
        self.queue.put(msg)

        with self.cv:
            self.cv.notify()

    def run(self):
        while True:
            while not self.queue.empty():
                self.queue.get()
                self.queue.task_done()

            with self.cv:
                self.cv.wait_for(lambda: not self.queue.empty())
================================================================

If you run a MemoryTest object in another thread, by calling its start() method, and you send it messages by using its put() method, you will see how RAM memory usage starts increasing.

This behaviour has been observed in Windows (64 bits) with Python 3.6, 3.7 & 3.8, but not with Python 3.5.

Thank you so much.

----------
components: Windows
messages: 369443
nosy: Cristian Martinez de Morentin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Memory leak in threading library with Python 3.6-3.8
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed May 20 11:54:01 2020
From: report at bugs.python.org (Manjusaka)
Date: Wed, 20 May 2020 15:54:01 +0000
Subject: [New-bugs-announce] [issue40700] Make WSGIRequestHandler easier to
 be customized by the user
Message-ID: <1589990041.35.0.995968442309.issue40700@roundup.psfhosted.org>


New submission from Manjusaka <lizheao940510 at gmail.com>:

Hello everyone

I think we can make WSGIRequestHandler in wsgiref easier to be customized by the user

Here's the detail

the WSGIRequestHandler in wsgiref.simple_server has some code like this

class WSGIRequestHandler(BaseHTTPRequestHandler):
    def handle(self):
        """Handle a single HTTP request"""

        self.raw_requestline = self.rfile.readline(65537)
        if len(self.raw_requestline) > 65536:
            self.requestline = ''
            self.request_version = ''
            self.command = ''
            self.send_error(414)
            return

        if not self.parse_request(): # An error code has been sent, just exit
            return

        handler = ServerHandler(
            self.rfile, self.wfile, self.get_stderr(), self.get_environ(),
            multithread=False,
        )
        handler.request_handler = self      # backpointer for logging
        handler.run(self.server.get_app())

If people want just to replace the ServerHandler, they need to override all the handle method, I don't think this is a good way to use.

I prefer do something like this

class WSGIRequestHandler(BaseHTTPRequestHandler):

    server_version = "WSGIServer/" + __version__
    server_handler = ServerHandler

    def handle(self):
        """Handle a single HTTP request"""

        self.raw_requestline = self.rfile.readline(65537)
        if len(self.raw_requestline) > 65536:
            self.requestline = ''
            self.request_version = ''
            self.command = ''
            self.send_error(414)
            return

        if not self.parse_request(): # An error code has been sent, just exit
            return

        handler = self.server_handler(
            self.rfile, self.wfile, self.get_stderr(), self.get_environ(),
            multithread=False,
        )
        handler.request_handler = self      # backpointer for logging
        handler.run(self.server.get_app())

Now if people just need simple code to replace the ServerHandler, like this

class CustomWSGIRequestHandler(WSGIRequestHandler):
    server_handler = CustomeServerHandler

what do you think, I'm glad to make a PR for this

----------
components: Library (Lib)
messages: 369465
nosy: Manjusaka
priority: normal
severity: normal
status: open
title: Make WSGIRequestHandler easier to be customized by the user
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/issue40700>
_______________________________________

From report at bugs.python.org  Wed May 20 15:20:24 2020
From: report at bugs.python.org (Eric L.)
Date: Wed, 20 May 2020 19:20:24 +0000
Subject: [New-bugs-announce] [issue40701] tempfile mixes str and bytes in an
 inconsistent manner
Message-ID: <1590002424.23.0.821521735552.issue40701@roundup.psfhosted.org>


New submission from Eric L. <ewl+python at lavar.de>:

tempfile fails on mixed str and bytes when setting tempfile.tempdir to a non-existent bytes path but succeeds when set to an existing bytes path.

$ python3.9
Python 3.9.0a6 (default, Apr 28 2020, 00:00:00) 
[GCC 10.0.1 20200430 (Red Hat 10.0.1-0.14)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tempfile
>>> tempfile.tempdir = b'/doesntexist'
>>> tempfile.TemporaryFile()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.9/tempfile.py", line 615, in TemporaryFile
    (fd, name) = _mkstemp_inner(dir, prefix, suffix, flags, output_type)
  File "/usr/lib64/python3.9/tempfile.py", line 248, in _mkstemp_inner
    file = _os.path.join(dir, pre + name + suf)
  File "/usr/lib64/python3.9/posixpath.py", line 90, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib64/python3.9/genericpath.py", line 155, in _check_arg_types
    raise TypeError("Can't mix strings and bytes in path components") from None
TypeError: Can't mix strings and bytes in path components
>>> tempfile.tempdir = b'/tmp'
>>> tempfile.TemporaryFile()
<_io.BufferedRandom name=3>
>>> tempfile.mktemp()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.9/tempfile.py", line 400, in mktemp
    file = _os.path.join(dir, prefix + name + suffix)
  File "/usr/lib64/python3.9/posixpath.py", line 90, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib64/python3.9/genericpath.py", line 155, in _check_arg_types
    raise TypeError("Can't mix strings and bytes in path components") from None
TypeError: Can't mix strings and bytes in path components

It seems to me that the case of `tempfile.tempdir` being of type bytes hasn't been completely considered and is handled inconsistently. My suggestion would be to manage the paths as bytes if there is no other indication like suffix or prefix.

----------
messages: 369469
nosy: ericzolf
priority: normal
severity: normal
status: open
title: tempfile mixes str and bytes in an inconsistent manner
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/issue40701>
_______________________________________

From report at bugs.python.org  Wed May 20 15:28:14 2020
From: report at bugs.python.org (Chris Cordero)
Date: Wed, 20 May 2020 19:28:14 +0000
Subject: [New-bugs-announce] [issue40702] frozensets should not allow the |=
 operator
Message-ID: <1590002894.78.0.324397414776.issue40702@roundup.psfhosted.org>


New submission from Chris Cordero <ccordero at protonmail.com>:

Frozensets disallow the .update and the .__ior__ methods from being used, but allows the |= operator, which I think is inconsistent with the disallowed methods?.

```
foo = frozenset()
print(foo)             # frozenset()
foo.update({"hello"})  # AttributeError, expected
foo.__ior__({"hello"}) # AttributeError, expected
foo |= {"hello"}       # No error
print(foo)             # frozenset({"hello"})
```

----------
messages: 369470
nosy: cs-cordero
priority: normal
severity: normal
status: open
title: frozensets should not allow the |= operator
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed May 20 17:24:32 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 20 May 2020 21:24:32 +0000
Subject: [New-bugs-announce] [issue40703] PyType_FromSpec*() overwrites the
 type's "__module__"
Message-ID: <1590009872.3.0.237127808252.issue40703@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

The PyType_FromSpec() functions set the type's "__module__" attribute at the end:

https://github.com/python/cpython/blob/0509c4547fc95cc32a91ac446a26192c3bfdf157/Objects/typeobject.c#L3154-L3172

There are only two possible cases, either it finds a module name in the spec name and sets "__module__" from that, or it outputs a deprecation warning. Both behaviours are annoying because they ignore anything that the type already has in its dict, e.g. a property entry from the "members" or "getset" structs.

Since this code can't really be moved before the call to "PyType_Ready()" (which creates the type's dict and populates it), I think the best fix would be to first check if "__module__" is already in the dict and only otherwise take care of setting it.

I noticed this when trying to make the "__module__" attribute of Cython's coroutine type work with type specs, which should actually return the instance specific module name, i.e. the module that defines the coroutine, not the module that defines the type. This would normally be solved with an entry in "members", but that is discarded by the code above. While this approach means that the type does not have its own "__module__" entry, I think the use cases of pickling and documentation support it, because they care about the module name of the instance, not of the type.

I think working around this behaviour is somewhat easy by creating a new descriptor with PyDescr_NewMember() and re-adding it after calling PyType_FromSpec*(), so this is something that can just be fixed in Py3.9+.

Relevant tickets: issue 15146 for setting "__module__" and issue 20204 for the deprecation warning.

----------
components: C API
messages: 369476
nosy: ncoghlan, petr.viktorin, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyType_FromSpec*() overwrites the type's "__module__"
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed May 20 18:09:55 2020
From: report at bugs.python.org (Maxwell Bernstein)
Date: Wed, 20 May 2020 22:09:55 +0000
Subject: [New-bugs-announce] [issue40704] PyIter_Check fails when compiling
 in the Limited API
Message-ID: <1590012595.85.0.72566867975.issue40704@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

PyIter_Check is itself marked as available in the Limited API but:

a) it's a macro, and
b) it pokes directly at tp_iternext

This means that it's functionally impossible to use PyIter_Check
when working with the Limited API.

----------
components: C API
messages: 369479
nosy: tekknolagi
priority: normal
severity: normal
status: open
title: PyIter_Check fails when compiling in the Limited API
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu May 21 01:22:11 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 21 May 2020 05:22:11 +0000
Subject: [New-bugs-announce] [issue40705] use-after-free in _zoneinfo.c's
 module_free function
Message-ID: <1590038531.88.0.263330697524.issue40705@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

This was caught on oss-fuzz's ASAN builder:

Step #4: ==7656==ERROR: AddressSanitizer: heap-use-after-free on address 0x604001568ea0 at pc 0x7f603e4b974b bp 0x7ffe4f7e8f90 sp 0x7ffe4f7e8f88
Step #4: READ of size 8 at 0x604001568ea0 thread T0
Step #4:     #0 0x7f603e4b974a in module_free /src/cpython3/Modules/_zoneinfo.c:2610:10
Step #4:     #1 0x570311 in module_dealloc /src/cpython3/Objects/moduleobject.c:675:9
Step #4:     #2 0x57b7fc in _Py_Dealloc /src/cpython3/Objects/object.c:2209:5
Step #4:     #3 0x54ce60 in _Py_DECREF /src/cpython3/./Include/object.h:430:9
Step #4:     #4 0x551cdc in _Py_XDECREF /src/cpython3/./Include/object.h:497:9
Step #4:     #5 0x54e1b2 in insertdict /src/cpython3/Objects/dictobject.c:1129:5
Step #4:     #6 0x54d2fe in PyDict_SetItem /src/cpython3/Objects/dictobject.c:1579:12
Step #4:     #7 0x55b5dc in dict_ass_sub /src/cpython3/Objects/dictobject.c:2179:16
Step #4:     #8 0x87520f in PyObject_SetItem /src/cpython3/Objects/abstract.c:210:16
Step #4:     #9 0x6c1e89 in _PyImport_Cleanup /src/cpython3/Python/import.c:523:13
Step #4:     #10 0x6fc40a in Py_FinalizeEx /src/cpython3/Python/pylifecycle.c:1422:5
Step #4:     #11 0x4dd17a in Py_RunMain /src/cpython3/Modules/main.c:634:9
Step #4:     #12 0x4ddbea in pymain_main /src/cpython3/Modules/main.c:662:12
Step #4:     #13 0x4dde34 in Py_BytesMain /src/cpython3/Modules/main.c:686:12
Step #4:     #14 0x4dd030 in main /src/cpython3/./Programs/python.c:15:12
Step #4:     #15 0x7f60440bc82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Step #4:     #16 0x434ce8 in _start (/src/cpython3/python+0x434ce8)
Step #4: 
Step #4: 0x604001568ea0 is located 16 bytes inside of 48-byte region [0x604001568e90,0x604001568ec0)
Step #4: freed by thread T0 here:
Step #4:     #0 0x4ad20d in free /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
Step #4:     #1 0x57c493 in _PyMem_RawFree /src/cpython3/Objects/obmalloc.c:127:5
Step #4:     #2 0x57dbc2 in PyObject_Free /src/cpython3/Objects/obmalloc.c:709:5
Step #4:     #3 0x75e81a in PyObject_GC_Del /src/cpython3/Modules/gcmodule.c:2325:5
Step #4:     #4 0x5a12cd in object_dealloc /src/cpython3/Objects/typeobject.c:4008:5
Step #4:     #5 0x59abbb in subtype_dealloc /src/cpython3/Objects/typeobject.c:1371:5
Step #4:     #6 0x57b7fc in _Py_Dealloc /src/cpython3/Objects/object.c:2209:5
Step #4:     #7 0x7f603e4b0700 in _Py_DECREF /src/cpython3/./Include/object.h:430:9
Step #4:     #8 0x7f603e4b05dc in _Py_XDECREF /src/cpython3/./Include/object.h:497:9
Step #4:     #9 0x7f603e4b96de in module_free /src/cpython3/Modules/_zoneinfo.c:2609:5
Step #4:     #10 0x570311 in module_dealloc /src/cpython3/Objects/moduleobject.c:675:9
Step #4:     #11 0x57b7fc in _Py_Dealloc /src/cpython3/Objects/object.c:2209:5
Step #4:     #12 0x54ce60 in _Py_DECREF /src/cpython3/./Include/object.h:430:9
Step #4:     #13 0x551cdc in _Py_XDECREF /src/cpython3/./Include/object.h:497:9
Step #4:     #14 0x54e1b2 in insertdict /src/cpython3/Objects/dictobject.c:1129:5
Step #4:     #15 0x54d2fe in PyDict_SetItem /src/cpython3/Objects/dictobject.c:1579:12
Step #4:     #16 0x55b5dc in dict_ass_sub /src/cpython3/Objects/dictobject.c:2179:16
Step #4:     #17 0x87520f in PyObject_SetItem /src/cpython3/Objects/abstract.c:210:16
Step #4:     #18 0x6c1e89 in _PyImport_Cleanup /src/cpython3/Python/import.c:523:13
Step #4:     #19 0x6fc40a in Py_FinalizeEx /src/cpython3/Python/pylifecycle.c:1422:5
Step #4:     #20 0x4dd17a in Py_RunMain /src/cpython3/Modules/main.c:634:9
Step #4:     #21 0x4ddbea in pymain_main /src/cpython3/Modules/main.c:662:12
Step #4:     #22 0x4dde34 in Py_BytesMain /src/cpython3/Modules/main.c:686:12
Step #4:     #23 0x4dd030 in main /src/cpython3/./Programs/python.c:15:12
Step #4:     #24 0x7f60440bc82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Step #4: 
Step #4: previously allocated by thread T0 here:
Step #4:     #0 0x4ad48d in malloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
Step #4:     #1 0x57c37c in _PyMem_RawMalloc /src/cpython3/Objects/obmalloc.c:99:12
Step #4:     #2 0x57da49 in PyObject_Malloc /src/cpython3/Objects/obmalloc.c:685:12
Step #4:     #3 0x75e17c in _PyObject_GC_Alloc /src/cpython3/Modules/gcmodule.c:2233:26
Step #4:     #4 0x75e0c5 in _PyObject_GC_Malloc /src/cpython3/Modules/gcmodule.c:2260:12
Step #4:     #5 0x598619 in PyType_GenericAlloc /src/cpython3/Objects/typeobject.c:1086:15
Step #4:     #6 0x5a1922 in object_new /src/cpython3/Objects/typeobject.c:4002:12
Step #4:     #7 0x59d2c7 in type_call /src/cpython3/Objects/typeobject.c:1017:11
Step #4:     #8 0x4fbb0b in _PyObject_MakeTpCall /src/cpython3/Objects/call.c:191:18
Step #4:     #9 0x4feefa in _PyObject_VectorcallTstate /src/cpython3/./Include/cpython/abstract.h:116:16
Step #4:     #10 0x4fb5e7 in _PyObject_CallNoArgTstate /src/cpython3/./Include/internal/pycore_call.h:33:12
Step #4:     #11 0x4fdaa6 in _PyObject_CallFunctionVa /src/cpython3/Objects/call.c:515:16
Step #4:     #12 0x4fe32a in callmethod /src/cpython3/Objects/call.c:614:12
Step #4:     #13 0x4fe193 in PyObject_CallMethod /src/cpython3/Objects/call.c:634:24
Step #4:     #14 0x7f603e4b91b1 in new_weak_cache /src/cpython3/Modules/_zoneinfo.c:2483:9
Step #4:     #15 0x7f603e4b95ec in initialize_caches /src/cpython3/Modules/_zoneinfo.c:2503:31
Step #4:     #16 0x7f603e4b0905 in zoneinfomodule_exec /src/cpython3/Modules/_zoneinfo.c:2669:9
Step #4:     #17 0x56ea8a in PyModule_ExecDef /src/cpython3/Objects/moduleobject.c:399:23
Step #4:     #18 0x6c8e0d in exec_builtin_or_dynamic /src/cpython3/Python/import.c:2242:12
Step #4:     #19 0x6c8d30 in _imp_exec_dynamic_impl /src/cpython3/Python/import.c:2316:12
Step #4:     #20 0x6c7c15 in _imp_exec_dynamic /src/cpython3/Python/clinic/import.c.h:358:21
Step #4:     #21 0x8cca28 in cfunction_vectorcall_O /src/cpython3/Objects/methodobject.c:510:24
Step #4:     #22 0x4fc8b4 in PyVectorcall_Call /src/cpython3/Objects/call.c:230:16
Step #4:     #23 0x4fc9b3 in _PyObject_Call /src/cpython3/Objects/call.c:265:16
Step #4:     #24 0x4fcb20 in PyObject_Call /src/cpython3/Objects/call.c:292:12
Step #4:     #25 0x679ff0 in do_call_core /src/cpython3/Python/ceval.c
Step #4:     #26 0x66942a in _PyEval_EvalFrameDefault /src/cpython3/Python/ceval.c:3607:22
Step #4:     #27 0x661fce in _PyEval_EvalFrame /src/cpython3/./Include/internal/pycore_ceval.h:40:12
Step #4:     #28 0x67b5a7 in _PyEval_EvalCode /src/cpython3/Python/ceval.c:4354:14
Step #4:     #29 0x4fce97 in _PyFunction_Vectorcall /src/cpython3/Objects/call.c:395:12

https://oss-fuzz-build-logs.storage.googleapis.com/log-42158c8c-476d-482a-ab04-75ea905e483c.txt

Sending out a patch shortly.

----------
components: Library (Lib)
messages: 369494
nosy: ammar2, p-ganssle
priority: normal
severity: normal
status: open
title: use-after-free in _zoneinfo.c's module_free function
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Thu May 21 02:08:42 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 21 May 2020 06:08:42 +0000
Subject: [New-bugs-announce] [issue40706] Unreachable code in
 _PyEval_EvalCode
Message-ID: <1590041322.58.0.905354707279.issue40706@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

When I was looking into https://bugs.python.org/issue40679, I couldn't come up with a test case for the following block, so I added a print statement:

--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -4179,6 +4179,7 @@ _PyEval_EvalCode(PyThreadState *tstate,
         Py_ssize_t j;

         if (keyword == NULL || !PyUnicode_Check(keyword)) {
+            printf("THIS CODE WAS RUN!\n");
             _PyErr_Format(tstate, PyExc_TypeError,
                           "%U() keywords must be strings",
                           qualname);

I ran the entire test suite and got no such "THIS CODE WAS RUN!". It looks like this is a double-check of the (worse -- no function name) error message produced by the changes at https://github.com/python/cpython/commit/0567786d26348aa7eaf0ab1b5d038fdabe409d92. For example:

    py -3.7 -c "f = lambda x: None; f(**{1:1})"
      ...
    TypeError: <lambda>() keywords must be strings

    py -3.8 -c "f = lambda x: None; f(**{1:1})"
      ...
    TypeError: <lambda>() keywords must be strings

    py -3.9 -c "f = lambda x: None; f(**{1:1})"
      ...
    TypeError: keywords must be strings

So:

* Can this check be eliminated since it's unreachable from Python?

* Otherwise, is there some reason a C caller would need this check? And could it be replaced by and assert?

* If it shouldn't change, then is there a good way to add test coverage?

----------
components: Interpreter Core
messages: 369498
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: Unreachable code in _PyEval_EvalCode
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu May 21 03:34:10 2020
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 21 May 2020 07:34:10 +0000
Subject: [New-bugs-announce] [issue40707] Popen.communicate documentation
 does not say how to get the return code
Message-ID: <1590046450.27.0.873343730184.issue40707@roundup.psfhosted.org>


New submission from Gareth Rees <gdr at garethrees.org>:

When using subprocess.Popen.communicate(), it is natural to wonder how to get
the exit code of the subprocess. However, the documentation [1] says:

    Interact with process: Send data to stdin. Read data from stdout and
    stderr, until end-of-file is reached. Wait for process to terminate. The
    optional input argument should be data to be sent to the child process, or
    None, if no data should be sent to the child. If streams were opened in
    text mode, input must be a string. Otherwise, it must be bytes.

    communicate() returns a tuple (stdout_data, stderr_data). The data will be
    strings if streams were opened in text mode; otherwise, bytes.

If you can guess that communicate() might set returncode, then you can find
what you need in the documentation for that attribute [2]:

    The child return code, set by poll() and wait() (and indirectly by
    communicate()).

I suggest that the documentation for communicate() be updated to mention that
it sets the returncode attribute. This would be consistent with poll() and
wait(), which already mention this.

[1]: https://docs.python.org/3/library/subprocess.html#subprocess.Popen.communicate
[2]: https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncode

----------
assignee: docs at python
components: Documentation
messages: 369502
nosy: docs at python, gdr at garethrees.org
priority: normal
severity: normal
status: open
title: Popen.communicate documentation does not say how to get the return code
type: enhancement
versions: Python 3.10, 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/issue40707>
_______________________________________

From report at bugs.python.org  Thu May 21 04:19:13 2020
From: report at bugs.python.org (Sanmitha)
Date: Thu, 21 May 2020 08:19:13 +0000
Subject: [New-bugs-announce] [issue40708] Malfunctioning of '\r'
Message-ID: <1590049153.19.0.498279112117.issue40708@roundup.psfhosted.org>


New submission from Sanmitha <sanmithasadhishkumar at gmail.com>:

'\r' in python 3.7.2, 3.7.4, 3.8.2, 2.x versions doesn't give the desired output
Eg:
print("computer\rscience")
The expected output of the above code is : sciencer
But it displays : computerscience without functioning of \r

----------
assignee: terry.reedy
components: IDLE
messages: 369504
nosy: Sanmitha, terry.reedy
priority: normal
severity: normal
status: open
title: Malfunctioning of '\r'
type: performance
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu May 21 05:17:19 2020
From: report at bugs.python.org (Sanmitha)
Date: Thu, 21 May 2020 09:17:19 +0000
Subject: [New-bugs-announce] [issue40709] Malfunctioning of '\r'
Message-ID: <1590052639.86.0.84675192196.issue40709@roundup.psfhosted.org>


New submission from Sanmitha <sanmithasadhishkumar at gmail.com>:

The escape sequence '\r' (carriage return) doesn't function in 3.x and 2.x versions.
Eg:
print("computer\rscience")
Expected output : sciencer
But, it displays computerscience without the functioning of'\r'

----------
assignee: terry.reedy
components: IDLE
files: error
messages: 369508
nosy: Sanmitha, terry.reedy
priority: normal
severity: normal
status: open
title: Malfunctioning of '\r'
type: performance
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49174/error

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

From report at bugs.python.org  Thu May 21 05:41:08 2020
From: report at bugs.python.org (Sanmitha)
Date: Thu, 21 May 2020 09:41:08 +0000
Subject: [New-bugs-announce] [issue40710] Malfunctioning of '\r'
Message-ID: <1590054068.64.0.707147540706.issue40710@roundup.psfhosted.org>


Change by Sanmitha <sanmithasadhishkumar at gmail.com>:


----------
assignee: terry.reedy
components: IDLE
nosy: Sanmitha Sadhishkumar, terry.reedy
priority: normal
severity: normal
status: open
title: Malfunctioning of '\r'
type: performance
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu May 21 05:45:36 2020
From: report at bugs.python.org (Sanmitha)
Date: Thu, 21 May 2020 09:45:36 +0000
Subject: [New-bugs-announce] [issue40711] Clearing the screen of IDLE
 interactive mode in Windows
Message-ID: <1590054336.96.0.00702534454231.issue40711@roundup.psfhosted.org>


Change by Sanmitha <sanmithasadhishkumar at gmail.com>:


----------
assignee: terry.reedy
components: IDLE
nosy: Sanmitha Sadhishkumar, terry.reedy
priority: normal
severity: normal
status: open
title: Clearing the screen of IDLE interactive mode in Windows
type: performance
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu May 21 07:02:48 2020
From: report at bugs.python.org (radkujawa)
Date: Thu, 21 May 2020 11:02:48 +0000
Subject: [New-bugs-announce] [issue40712] fstrings are not docstrings
Message-ID: <1590058968.97.0.0636260387213.issue40712@roundup.psfhosted.org>


New submission from radkujawa <radek_kujawa at o2.pl>:

see example:

>>> def f():
...     f"""asdf"""
...     pass
... 
>>> f.__doc__
>>> def f():
...     """asdf"""
...     pass
... 
>>> f.__doc__
'asdf'
>>>

----------
components: Tests
messages: 369518
nosy: radkujawa
priority: normal
severity: normal
status: open
title: fstrings are not docstrings
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu May 21 09:47:59 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 21 May 2020 13:47:59 +0000
Subject: [New-bugs-announce] [issue40713] _zoneinfo.c can use dst_offset
 without initialization in parse_tz_str()
Message-ID: <1590068879.49.0.231802096396.issue40713@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Here's the warning given by clang:


/Users/remi/src/cpython/Modules/_zoneinfo.c:1487:9: warning: variable 'dst_offset' is used uninitialized whenever 'if'
      condition is true [-Wsometimes-uninitialized]
    if (*p == '\0') {
        ^~~~~~~~~~
/Users/remi/src/cpython/Modules/_zoneinfo.c:1544:50: note: uninitialized use occurs here
    build_tzrule(std_abbr, dst_abbr, std_offset, dst_offset, start, end, out);
                                                 ^~~~~~~~~~
/Users/remi/src/cpython/Modules/_zoneinfo.c:1487:5: note: remove the 'if' if its condition is always false
    if (*p == '\0') {
    ^~~~~~~~~~~~~~~~~
/Users/remi/src/cpython/Modules/_zoneinfo.c:1460:32: note: initialize the variable 'dst_offset' to silence this warning
    long std_offset, dst_offset;
                               ^
                                = 0
/Users/remi/src/cpython/Modules/_zoneinfo.c:1910:19: warning: suggest braces around initialization of subobject
      [-Wmissing-braces]
    _tzrule rv = {0};
                  ^
                  {}

Looking at the code path, the unitialized dst_offset may create a ZoneInfo with a garbage value in dstoff with some inputs so this should be backported to Python3.9 too.

----------
components: Library (Lib)
messages: 369523
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: _zoneinfo.c can use dst_offset without initialization in parse_tz_str()
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu May 21 11:54:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 21 May 2020 15:54:27 +0000
Subject: [New-bugs-announce] [issue40714] Remove compile warning from
 _zoneinfo.c
Message-ID: <1590076467.03.0.601843943956.issue40714@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

/Users/corona10/oss/cpython/Modules/_zoneinfo.c:1487:9: warning: variable
      'dst_offset' is used uninitialized whenever 'if' condition is true
      [-Wsometimes-uninitialized]
    if (*p == '\0') {
        ^~~~~~~~~~
/Users/corona10/oss/cpython/Modules/_zoneinfo.c:1544:50: note: uninitialized use
      occurs here
    build_tzrule(std_abbr, dst_abbr, std_offset, dst_offset, start, end, out);
                                                 ^~~~~~~~~~
/Users/corona10/oss/cpython/Modules/_zoneinfo.c:1487:5: note: remove the 'if' if
      its condition is always false
    if (*p == '\0') {
    ^~~~~~~~~~~~~~~~~
/Users/corona10/oss/cpython/Modules/_zoneinfo.c:1460:32: note: initialize the
      variable 'dst_offset' to silence this warning
    long std_offset, dst_offset;
                               ^
                                = 0
/Users/corona10/oss/cpython/Modules/_zoneinfo.c:1910:19: warning: suggest braces
      around initialization of subobject [-Wmissing-braces]
    _tzrule rv = {0};
                  ^
                  {}

----------
messages: 369525
nosy: corona10
priority: normal
severity: normal
status: open
title: Remove compile warning from _zoneinfo.c
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu May 21 12:37:08 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 21 May 2020 16:37:08 +0000
Subject: [New-bugs-announce] [issue40715] Pegen: dict unpacking inside dict
 comprehension
Message-ID: <1590079028.52.0.440007809854.issue40715@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

>>> {**{} for a in [1]}
ValueError: field 'key' is required for DictComp

should be

>>> {**{} for a in [1]}
  File "<stdin>", line 1
    {**{} for a in [1]}
     ^
SyntaxError: dict unpacking cannot be used in dict comprehension

----------
messages: 369527
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Pegen: dict unpacking inside dict comprehension

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

From report at bugs.python.org  Thu May 21 13:44:28 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 21 May 2020 17:44:28 +0000
Subject: [New-bugs-announce] [issue40716] Pegen: improve error messages for
 unparenthesized from imports with trailing comma
Message-ID: <1590083068.82.0.382306142044.issue40716@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

$ python
Python 3.10.0a0 (heads/bpo-xxxxx:f2947e354c, May 21 2020, 18:54:57) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from x import y,
  File "<stdin>", line 1
    from x import y,
                    ^
SyntaxError: invalid syntax
>>> 
(.venv) (Python 3.10.0a0) [  8:44?S ]  [ isidentical at x200:~/cpython/cpython(bpo-xxxxx?) ]
 $ python -X oldparser
Python 3.10.0a0 (heads/bpo-xxxxx:f2947e354c, May 21 2020, 18:54:57) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from x import y,
  File "<stdin>", line 1
SyntaxError: trailing comma not allowed without surrounding parentheses

----------
messages: 369530
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Pegen: improve error messages for unparenthesized from imports with trailing comma

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

From report at bugs.python.org  Thu May 21 14:17:25 2020
From: report at bugs.python.org (Hanno Boeck)
Date: Thu, 21 May 2020 18:17:25 +0000
Subject: [New-bugs-announce] [issue40717] pl.python.org has expired cert and
 links to nonexistent django.pl page
Message-ID: <1590085045.87.0.531667812908.issue40717@roundup.psfhosted.org>


New submission from Hanno Boeck <hanno at hboeck.de>:

I'm not sure if this is a good place to report this, but I haven't found a separate bug tracker or feedback contact for the webpages.

https://pl.python.org/
has an expired certificate and it contains a prominent link to django.pl, which itself returns a DNS SERVFAIL error.

----------
assignee: docs at python
components: Documentation
messages: 369531
nosy: docs at python, hanno
priority: normal
severity: normal
status: open
title: pl.python.org has expired cert and links to nonexistent django.pl page

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

From report at bugs.python.org  Thu May 21 15:25:54 2020
From: report at bugs.python.org (jakirkham)
Date: Thu, 21 May 2020 19:25:54 +0000
Subject: [New-bugs-announce] [issue40718] Support out-of-band pickling for
 builtin types
Message-ID: <1590089154.09.0.42583865069.issue40718@roundup.psfhosted.org>


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

It would be nice (where possible) to support out-of-band pickling of builtin `bytes`-like types. This would allow binary data from these objects to be shipped along separately zero-copy and later reconstructed during unpickling.

It seems that `bytes`, `bytearray`, and `array` would be good candidates for this behavior. Not sure if `mmap` or `memoryview` would make sense as it might not be clear on how to reconstruct them during unpickling, but if someone sees a way those would be nice to support too.

To illustrate this a bit, here is the behavior with a `bytes` object today:

```
In [1]: import pickle

In [2]: b = b"abc"

In [3]: l = []

In [4]: p = pickle.dumps(b, protocol=5, buffer_callback=l.append)

In [5]: l
Out[5]: []
```

With this change, we would see this behavior instead:

```
In [1]: import pickle

In [2]: b = b"abc"

In [3]: l = []

In [4]: p = pickle.dumps(b, protocol=5, buffer_callback=l.append)

In [5]: l
Out[5]: [<pickle.PickleBuffer at 0x10efe7540>]
```

(This is my first Python bug submission. So apologies if I got turned around here. Please go easy on me :)

----------
messages: 369533
nosy: jakirkham
priority: normal
severity: normal
status: open
title: Support out-of-band pickling for builtin types
type: performance
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu May 21 16:40:39 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Thu, 21 May 2020 20:40:39 +0000
Subject: [New-bugs-announce] [issue40719] Add pt-br to the language switcher
 at the Python 3.6 and 2.7 docs website
Message-ID: <1590093639.24.0.0882809667446.issue40719@roundup.psfhosted.org>


New submission from Rafael Fontenelle <rffontenelle at gmail.com>:

Thanks to bpo-38592, pt-br is listed in 3.8 and 3.7 versions.  Now, pt-br team's repository has 3.6 and 2.7 branches daily pomerged from 3.8 branch.  So, I believe it would nice to have it in those older versions' language switcher.

----------
assignee: docs at python
components: Documentation
messages: 369540
nosy: docs at python, rffontenelle
priority: normal
severity: normal
status: open
title: Add pt-br to the language switcher at the Python 3.6 and 2.7 docs website
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu May 21 17:32:53 2020
From: report at bugs.python.org (Marten H. van Kerkwijk)
Date: Thu, 21 May 2020 21:32:53 +0000
Subject: [New-bugs-announce] [issue40720] accessing mmap of file that is
 overwritten causes bus error
Message-ID: <1590096773.09.0.253309734553.issue40720@roundup.psfhosted.org>


New submission from Marten H. van Kerkwijk <mhvk at astro.utoronto.ca>:

While debugging a strange failure with tests and np.memmap, I realized that the following direct use of mmap reliably leads to a bus error. Here, obviously mmap'ing a file, closing it, opening the file for writing but not writing anything, and then again accessing the mmap is not something one should do (but a test case did it anyway), but it would nevertheless be nice to avoid a crash!
```
import mmap


with open('test.dat', 'wb') as fh:
    fh.write(b'abcdefghijklmnopqrstuvwxyz')


with open('test.dat', 'rb') as fh:
    mm = mmap.mmap(fh.fileno(), 0, access=mmap.ACCESS_READ)


with open('test.dat', 'wb') as fh:
    pass  # Note: if something is written, then I get no bus error.


mm[2]
```

----------
components: Library (Lib)
messages: 369543
nosy: mhvk
priority: normal
severity: normal
status: open
title: accessing mmap of file that is overwritten causes bus error
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu May 21 17:42:56 2020
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 21 May 2020 21:42:56 +0000
Subject: [New-bugs-announce] [issue40721] PEP0435 (enums) -- there is no
 standard on enum item letters case
Message-ID: <1590097376.47.0.46238939319.issue40721@roundup.psfhosted.org>


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

Example from PEP0435:

(https://www.python.org/dev/peps/pep-0435)

>>> from enum import Enum
>>> class Color(Enum):
...     red = 1
...     green = 2
...     blue = 3

Example from Python documentation:

(https://docs.python.org/3/library/enum.html)

>>> from enum import Enum
>>> class Color(Enum):
...     RED = 1
...     GREEN = 2
...     BLUE = 3
...

So, what are the rules for naming enum members?
CamelCase ? snake_case ? ALL_CAPS ?

Someone should explain how should we format sources. So various linters may check for that.

----------
assignee: docs at python
components: Documentation
messages: 369544
nosy: docs at python, socketpair
priority: normal
severity: normal
status: open
title: PEP0435 (enums) -- there is no standard on enum item letters case
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu May 21 18:49:42 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 21 May 2020 22:49:42 +0000
Subject: [New-bugs-announce] [issue40722] test_ttk_guionly times out on
 Ubuntu CI
Message-ID: <1590101382.1.0.392017281749.issue40722@roundup.psfhosted.org>


New submission from Dennis Sweeney <sweeney.dennis650 at gmail.com>:

One of the tests (test_ttk_guionly.test_variable_change) on the Ubuntu CI is intermittently hanging on this code:

    https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/tkinter/test/test_ttk/test_extensions.py#L147

    def test_variable_change(self):
        x = ttk.LabeledScale(self.root)
        x.pack()
        x.wait_visibility()
        ^^^^^^^^^^^^^^^^^^^

The failure at https://github.com/python/cpython/runs/697113653 gave the logs:

    0:28:29 load avg: 0.00 [425/425/1] test_ttk_guionly crashed (Exit code 1)
    Timeout (0:20:00)!
    Thread 0x00007fa268d0c080 (most recent call first):
    File "/home/runner/work/cpython/cpython/Lib/tkinter/__init__.py", line 697 in wait_visibility
    File "/home/runner/work/cpython/cpython/Lib/tkinter/test/test_ttk/test_extensions.py", line 147 in test_variable_change
    ...

The same did not happen when I re-ran the CI checks. I thought I remembered a similar issue in the past, but I couldn't find an bpo issue about it.

----------
components: Tkinter
messages: 369549
nosy: Dennis Sweeney
priority: normal
severity: normal
status: open
title: test_ttk_guionly times out on Ubuntu CI
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri May 22 00:07:15 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 May 2020 04:07:15 +0000
Subject: [New-bugs-announce] [issue40723] IDLE: make autocomplete test run
 without __main__.__file__
Message-ID: <1590120435.83.0.2126629623.issue40723@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

import test.test_idle as ti
import unittest as u
u.main(ti)

has one failure:
Traceback (most recent call last):
  File "C:\Programs\Python39\lib\idlelib\idle_test\test_autocomplete.py", line 230, in test_fetch_completions
    if __main__.__file__ != ac.__file__:
AttributeError: module '__main__' has no attribute '__file__'

ac = autocomplete. The condition is followed by 
            self.assertNotIn('AutoComplete', small)  # See issue 36405

which is false when ac is run as main to run the test.  Adding "hasattr(__main__, '__file__') and " to the beginning of the condition should be sufficient.  I should add a note to #36405 explaining this conditional assertion better.

----------
assignee: terry.reedy
components: IDLE
messages: 369555
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: make autocomplete test run without __main__.__file__
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 22 03:51:02 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 22 May 2020 07:51:02 +0000
Subject: [New-bugs-announce] [issue40724] Support buffer protocol with type
 specs
Message-ID: <1590133862.04.0.206694262407.issue40724@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

As far as I can see it in typeslots.h [1], the buffer protocol is still not supported when using type specs:

/* Disabled, see #10181 */
#undef Py_bf_getbuffer
#undef Py_bf_releasebuffer

It seems that the discussion in issue 10181 did not lead anywhere at the time (2010-2012).

I'm not talking about the limited API or the stable ABI here, I'm talking about using type specs to define an extension type. The work-around is to manually set "PyTypeObject->tp_as_buffer" after creating the type, but since PyType_Ready() then does not see that struct pointer, you also still have to make sure that the type correctly inherits the slots from the base type if you're not defining all of them yourself.

Can we just add support for the above slots?

[1] https://github.com/python/cpython/blob/ca829102213c466ffecb1e464be5c8cb3967d961/Include/typeslots.h#L2-L4

----------
components: C API
messages: 369561
nosy: ncoghlan, paul.moore, petr.viktorin, pitrou, scoder, skrah, vstinner
priority: normal
severity: normal
status: open
title: Support buffer protocol with type specs
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri May 22 03:59:27 2020
From: report at bugs.python.org (=?utf-8?q?Jakub_Ber=C3=A1nek?=)
Date: Fri, 22 May 2020 07:59:27 +0000
Subject: [New-bugs-announce] [issue40725] Documentation: Benchmark table in
 "What's new in Python 3.9" has weird values
Message-ID: <1590134367.99.0.352272483553.issue40725@roundup.psfhosted.org>


New submission from Jakub Ber?nek <berykubik at gmail.com>:

The "What's new in Python 3.9" page displays a table with microbenchmark results between different Python version (https://docs.python.org/3.9/whatsnew/3.9.html#optimizations).

The values provided for Python 3.4 are suspicious, as they are several times smaller than all following Python versions. Therefore it looks like Python got much slower in the recent releases, although the opposite is probably true.

----------
assignee: docs at python
components: Documentation
messages: 369563
nosy: Jakub Ber?nek, docs at python
priority: normal
severity: normal
status: open
title: Documentation: Benchmark table in "What's new in Python 3.9" has weird values
versions: Python 3.9

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

From report at bugs.python.org  Fri May 22 04:34:59 2020
From: report at bugs.python.org (gaborbernat)
Date: Fri, 22 May 2020 08:34:59 +0000
Subject: [New-bugs-announce] [issue40726] ast.Call end_lineno is defined and
 returns None
Message-ID: <1590136499.66.0.128776260794.issue40726@roundup.psfhosted.org>


New submission from gaborbernat <gaborjbernat at gmail.com>:

Reporting an issue from https://github.com/xonsh/xonsh/issues/3581; boils down to, ast.Call used to not define end_lineno in 3.8:

py -3.8 -c 'import ast; type(ast.Call().end_lineno)'                                                                                                                                                                 Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'Call' object has no attribute 'end_lineno'

However in 3.9 is defined with None:

py -3.9 -c 'import ast; type(ast.Call().end_lineno)'

This messes with some other operations in ast, namely https://github.com/python/cpython/blob/master/Lib/ast.py#L233

----------
messages: 369567
nosy: gaborbernat
priority: normal
severity: normal
status: open
title: ast.Call end_lineno is defined and returns None
versions: Python 3.9

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

From report at bugs.python.org  Fri May 22 05:29:10 2020
From: report at bugs.python.org (Recursing)
Date: Fri, 22 May 2020 09:29:10 +0000
Subject: [New-bugs-announce] [issue40727] SSLContext.load_verify_locations
 leaks memory on Linux in async code
Message-ID: <1590139750.66.0.29133421121.issue40727@roundup.psfhosted.org>


New submission from Recursing <buonanno.lorenzo at gmail.com>:

Minimal code to reproduce:
```
import ssl
import certifi
import gc
import asyncio


ca_path = certifi.where()
async def make_async_context() -> None:
    context = ssl.SSLContext(ssl.PROTOCOL_TLS)
    context.load_verify_locations(ca_path)
    await asyncio.sleep(1)


async def main(n: int) -> None:
    await asyncio.wait([make_async_context() for _ in range(n)])


gc.collect()
asyncio.run(main(2000))
input("Finished run, still using lots of memory :(")
gc.collect()
input("gc.collect() does not help :(")
```

Running this code on several linux machines (with python from 3.6.9 to 3.9.0a5, and openSSL from 1.1.1  11 Sep 2018 to 1.1.1g  21 Apr 2020) causes a significant memory leak, while on windows memory usage peaks around 1 GB but gets freed

----------
assignee: christian.heimes
components: Library (Lib), SSL, asyncio
messages: 369573
nosy: Recursing, asvetlov, christian.heimes, yselivanov
priority: normal
severity: normal
status: open
title: SSLContext.load_verify_locations leaks memory on Linux in async code
type: resource usage
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 22 06:59:11 2020
From: report at bugs.python.org (Oleksandr Suvorov)
Date: Fri, 22 May 2020 10:59:11 +0000
Subject: [New-bugs-announce] [issue40728] UnboundLocalError as a result of
 except statement variable re-assignment
Message-ID: <1590145151.0.0.634189101704.issue40728@roundup.psfhosted.org>


New submission from Oleksandr Suvorov <susliko at gmail.com>:

def foo(exc):
   try:
       1/0
   except Exception as exc:
       ...
   finally:
       return exc

foo(1)

Executing the following code results in UnboundLocalError, while exc has been defined and passed to a function explicitly.

I think this is something similar to python2 issue when list comprehensions where overwriting local variable values, expected behaviour in here is that foo(1) returns 1

----------
components: Interpreter Core
messages: 369588
nosy: oleksandr.suvorov
priority: normal
severity: normal
status: open
title: UnboundLocalError as a result of except statement variable re-assignment
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri May 22 09:37:06 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 22 May 2020 13:37:06 +0000
Subject: [New-bugs-announce] [issue40729] Update the list of auto-generated
 files in .gitattributes
Message-ID: <1590154626.16.0.942670011687.issue40729@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Update the list of auto-generated files in .gitattributes

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

From report at bugs.python.org  Fri May 22 10:39:35 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 22 May 2020 14:39:35 +0000
Subject: [New-bugs-announce] [issue40730] Odd sentence in 3.9 What's New
Message-ID: <1590158375.86.0.395536416991.issue40730@roundup.psfhosted.org>


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

https://docs.python.org/3.9/whatsnew/3.9.html#optimizations has this sentence: "Unlike to the := operator this idiom does not leak a variable to the outer scope.". I'm not exactly sure what it should be. Probably the first "to" should be deleted?

----------
assignee: docs at python
components: Documentation
messages: 369607
nosy: docs at python, eric.smith
priority: normal
severity: normal
status: open
title: Odd sentence in 3.9 What's New
versions: Python 3.9

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

From report at bugs.python.org  Fri May 22 11:12:00 2020
From: report at bugs.python.org (Vinicius Henrique Silva Bastos)
Date: Fri, 22 May 2020 15:12:00 +0000
Subject: [New-bugs-announce] [issue40731] CWI url's protocol on LICENSE file
 from http to https
Message-ID: <1590160320.55.0.258105896385.issue40731@roundup.psfhosted.org>


New submission from Vinicius Henrique Silva Bastos <bastosvinicius at live.com>:

CWI url's protocol on LICENSE file from http to https

from: http://www.cwi.nl
to: https://www.cwi.nl

Obs.: Learning about pull requests and how it works.

----------
assignee: docs at python
components: Documentation
files: LICENSE
hgrepos: 388
messages: 369610
nosy: bastosvinicius, docs at python
priority: normal
severity: normal
status: open
title: CWI url's protocol on LICENSE file from http to https
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49181/LICENSE

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

From report at bugs.python.org  Fri May 22 14:31:28 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 22 May 2020 18:31:28 +0000
Subject: [New-bugs-announce] [issue40732] New realpath breaks setuptools_scm
Message-ID: <1590172288.82.0.9827381954.issue40732@roundup.psfhosted.org>


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

I've encountered an apparent regression on Python 3.8 on Windows when the current working directory is in a symlink to another volume and one runs `setup.py develop` on a project using setuptools_scm (https://github.com/pypa/setuptools_scm/issues/436).

I suspect the issue stems from changes in issue9949 and is likely a manifestation of the issues articulated by Eryk in issue9949#msg350138.

----------
components: Windows
keywords: 3.8regression
messages: 369629
nosy: jaraco, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: New realpath breaks setuptools_scm
versions: Python 3.8

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

From report at bugs.python.org  Fri May 22 16:27:42 2020
From: report at bugs.python.org (paul rubin)
Date: Fri, 22 May 2020 20:27:42 +0000
Subject: [New-bugs-announce] [issue40733] mention IDLE in main python ocs
 page
Message-ID: <1590179262.31.0.599943692588.issue40733@roundup.psfhosted.org>


New submission from paul rubin <phr-pythonbugs at nightsong.com>:

The IDLE documentation is in https://docs.python.org/3/library/idle.html which is not where I'd have thought to look for it, since I think of IDLE as an application rather than a library.  So I looked for it on the main docs page, docs.python.org, and didn't find it there.  I ended up finding it by web search.  

I guess its current location is reasonable, but maybe a link to it could be included in docs.python.org's main page left side navigation panel, or IDLE could simply be mentioned in the entry for library documentation.

----------
assignee: docs at python
components: Documentation
messages: 369640
nosy: docs at python, phr
priority: normal
severity: normal
status: open
title: mention IDLE in main python ocs page
type: enhancement

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

From report at bugs.python.org  Fri May 22 16:35:21 2020
From: report at bugs.python.org (paul rubin)
Date: Fri, 22 May 2020 20:35:21 +0000
Subject: [New-bugs-announce] [issue40734] /usr/bin surprisingly in sys.path
 under IDLE
Message-ID: <1590179721.27.0.0407406629035.issue40734@roundup.psfhosted.org>


New submission from paul rubin <phr-pythonbugs at nightsong.com>:

This is in the standard python 3.7.3 install under Debian 10.  It's possible that this is on purpose, and it's (separately) possible that the Debian packagers did this for some reason.  I'm not sure it's a bug but am reporting it as it's an oddity that might warrant looking into.

When I look at sys.path in the IDLE shell, the path includes /usr/bin, which is not there under the normal python prompt.  Since /usr/bin is not a place where python modules usually live, it's a bit strange to find it on the path.  It doesn't seem healthy since it could lead to surprises.  But maybe I'm missing something.

Feel free to close this if the inclusion is intentional.

----------
assignee: terry.reedy
components: IDLE
messages: 369643
nosy: phr, terry.reedy
priority: normal
severity: normal
status: open
title: /usr/bin surprisingly in sys.path under IDLE
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri May 22 17:07:45 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 May 2020 21:07:45 +0000
Subject: [New-bugs-announce] [issue40735] test_nntplib: sporadic failures,
 NetworkedNNTP_SSLTests.test_with_statement
Message-ID: <1590181665.98.0.604811088124.issue40735@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

A sporadic failure of test_nntplib.NetworkedNNTP_SSLTests.test_with_statement on the CI for macOS:
https://github.com/python/cpython/pull/20321/checks?check_run_id=700729471#step:6:612

See also:
* https://bugs.python.org/issue19613 (test_article_head_body)
* https://bugs.python.org/issue19756 (test_capabilities)

ERROR: test_with_statement (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 277, in test_with_statement
    server = self.NNTP_CLASS(self.NNTP_HOST,
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 1025, in __init__
    super().__init__(host, port, user, password, readermode,
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 334, in __init__
    self.sock = self._create_socket(timeout)
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 1031, in _create_socket
    sock = _encrypt_on(sock, self.ssl_context, self.host)
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/nntplib.py", line 292, in _encrypt_on
    return context.wrap_socket(sock, server_hostname=hostname)
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/ssl.py", line 500, in wrap_socket
    return self.sslsocket_class._create(
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/ssl.py", line 1040, in _create
    self.do_handshake()
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/ssl.py", line 1309, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:1097)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 250, in wrapped
    meth(self)
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 293, in test_with_statement
    if re.search(r'(?i)KEY.TOO.SMALL', ssl_err.reason):
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/re.py", line 201, in search
    return _compile(pattern, flags).search(string)
TypeError: expected string or bytes-like object

----------
components: Tests
messages: 369648
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: test_nntplib: sporadic failures, NetworkedNNTP_SSLTests.test_with_statement
type: behavior

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

From report at bugs.python.org  Fri May 22 17:12:55 2020
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 May 2020 21:12:55 +0000
Subject: [New-bugs-announce] [issue40736] better message for re.search
 TypeError ("expected string or bytes-like object")
Message-ID: <1590181975.57.0.833400253921.issue40736@roundup.psfhosted.org>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This TypeError could be a bit better:

"/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/test/test_nntplib.py", line 293, in test_with_statement
    if re.search(r'(?i)KEY.TOO.SMALL', ssl_err.reason):
  File "/Users/runner/runners/2.262.1/work/cpython/cpython/Lib/re.py", line 201, in search
    return _compile(pattern, flags).search(string)
TypeError: expected string or bytes-like object

It just says "expected string or bytes-like object" but could include what type it found.

----------
components: Library (Lib)
messages: 369652
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: better message for re.search TypeError ("expected string or bytes-like object")
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Fri May 22 18:16:00 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 22 May 2020 22:16:00 +0000
Subject: [New-bugs-announce] [issue40737] Handle PyModule_AddObject() error
 correctly in sqlite3
Message-ID: <1590185760.13.0.611798281854.issue40737@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

According to the documentation, PyModule_AddObject() only decrements the reference count of value on success. The calling code must PyDECREF() manually on error.

Fixed by attached patch.

----------
components: Library (Lib)
files: 0001-Use-PyModule_AddObject-correctly-in-sqlite3.patch
keywords: patch
messages: 369658
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Handle PyModule_AddObject() error correctly in sqlite3
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49183/0001-Use-PyModule_AddObject-correctly-in-sqlite3.patch

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

From report at bugs.python.org  Fri May 22 21:59:11 2020
From: report at bugs.python.org (Stan Hendryx)
Date: Sat, 23 May 2020 01:59:11 +0000
Subject: [New-bugs-announce] [issue40738] backspace character \b not
 processed by IDLE
Message-ID: <1590199151.54.0.454885247619.issue40738@roundup.psfhosted.org>


New submission from Stan Hendryx <stan at hendryxassoc.com>:

The backspace character \b is not processed correctly in IDLE 3.8.2:
>>> print("deleted\b file")
deleted file

Running the interpreter from Terminal, it works:
>>> print("deleted\b file")
delete file

Same result on two systems: MacBook Pro, one on OSX 10.14.6 and another on 10.13.6.

----------
assignee: terry.reedy
components: IDLE
messages: 369685
nosy: stanhx, terry.reedy
priority: normal
severity: normal
status: open
title: backspace character \b not processed by IDLE
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat May 23 03:41:27 2020
From: report at bugs.python.org (Frederik Rietdijk)
Date: Sat, 23 May 2020 07:41:27 +0000
Subject: [New-bugs-announce] [issue40739] find_library broken for binutils
 >= 2.32 / 2.34
Message-ID: <1590219687.71.0.404083343675.issue40739@roundup.psfhosted.org>


New submission from Frederik Rietdijk <fridh at fridh.nl>:

With binutils 2.34 Python 3 (any version) the following returns None

    python3 -c 'import ctypes.util; print((ctypes.util.find_library("c")))'

instead of the requested library which we think may be caused by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=727a29badd95a68d08b86fec0b98702ce756c660
which is included in binutils 2.32 and up.


With binutils at 2.31 we got

# recent unstable
$ nix-shell --pure -p hello --run 'ld -t -o /dev/null -lc'
/nix/store/a57856fs4m8ir6vlv14h3gq3sv9aq2lb-binutils-2.31.1/bin/ld: mode elf_x86_64
/nix/store/nwsn18fysga1n5s0bj4jp4wfwvlbx8b1-glibc-2.30/lib/libc.so.6
/nix/store/nwsn18fysga1n5s0bj4jp4wfwvlbx8b1-glibc-2.30/lib/ld-linux-x86-64.so.2
/nix/store/nwsn18fysga1n5s0bj4jp4wfwvlbx8b1-glibc-2.30/lib/ld-linux-x86-64.so.2
/nix/store/a57856fs4m8ir6vlv14h3gq3sv9aq2lb-binutils-2.31.1/bin/ld: warning: cannot find entry symbol _start; not setting start address

however with 2.34 we get

# current staging
$ nix-shell --pure -p hello --run 'ld -t -o /dev/null -lc'
/nix/store/j1l6ds4mhm97nqw965w9sg07i9fric4d-glibc-2.30/lib/libc.so
/nix/store/j1l6ds4mhm97nqw965w9sg07i9fric4d-glibc-2.30/lib/libc.so.6
/nix/store/j1l6ds4mhm97nqw965w9sg07i9fric4d-glibc-2.30/lib/libc_nonshared.a
/nix/store/j1l6ds4mhm97nqw965w9sg07i9fric4d-glibc-2.30/lib/ld-linux-x86-64.so.2
/nix/store/j1l6ds4mhm97nqw965w9sg07i9fric4d-glibc-2.30/lib/libc_nonshared.a
/nix/store/j1l6ds4mhm97nqw965w9sg07i9fric4d-glibc-2.30/lib/ld-linux-x86-64.so.2
/nix/store/j284mk8hdv9ccxfdlhcdk1lg2jml4fhk-binutils-2.34/bin/ld: warning: cannot find entry symbol _start; not setting start address

The text-file libc.so is present which find_library cannot handle.

I suppose the regex needs to be fixed to exclude these references or otherwise handle them. It may be a bit late for binutils to revert their change.

Note this issue was discovered with the CFFI test suite https://foss.heptapod.net/pypy/cffi/blob/2aa5775ffdd6a911e9f40e3c2f5ba766155349c5/c/test_c.py#L60

Nixpkgs issue: https://github.com/NixOS/nixpkgs/pull/86954#issuecomment-632985576

----------
components: ctypes
messages: 369699
nosy: Frederik Rietdijk
priority: normal
severity: normal
status: open
title: find_library broken for binutils >= 2.32 / 2.34
type: behavior
versions: Python 3.10, 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/issue40739>
_______________________________________

From report at bugs.python.org  Sat May 23 05:11:53 2020
From: report at bugs.python.org (honglei jiang)
Date: Sat, 23 May 2020 09:11:53 +0000
Subject: [New-bugs-announce] [issue40740] Missing
 api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd64.exe Under Win7
Message-ID: <1590225113.89.0.949676590632.issue40740@roundup.psfhosted.org>


New submission from honglei jiang <jhonglei at gmail.com>:

Python.exe cannot run for missing  api-ms-win-core-path-l1-1.0.dll ,

api-ms-win-core-path-l1-1-0.dll is for only Windows 8?

https://github.com/microsoft/CNTK/issues/224

----------
components: Windows
messages: 369707
nosy: honglei.jiang, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Missing api-ms-win-core-path-l1-1.0.dll for python-3.9.0b1-amd64.exe Under Win7
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sat May 23 06:32:38 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 23 May 2020 10:32:38 +0000
Subject: [New-bugs-announce] [issue40741] Upgrade to SQLite v3.32.0 in
 Windows and macOS builds
Message-ID: <1590229958.06.0.659446886323.issue40741@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

SQLite 3.32.0 is out: https://www.sqlite.org/releaselog/3_32_0.html

I'll preparing a PR for cpython-source-deps and cpython.

----------
components: Windows, macOS
messages: 369711
nosy: erlendaasland, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade to SQLite v3.32.0 in Windows and macOS builds
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 23 06:56:47 2020
From: report at bugs.python.org (Julien Palard)
Date: Sat, 23 May 2020 10:56:47 +0000
Subject: [New-bugs-announce] [issue40742] Doc: Parallel build break audit
 table
Message-ID: <1590231407.13.0.794441624197.issue40742@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

Currently we can't build the doc using sphinx parallel builds, like: `sphinx-build -j auto`, because the audit-events table [1] is not generated in this case.

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

To reproduce:

    make -C Doc SPHINXOPTS='-j auto' autobuild-dev-html
    see build/html/library/audit_events.html

see also: https://mail.python.org/archives/list/python-dev at python.org/thread/POWT35ULU2CPELWQ6BRTLTU5H3YKHQZW/

----------
assignee: docs at python
components: Documentation
messages: 369712
nosy: docs at python, mdk, xtreak
priority: normal
severity: normal
status: open
title: Doc: Parallel build break audit table
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May 23 10:56:08 2020
From: report at bugs.python.org (TheUltimatePineapple)
Date: Sat, 23 May 2020 14:56:08 +0000
Subject: [New-bugs-announce] [issue40743] [CMake] It's 2020, where is CMake?
Message-ID: <1590245768.91.0.904361700086.issue40743@roundup.psfhosted.org>


New submission from TheUltimatePineapple <hentai666 at outlook.com>:

The current CPython build system is antiquated and makes cross-platform builds difficult (in my experience). There have been unofficial CMake implementations but they are either outdated, abandoned or just unusable.

Adopting CMake has many benefits, here are few:

1. Simplifies cross-platform builds and inclusion of CPython in other projects as subdirectory/subproject.

2. Automatically generated builds for any CMake supported OS'es, no need to maintain an unique build system for each OS, only the CMake script.

3. Faster. Just the configuration process in current build system for Unix is super slow, making testing changes slow and painful.

----------
components: Build
messages: 369724
nosy: TheUltimatePineapple
priority: normal
severity: normal
status: open
title: [CMake] It's 2020, where is CMake?
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat May 23 12:40:54 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 23 May 2020 16:40:54 +0000
Subject: [New-bugs-announce] [issue40744] Explicitly drop support for SQLite
 version < 3.7.3
Message-ID: <1590252054.91.0.549618457347.issue40744@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Currently, we use sqlite3_create_function_v2() without wrapping it in any #ifdefs, so in practise the sqlite3 module will not build against sqlite3 pre 3.7.3. Despite this, we still wrap parts of the code in #ifdefs for versions 3.6.x and older.

Added patch drops support for sqlite3 pre 3.7.3.

----------
components: Library (Lib)
files: 0001-Drop-support-for-sqlite3-3.7.3.patch
keywords: patch
messages: 369729
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Explicitly drop support for SQLite version < 3.7.3
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49187/0001-Drop-support-for-sqlite3-3.7.3.patch

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

From report at bugs.python.org  Sat May 23 12:55:52 2020
From: report at bugs.python.org (=?utf-8?q?H=C3=A9ctor_Canto?=)
Date: Sat, 23 May 2020 16:55:52 +0000
Subject: [New-bugs-announce] [issue40745] Typo in library/typing
Message-ID: <1590252952.01.0.421861710026.issue40745@roundup.psfhosted.org>


New submission from H?ctor Canto <hectorcanto at gmail.com>:

I found a small typo here:
https://docs.python.org/3.8/library/typing.html?highlight=typing#typing.NewType

I checked also in other 3.x versions and it is there too.

Original:
A helper function to indicate a distinct types to a typechecker, see NewType

Possible solution (remove the "s" in types):
A helper function to indicate a distinct type to a typechecker, see NewType

----------
assignee: docs at python
components: Documentation
messages: 369730
nosy: docs at python, hectorcanto
priority: normal
severity: normal
status: open
title: Typo in library/typing
type: enhancement
versions: Python 3.10, 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/issue40745>
_______________________________________

From report at bugs.python.org  Sat May 23 14:30:25 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 23 May 2020 18:30:25 +0000
Subject: [New-bugs-announce] [issue40746] test_gdb failing on Raspbian on
 3.9, regression from 3.8
Message-ID: <1590258625.25.0.246740749681.issue40746@roundup.psfhosted.org>


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

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

test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples ... ok
test_bt (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works ... FAIL
Stderr:
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0xfffffedc: 
Error occurred in Python command: Cannot access memory at address 0xfffffedc

and a pile of similar errors after test_bt

Marking release blocker as this isn't present in 3.8 or earlier, we've got a regression here.

i haven't tried to debug yet, but that pointer value smells like something did a negative offset from NULL...

----------
components: Tests
messages: 369736
nosy: gregory.p.smith
priority: release blocker
severity: normal
status: open
title: test_gdb failing on Raspbian on 3.9, regression from 3.8
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May 23 16:47:46 2020
From: report at bugs.python.org (mattip)
Date: Sat, 23 May 2020 20:47:46 +0000
Subject: [New-bugs-announce] [issue40747]
 sysconfig.get_config_var("py_version_nodot") should return 3_10
Message-ID: <1590266866.08.0.16909581495.issue40747@roundup.psfhosted.org>


New submission from mattip <matti.picus at gmail.com>:

Over in packaging, that code expects `sysconfig.get_config_var("py_version_nodot")` to be consistent with `tags._version_nodot`, which expects 3_10 for python 3.10. See https://github.com/pypa/packaging/issues/308. The current value of `sysconfig.get_config_var("py_version_nodot")` (which comes from https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L89) is `310` which is ambiguous.

----------
components: Installation
messages: 369750
nosy: mattip
priority: normal
severity: normal
status: open
title: sysconfig.get_config_var("py_version_nodot") should return 3_10
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Sat May 23 18:27:11 2020
From: report at bugs.python.org (Chas Belov)
Date: Sat, 23 May 2020 22:27:11 +0000
Subject: [New-bugs-announce] [issue40748] Tutorial 4.7 More on Defining
 Functions missing screen prompts
Message-ID: <1590272831.41.0.177431778032.issue40748@roundup.psfhosted.org>


New submission from Chas Belov <docorbit at sonic.net>:

The tutorial on More on Defining Functions at https://docs.python.org/3.7/tutorial/controlflow.html#more-on-defining-functions is missing most of the >>> and ... screen prompts that show elsewhere in the tutorial. This is potentially confusing to readers.

I am going to attempt a PR by May 26, 2020.

----------
assignee: docs at python
components: Documentation
messages: 369753
nosy: Chas Belov, docs at python
priority: normal
severity: normal
status: open
title: Tutorial 4.7 More on Defining Functions missing screen prompts
versions: Python 3.10, 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/issue40748>
_______________________________________

From report at bugs.python.org  Sat May 23 19:07:34 2020
From: report at bugs.python.org (Elijah Rippeth)
Date: Sat, 23 May 2020 23:07:34 +0000
Subject: [New-bugs-announce] [issue40749] Consider adding decorator for
 required inner class
Message-ID: <1590275254.34.0.427157211052.issue40749@roundup.psfhosted.org>


New submission from Elijah Rippeth <elijah.rippeth at gmail.com>:

Sometimes it's desirable to couple classes together by nesting. Currently there's no way to signal to an interface implementer that an inner class is a required attribute to be implemented. 

I propose a decorator for `abstractnestedclass` to fill this gap. A simple example use-case is outlined below:

```
from abc import ABCMeta, abstractnestedclass

class BaseComponent(metaclass=ABCMeta):
    @abstractnestedclass
    class Config:
        pass

class MissingNestedComponent(BaseComponent):
    # This will raise when constructed because 
    # BaseComponent.Config is not implemented
    pass

class NonraisingComponent(BaseComponent):
    # This will be constructable
    class NonraisingComponentConfig(BaseComponent.Config):
        pass
    pass
```

----------
components: Library (Lib)
messages: 369756
nosy: Elijah Rippeth
priority: normal
severity: normal
status: open
title: Consider adding decorator for required inner class
type: enhancement

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

From report at bugs.python.org  Sat May 23 21:41:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 24 May 2020 01:41:37 +0000
Subject: [New-bugs-announce] [issue40750] Support -d flag in the new parser
Message-ID: <1590284497.38.0.369695690738.issue40750@roundup.psfhosted.org>


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

Python has a (mostly unknown) -d flag that can only be used in debug builds that emit some debug output for the old parser. The new parser does not support such flag. This is very useful when playing with the grammar as it helps enormously to inspect how the parser has behaved and what rules have accepted/rejected in its path.

----------
components: Interpreter Core
messages: 369763
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Support -d flag in the new parser
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May 23 22:57:34 2020
From: report at bugs.python.org (Jonny Li)
Date: Sun, 24 May 2020 02:57:34 +0000
Subject: [New-bugs-announce] [issue40751] command 'elif' does not work
Message-ID: <1590289054.9.0.380521539599.issue40751@roundup.psfhosted.org>


Change by Jonny Li <cnshlcx at gmail.com>:


----------
assignee: terry.reedy
components: IDLE
files: Screen Shot 2020-05-24 at 10.56.55.png
nosy: Jonny Li, terry.reedy
priority: normal
severity: normal
status: open
title: command 'elif' does not work
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49188/Screen Shot 2020-05-24 at 10.56.55.png

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

From report at bugs.python.org  Sun May 24 04:04:44 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 24 May 2020 08:04:44 +0000
Subject: [New-bugs-announce] [issue40752] Implement PurePath.__len__
Message-ID: <1590307484.83.0.323009178084.issue40752@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I'm writing the patch now.

----------
components: Library (Lib)
messages: 369767
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement PurePath.__len__
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun May 24 04:51:45 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 24 May 2020 08:51:45 +0000
Subject: [New-bugs-announce] [issue40753] Remove Python 2 compatibility code
 from pathlib
Message-ID: <1590310305.67.0.10587858574.issue40753@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

No need to inherit from object. I'm writing the patch now.

----------
components: Library (Lib)
messages: 369770
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Remove Python 2 compatibility code from pathlib
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun May 24 08:47:10 2020
From: report at bugs.python.org (honglei jiang)
Date: Sun, 24 May 2020 12:47:10 +0000
Subject: [New-bugs-announce] [issue40754] ModuleNotFoundError: No module
 named '_testinternalcapi' under Win10
Message-ID: <1590324430.61.0.117510991737.issue40754@roundup.psfhosted.org>


New submission from honglei jiang <jhonglei at gmail.com>:

https://www.python.org/ftp/python/3.9.0/python-3.9.0b1-amd64.exe

C:\Python39>python.exe -m test test_deque -v
== CPython 3.9.0b1 (tags/v3.9.0b1:97fe9cf, May 19 2020, 09:02:07) [MSC v.1924 64 bit (AMD64)]
== Windows-10-10.0.18362-SP0 little-endian
== cwd: C:\Users\jhong\AppData\Local\Temp\test_python_3376
== CPU count: 4
== encodings: locale=cp936, FS=utf-8
0:00:00 Run tests sequentially
0:00:00 [1/1] test_deque
test_add (test.test_deque.TestBasic) ... ok
test_basics (test.test_deque.TestBasic) ... ok
test_big_queue_popleft (test.test_deque.TestBasic) ... ok
test_big_queue_popright (test.test_deque.TestBasic) ... ok
test_big_stack_left (test.test_deque.TestBasic) ... ok
test_big_stack_right (test.test_deque.TestBasic) ... ok
test_clear (test.test_deque.TestBasic) ... ok
test_comparisons (test.test_deque.TestBasic) ... ok
test_container_iterator (test.test_deque.TestBasic) ... ok
test_contains (test.test_deque.TestBasic) ... ok
test_contains_count_stop_crashes (test.test_deque.TestBasic) ... ok
test_copy (test.test_deque.TestBasic) ... ok
test_copy_method (test.test_deque.TestBasic) ... ok
test_count (test.test_deque.TestBasic) ... ok
test_deepcopy (test.test_deque.TestBasic) ... ok
test_delitem (test.test_deque.TestBasic) ... ok
test_extend (test.test_deque.TestBasic) ... ok
test_extendleft (test.test_deque.TestBasic) ... ok
test_gc_doesnt_blowup (test.test_deque.TestBasic) ... ok
test_getitem (test.test_deque.TestBasic) ... ok
test_hash (test.test_deque.TestBasic) ... ok
test_iadd (test.test_deque.TestBasic) ... ok
test_imul (test.test_deque.TestBasic) ... ok
test_index (test.test_deque.TestBasic) ... ok
test_index_bug_24913 (test.test_deque.TestBasic) ... ok
test_init (test.test_deque.TestBasic) ... ok
test_insert (test.test_deque.TestBasic) ... ok
test_insert_bug_26194 (test.test_deque.TestBasic) ... ok
test_iterator_pickle (test.test_deque.TestBasic) ... ok
test_len (test.test_deque.TestBasic) ... ok
test_long_steadystate_queue_popleft (test.test_deque.TestBasic) ... ok
test_long_steadystate_queue_popright (test.test_deque.TestBasic) ... ok
test_maxlen (test.test_deque.TestBasic) ... ok
test_maxlen_attribute (test.test_deque.TestBasic) ... ok
test_maxlen_zero (test.test_deque.TestBasic) ... ok
test_mul (test.test_deque.TestBasic) ... ok
test_pickle (test.test_deque.TestBasic) ... ok
test_pickle_recursive (test.test_deque.TestBasic) ... ok
test_print (test.test_deque.TestBasic) ... ok
test_remove (test.test_deque.TestBasic) ... ok
test_repr (test.test_deque.TestBasic) ... ok
test_reverse (test.test_deque.TestBasic) ... ok
test_reversed (test.test_deque.TestBasic) ... ok
test_reversed_new (test.test_deque.TestBasic) ... ok
test_rotate (test.test_deque.TestBasic) ... ok
test_roundtrip_iter_init (test.test_deque.TestBasic) ... ok
test_setitem (test.test_deque.TestBasic) ... ok
test_sizeof (test.test_deque.TestBasic) ... ERROR
test_underflow (test.test_deque.TestBasic) ... ok
test_constructor (test.test_deque.TestVariousIteratorArgs) ... ok
test_iter_with_altered_data (test.test_deque.TestVariousIteratorArgs) ... ok
test_runtime_error_on_empty_deque (test.test_deque.TestVariousIteratorArgs) ... ok
test_basics (test.test_deque.TestSubclass) ... ok
test_bug_31608 (test.test_deque.TestSubclass) ... ok
test_copy_pickle (test.test_deque.TestSubclass) ... ok
test_pickle_recursive (test.test_deque.TestSubclass) ... ok
test_strange_subclass (test.test_deque.TestSubclass) ... ok
test_weakref (test.test_deque.TestSubclass) ... ok
test_subclass_with_kwargs (test.test_deque.TestSubclassWithKwargs) ... ok
test_addmul (test.test_deque.TestSequence) ... ok
test_bigrepeat (test.test_deque.TestSequence) ... ok
test_constructors (test.test_deque.TestSequence) ... ok
test_contains (test.test_deque.TestSequence) ... ok
test_contains_fake (test.test_deque.TestSequence) ... ok
test_contains_order (test.test_deque.TestSequence) ... ok
test_count (test.test_deque.TestSequence) ... ok
test_free_after_iterating (test.test_deque.TestSequence) ... skipped "Exhausted deque iterator doesn't free a deque"
test_getitem (test.test_deque.TestSequence) ... ok
test_getitemoverwriteiter (test.test_deque.TestSequence) ... ok
test_getslice (test.test_deque.TestSequence) ... ok
test_iadd (test.test_deque.TestSequence) ... ok
test_imul (test.test_deque.TestSequence) ... ok
test_index (test.test_deque.TestSequence) ... ok
test_len (test.test_deque.TestSequence) ... ok
test_minmax (test.test_deque.TestSequence) ... ok
test_pickle (test.test_deque.TestSequence) ... ok
test_repeat (test.test_deque.TestSequence) ... ok
test_subscript (test.test_deque.TestSequence) ... ok
test_truth (test.test_deque.TestSequence) ... ok

======================================================================
ERROR: test_sizeof (test.test_deque.TestBasic)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python39\lib\test\test_deque.py", line 781, in test_sizeof
    check(deque(), basesize + blocksize)
  File "C:\Python39\lib\test\support\__init__.py", line 1483, in check_sizeof
    import _testinternalcapi
ModuleNotFoundError: No module named '_testinternalcapi'

----------------------------------------------------------------------

Ran 79 tests in 0.696s

FAILED (errors=1, skipped=1)
test test_deque failed
test_deque failed

== Tests result: FAILURE ==

1 test failed:
    test_deque

Total duration: 906 ms
Tests result: FAILURE

C:\Python39>

----------
components: Tests
messages: 369798
nosy: honglei.jiang
priority: normal
severity: normal
status: open
title: ModuleNotFoundError: No module named '_testinternalcapi' under Win10
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sun May 24 11:11:00 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 May 2020 15:11:00 +0000
Subject: [New-bugs-announce] [issue40755] Add missing multiset predicates to
 collections.Counter
Message-ID: <1590333060.51.0.256014570882.issue40755@roundup.psfhosted.org>


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

These missing predicates have been requested a number of times:

   isequal()
   issubset()
   issuperset()
   isdisjoint()

----------
assignee: rhettinger
components: Library (Lib)
messages: 369808
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add missing multiset predicates to collections.Counter
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun May 24 14:02:38 2020
From: report at bugs.python.org (Arturo Escaip)
Date: Sun, 24 May 2020 18:02:38 +0000
Subject: [New-bugs-announce] [issue40756] Second argument of
 LoggerAdapter.__init__ should default to None
Message-ID: <1590343358.29.0.207811312221.issue40756@roundup.psfhosted.org>


New submission from Arturo Escaip <arturoescaip at gmail.com>:

The 'extra' argument is not always used by custom logger adapters. There
example:

class IndentAdapter(logging.LoggerAdapter):
    def process(self, msg, kwargs):
        indent = kwargs.pop(indent, 1)
        return ' ' * indent + msg, kwargs

It is cleaner and friendlier to default the 'extra' argument to None
instead of either forcing the subclasses of LoggerAdapter to pass a None
value directly or to override the constructor.

----------
components: Library (Lib)
messages: 369815
nosy: arturoescaip
priority: normal
severity: normal
status: open
title: Second argument of LoggerAdapter.__init__ should default to None
type: enhancement

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

From report at bugs.python.org  Sun May 24 14:10:44 2020
From: report at bugs.python.org (mxmlnkn)
Date: Sun, 24 May 2020 18:10:44 +0000
Subject: [New-bugs-announce] [issue40757] tarfile: ignore_zeros = True won't
 raise exception even on invalid (non-zero) TARs
Message-ID: <1590343844.38.0.257135087645.issue40757@roundup.psfhosted.org>


New submission from mxmlnkn <maxinator333 at googlemail.com>:

Normally, when opening an existing non-TAR file, e.g., a file with random data, an exception is raised:

tarfile.open( "foo.txt" )

    ---------------------------------------------------------------------------
    ReadError                                 Traceback (most recent call last)
    <ipython-input-53-aa60172c3e3b> in <module>()
    ----> 1 f = tarfile.open( "notes.txt", ignore_zeros = False )

    /usr/lib/python3.7/tarfile.py in open(cls, name, mode, fileobj, bufsize, **kwargs)
       1576                         fileobj.seek(saved_pos)
       1577                     continue
    -> 1578             raise ReadError("file could not be opened successfully")
       1579 
       1580         elif ":" in mode:

    ReadError: file could not be opened successfully

However, when specifying ignore_zeros = True, this check against invalid data seems to be turned off. Note that it is >invalid< data not >zero< data and therefore should still raise an exception!

tarfile.open( "foo.txt", ignore_zeros = True )

Iterating over that opened tarfile also works without exception however nothing will be iterated over, i.e., it behaves like an empty TAR instead of like an invalid TAR.

----------
components: Library (Lib)
messages: 369816
nosy: mxmlnkn
priority: normal
severity: normal
status: open
title: tarfile: ignore_zeros = True won't raise exception even on invalid (non-zero) TARs
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun May 24 16:49:25 2020
From: report at bugs.python.org (Chas Belov)
Date: Sun, 24 May 2020 20:49:25 +0000
Subject: [New-bugs-announce] [issue40758] For 7.2.7. Code Examples,
 distinguish between the Tutorial and other documentation
Message-ID: <1590353365.14.0.907078183909.issue40758@roundup.psfhosted.org>


New submission from Chas Belov <docorbit at sonic.net>:

7.2.7. Code Examples https://devguide.python.org/documenting/#code-examples states:

Short code examples can be a useful adjunct to understanding. Readers can often grasp a simple example more quickly than they can digest a formal description in prose.

[snip]

The ellipsis for the sys.ps2 secondary interpreter prompt should only be used sparingly, where it is necessary to clearly differentiate between input lines and output lines. Besides contributing visual clutter, it makes it difficult for readers to cut-and-paste examples so they can experiment with variations.

-----

I am requesting, as a newcomer to Python who is attempting to navigate the Tutorials and encountering challenges, that this be reworded to something like:

Short code examples can be a useful adjunct to understanding. Readers can often grasp a simple example more quickly than they can digest a formal description in prose.

[snip]

Outside of the Tutorial, the ellipsis for the sys.ps2 secondary interpreter prompt should only be used sparingly, where it is necessary to clearly differentiate between input lines and output lines. Besides contributing visual clutter, it makes it difficult for readers to cut-and-paste examples so they can experiment with variations.

Within the Tutorial, however, make the appearance of code blocks as consistent with what the student will be experiencing as feasible, to reduce cognitive load and allow them to focus on the content.

-----

While I can in fact suss out whether a particular unmarked code block is meant to be input or output, it is a distraction that uses up some of my attention that I would prefer to spend on learning the language.

----------
messages: 369825
nosy: Chas Belov
priority: normal
severity: normal
status: open
title: For 7.2.7. Code Examples, distinguish between the Tutorial and other documentation
versions: Python 3.10

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

From report at bugs.python.org  Sun May 24 16:51:46 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 24 May 2020 20:51:46 +0000
Subject: [New-bugs-announce] [issue40759] Deprecate the symbol module
Message-ID: <1590353506.35.0.123027767636.issue40759@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Parser is deprecated so there is no need for the 'symbol' module. I think this should be backported to 3.9, so I'm CC-ing @?ukasz.

----------
components: Library (Lib)
messages: 369826
nosy: BTaskaya, lukasz.langa
priority: normal
severity: normal
status: open
title: Deprecate the symbol module
versions: Python 3.9

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

From report at bugs.python.org  Sun May 24 17:36:37 2020
From: report at bugs.python.org (Amol Sharma)
Date: Sun, 24 May 2020 21:36:37 +0000
Subject: [New-bugs-announce] [issue40760] Dictionary comprehension using
 older division behavior
Message-ID: <1590356197.08.0.726126426417.issue40760@roundup.psfhosted.org>


New submission from Amol Sharma <guesswhoas at gmail.com>:

Using comprehension to divide all the values in a dictionary like in the following results in integer division in 3.8.

some_dict = {k: v/5 for k, v in some_dict.items()}

This was solved by changing 5 to 5.0, reflecting behavior from python2. I would have expected to have the use the // operator for integer division.

Please correct me if this is expected behavior!

----------
messages: 369833
nosy: Amol Sharma
priority: normal
severity: normal
status: open
title: Dictionary comprehension using older division behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun May 24 23:02:45 2020
From: report at bugs.python.org (lee yummy)
Date: Mon, 25 May 2020 03:02:45 +0000
Subject: [New-bugs-announce] [issue40761] unittest.TestCase.asserTrue return
 True even if the expr is False
Message-ID: <1590375765.94.0.197466932598.issue40761@roundup.psfhosted.org>


New submission from lee yummy <liymsysu at gmail.com>:

self.assertTrue(np.array_equal(x, y), "") # x.shape is [58, 139]

np.array_equal(x, y) is False, but `self.assertTrue(np.array_equal(x, y), "")` doesn't raise error.

----------
components: Tests
messages: 369843
nosy: lee yummy
priority: normal
severity: normal
status: open
title: unittest.TestCase.asserTrue return True even if the expr is False
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon May 25 01:49:18 2020
From: report at bugs.python.org (Sidhant Bansal)
Date: Mon, 25 May 2020 05:49:18 +0000
Subject: [New-bugs-announce] [issue40762] Writing bytes using CSV module
 results in b prefixed strings
Message-ID: <1590385758.36.0.528402625132.issue40762@roundup.psfhosted.org>


New submission from Sidhant Bansal <sidhbansal at gmail.com>:

The following code
```
import csv
with open("abc.csv", "w") as f:
   data = [b'\xc2a9', b'\xc2a9']
   w = csv.writer(f)
   w.writerow(data)
```
writes "b'\xc2a9',b'\xc2a9'" in "abc.csv", i.e the b-prefixed byte string instead of the actual bytes. 

Although one can argue that the write is done in text mode and not binary mode, however I believe the more natural expectation by the user will be to have the bytes written actually in the "abc.csv".

Can refer to this https://github.com/pandas-dev/pandas/issues/9712 to see one of the issues this brings in Pandas. From the discussion on this issue, the main reasons of changing this behaviour in Python would be to avoid leaking python's encoding system syntax into a generic data exchange format, i.e CSV.

----------
components: Library (Lib)
messages: 369848
nosy: sidhant
priority: normal
severity: normal
status: open
title: Writing bytes using CSV module results in b prefixed strings
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon May 25 03:18:15 2020
From: report at bugs.python.org (Va)
Date: Mon, 25 May 2020 07:18:15 +0000
Subject: [New-bugs-announce] [issue40763] zipfile.extractall is safe by now
Message-ID: <1590391095.61.0.387813168658.issue40763@roundup.psfhosted.org>


New submission from Va <d.python.dc54 at indigo.re>:

In documentation of all Python 3 versions, [ZipFile.extractall](https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.extractall) states with a big red warning:

> Warning
> Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with "/" or filenames with two dots "..". This module attempts to prevent that. See extract() note.

However, when looking at the implementation, it calls _extract_member() which seems to sanitize filenames. So the warning might not be relevant anymore.

Furthermore, when looking at [Python 2](https://docs.python.org/2/library/zipfile.html#zipfile.ZipFile.extractall) documentation, we can see the same warning, along with a change note:

> Changed in version 2.7.4: The zipfile module attempts to prevent that. See extract() note.

So, the big red warning in Python 3 documentation might be relevant only for Python < 2.7.4, not for any Python 3 version.

----------
assignee: docs at python
components: Documentation
messages: 369854
nosy: VA, docs at python
priority: normal
severity: normal
status: open
title: zipfile.extractall is safe by now
type: behavior
versions: Python 3.10, 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/issue40763>
_______________________________________

From report at bugs.python.org  Mon May 25 05:28:30 2020
From: report at bugs.python.org (Paul)
Date: Mon, 25 May 2020 09:28:30 +0000
Subject: [New-bugs-announce] [issue40764] Conflation of Counter with Multiset
Message-ID: <1590398910.64.0.370990898211.issue40764@roundup.psfhosted.org>


New submission from Paul <python at paulkoppen.com>:

The collections docs state: "Several mathematical operations are provided for combining Counter objects to produce multisets (counters that have counts greater than zero)."

I am surprised at the clear level of decision into conflating counters with multisets. Why break all functionality for negative counts in favour of multisets? Why not create a Multiset object for multisets?

One example use of negative counts is in factorisation (https://bugs.python.org/msg368298 will be surprised counters don't count)
18   = 2**1 * 3**2  --> x18 = Counter({2: 1, 3: 2})
 4   = 2**2         --> x4 = Counter({2: 2})

To compute 18/4 in this representation (which I believe is exactly precisely a count), one would expect

18/4 = 2**-1 * 3**2 --> x4_5 = x18 - x4 = Counter({2: -1, 3: 2})

But instead,

x18 - x4 = Counter({3: 2}) = 9 ???

This is just an example. The use case for negative counts is plain and obvious. The question is: why does collections break counter behaviour in favour of conflation with multisets? Why not have two objects: Counter for counters and Multiset for multisets?

----------
components: Library (Lib)
messages: 369867
nosy: wpk-
priority: normal
severity: normal
status: open
title: Conflation of Counter with Multiset
type: behavior
versions: Python 3.10, 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/issue40764>
_______________________________________

From report at bugs.python.org  Mon May 25 06:48:38 2020
From: report at bugs.python.org (sagar)
Date: Mon, 25 May 2020 10:48:38 +0000
Subject: [New-bugs-announce] [issue40765] clear screen in idle
Message-ID: <1590403718.48.0.166169360249.issue40765@roundup.psfhosted.org>


New submission from sagar <sagarkancharla19 at gmail.com>:

please provide clear screen option in windows idle.
clear screen means moving command line to start of the page.

----------
assignee: terry.reedy
components: IDLE
messages: 369870
nosy: sagarkancharlas, terry.reedy
priority: normal
severity: normal
status: open
title: clear screen in idle
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Mon May 25 07:13:46 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 25 May 2020 11:13:46 +0000
Subject: [New-bugs-announce] [issue40766] Add support for SQLITE_DIRECTONLY
 and SQLITE_INNOCUOUS for user-defined functions
Message-ID: <1590405226.61.0.516885064285.issue40766@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Add support for SQLITE_DIRECTONLY and SQLITE_INNOCUOUS in `sqlite3.create_function()` and `sqlite3.create_aggregate()`.

>From the SQLite 3.31.0 changelog:
- Provide the ability to tag application-defined SQL functions with new properties SQLITE_INNOCUOUS or SQLITE_DIRECTONLY.


https://www.sqlite.org/c3ref/c_deterministic.html#sqlitedirectonly
https://www.sqlite.org/changes.html

----------
components: Library (Lib)
messages: 369871
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Add support for SQLITE_DIRECTONLY and SQLITE_INNOCUOUS for user-defined functions
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 25 07:38:08 2020
From: report at bugs.python.org (Jeremy Attali)
Date: Mon, 25 May 2020 11:38:08 +0000
Subject: [New-bugs-announce] [issue40767] Allow pure Wayland to get default
 XDG webbrowser
Message-ID: <1590406688.74.0.158171351248.issue40767@roundup.psfhosted.org>


New submission from Jeremy Attali <jeremy.attali at gmail.com>:

In a pure Wayland environment (without xwayland), the DISPLAY environment variable is not present. Therefore the call to `xdg-settings get default-browser` is not made. So the webbrowser behaviour is different between X11 and Wayland environment. I'm working on a fix, should submit a GitHub PR soon.

```
? export | grep DISPLAY
WAYLAND_DISPLAY=wayland-0
? python -c "import webbrowser; print(webbrowser.get())"
<webbrowser.GenericBrowser object at 0x7f6f1b755160>
```

----------
components: Library (Lib)
messages: 369872
nosy: Jeremy Attali
priority: normal
severity: normal
status: open
title: Allow pure Wayland to get default XDG webbrowser
type: behavior
versions: Python 3.10, 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/issue40767>
_______________________________________

From report at bugs.python.org  Mon May 25 09:19:54 2020
From: report at bugs.python.org (Mansi)
Date: Mon, 25 May 2020 13:19:54 +0000
Subject: [New-bugs-announce] [issue40768] pyaudio
Message-ID: <1590412794.98.0.497515762092.issue40768@roundup.psfhosted.org>


Change by Mansi <shanayaa0000 at gmail.com>:


----------
files: Screenshot (22).png
nosy: mansi
priority: normal
severity: normal
status: open
title: pyaudio
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file49193/Screenshot (22).png

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

From report at bugs.python.org  Mon May 25 11:03:00 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 25 May 2020 15:03:00 +0000
Subject: [New-bugs-announce] [issue40769] Pegen: cover extra surrounding
 parentheses for invalid annotated assignment
Message-ID: <1590418980.01.0.581408233442.issue40769@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

$ python -X oldparser
Python 3.10.0a0 (heads/bpo-xxxxx:f2947e354c, May 21 2020, 18:54:57) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> (()): int
  File "<stdin>", line 1
SyntaxError: only single target (not tuple) can be annotated
>>> ((())): int
  File "<stdin>", line 1
SyntaxError: only single target (not tuple) can be annotated
>>> (((()))): int
  File "<stdin>", line 1
SyntaxError: only single target (not tuple) can be annotated
>>> ([]): int
  File "<stdin>", line 1
SyntaxError: only single target (not list) can be annotated
>>> (([])): int
  File "<stdin>", line 1
SyntaxError: only single target (not list) can be annotated

---- current ----

>>> (()): int
  File "<stdin>", line 1
    (()): int
     ^
SyntaxError: illegal target for annotation
>>> (((()))): int
  File "<stdin>", line 1
    (((()))): int
       ^
SyntaxError: illegal target for annotation
>>> ([]): int
  File "<stdin>", line 1
    ([]): int
     ^
SyntaxError: illegal target for annotation
>>> (([])): int
  File "<stdin>", line 1
    (([])): int
      ^
SyntaxError: illegal target for annotation

----------
messages: 369885
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Pegen: cover extra surrounding parentheses for invalid annotated assignment

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

From report at bugs.python.org  Mon May 25 12:09:02 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Mon, 25 May 2020 16:09:02 +0000
Subject: [New-bugs-announce] [issue40770] RFE: Run linkchecker on
 documentation on the CI
Message-ID: <1590422942.58.0.668271802455.issue40770@roundup.psfhosted.org>


New submission from Miro Hron?ok <miro at hroncok.cz>:

In Fedora, we run the following check when we build Python documentation:

# Verify that all of the local links work
#
# (we can't check network links, as we shouldn't be making network connections
# within a build.  Also, don't bother checking the .txt source files; some
# contain example URLs, which don't work)
linkchecker \
  --ignore-url=^mailto: --ignore-url=^http --ignore-url=^ftp \
  --ignore-url=.txt\$ --no-warnings \
  Doc/build/html/index.html

>From time to time, it discovers broken links:

  https://github.com/python/cpython/pull/15700
  https://github.com/python/cpython/pull/20383
  https://github.com/python/cpython/pull/20388

It would be really nice if this check run as part of the CI that builds the documentation.

----------
assignee: docs at python
components: Documentation
messages: 369892
nosy: docs at python, hroncok, vstinner
priority: normal
severity: normal
status: open
title: RFE: Run linkchecker on documentation on the CI
versions: Python 3.10

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

From report at bugs.python.org  Mon May 25 12:47:53 2020
From: report at bugs.python.org (Jim Carroll)
Date: Mon, 25 May 2020 16:47:53 +0000
Subject: [New-bugs-announce] [issue40771] python3 fromtimestamp generates
 OSError
Message-ID: <1590425273.09.0.343345283384.issue40771@roundup.psfhosted.org>


New submission from Jim Carroll <jim at carroll.com>:

We encountered an interesting mtime problem in the field, that I believe represents a bug in python's datetime timestamp handling.

A file stored on a windows server had the last-modified date '1/1/4501' (that's the year 4501). os.path.getmtime() returns a valid timestamp, but when we try to pass this back into datetime.datetime.fromtimestamp() we get an OSError.

I understand that generating an OSError when the date exceeds the epoch support on Windows is consistent with the python docs. In our case, the date is clearly supported by Windows as evidenced by it's storage in the filesystem. Further, we can reproduce the situation using the cygwin touch utility.

>>> import os, datetime
>>> os.system('touch -d "4501-01-01" file.txt')
>>> t = os.path.getmtime('file.txt')
>>> datetime.datetime.fromtimestamp(t)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

What's interesting is we can manually convert it with reference to the epoch

>>> datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=t)
datetime.datetime(4501, 1, 1, 5, 0)

We used Windows 10-Pro for our tests running python 3.8.1.

----------
components: Library (Lib)
messages: 369895
nosy: jamercee
priority: normal
severity: normal
status: open
title: python3 fromtimestamp generates OSError
versions: Python 3.8

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

From report at bugs.python.org  Mon May 25 14:09:07 2020
From: report at bugs.python.org (Titusz Ban)
Date: Mon, 25 May 2020 18:09:07 +0000
Subject: [New-bugs-announce] [issue40772] module 'resource' has no attribute
 'RLIMIT_VMEM'
Message-ID: <1590430147.26.0.291044051097.issue40772@roundup.psfhosted.org>


New submission from Titusz Ban <tituszban at gmail.com>:

While trying to limit the virtual memory used by a process, using

import resource
MAX_VIRTUAL_MEMORY = 1 * 1024 * 1024
resource.setrlimit(resource.RLIMIT_VMEM, (MAX_VIRTUAL_MEMORY, MAX_VIRTUAL_MEMORY))

The following error occurred:

AttributeError: module 'resource' has no attribute 'RLIMIT_VMEM'

This is on Ubuntu 16.04 running inside WSL. on Python 3.8.2.

----------
messages: 369902
nosy: Titusz Ban
priority: normal
severity: normal
status: open
title: module 'resource' has no attribute 'RLIMIT_VMEM'
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Mon May 25 15:53:34 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 25 May 2020 19:53:34 +0000
Subject: [New-bugs-announce] [issue40773] DOC: Fix rendering for 'retval' on
 the pdb page
Message-ID: <1590436414.36.0.494727849447.issue40773@roundup.psfhosted.org>


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

Please only work on this issue if it would be your first contribution to CPython.

The rendering for 'retval' description at the bottom of the pdb doc page isn't quite right.

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

----------
assignee: docs at python
components: Documentation
keywords: easy, newcomer friendly
messages: 369918
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: Fix rendering for 'retval' on the pdb page
type: enhancement
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon May 25 19:07:08 2020
From: report at bugs.python.org (Stephan Hohe)
Date: Mon, 25 May 2020 23:07:08 +0000
Subject: [New-bugs-announce] [issue40774] "Important" block in documentation
 of asyncio.create_subprocess_shell() not indented correctly
Message-ID: <1590448028.26.0.390757544859.issue40774@roundup.psfhosted.org>


New submission from Stephan Hohe <sth.dev at tejp.de>:

The [documentation][1] for asyncio.create_subprocess_shell() contains an "important" block about quoting special characters. This block and the following deprecation note belong to this specific function, but are not correctly indented and shown at module level.

 [1]: https://docs.python.org/3.10/library/asyncio-subprocess.html#asyncio.create_subprocess_shell

----------
assignee: docs at python
components: Documentation
messages: 369930
nosy: docs at python, sth
priority: normal
severity: normal
status: open
title: "Important" block in documentation of asyncio.create_subprocess_shell() not indented correctly
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 26 04:22:48 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Tue, 26 May 2020 08:22:48 +0000
Subject: [New-bugs-announce] [issue40775] Fix missing dot in sqlite3 Node
 type name
Message-ID: <1590481368.15.0.745796272194.issue40775@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
components: Library (Lib)
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Fix missing dot in sqlite3 Node type name
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 26 05:28:56 2020
From: report at bugs.python.org (Asmi Ariv)
Date: Tue, 26 May 2020 09:28:56 +0000
Subject: [New-bugs-announce] [issue40776] Python 3.7.6 installation issue on
 mac os x 10.6.8
Message-ID: <1590485336.47.0.935532303121.issue40776@roundup.psfhosted.org>


New submission from Asmi Ariv <asmiariv at gmail.com>:

I am unable to install Python 3.7.6 on my Macbook with OS X 10.6.8 (Snow Leopard). I am getting the following error:

The operation couldn?t be completed. (com.apple.installer.pagecontroller error -1.)
Couldn't open "python-3.7.6-macosx10.6.pkg".

Is it possible for you to provide .dmg file for the same or any higher version compatible with Mac OS X 10.6.8 (Snow Leopard). Many thanks!

Regards
Asmi Ariv

----------
components: Installation
messages: 369962
nosy: AsmiAriv
priority: normal
severity: normal
status: open
title: Python 3.7.6 installation issue on mac os x 10.6.8
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Tue May 26 05:55:41 2020
From: report at bugs.python.org (Sandro Mani)
Date: Tue, 26 May 2020 09:55:41 +0000
Subject: [New-bugs-announce] [issue40777] _datetimemodule.c:3328:16: error:
 initializer element is not constant
Message-ID: <1590486941.4.0.263574761351.issue40777@roundup.psfhosted.org>


New submission from Sandro Mani <manisandro at gmail.com>:

Hitting this when attempting to cross-compile python-3.9 to mingw:

/builddir/build/BUILD/Python-3.9.0b1/Modules/_datetimemodule.c:3328:16: error: initializer element is not constant
 3328 |     .tp_base = &PyTuple_Type,

Indeed PyTuple_Type does not have static storage, so I suppose this [1] applies.

[1] https://stackoverflow.com/a/3025106/1338788

----------
components: Build
messages: 369965
nosy: smani
priority: normal
severity: normal
status: open
title: _datetimemodule.c:3328:16: error: initializer element is not constant
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Tue May 26 08:31:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 26 May 2020 12:31:35 +0000
Subject: [New-bugs-announce] [issue40778] Updating Py_REFCNT and Py_SIZE to
 use _PyObject_CAST_CONS
Message-ID: <1590496295.28.0.309191612297.issue40778@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

See: https://github.com/python/cpython/pull/20290#discussion_r430007803

----------
assignee: corona10
components: C API
messages: 369974
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: Updating Py_REFCNT and Py_SIZE to use _PyObject_CAST_CONS
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue May 26 10:06:10 2020
From: report at bugs.python.org (Tomasz Pytel)
Date: Tue, 26 May 2020 14:06:10 +0000
Subject: [New-bugs-announce] [issue40779] incorrect end column for single
 argument generator function call AST
Message-ID: <1590501970.38.0.210271516775.issue40779@roundup.psfhosted.org>


New submission from Tomasz Pytel <tompytel at gmail.com>:

When calling a function with a single argument which is an unparenthesized generator expression the end column for the AST node is incorrect, it is one greater than the start of the function call parentheses where I assume it should be one past the closing parentheses.

This call:

func(i for i in range(3))

Generates the following node for the generator expression (line:col_offset -> end_line:end_col_offset):

<_ast.GeneratorExp object at 0x7f3ba61f78c0> .. 1:4 -> 1:5

----------
components: Interpreter Core
messages: 369982
nosy: Tomasz Pytel
priority: normal
severity: normal
status: open
title: incorrect end column for single argument generator function call AST
versions: Python 3.8

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

From report at bugs.python.org  Tue May 26 10:15:19 2020
From: report at bugs.python.org (David Chambers)
Date: Tue, 26 May 2020 14:15:19 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue40780=5D_str=2Eformat=28?=
 =?utf-8?q?=29_handles_trailing_zeros_inconsistently_in_=E2=80=9Cgeneral?=
 =?utf-8?q?=E2=80=9D_format?=
Message-ID: <1590502519.54.0.593108276962.issue40780@roundup.psfhosted.org>


New submission from David Chambers <dc at davidchambers.me>:

According to https://docs.python.org/3/library/string.html#format-specification-mini-language, ?insignificant trailing zeros are removed from the significand? when 'g' is specified. I encountered a situation in which a trailing zero is not removed:

    $ python3
    Python 3.7.7 (default, Mar 10 2020, 15:43:03)
    [Clang 11.0.0 (clang-1100.0.33.17)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> '{0:.3g}'.format(1504)
    '1.5e+03'
    >>> '{0:.3g}'.format(1505)
    '1.50e+03'
    >>> '{0:.3g}'.format(1506)
    '1.51e+03'

Is this behaviour intentional? If so, why is the trailing zero in 1.50 considered significant for 1505 but insignificant for 1504?

----------
messages: 369983
nosy: davidchambers
priority: normal
severity: normal
status: open
title: str.format() handles trailing zeros inconsistently in ?general? format
type: behavior

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

From report at bugs.python.org  Tue May 26 10:48:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 May 2020 14:48:52 +0000
Subject: [New-bugs-announce] [issue40781] Remove sys._debugmallocstats()
 function and PYTHONMALLOCSTATS environment variable
Message-ID: <1590504532.44.0.996467674313.issue40781@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I never used sys._debugmallocstats() function or PYTHONMALLOCSTATS environment variable, whereas I spend significant time on optimizing memory allocators and free lists. The output is written into stderr which is very convenient to process these data.

I only "re"-discovered recently this debug feature when writing PR 20247 "Make tuple free list per-interpreter": I had to update _PyTuple_DebugMallocStats().

Removing this debug feature reduces the maintenance burden.

Attached PR removes all code related to the sys._debugmallocstats() function and the PYTHONMALLOCSTATS environment variable.

If someone wants to hack Python memory allocators or free lists, I suggest to add temporary code to dump some stats. But I don't think that it's worth it to keep the feature for all uses in Python.

People who worry about the memory usage of their application don't have to go into this low level of details, but care more about memory peak, where the memory was allocated (ex: tracemalloc module), RSS memory, etc.

----------
components: Interpreter Core
messages: 369987
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove sys._debugmallocstats() function and PYTHONMALLOCSTATS environment variable
versions: Python 3.10

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

From report at bugs.python.org  Tue May 26 11:45:38 2020
From: report at bugs.python.org (James Barrett)
Date: Tue, 26 May 2020 15:45:38 +0000
Subject: [New-bugs-announce] [issue40782] AbstactEventLoop.run_in_executor
 is listed as an async method, but should actually return a Futrue
Message-ID: <1590507938.7.0.58927076005.issue40782@roundup.psfhosted.org>


New submission from James Barrett <james.barrett at bbc.co.uk>:

As discussed in < https://github.com/python/typeshed/issues/3999#issuecomment-634097968 > the type of `AbstractEventLoop.run_in_executor` is defined at < https://github.com/python/cpython/blob/master/Lib/asyncio/events.py#L286 > as follows:

```
async def run_in_executor(self, executor, func, *args):
        raise NotImplementedError
```

However all concrete implementations of this method are actually not async methods but rather synchronous methods which return a Future object.

Logically this appears to make sense: at base `run_in_executor` is not a coroutine, since it doesn't create an object representing code which will be executed when the object is awaited, rather it returns an object representing code which is running asynchronously elsewhere (on another thread) and which can be awaited to wait for that other thread to complete its task. Which seems to be a perfect match to what a Future object is supposed to be.

As such it seems that the current definition of the method as a coroutine is possibly a mistake.

Alternatively if some feel that it is important to allow concrete implementations to implement it as a coroutine if they need to then perhaps it could be specified to be a method returning an Awaitable, since that would cover both options?

----------
components: Library (Lib)
messages: 370005
nosy: jamesba
priority: normal
severity: normal
status: open
title: AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Futrue
type: behavior
versions: Python 3.10, 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/issue40782>
_______________________________________

From report at bugs.python.org  Tue May 26 12:37:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 26 May 2020 16:37:03 +0000
Subject: [New-bugs-announce] [issue40783] test_interpreters
 test_interpreters leaked [216, 216, 216] references
Message-ID: <1590511023.44.0.277670003926.issue40783@roundup.psfhosted.org>


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

https://buildbot.python.org/all/#/builders/394/builds/94

......
test_interpreters leaked [216, 216, 216] references, sum=648
test_interpreters leaked [84, 84, 84] memory blocks, sum=252
1 test failed again:
    test_interpreters

----------
components: Tests
messages: 370014
nosy: eric.snow, nanjekyejoannah, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_interpreters test_interpreters leaked [216, 216, 216] references
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Tue May 26 13:33:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 May 2020 17:33:00 +0000
Subject: [New-bugs-announce] [issue40784] test_sqlite:
 CheckFuncDeterministic() fails with SQLite 3.32
Message-ID: <1590514380.08.0.324391488999.issue40784@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

With SQLite 3.32, test_sqlite fails with:

FAIL: CheckFuncDeterministic (sqlite3.test.userfunctions.FunctionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.9.0b1/Lib/sqlite3/test/userfunctions.py", line 290, in CheckFuncDeterministic
    self.assertEqual(mock.call_count, 1)
AssertionError: 2 != 1

This test defines a "deterministic" function and ensures that calling it twice in SQLite with only call the underyling Python function only once.

Copy of the test:

    @unittest.skipIf(sqlite.sqlite_version_info < (3, 8, 3), "deterministic parameter not supported")
    def CheckFuncDeterministic(self):
        mock = unittest.mock.Mock(return_value=None)
        self.con.create_function("deterministic", 0, mock, deterministic=True)
        self.con.execute("select deterministic() = deterministic()")
        self.assertEqual(mock.call_count, 1)

In pysqlite_connection_create_function() of Modules/_sqlite/connection.c, determistic=1 sets the following flag:

        flags |= SQLITE_DETERMINISTIC;

This flag is documented as:
"A deterministic function always gives the same answer when it has the same inputs."

* https://www.sqlite.org/deterministic.html
* https://www.sqlite.org/c3ref/c_deterministic.html

"SELECT 1 WHERE deterministic() = deterministic()" query also calls the mock twice.

Running "SELECT deterministic()" query twice also calls the mock twice.

It seems like SQLite 3.32 behaves differently.

Fedora issue: https://bugzilla.redhat.com/show_bug.cgi?id=1839826

----------
components: Tests
messages: 370022
nosy: ghaering, vstinner
priority: normal
severity: normal
status: open
title: test_sqlite: CheckFuncDeterministic() fails with SQLite 3.32
versions: Python 3.10

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

From report at bugs.python.org  Tue May 26 16:44:43 2020
From: report at bugs.python.org (Enji Cooper)
Date: Tue, 26 May 2020 20:44:43 +0000
Subject: [New-bugs-announce] [issue40785] `mmap.mmap(..., 0)` doesn't work
 as advertised in docs (fails with EINVAL);
 relies on compatibility behavior no longer permitted by [some] Unix OSes
Message-ID: <1590525883.45.0.922905943745.issue40785@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

The documentation for mmap.mmap() claims that passing a length of 0 will map in an entire file, but unfortunately that doesn't work as shown below:

>>> mmap.mmap(-1, 0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

I've double-checked that this isn't an OS specific bug on the following OS platforms:

* Fedora 31
* FreeBSD 
* OSX Catalina

The errno == EINVAL issue is documented in the OS X Catalina manpage as follows:

```
     [EINVAL]           The len argument was negative or zero. Historically, the system call would not return an error if the argument was zero.  See other potential additional
                        restrictions in the COMPATIBILITY section below.

...

COMPATIBILITY
     mmap() now returns with errno set to EINVAL in places that historically succeeded.  The rules have changed as follows:

     o   The flags parameter must specify either MAP_PRIVATE or MAP_SHARED.

     o   The len parameter must not be 0.

     o   The off parameter must be a multiple of pagesize, as returned by sysconf().
```

POSIX concurs: https://pubs.opengroup.org/onlinepubs/9699919799/ .

So, in short -- python's mmap.mmap(.., 0) implementation relies on behavior which is now not permitted in multiple OSes and is not permitted per the POSIX spec for mmap(2).

1. https://docs.python.org/3/library/mmap.html#mmap.mmap

----------
components: Interpreter Core
messages: 370029
nosy: ngie
priority: normal
severity: normal
status: open
title: `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails with EINVAL); relies on compatibility behavior no longer permitted by [some] Unix OSes
versions: Python 3.8

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

From report at bugs.python.org  Tue May 26 18:30:35 2020
From: report at bugs.python.org (Enji Cooper)
Date: Tue, 26 May 2020 22:30:35 +0000
Subject: [New-bugs-announce] [issue40786] madvise should be accessible
 outside of mmap instance
Message-ID: <1590532235.06.0.164268406367.issue40786@roundup.psfhosted.org>


New submission from Enji Cooper <yaneurabeya at gmail.com>:

madvise can be used when manipulating mmap'ed pages, but it can also be used when protecting processes and other things.

Having madvise be available in mmap as a function would be helpful instead of having to jump through a lot of hoops to run `MADV_PROTECT` on a process.

----------
messages: 370036
nosy: ngie
priority: normal
severity: normal
status: open
title: madvise should be accessible outside of mmap instance
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue May 26 21:50:46 2020
From: report at bugs.python.org (Lucas)
Date: Wed, 27 May 2020 01:50:46 +0000
Subject: [New-bugs-announce] [issue40787] Mysql + unittest crash
Message-ID: <1590544246.45.0.611703260783.issue40787@roundup.psfhosted.org>


New submission from Lucas <lgerosa2002 at gmail.com>:

environment: win10 cmd, python 3.8 32-bit, mysql, unittest

description: When restoring a database through mysql in a unittest function, the command prompt freezes before giving the result of the test, and I am forced to close it to quit.

steps to replicate: Have mysql installed, create a database with some content, dump the latter in a file, create a unit test using python's unittest with at least two test functions, and restore the file in one of them.

----------
components: Library (Lib)
messages: 370039
nosy: lgerosa
priority: normal
severity: normal
status: open
title: Mysql + unittest crash
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Tue May 26 22:58:42 2020
From: report at bugs.python.org (Warren Hardy)
Date: Wed, 27 May 2020 02:58:42 +0000
Subject: [New-bugs-announce] [issue40788] Build issue Solaris 10 Sparc
Message-ID: <1590548322.5.0.995785667003.issue40788@roundup.psfhosted.org>


New submission from Warren Hardy <munkees at mac.com>:

I am using Solaris 10 (last oracle release). GCC 5.5.0

I had trouble with _ssl not building it was failing out with sethostname reference

I fixed this by removing the  -Werror=implicit-function-declaration

My main issue is that _ctypes is not being built and I am not sure why. I have googled for an answer, I have not found one. 

please can somebody explain simply how I rectify this problem. 

Thank you in advanced

----------
assignee: christian.heimes
components: SSL, ctypes
messages: 370041
nosy: christian.heimes, munocat
priority: normal
severity: normal
status: open
title: Build issue Solaris 10 Sparc
versions: Python 3.8

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

From report at bugs.python.org  Tue May 26 23:56:31 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Wed, 27 May 2020 03:56:31 +0000
Subject: [New-bugs-announce] [issue40789] C-level destructor in PySide2
 breaks gen_send_ex,
 which assumes it's safe to call Py_DECREF with a live exception
Message-ID: <1590551791.79.0.515609150701.issue40789@roundup.psfhosted.org>


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

Consider the following short program. demo() is a trivial async function that creates a QObject instance, connects a Python signal, and then exits. When we call `send(None)` on this object, we expect to get a StopIteration exception.

-----

from PySide2 import QtCore

class MyQObject(QtCore.QObject):
    sig = QtCore.Signal()

async def demo():
    myqobject = MyQObject()
    myqobject.sig.connect(lambda: None)
    return 1

coro = demo()
try:
    coro.send(None)
except StopIteration as exc:
    print(f"OK: got {exc!r}")
except SystemError as exc:
    print(f"WTF: got {exc!r}")

-----

Actual output (tested on 3.8.2, but I think the code is present on all versions):

-----
StopIteration: 1
WTF: got SystemError("<method 'send' of 'coroutine' objects> returned NULL without setting an error")
-----

So there are two weird things here: the StopIteration exception is being printed on the console for some reason, and then the actual `send` method is raising SystemError instead of StopIteration.

Here's what I think is happening:

In genobject.c:gen_send_ex, when the coroutine finishes, we call _PyGen_SetStopIterationValue to raise the StopIteration exception:

https://github.com/python/cpython/blob/404b23b85b17c84e022779f31fc89cb0ed0d37e8/Objects/genobject.c#L241

Then, after that, gen_send_ex clears the frame object and drops references to it:

https://github.com/python/cpython/blob/404b23b85b17c84e022779f31fc89cb0ed0d37e8/Objects/genobject.c#L266-L273

At this point, the reference count for `myqobject` drops to zero, so its destructor is invoked. And this destructor ends up clearing the current exception again. Here's a stack trace:

-----
#0  0x0000000000677eb7 in _PyErr_Fetch (p_traceback=0x7ffd9fda77d0, 
    p_value=0x7ffd9fda77d8, p_type=0x7ffd9fda77e0, tstate=0x2511280)
    at ../Python/errors.c:399
#1  _PyErr_PrintEx (tstate=0x2511280, set_sys_last_vars=1) at ../Python/pythonrun.c:670
#2  0x00007f1afb455967 in PySide::GlobalReceiverV2::qt_metacall(QMetaObject::Call, int, void**) ()
   from /home/njs/.user-python3.8/lib/python3.8/site-packages/PySide2/libpyside2.abi3.so.5.14
#3  0x00007f1afaf2f657 in void doActivate<false>(QObject*, int, void**) ()
   from /home/njs/.user-python3.8/lib/python3.8/site-packages/PySide2/Qt/lib/libQt5Core.so.5
#4  0x00007f1afaf2a37f in QObject::destroyed(QObject*) ()
   from /home/njs/.user-python3.8/lib/python3.8/site-packages/PySide2/Qt/lib/libQt5Core.so.5
#5  0x00007f1afaf2d742 in QObject::~QObject() ()
   from /home/njs/.user-python3.8/lib/python3.8/site-packages/PySide2/Qt/lib/libQt5Core.so.5
#6  0x00007f1afb852681 in QObjectWrapper::~QObjectWrapper() ()
   from /home/njs/.user-python3.8/lib/python3.8/site-packages/PySide2/QtCore.abi3.so
#7  0x00007f1afbf785bb in SbkDeallocWrapperCommon ()
   from /home/njs/.user-python3.8/lib/python3.8/site-packages/shiboken2/libshiboken2.abi3.so.5.14
#8  0x00000000005a4fbc in subtype_dealloc (self=<optimized out>)
    at ../Objects/typeobject.c:1289
#9  0x00000000005e8c08 in _Py_Dealloc (op=<optimized out>) at ../Objects/object.c:2215
#10 _Py_DECREF (filename=0x881795 "../Objects/frameobject.c", lineno=430, 
    op=<optimized out>) at ../Include/object.h:478
#11 frame_dealloc (f=Frame 0x7f1afc572dd0, for file qget-min.py, line 12, in demo ())
    at ../Objects/frameobject.c:430
#12 0x00000000004fdf30 in _Py_Dealloc (
    op=Frame 0x7f1afc572dd0, for file qget-min.py, line 12, in demo ())
    at ../Objects/object.c:2215
#13 _Py_DECREF (filename=<synthetic pointer>, lineno=279, 
    op=Frame 0x7f1afc572dd0, for file qget-min.py, line 12, in demo ())
    at ../Include/object.h:478
#14 gen_send_ex (gen=0x7f1afbd08440, arg=<optimized out>, exc=<optimized out>, 
    closing=<optimized out>) at ../Objects/genobject.c:279

------

We can read the source for PySide::GlobalReceiverV2::qt_metacall here: https://sources.debian.org/src/pyside2/5.13.2-3/sources/pyside2/libpyside/globalreceiverv2.cpp/?hl=310#L310

And we see that it (potentially) runs some arbitrary Python code, and then handles any exceptions by doing:

if (PyErr_Occurred()) {
    PyErr_Print();
}

This is intended to catch exceptions caused by the code it just executed, but in this case, gen_send_ex ends up invoking it with an exception already active, so PySide2 gets confused and clears the StopIteration.

-----------------------------------

OK so... what to do. I'm actually not 100% certain whether this is a CPython bug or a PySide2 bug.

In PySide2, it could be worked around by saving the exception state before executing that code, and then restoring it afterwards.

In gen_send_ex, it could be worked around by dropping the reference to the frame before setting the StopIteration exception.

In CPython in general, it could be worked around by not invoking deallocators with a live exception... I'm actually pretty surprised that this is even possible! It seems like having a live exception when you start executing arbitrary Python code would be bad. So maybe that's the real bug? Adding both "asyncio" and "memory management" interest groups to the nosy.

----------
messages: 370046
nosy: asvetlov, lemburg, njs, tim.peters, twouters, yselivanov
priority: normal
severity: normal
status: open
title: C-level destructor in PySide2 breaks gen_send_ex, which assumes it's safe to call Py_DECREF with a live exception
versions: Python 3.10, 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/issue40789>
_______________________________________

From report at bugs.python.org  Wed May 27 03:13:03 2020
From: report at bugs.python.org (laike9m)
Date: Wed, 27 May 2020 07:13:03 +0000
Subject: [New-bugs-announce] [issue40790] Python should enable computed
 gotos on Mac by default
Message-ID: <1590563583.44.0.646993465948.issue40790@roundup.psfhosted.org>


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

Issue is described here with more details:
https://stackoverflow.com/q/61860463/2142577

Basically, when building on Mac, Python should enable computed gotos by default, because it is supported (https://stackoverflow.com/a/62037189/2142577).

The documentation(https://docs.python.org/3/whatsnew/3.2.html#build-and-c-api-changes) says
> Computed gotos are now enabled by default on supported compilers (which are detected by the configure script). They can still be disabled selectively by specifying --without-computed-gotos.

This seems to imply that the capability detection is wrong.

----------
components: macOS
messages: 370051
nosy: laike9m, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python should enable computed gotos on Mac by default
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed May 27 03:41:07 2020
From: report at bugs.python.org (Devin Jeanpierre)
Date: Wed, 27 May 2020 07:41:07 +0000
Subject: [New-bugs-announce] [issue40791] hmac.compare_digest could try
 harder to be constant-time.
Message-ID: <1590565267.04.0.961881522519.issue40791@roundup.psfhosted.org>


New submission from Devin Jeanpierre <jeanpierreda at gmail.com>:

`hmac.compare_digest` (via `_tscmp`) does not mark the accumulator variable `result` as volatile, which means that the compiler is allowed to short-circuit the comparison loop as long as it still reads from both strings.

In particular, when `result` is non-volatile, the compiler is allowed to change the loop from this:


```c
for (i=0; i < length; i++) {
    result |= *left++ ^ *right++;
}
return (result == 0);
```

into (the moral equivalent of) this:


```c
for (i=0; i < length; i++) {
    result |= *left++ ^ *right++;
    if (result) {
        for (; ++i < length;) {
            *left++; *right++;
        }
        return 1;
    }
}
return (result == 0);
```

(Code not tested.)

This might not seem like much, but it cuts out almost all of the data dependencies between `result`, `left`, and `right`, which in theory would free the CPU to race ahead using out of order execution -- it could execute code that depends on the result of `_tscmp`, even while `_tscmp` is still performing the volatile reads. (I have not actually benchmarked this. :)) In other words, this weird short circuiting could still actually improve performance. That, in turn, means that it would break constant-time guarantees.

(This is different from saying that it _would_ increase performance, but marking it volatile removes the worry.)

(Prior art/discussion: https://github.com/google/tink/commit/335291c42eecf29fca3d85fed6179d11287d253e )


I propose two changes, one trivial, and one that's more invasive:

1) Make `result` a `volatile unsigned char` instead of `unsigned char`. 

2) When SSL is available, instead use `CRYPTO_memcmp` from OpenSSL/BoringSSL. We are, in effect, "rolling our own crypto". The SSL libraries are more strictly audited for timing issues, down to actually checking the generated machine code. As tools improve, those libraries will grow to use those tools. If we use their functions, we get the benefit of those audits and improvements.

----------
components: Library (Lib)
messages: 370053
nosy: Devin Jeanpierre
priority: normal
severity: normal
status: open
title: hmac.compare_digest could try harder to be constant-time.
versions: Python 3.10, 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/issue40791>
_______________________________________

From report at bugs.python.org  Wed May 27 03:57:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 May 2020 07:57:47 +0000
Subject: [New-bugs-announce] [issue40792] Make PyNumber_Index() always
 returning an exact int instance
Message-ID: <1590566267.28.0.18988326269.issue40792@roundup.psfhosted.org>


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

Currently PyNumber_Index() can return something that's an instance of a strict subclass of int. For example PyNumber_Index(Py_True) returns Py_True. The same for operator.index():

>>> import operator
>>> operator.index(True)
True

The proposed PR makes it always return an int.

To avoid possible overhead for creating temporary integer object, added private function _PyNumber_Index() with the past behavior. It can be used for short-living integer objects which for which only its value will be used, but not its methods. For example in the implementation of PyLong_AsLong() and similar functions.

See also issue17576.

----------
components: Interpreter Core
messages: 370054
nosy: barry, mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make PyNumber_Index() always returning an exact int instance
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed May 27 08:03:59 2020
From: report at bugs.python.org (U.W.)
Date: Wed, 27 May 2020 12:03:59 +0000
Subject: [New-bugs-announce] [issue40793] print() performance problem with
 very large numbers
Message-ID: <1590581039.49.0.292614137466.issue40793@roundup.psfhosted.org>


New submission from U.W. <ulrich.wittenberg at web.de>:

Printing very large numbers takes forever.

Example:
print((2**24)**(3840*2160))

That number has about 60 Million digits and my machine is busy now for more than an hour and still not finished.

The calculation of the number is no problem, btw. and finishes in under a second.

----------
components: Interpreter Core
messages: 370066
nosy: U.W.
priority: normal
severity: normal
status: open
title: print() performance problem with very large numbers
versions: Python 3.6

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

From report at bugs.python.org  Wed May 27 08:48:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 27 May 2020 12:48:52 +0000
Subject: [New-bugs-announce] [issue40794] dataclass signatures and
 docstrings w/future-annotations
Message-ID: <1590583732.13.0.63871735416.issue40794@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

While I was working on making 'future annotations' default, I noticed that dataclasses acts differently under the annotation feature. One example would be the file [signature.py]:

[ without future import]
 $ python t.py
X(a: int, b: int)
[ with future import]
 $ python t.py
X(a: '_type_a', b: '_type_b') -> '_return_type'

This is causing too much test to fail,
AssertionError: '_return_type' is not None

- C(x:'_type_x')->'_return_type'
+ C(x:collections.deque)

- C(x:'_type_x'=<factory>)->'_return_type'
+ C(x:collections.deque=<factory>)

- C(x:'_type_x')->'_return_type'
+ C(x:List[int])

(and more)

----------
files: script.py
messages: 370073
nosy: BTaskaya, eric.smith
priority: normal
severity: normal
status: open
title: dataclass signatures and docstrings w/future-annotations
Added file: https://bugs.python.org/file49195/script.py

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

From report at bugs.python.org  Wed May 27 10:44:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 May 2020 14:44:18 +0000
Subject: [New-bugs-announce] [issue40795] ctypes: PyErr_WriteUnraisable()
 called with no exception set on converting callback result failure
Message-ID: <1590590658.49.0.612790938119.issue40795@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Example:
---
from ctypes import c_int, CFUNCTYPE

def func():
    return (1, 2, 3)

cb = CFUNCTYPE(c_int)(func)
cb()
---

Output:
---
Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 262, in 'converting callback result'
TypeError: an integer is required (got type tuple)
Exception ignored in: <function func at 0x7f0c267ff1f0>
---

Assertion error in debug mode:
---
Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 262, in 'converting callback result'
TypeError: 'tuple' object cannot be interpreted as an integer
python: Python/errors.c:1435: _PyErr_WriteUnraisableMsg: Assertion `exc_type != NULL' failed.
Abandon (core dumped)
---

Attached PR fix the issue.

----------
components: Library (Lib)
messages: 370089
nosy: vstinner
priority: normal
severity: normal
status: open
title: ctypes: PyErr_WriteUnraisable() called with no exception set on converting callback result failure
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Wed May 27 13:23:17 2020
From: report at bugs.python.org (Darrick Yee)
Date: Wed, 27 May 2020 17:23:17 +0000
Subject: [New-bugs-announce] [issue40796] dataclasses.make_dataclass:
 Exception when called with different field orders
Message-ID: <1590600197.98.0.468559404003.issue40796@roundup.psfhosted.org>


New submission from Darrick Yee <darrick.yee at gmail.com>:

https://docs.python.org/3/library/dataclasses.html#module-dataclasses

`make_dataclass` takes a `field` parameter, which is an iterable whose entries may be tuples of `(name, type)` or `(name, type, dataclasses.Field)`.  However, an exception is thrown if such tuples are provided in a particular order.  Example:


from dataclasses import field, make_dataclass

fieldspec1 = ('field1', str)
fieldspec2 = ('field2', str, field(default='Hello'))

MyDc1 = make_dataclass('MyDc1', [fieldspec1, fieldspec2]) # Ok
MyDc2 = make_dataclass('MyDc2', [fieldspec2, fieldspec1]) # TypeError

I am guessing this is not intentional...

----------
messages: 370112
nosy: Darrick Yee
priority: normal
severity: normal
status: open
title: dataclasses.make_dataclass: Exception when called with different field orders
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed May 27 16:27:22 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 27 May 2020 20:27:22 +0000
Subject: [New-bugs-announce] [issue40797] multiprocessing.Semaphore has
 undocumented get_value() method
Message-ID: <1590611242.05.0.840609180281.issue40797@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

The threading.Semaphore class does not have this method, it is undocumented and useless on some system (at least MacOS):

>>> s.get_value()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/multiprocessing/synchronize.py", line 129, in get_value
    return self._semlock._get_value()
NotImplementedError



The implementation is at https://github.com/python/cpython/blob/master/Modules/_multiprocessing/semaphore.c#L537-L553

I think this method could be removed, since it's undocumented and probably not used can I just remove it or does it need a deprecation cycle?

----------
components: Library (Lib)
messages: 370128
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: multiprocessing.Semaphore has undocumented get_value() method
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Wed May 27 17:56:58 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 27 May 2020 21:56:58 +0000
Subject: [New-bugs-announce] [issue40798] The deprecated-removed Sphinx
 extension need to change the error message based on the Python version
Message-ID: <1590616618.29.0.703498404088.issue40798@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

The new deprecated-removed extension in the documentation always produces text like this:

   Deprecated since version 3.4, will be removed in version 3.8: MD5 as implicit default digest

This message should be used in the documentation of 3.4 to 3.7 and then it should produce:

   Deprecated since version 3.4, removed in version 3.8: MD5 as implicit default digest

I'm not sure if Sphinx knows which Python version it is building the documentation for.

This is the only instance were this is used with a version less than 3.9 so all other messages are currently correct.

I think a new contributor should be able to fix this.

----------
assignee: docs at python
components: Documentation
messages: 370141
nosy: docs at python, remi.lapeyre
priority: normal
severity: normal
status: open
title: The deprecated-removed Sphinx extension need to change the error message based on the Python version
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed May 27 20:06:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 May 2020 00:06:58 +0000
Subject: [New-bugs-announce] [issue40799] Create Lib/_pydecimal.py file to
 optimize "import datetime" when _decimal is available
Message-ID: <1590624418.05.0.296780868092.issue40799@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, "import datetime" starts by importing time, math, sys and operator modules, and then execute 2500 lines of Python code, define 7 classes, etc. For what? Just to remove all classes, functions, etc. to replace them with symbols from _decimal module:
---
try:
    from _datetime import *
except ImportError:
    pass
else:
    # Clean up unused names
    del (_DAYNAMES, _DAYS_BEFORE_MONTH, _DAYS_IN_MONTH, _DI100Y, _DI400Y,
         _DI4Y, _EPOCH, _MAXORDINAL, _MONTHNAMES, _build_struct_time,
         _check_date_fields, _check_time_fields,
         _check_tzinfo_arg, _check_tzname, _check_utc_offset, _cmp, _cmperror,
         _date_class, _days_before_month, _days_before_year, _days_in_month,
         _format_time, _format_offset, _index, _is_leap, _isoweek1monday, _math,
         _ord2ymd, _time, _time_class, _tzinfo_class, _wrap_strftime, _ymd2ord,
         _divide_and_round, _parse_isoformat_date, _parse_isoformat_time,
         _parse_hh_mm_ss_ff, _IsoCalendarDate)
    # XXX Since import * above excludes names that start with _,
    # docstring does not get overwritten. In the future, it may be
    # appropriate to maintain a single module level docstring and
    # remove the following line.
    from _datetime import __doc__
---

I would prefer to use the same approach than the decimal module which also has large C and Python implementation. Lib/decimal.py is just:
---
try:
    from _decimal import *
    from _decimal import __doc__
    from _decimal import __version__
    from _decimal import __libmpdec_version__
except ImportError:
    from _pydecimal import *
    from _pydecimal import __doc__
    from _pydecimal import __version__
    from _pydecimal import __libmpdec_version__
---

Advantages:

* Faster import time
* Avoid importing indirectly time, math, sys and operator modules, whereas they are not used

IMO it also better separate the C and the Python implementations.


Attached PR implements this idea.


Currently, "import datetime" imports 4 modules:

  ['_operator', 'encodings.ascii', 'math', 'operator']

With the PR, "import datetime"  imports only 1 module:

  ['encodings.ascii']

Import performance:

  [ref] 814 us +- 32 us -> [change] 189 us +- 4 us: 4.31x faster (-77%)

Measured by:

  env/bin/python -m pyperf timeit -s 'import sys' 'import datetime; del sys.modules["datetime"]; del sys.modules["_datetime"]; del datetime'


Note: I noticed that "import datetime" imports the math module while working on minimizing "import test.support" imports, bpo-40275.

----------
components: Library (Lib)
messages: 370153
nosy: vstinner
priority: normal
severity: normal
status: open
title: Create Lib/_pydecimal.py file to optimize "import datetime" when _decimal is available
versions: Python 3.10

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

From report at bugs.python.org  Thu May 28 01:36:59 2020
From: report at bugs.python.org (Davy Durham)
Date: Thu, 28 May 2020 05:36:59 +0000
Subject: [New-bugs-announce] [issue40800] asyncio.sleep(0) should "yield"
 back to the event loop, but it doesn't behave as expected
Message-ID: <1590644219.7.0.394616254827.issue40800@roundup.psfhosted.org>


New submission from Davy Durham <davydurham at gmail.com>:

I was searching for a way to "yield" from task/coroutinue back to the event loop (not yielding a value in terms of a generator) and not finding anything documented, I found this bug report and PR: 
   https://github.com/python/asyncio/issues/284

It states that asyncio.sleep(0) should cause the coroutine to send control back to the event loop without wastefully doing other work.  That makes sense and a perfectly good way to do that.

And, the code appears to handle a value of <= 0 specifically: https://github.com/python/cpython/blob/3.8/Lib/asyncio/tasks.py#L632

However, using sleep(0) to yield back does not cause it to raise a CancelledError if the task has been cancelled as cancel()'s documentation indicates it should.  But sleeping for anything >0 does (e.g. 0.001)

The below code snippet will demonstrate the problem:

TIA

----

import asyncio
import time

async def cancel_me():
    print('cancel_me(): before sleep')

    try:
        while True:
            print("doing some really intensive cpu stuff")
            time.sleep(2)

            # now I want to yield control back to the event loop in order to determine if we've been cancelled 
            await asyncio.sleep(0) # I'm expecting this to throw CancelledError, but it never does.. it DOES throw if the delay > 0 (e.g. 0.001)

    except asyncio.CancelledError:
        print('cancel_me(): cancelled!')
        raise



async def main():
    task = asyncio.create_task(cancel_me())

    await asyncio.sleep(1)

    task.cancel()
    try:
        await task
    except asyncio.CancelledError:
        print("main(): cancel_me is cancelled now")

asyncio.run(main())

----------
components: asyncio
messages: 370164
nosy: Davy Durham, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.sleep(0) should "yield" back to the event loop, but it doesn't behave as expected
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu May 28 05:23:06 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 28 May 2020 09:23:06 +0000
Subject: [New-bugs-announce] [issue40801] Expose PyFloat_ToDouble at Python
 level: operator.to_float?
Message-ID: <1590657786.78.0.118668826809.issue40801@roundup.psfhosted.org>


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

Motivation
----------

Various pieces of Python need to do a duck-typed conversion of an arbitrary float-like object to a float (or a C double) for computation. The math module is the most obvious example - most math-module functions that accept a float also accept float-like things, like np.float32 and Decimal - but it's not the only place that this is needed.

This conversion is easy at C level, being encapsulated in a single function call: PyFloat_AsDouble. (Plus a PyFloat_FromDouble if you want to go back to Python space, of course.)

But: it's surprisingly awkward to get an equivalent effect in pure Python code. Options are:

1. Do an explicit type check to exclude str, bytes and bytearray, and then call the float constructor. But the extra type check is ugly and potentially not future-proof.

2. Call type(obj).__float__(obj). But this has several problems: __float__ can return an instance of a float subclass rather than a strict float, and then it's hard to convert to an actual float. And in more recent versions of Python, this no longer matches PyFloat_AsDouble because it doesn't account for objects that provide __index__ but not __float__. And calling dunder methods directly should rarely be the Right Way To Do It.

3. Use the implicit ability of the math module to do this, for example using math.copysign(obj, obj). This works! But it's not a clear expression of the intent.

This has bitten me in Real Code (TM), where I've needed a way to convert an arbitrary float-like thing to a float, ideally following the same rules that Python uses. And also ideally in such a way that my own code doesn't have to change if Python updates its rules, as for example it did recently to allow things with an __index__ to be considered float-like.


Proposal
--------

Add a new operator function "operator.as_float" which matches Python's duck-typed acceptance of float-like things, in the same way that the existing operator.index matches Python's implicit acceptance of int-like things in various APIs that expect integers.

Internally, "operator.as_float" would simply call PyFloat_AsDouble followed by PyFloat_FromDouble (possibly with a fast path to pass objects of exact type float through directly).



Related: #17576.

----------
messages: 370181
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Expose PyFloat_ToDouble at Python level: operator.to_float?
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Thu May 28 05:31:51 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 28 May 2020 09:31:51 +0000
Subject: [New-bugs-announce] [issue40802]
 AbstractEventLoop.shutdown_default_executor breaks backwards compatibility
Message-ID: <1590658311.02.0.725664008315.issue40802@roundup.psfhosted.org>


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

In bpo-34037, AbstractEventLoop gained a new abstract method, shutdown_default_executor:
https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.loop.shutdown_default_executor

All AbstractEventLoop subclasses need to define this method, otherwise they are not compatible with Python 3.9's asyncio. It seems that the anyio and uvloop projects are affected: https://github.com/agronholm/anyio/issues/110

This is mentioned in What's New: https://docs.python.org/dev/whatsnew/3.9.html#changes-in-the-python-api

I'd like to make extra sure asyncio experts know about this backwards incompatibility.
Since asyncio is no longer provisional, should it break backwards compatibility with just a What's New entry?

----------
components: asyncio
messages: 370182
nosy: asvetlov, petr.viktorin, yselivanov
priority: normal
severity: normal
status: open
title: AbstractEventLoop.shutdown_default_executor breaks backwards compatibility
versions: Python 3.9

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

From report at bugs.python.org  Thu May 28 05:46:22 2020
From: report at bugs.python.org (Robin)
Date: Thu, 28 May 2020 09:46:22 +0000
Subject: [New-bugs-announce] [issue40803] Unable to execute python.exe from
 zip in wine
Message-ID: <1590659182.08.0.861288349289.issue40803@roundup.psfhosted.org>


New submission from Robin <robin at clanmills.com>:

I've downloaded python38.zip(and python32.zip).  It doesn't run because it's using an API `PathCchCanonicalizeEx()` that's not provided in wine.

```
Z:\home\rmills\temp\python-3>wine: Call from 0x7b43cfbc to unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCanonicalizeEx, aborting
wine: Unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCanonicalizeEx called at address 0x7bc50023:0x7b43cfbc (thread 0034), starting debugger...
Unhandled exception: unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCanonicalizeEx called in 32-bit code (0x7b43cfbc).
```

----------
components: Windows
messages: 370183
nosy: clanmills, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to execute python.exe from zip in wine
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Thu May 28 06:02:25 2020
From: report at bugs.python.org (amansi26)
Date: Thu, 28 May 2020 10:02:25 +0000
Subject: [New-bugs-announce] [issue40804] Bug report in python3.6.8 using
 argparse module
Message-ID: <1590660145.62.0.878153960448.issue40804@roundup.psfhosted.org>


New submission from amansi26 <amansi26 at in.ibm.com>:

I am using 3.6.8 version of python.
I am seeing an error as AttributeError: 'Namespace' object has no attribute 'func' while using argparse . The code is working fine with python2.7 argparser.

I see a similar bug [4] reported at python 3.3 and  python3.4. The workaround mentioned works fine for a single level command.
 
Scenarios:
- If there is one command and various subcommands, like [1].The solution works fine.
- But suppose I have a command with mutiple level of subcommands like [2]. In this case if I give [3] as a command the ArgumentParser.prog() takes just the first command as input in this 
  case (open-stack). Hence the parser.print_usage prints [1].
 
 [1] [2] [3]   https://bpa.st/PUPA
 
[4]  https://bugs.python.org/issue16308

----------
messages: 370184
nosy: amansi26
priority: normal
severity: normal
status: open
title: Bug report in python3.6.8 using argparse module
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu May 28 08:19:57 2020
From: report at bugs.python.org (Rob Taft)
Date: Thu, 28 May 2020 12:19:57 +0000
Subject: [New-bugs-announce] [issue40805] Can no longer patch flask.g
Message-ID: <1590668397.14.0.891806096405.issue40805@roundup.psfhosted.org>


New submission from Rob Taft <rrtaft at gmail.com>:

Whenever I try to patch flask.g, it appears to do nothing.  This happened when I upgraded mock from 3.x to 4.x.  I reported it on the mock github page https://github.com/testing-cabal/mock/issues/490 and was asked to report it here.  The folllowing code run with pytest works fine in mock 3.0.5, but fails to patch in 4.0.0 and up.

from mock import patch

import flask


def some_function():
    flask.g.somevariable = True
    return flask.g.somevariable


@patch('flask.g')
def test_some_function(mock_flask_global):
    assert some_function()

----------
components: Tests
messages: 370197
nosy: Rob Taft
priority: normal
severity: normal
status: open
title: Can no longer patch flask.g
type: behavior
versions: Python 3.6, Python 3.8

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

From report at bugs.python.org  Thu May 28 08:55:46 2020
From: report at bugs.python.org (Ramil Nugmanov)
Date: Thu, 28 May 2020 12:55:46 +0000
Subject: [New-bugs-announce] [issue40806] itertools.product not lazy
Message-ID: <1590670546.03.0.0667180087022.issue40806@roundup.psfhosted.org>


New submission from Ramil Nugmanov <nougmanoff at hotmail.com>:

def x(y):
    while True:
        yield y

p = product(x(1), x(2))

next(p)  # this string will never be reached.

----------
components: Library (Lib)
messages: 370201
nosy: nougmanoff
priority: normal
severity: normal
status: open
title: itertools.product not lazy
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu May 28 09:55:08 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 28 May 2020 13:55:08 +0000
Subject: [New-bugs-announce] [issue40807] CODEOP: Show warnings once during
 _maybe_compile
Message-ID: <1590674108.19.0.341062869134.issue40807@roundup.psfhosted.org>


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

When calling `codeop._maybe_compile`, `compile` is run three times.  If the code being compiled causes a warning message, the warning is generated each time that `compile` is called, thus (possibly) showing the message three times.


See msg370163 and that issue for context.

----------
components: Library (Lib)
messages: 370208
nosy: cheryl.sabella
priority: normal
severity: normal
status: open
title: CODEOP: Show warnings once during _maybe_compile
type: enhancement
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu May 28 09:56:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 May 2020 13:56:01 +0000
Subject: [New-bugs-announce] [issue40808] test_venv fails with HOME=/ on
 AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1590674161.97.0.214019790638.issue40808@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

test_venv fails on AMD64 FreeBSD Non-Debug 3.x since this build:
https://buildbot.python.org/all/#/builders/214/builds/808

This build has 3 changes. IMHO the regression comes from the commit feb0846c3a28b05b4cfbc6ab34c764957f3eff55: "Upgrade bundled versions of pip & setuptools (#16782)" (bpo-38488).

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/test/test_venv.py", line 535, in test_with_pip
    self.do_test_with_pip(False)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/test/test_venv.py", line 518, in do_test_with_pip
    self.assertEqual(err.rstrip(), "")
AssertionError: "WARNING: The directory '/.cache/pip' or [206 chars]lag." != ''
- WARNING: The directory '/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
+ 



test.pythoninfo says:

os.environ[HOME]: /
pwd.getpwuid(1002): pwd.struct_passwd(pw_name='buildbot', pw_passwd='*', pw_uid=1002, pw_gid=1002, pw_gecos='FreeBSD BuildBot', pw_dir='/home/buildbot', pw_shell='/bin/sh')
os.getuid: 1002
os.login: koobs
os.getgid: 1002
os.getgrouplist: 1002
os.getgroups: 1002

----------
components: Tests
messages: 370209
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_venv fails with HOME=/ on AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.10

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

From report at bugs.python.org  Thu May 28 12:33:22 2020
From: report at bugs.python.org (chirag maliwal)
Date: Thu, 28 May 2020 16:33:22 +0000
Subject: [New-bugs-announce] [issue40809] list.Count() isn't working as
 expected for the series of same numbers in a list
Message-ID: <1590683602.43.0.57315900745.issue40809@roundup.psfhosted.org>


New submission from chirag maliwal <chiragmaliwal1995 at gmail.com>:

a = [1,1,1,1]

for i in a:
    if a.count(i) > 1:
        a.remove(i)
 
print(a)


"""
Output:
[1,1]


expected:
[1]
"""

----------
files: test.py
messages: 370239
nosy: cmaliwal
priority: normal
severity: normal
status: open
title: list.Count() isn't working as expected for the series of same numbers in a list
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49200/test.py

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

From report at bugs.python.org  Thu May 28 13:47:38 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 28 May 2020 17:47:38 +0000
Subject: [New-bugs-announce] [issue40810] sqlite3 test
 CheckTraceCallbackContent fails for sqlite v3.7.3 through 3.7.14.1
Message-ID: <1590688058.38.0.22519081316.issue40810@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

`CheckTraceCallbackContent()` in `Lib/sqlite3/test/hooks.py` fails for SQLite versions 3.7.3 through 3.7.14.1, apparently because of an SQLite bug that was fixed in 3.7.15 (2012-12-12). Extract from the changelog https://sqlite.org/changes.html:
```
Avoid invoking the sqlite3_trace() callback multiple times when a statement is automatically reprepared due to SQLITE_SCHEMA errors.
```

Either we fix tests for SQLite < 3.7.15, or we drop support for SQLite < 3.7.15. (I'm +1 for the latter.)

NB: Versions pre 3.7.3 does not build at all, because of `sqlite3_create_function_v2()`. See bpo-40744 and GH-20330.

----------
components: Library (Lib)
messages: 370256
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: sqlite3 test CheckTraceCallbackContent fails for sqlite v3.7.3 through 3.7.14.1
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu May 28 13:54:39 2020
From: report at bugs.python.org (Christian Exposito)
Date: Thu, 28 May 2020 17:54:39 +0000
Subject: [New-bugs-announce] [issue40811] Allow to create new Event Loops on
 Threads
Message-ID: <1590688479.36.0.418054824205.issue40811@roundup.psfhosted.org>


New submission from Christian Exposito <chexca20 at gmail.com>:

Right now, Async IO module is not automatically creating a new event loop on threads that are not the main thread (https://github.com/python/cpython/blob/master/Lib/asyncio/events.py#L638), but it should be interesting to do it. For example, WSGI applications handle web requests by spawning a new thread. If we allow Async IO module to create event loops on those threads, we will improve its adoption for developing web applications.

----------
components: asyncio
messages: 370257
nosy: Christian Exposito, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Allow to create new Event Loops on Threads
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri May 29 05:17:07 2020
From: report at bugs.python.org (zhang)
Date: Fri, 29 May 2020 09:17:07 +0000
Subject: [New-bugs-announce] [issue40812] _tkinter build failed when install
 Python-3.6.10
Message-ID: <1590743827.01.0.590826565689.issue40812@roundup.psfhosted.org>


New submission from zhang <zhangxq at personalbio.cn>:

building '_tkinter' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -DWITH_APPINIT=1 -I./Include -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python/Python-3.6.10/include -I. -I/usr/local/include -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Include -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10 -c /YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Modules/_tkinter.c -o build/temp.linux-x86_64-3.6/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Modules/_tkinter.o -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/tcltk/8.6.8/include/
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -DWITH_APPINIT=1 -I./Include -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python/Python-3.6.10/include -I. -I/usr/local/include -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Include -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10 -c /YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Modules/tkappinit.c -o build/temp.linux-x86_64-3.6/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Modules/tkappinit.o -I/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/tcltk/8.6.8/include/
gcc -pthread -shared build/temp.linux-x86_64-3.6/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Modules/_tkinter.o build/temp.linux-x86_64-3.6/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python-3.6.10/Modules/tkappinit.o -L/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/Python/Python-3.6.10/lib -L/usr/local/lib -o build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu.so -L/YZGROUP4/STORAGE/personalbio/Work/Transcriptome/T06/zhangxq/software/tcltk/8.6.8/lib/
warning: building with the bundled copy of libffi is deprecated on this platform.  It will not be distributed with Python 3.7
*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-3.6/_tkinter.cpython-36m-x86_64-linux-gnu.so: undefined symbol: Tcl_GetCharLength

----------
components: Build
messages: 370281
nosy: zhang
priority: normal
severity: normal
status: open
title: _tkinter build failed when install Python-3.6.10
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Fri May 29 06:08:32 2020
From: report at bugs.python.org (timofej)
Date: Fri, 29 May 2020 10:08:32 +0000
Subject: [New-bugs-announce] [issue40813] Output SyntaxError is not defective
Message-ID: <1590746912.78.0.622485430276.issue40813@roundup.psfhosted.org>


New submission from timofej <tima12332184 at gmail.com>:

a SyntaxError must be look like:

File "main.py", line 7
    print("hello world"
                      ^
SyntaxError: unexpected EOF while parsing

but instead of this i'm get this:

File "main.py", line 3

                           ^
SyntaxError: unexpected EOF while parsing

It seems to me that this problem is only in windows.

----------
components: Build
messages: 370287
nosy: timofej
priority: normal
severity: normal
status: open
title: Output SyntaxError is not defective
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Fri May 29 08:28:33 2020
From: report at bugs.python.org (=?utf-8?b?TWF0w7rFoSBWYWxv?=)
Date: Fri, 29 May 2020 12:28:33 +0000
Subject: [New-bugs-announce] [issue40814] Update typing module documentation
 based on PEP 585
Message-ID: <1590755313.42.0.558710518983.issue40814@roundup.psfhosted.org>


New submission from Mat?? Valo <matusvalo at gmail.com>:

In documentation of typing module there is no mention of new possibilities based on PEP 585. Moreover, should be old constructs like  List, Dict,... marked as deprecated?

----------
assignee: docs at python
components: Documentation
messages: 370306
nosy: Mat?? Valo, docs at python, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Update typing module documentation based on PEP 585
type: behavior
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Fri May 29 09:25:00 2020
From: report at bugs.python.org (Ben)
Date: Fri, 29 May 2020 13:25:00 +0000
Subject: [New-bugs-announce] [issue40815] Multiprocessing docs don't
 describe thread-safety
Message-ID: <1590758700.82.0.757809403714.issue40815@roundup.psfhosted.org>


New submission from Ben <benjsimner at gmail.com>:

The Multiprocessing docs specifically say that Queue is process- and thread- safe: https://docs.python.org/3/library/multiprocessing.html#exchanging-objects-between-processes.

But this information is not given for the various synchronisation primitives and such (Lock, Semaphore, Event, etc)

Are they thread-safe?  Should the docs say whether they are or are not?

----------
assignee: docs at python
components: Documentation
messages: 370310
nosy: bjs, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing docs don't describe thread-safety

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

From report at bugs.python.org  Fri May 29 10:53:13 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Fri, 29 May 2020 14:53:13 +0000
Subject: [New-bugs-announce] [issue40816] Add missed AsyncContextDecorator
 to contextlib
Message-ID: <1590763993.17.0.319482222949.issue40816@roundup.psfhosted.org>


New submission from ?????? ???????? <heckad at yandex.ru>:

I can use context manager as decorator but can't use async context manager. Seems it because didn't implemented AsyncContextDecorator class

----------
components: Library (Lib)
messages: 370317
nosy: heckad
priority: normal
severity: normal
status: open
title: Add missed AsyncContextDecorator to contextlib
versions: Python 3.9

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

From report at bugs.python.org  Fri May 29 12:02:21 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 29 May 2020 16:02:21 +0000
Subject: [New-bugs-announce] [issue40817] Document the asyncio shell
Message-ID: <1590768141.96.0.0419564634839.issue40817@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Python 3.8 introduced `python -m asyncio` to run a Python shell with asyncio support. It had a note in What's New but was not documented, I think a note in https://docs.python.org/3/library/asyncio.html should be helpful.


This could be a good issue for a new contributor.

----------
assignee: docs at python
components: Documentation
messages: 370319
nosy: docs at python, remi.lapeyre
priority: normal
severity: normal
status: open
title: Document the asyncio shell
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri May 29 12:06:44 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 29 May 2020 16:06:44 +0000
Subject: [New-bugs-announce] [issue40818] Run sys.__interactivehook__ for
 asyncio REPLs
Message-ID: <1590768404.22.0.270974343811.issue40818@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

As a nice side effect, it gives the same completion than the standard shell.

----------
components: Library (Lib)
messages: 370321
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: Run sys.__interactivehook__ for asyncio REPLs
versions: Python 3.10

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

From report at bugs.python.org  Fri May 29 12:39:31 2020
From: report at bugs.python.org (Bev)
Date: Fri, 29 May 2020 16:39:31 +0000
Subject: [New-bugs-announce] [issue40819] Idle Context Menu Copy/Cut Grayed
 Out
Message-ID: <1590770371.71.0.221082302956.issue40819@roundup.psfhosted.org>


New submission from Bev <countryone77 at gmail.com>:

In Idle on macOS, when I select text in either the Shell or a file, both copy and cut should be available in the context menu, but they are grayed out (not selectable).  Both copy and cut are still available via the menu bar Edit menu and keyboard shortcuts, <command>c and <command>x, respectively.  I tried this on macOS El Capitan 10.11.6 and Catalina 10.15.4

----------
assignee: terry.reedy
components: IDLE
files: copy and cut missinf from context menu.png
messages: 370324
nosy: BevInTX, terry.reedy
priority: normal
severity: normal
status: open
title: Idle Context Menu Copy/Cut Grayed Out
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49202/copy and cut missinf from context menu.png

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

From report at bugs.python.org  Fri May 29 14:04:01 2020
From: report at bugs.python.org (Andrius Gobis)
Date: Fri, 29 May 2020 18:04:01 +0000
Subject: [New-bugs-announce] [issue40820] Mock Call attributes args and
 kwargs have no changeversion
Message-ID: <1590775441.68.0.287476629705.issue40820@roundup.psfhosted.org>


New submission from Andrius Gobis <gobisandrius at gmail.com>:

In Python 3.8, the ``args`` and ``kwargs`` properties were added to Mock ``Call`` objects (PR: https://github.com/python/cpython/pull/11807 Issue: https://bugs.python.org/issue21269).

However, the change did not add a change version to the documentation.

The ``Doc/library/unittest.mock.rst`` file should include the following in the ``Call`` section:
```
The ``Doc/library/unittest.mock.rst`` file should include the following in the ``Call`` section:
```
   .. versionchanged:: 3.8

      Added the ``args`` and ``kwargs`` properties to more easily access the positional args and keyword args within a ``Call``        object tuple.
```

----------
assignee: docs at python
components: Documentation
messages: 370330
nosy: Andrius Gobis, docs at python
priority: normal
severity: normal
status: open
title: Mock Call attributes args and kwargs have no changeversion
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri May 29 16:31:30 2020
From: report at bugs.python.org (Manickaraja Kumarappan)
Date: Fri, 29 May 2020 20:31:30 +0000
Subject: [New-bugs-announce] [issue40821] os.getlogin() not working
Message-ID: <1590784290.42.0.113469889536.issue40821@roundup.psfhosted.org>


New submission from Manickaraja Kumarappan <manickarajak at gmail.com>:

Hi,
We are using below command to get the original login user. In some cases folks sudo as different user and run commands. In some cases folks use switch to different user (su - <>) and then run command. In all cases we would like to get original user who logged into the terminal to run the command. We are using below command to get the same.

user=os.getlogin()

We got three RHEL linux systems with Python 3 and strangely on two of them this command works fine. However only on third system it is failing with below error

OSError: [Errno 6] No such device or address

Not sure if it is some o/s env setup which is causing this command to fail. Any pointers to run this command will be of great help so that we can pin point the issue.

Please note on faiing system if I do python and then run the command it works fine without any issue. However if it is triggered through our Scheduler (Control M) it is failing with above message.

Give below is the command how Scheduler triggers the job.

/bin/su - edwadm -c /bin/sh -x <>

Thanks
Manick.

----------
components: Extension Modules
messages: 370336
nosy: Manickaraja Kumarappan
priority: normal
severity: normal
status: open
title: os.getlogin() not working
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sat May 30 05:01:45 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 30 May 2020 09:01:45 +0000
Subject: [New-bugs-announce] [issue40822] Drop support for SQLite 3.7.15
Message-ID: <1590829305.32.0.448529686599.issue40822@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Ref. bpo-40810 and GH-20330

----------
components: Library (Lib)
messages: 370367
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Drop support for SQLite 3.7.15
versions: Python 3.10

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

From report at bugs.python.org  Sat May 30 07:35:53 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sat, 30 May 2020 11:35:53 +0000
Subject: [New-bugs-announce] [issue40823] Don't use obsolete
 unittest.makeSuite() in sqlite3 tests
Message-ID: <1590838553.12.0.97963003429.issue40823@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

Use `loadTestsFromTestCase()` iso. `makeSuite()` in sqlite3 tests. Implies changing the prefix for all test methods.

Ref. bpo-5846

----------
components: Tests
messages: 370371
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Don't use obsolete unittest.makeSuite() in sqlite3 tests
versions: Python 3.10

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

From report at bugs.python.org  Sat May 30 07:36:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 May 2020 11:36:12 +0000
Subject: [New-bugs-announce] [issue40824] Unexpected errors in __iter__ are
 masked in "in" and the operator module
Message-ID: <1590838572.36.0.635736065326.issue40824@roundup.psfhosted.org>


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

All errors raised in the __iter__ method are masked by the TypeError exception in the "in" operator and functions operator.contains(), operator.indexOf() and operator.countOf().

>>> class BadIterable:
...     def __iter__(self):
...         1/0
... 
>>> 
>>> 1 in BadIterable()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'BadIterable' is not iterable

It includes exceptions out of control of the programmer like MemoryError and KeyboardInterrupt. Converting them to TypeError can lead to weird errors or incorrect results.

See also similar issue26407.

----------
components: Interpreter Core
messages: 370372
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Unexpected errors in __iter__ are masked in "in" and the operator module
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 30 08:31:33 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 30 May 2020 12:31:33 +0000
Subject: [New-bugs-announce] [issue40825] Add a "strict" parameter to
 csv.writer and csv.DictWriter
Message-ID: <1590841893.39.0.979050889653.issue40825@roundup.psfhosted.org>


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

Currently, the csv library calls str() on each value it writes. This can lead to surprising behavior, see issue40762 for example.

On the other hand, for writing the documentation says that the values must be strings or numbers.

The proposed "strict" argument would raise a TypeError if the supplied values are not strings, numbers, or None.

See https://github.com/python/cpython/blob/ba1c2c85b39fbcb31584c20f8a63fb87f9cb9c02/Modules/_csv.c#L1203 for where str() is called.

The documentation should be changed to note that None is allowed. Currently, None results in an empty string. I'm not proposing to change this, just document it as one of the allowed types.

How to check for "value is a number" needs to be decided.

----------
messages: 370380
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Add a "strict" parameter to csv.writer and csv.DictWriter
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sat May 30 10:19:46 2020
From: report at bugs.python.org (Jelle Zijlstra)
Date: Sat, 30 May 2020 14:19:46 +0000
Subject: [New-bugs-announce] [issue40826] Segfaults on io.FileIO(0).name in
 3.9
Message-ID: <1590848386.77.0.354375723351.issue40826@roundup.psfhosted.org>


New submission from Jelle Zijlstra <jelle.zijlstra at gmail.com>:

$ gdb ./python 
...
(gdb) r
...
Python 3.9.0b1 (tags/v3.9.0b1:97fe9cfd9f8, May 30 2020, 05:26:48) 
...
>>> import io
>>> io.FileIO(0).name
0
>>> 
Program received signal SIGSEGV, Segmentation fault.
_PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:100
100         return tstate->interp;
(gdb) bt
#0  _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:100
#1  PyOS_InterruptOccurred () at ./Modules/signalmodule.c:1785
#2  0x0000000000673905 in my_fgets (buf=buf at entry=0xa40780 "8LJ\367\377\177", len=len at entry=100, fp=fp at entry=0x7ffff74a48e0 <_IO_2_1_stdin_>) at Parser/myreadline.c:87
#3  0x000000000067397b in PyOS_StdioReadline (sys_stdin=sys_stdin at entry=0x7ffff74a48e0 <_IO_2_1_stdin_>, sys_stdout=sys_stdout at entry=0x7ffff74a5620 <_IO_2_1_stdout_>, 
    prompt=prompt at entry=0x7ffff6f8d8e0 ">>> ") at Parser/myreadline.c:269
#4  0x0000000000673b4f in PyOS_Readline (sys_stdin=0x7ffff74a48e0 <_IO_2_1_stdin_>, sys_stdout=0x7ffff74a5620 <_IO_2_1_stdout_>, prompt=0x7ffff6f8d8e0 ">>> ") at Parser/myreadline.c:355
#5  0x00000000005d90d9 in tok_nextc (tok=0xa3fd30) at Parser/tokenizer.c:856
#6  0x00000000005dad02 in tok_get (tok=tok at entry=0xa3fd30, p_start=p_start at entry=0x7fffffffd508, p_end=p_end at entry=0x7fffffffd510) at Parser/tokenizer.c:1194
#7  0x00000000005dcb69 in PyTokenizer_Get (tok=0xa3fd30, p_start=p_start at entry=0x7fffffffd508, p_end=p_end at entry=0x7fffffffd510) at Parser/tokenizer.c:1842
#8  0x0000000000653c73 in _PyPegen_fill_token (p=0x7ffff6f8f540) at Parser/pegen/pegen.c:551
#9  0x0000000000670355 in statement_newline_rule (p=0x7ffff6f8f540) at Parser/pegen/parse.c:1143
#10 interactive_rule (p=0x7ffff6f8f540) at Parser/pegen/parse.c:725
#11 _PyPegen_parse (p=p at entry=0x7ffff6f8f540) at Parser/pegen/parse.c:19388
#12 0x0000000000654b32 in _PyPegen_run_parser (p=0x7ffff6f8f540) at Parser/pegen/pegen.c:1037
#13 0x0000000000654e4c in _PyPegen_run_parser_from_file_pointer (fp=fp at entry=0x70f74a48e0, start_rule=start_rule at entry=80, filename_ob=filename_ob at entry=0x7ffff6f84eb0, 
    enc=enc at entry=0x7ffff704ec60 "utf-8", ps1=ps1 at entry=0x7ffff6f8d8e0 ">>> ", ps2=ps2 at entry=0x90000000d0 <error: Cannot access memory at address 0x90000000d0>, flags=0x7fffffffd7b8, 
    errcode=0x7fffffffd6e4, arena=0x7ffff6ff6b30) at Parser/pegen/pegen.c:1097
#14 0x00000000005d6bea in PyPegen_ASTFromFileObject (fp=0x70f74a48e0, fp at entry=0x7ffff74a48e0 <_IO_2_1_stdin_>, filename_ob=filename_ob at entry=0x7ffff6f84eb0, mode=80, mode at entry=256, 
    enc=enc at entry=0x7ffff704ec60 "utf-8", ps1=ps1 at entry=0x7ffff6f8d8e0 ">>> ", ps2=0x90000000d0 <error: Cannot access memory at address 0x90000000d0>, ps2 at entry=0x7ffff6f8dbe0 "... ", 
    flags=<optimized out>, errcode=<optimized out>, arena=<optimized out>) at Parser/pegen/peg_api.c:52
#15 0x00000000005460d9 in PyRun_InteractiveOneObjectEx (fp=fp at entry=0x7ffff74a48e0 <_IO_2_1_stdin_>, filename=filename at entry=0x7ffff6f84eb0, flags=flags at entry=0x7fffffffd7b8) at Python/pythonrun.c:243
#16 0x000000000054631e in PyRun_InteractiveLoopFlags (fp=fp at entry=0x7ffff74a48e0 <_IO_2_1_stdin_>, filename_str=filename_str at entry=0x673e32 "<stdin>", flags=flags at entry=0x7fffffffd7b8)
    at Python/pythonrun.c:122
#17 0x0000000000546d4c in PyRun_AnyFileExFlags (fp=0x7ffff74a48e0 <_IO_2_1_stdin_>, filename=0x673e32 "<stdin>", closeit=0, flags=0x7fffffffd7b8) at Python/pythonrun.c:81
#18 0x0000000000429fb7 in pymain_run_stdin (cf=0x7fffffffd7b8, config=0x9bd800) at Modules/main.c:467
#19 pymain_run_python (exitcode=0x7fffffffd7b0) at Modules/main.c:556
#20 Py_RunMain () at Modules/main.c:632
#21 0x000000000042a2d6 in pymain_main (args=0x7fffffffd8a0) at Modules/main.c:662
#22 Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:686
#23 0x00007ffff7100830 in __libc_start_main (main=0x41ef30 <main>, argc=1, argv=0x7fffffffd9f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd9e8)
    at ../csu/libc-start.c:291
#24 0x0000000000429089 in _start ()
(gdb) 


Same happens with Python 3.9.0b1+ (heads/3.9:588efc29c5d, May 30 2020, 14:16:10) (current HEAD of the 3.9 branch).

In previous versions of Python this would exit the interpreter but not segfault.

----------
keywords: 3.9regression
messages: 370386
nosy: Jelle Zijlstra, benjamin.peterson, stutzbach
priority: normal
severity: normal
status: open
title: Segfaults on io.FileIO(0).name in 3.9
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May 30 12:31:07 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 30 May 2020 16:31:07 +0000
Subject: [New-bugs-announce] [issue40827] os.readlink should support getting
 the target's printname in Windows
Message-ID: <1590856267.7.0.74543194815.issue40827@roundup.psfhosted.org>


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

As discussed in issue 40654, os.readlink should provide a way to get the print name of a symlink target. This is the target path that was actually passed to WinAPI CreateSymbolicLinkW (except for drive-relative paths) and is what a shell would display as the link target (e.g. CMD's "dir" command). Perhaps a keyword-only parameter could be supported to query the print name, e.g. readlink(path, printname=True). In POSIX, passing printname=True would make no difference, since a POSIX symlink only has a substitute name.

----------
components: Library (Lib), Windows
messages: 370389
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: os.readlink should support getting the target's printname in Windows
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat May 30 13:57:21 2020
From: report at bugs.python.org (trapezoid677)
Date: Sat, 30 May 2020 17:57:21 +0000
Subject: [New-bugs-announce] [issue40828] shared memory problems with
 multiprocessing.Pool
Message-ID: <1590861441.57.0.917224278177.issue40828@roundup.psfhosted.org>


New submission from trapezoid677 <hieronymi at web.de>:

Under Linux, the resource_tracker throws warnings about not released memory blocks after the programs has finished and when used together with multiprocessing.Pool. This depends on the sequence of initialization of the shared memory block and the multiprocessing pool. In addition, .close() on the shared memory block generates a segmentation fault in the example code. 

Under MS Windows, the shared memory block holds arbitrary values when being read in the worker routines, but no warnings are thrown and no segmentation fault occurs when closing the memory block.

----------
components: Library (Lib)
files: shared_memory.py
messages: 370396
nosy: trapezoid677
priority: normal
severity: normal
status: open
title: shared memory problems with multiprocessing.Pool
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49203/shared_memory.py

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

From report at bugs.python.org  Sat May 30 14:23:57 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 30 May 2020 18:23:57 +0000
Subject: [New-bugs-announce] [issue40829] Add a what's new entry about
 deprecation of random.shuffle
Message-ID: <1590863037.59.0.754503500546.issue40829@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

random.shuffle deprecated with bpo-40465 but a what's news entry didn't exist about it.

----------
assignee: docs at python
components: Documentation
messages: 370397
nosy: BTaskaya, docs at python
priority: normal
severity: normal
status: open
title: Add a what's new entry about deprecation of random.shuffle
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat May 30 16:07:09 2020
From: report at bugs.python.org (Kodiologist)
Date: Sat, 30 May 2020 20:07:09 +0000
Subject: [New-bugs-announce] [issue40830] Certain uses of dictionary
 unpacking raise TypeError
Message-ID: <1590869229.29.0.66661660878.issue40830@roundup.psfhosted.org>


New submission from Kodiologist <nonce0010lep at arfer.net>:

On Python 3.8.2, the below program runs without errors. On Python 3.9.0b1, it raises "TypeError: 'tuple' object is not callable" for the last line.

d1 = {'a': 1}
d2 = {'c': 3}
def fun(a, b, c):
    return a, b, c
print(fun(**d1, b='b', **d2))

----------
messages: 370400
nosy: Kodiologist
priority: normal
severity: normal
status: open
title: Certain uses of dictionary unpacking raise TypeError
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Sun May 31 01:40:41 2020
From: report at bugs.python.org (Eric L.)
Date: Sun, 31 May 2020 05:40:41 +0000
Subject: [New-bugs-announce] [issue40831] Wrong statement that bytes paths
 are deprecated under Windows regarding MAX_PATH docs
Message-ID: <1590903641.69.0.63227467071.issue40831@roundup.psfhosted.org>


New submission from Eric L. <ewl+python at lavar.de>:

In chapter 3.1.2. Removing the MAX_PATH Limitation of https://docs.python.org/3/using/windows.html#removing-the-max-path-limitation (also in 3.9 and 3.10), it is written that "(Use of bytes as paths is deprecated on Windows, and this feature is not available when using bytes.)" but my understanding is that since 3.8 bytes paths are _not_ deprecated any more under Windows (and it is good so!), which makes unclear if the feature is still not available with bytes paths. In which case, it should be implemented.

I'm sorry I couldn't test if it actually works or not but I'm stuck with Python 3.7 where I guess the statement is still correct, but I hope to see the issue fixed once I can upgrade :-)

----------
components: Windows
messages: 370414
nosy: ericzolf, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Wrong statement that bytes paths are deprecated under Windows regarding MAX_PATH docs
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May 31 03:16:01 2020
From: report at bugs.python.org (Vikash Raja Samuel Selvin)
Date: Sun, 31 May 2020 07:16:01 +0000
Subject: [New-bugs-announce] [issue40832] hi param in bisect module should
 not accept negative values
Message-ID: <1590909361.92.0.18411743492.issue40832@roundup.psfhosted.org>


New submission from Vikash Raja Samuel Selvin <selvin.samuel2 at gmail.com>:

>>> bisect.bisect_right(l, 5.1, -1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: lo must be non-negative

>>> l
[0, 1, 2, 3, 4, 5, 5, 5, 6, 7, 8, 9]

>>> bisect.bisect_right(l, 5.1, 0, -2)
0

In order to be consistent with the behavior for lo and not return  wrong answers when hi is provided with a negative value

----------
components: Library (Lib)
messages: 370416
nosy: samuel72
priority: normal
severity: normal
status: open
title: hi param in bisect module should not accept negative values
type: behavior

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

From report at bugs.python.org  Sun May 31 09:50:48 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 31 May 2020 13:50:48 +0000
Subject: [New-bugs-announce] [issue40833] Clarify docstring of Path.rename
Message-ID: <1590933048.45.0.441602956173.issue40833@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

Writing the PR now.

----------
assignee: docs at python
components: Documentation
messages: 370459
nosy: brandtbucher, cool-RR, docs at python
priority: normal
severity: normal
status: open
title: Clarify docstring of Path.rename
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May 31 11:45:42 2020
From: report at bugs.python.org (AnLong)
Date: Sun, 31 May 2020 15:45:42 +0000
Subject: [New-bugs-announce] [issue40834] sending str via channel caused
 truncate on last character
Message-ID: <1590939942.99.0.486356064631.issue40834@roundup.psfhosted.org>


New submission from AnLong <aisk1988 at gmail.com>:

Sending a str object for example "asdf" via channel, the received str object turn into "asd".

The attachment file test.py can re-produce this issue, with python3.8 and 3.9a1.

----------
components: Subinterpreters
files: test.py
messages: 370487
nosy: asaka
priority: normal
severity: normal
status: open
title: sending str via channel caused truncate on last character
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49204/test.py

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

From report at bugs.python.org  Sun May 31 16:56:52 2020
From: report at bugs.python.org (Doug Addy)
Date: Sun, 31 May 2020 20:56:52 +0000
Subject: [New-bugs-announce] [issue40835] Incorrect handling for msgctxt in
 msgfmt.py
Message-ID: <1590958612.57.0.0461215305569.issue40835@roundup.psfhosted.org>


New submission from Doug Addy <da1910 at protonmail.com>:

Running msgfmt.py with the attached po file will produce an incorrect context for the entry "test".

Looking at the script, we require a comment to follow a contexted section for the context to be cleared. The gettext documentation makes clear that all comments are optional, so this is not desired behaviour.

My reading of the gettext documentation has a "msgctxt" line applying only to the current entry, so it should be cleared once the last msgstr has been written for that entry.

I will endeavour to provide a patch within the next day or two.

----------
components: Demos and Tools
messages: 370502
nosy: da1910
priority: normal
severity: normal
status: open
title: Incorrect handling for msgctxt in msgfmt.py
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun May 31 20:39:39 2020
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 01 Jun 2020 00:39:39 +0000
Subject: [New-bugs-announce] [issue40836] logging.fatal() and
 logging.Logger.fatal() should raise a DeprecationWarning
Message-ID: <1590971979.28.0.133253133772.issue40836@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Both are not documented and synonymous for critical() but don't raise a DeprecationWarning.

----------
components: Library (Lib)
messages: 370522
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: logging.fatal() and logging.Logger.fatal() should raise a DeprecationWarning
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun May 31 22:17:06 2020
From: report at bugs.python.org (SpaceOne)
Date: Mon, 01 Jun 2020 02:17:06 +0000
Subject: [New-bugs-announce] [issue40837] email.utils.encode_rfc2231(string,
 None, None) returns broken value
Message-ID: <1590977826.25.0.0895335032044.issue40837@roundup.psfhosted.org>


New submission from SpaceOne <python at florianbest.de>:

`encode_rfc2231()` must not change the returned value if no transformation of the input was done.
This is also mentioned in the docstring of that function.

Actual behavior:
encode_rfc2231('foo bar', None, None)
'foo%20bar'

Expected behavior:
encode_rfc2231('foo bar', None, None)
'foo bar'

----------
components: Library (Lib)
messages: 370526
nosy: spaceone
priority: normal
pull_requests: 19805
severity: normal
status: open
title: email.utils.encode_rfc2231(string, None, None) returns broken value
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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